Nån som vet hur man kan sätta 1:a hands cookies fastän man inte äger domänen? Dvs som Google Analytics gör. Det behövs någon slags javascript library för att kunna skriva/läsa cookies på valfri domän. Jag har sökt, men inte hittat något...

Lösningen finns iofs gömd här: http://www.google-analytics.com/urchin.js :) Men min hjärna pallar inte just nu.

Dvs. om du stoppar in en länk till ovanstående sida på din egen hemsida så kan google sätta och läsa förstahands kakor. Dessa kakor är svåra att blockera. Så om man exempelvis har ett tracking-system (som Google Analytics) så är det en bra teknik att använda sig av då mätningarna blir mer korrekta.

Om det är någon som vet hur de bär sig åt - skriv här eller PM:a. Jag vill veta främst av nyfikenhet.

ps. kom inte och säg att det är omöjligt att sätta 1:a handskakor på detta sätt. Det är möjligt. Läs mer här http://www.webmasternetwork.se/f3t10841hl-st75.html

Det Analytics gör, är att du inkluderar ett javascript bibliotek typ... Sen körs ju scriptet på domänen...

Eftersom webläsaren inte fattar att du inkluderat ett script från en annan domän, så antar den att du vet vad du gör med javascriptet och tolkar det som om att det är du som "äger" det...

Då har scriptet fulla rättigheter på den domänen...

Analytics sätter ju bara en vanlig kaka på domänen... Hur lätt som helst...

Därav att man ser detta så ofta i cut'n'paste script för olika tjänster.

Det jag undrar är alltså hur Google Analytics gör när de sätter cookies. Och så vitt jag förstår inkluderar de ett JavaScript som sätter 1:a hands cookies. Det går väl inte att göra på servern?

På vilket sätt är detta fusk? Det enda som går att invända är väl att det hela skapas av javascript och de som har detta avstängt får ingen cookie - å andra sidan får ju de som helt har cookies avstängda inte heller cookies som skickade server-side.

Jag förstår inte riktigt din terminologi. Vad menar du med "skapas i webbläsaren"?

Menar du att Google Analytics kakor inte är 1:a hands kakor, eftersom de sätts av Google och inte av orginalsidan?

Jag trodde att det som var så speciellt med Google Analytics var att de fick det att se ut som 1:a handskakor. Och att deras statistik genom detta blir mer träffsäker?

Jag förstår vad du menar. Men i praktiken är det viktigaste att få så bra mätresultat som möjligt. Och då har det inte någon betydelse om det är riktiga 1:a parts server-side kakor eller 1:a parts "fusk" kakor. Effekten blir densamma. Och ur ett praktist perspektiv måste du väl hålla med om att det är mycket lättare att använda Google Analytics system där man endast klistrar in lite javascript på sin hemsida, jämfört med att ändra i sin php/asp/... kod?

Är det inte snarare så att det är många mätsystem som inte klarar av att sätta 1:a parts cookies överhuvudtaget? Det måste väl isåfall anses vara ett större problem, då mätresultaten inte blir lika tillförlitliga?

En nackdel med att använda 1:a parts "fusk" kakor är om man har ett system som använder sig av ett shoppingsystem som levereras via en annan domän. Då kan mätresultaten bli felaktiga. Detta tror jag inte är ett problem om man använder sig av äkta 1:a hands kakor. Jag läste om denna problematik i en blogg som jag följer:

http://cutroni.com/blog/2006/06/25/h...party-domains/

Fulton: Kanske någonting som är värt att nämna i en kommande artikel? ;)

Är det inte bättre att kalla det för äkta och falska 1:a hands kakor? Eller är "fusk" kakor en benämning som många "i branschen" redan använder?

Fusk låter oärligt - och det tycker jag inte att det är. Det är bara en annan metod.

Tekniskt sett är de 1:a part (håller du inte med får du väl diskutera det med Microsoft m.fl. som anser att dylika cookies är just 1:a part). Sedan kan man väl diskutera om de i praktiken är 1:a part. Det finns dock ingen anledning att kalla det fusk annat än för att misskreditera de som väljer att använda tekniken (såsom Blackex påpekar).

Cookien "sänds" av webbplatsen, precis som en cookie som sätts av ASP/PHP/etc. Det finns ingen reell teknisk skillnad annat än att cookien skickas som en header istället för javascript-kod vid ASP/PHP/etc. Javascript-koden exekveras på klienten men det vore ju galet att påstå att klienten sänder ut cookien. Att klienten skapar cookien är ju rätt uppenbart då så alltid är fallet, eftersom den endast mottar en instruktion från webbplatsen som besöks (som den sedan kan göra vad den vill med).

Jag ser med få undantag inte på TV och kan därför inte kommentera jämförelsen med reklamfilm.

Jo, den enda skillnaden mellan "räknare" som använder det Fulton kallar 1:a-hands-cookies och det som används av bl.a. Google Analytics (GA) är att GA kräver Javascript för att klienten ska få sin cookie.

Vill man inte missa att ge cookies till de som inte använder Javascript, ja då får man väl förlita sig på det system som Fulton säljer, som bygger på att man pekar om en subdomän mot deras servrar för att kunna låta den sätta vad Fulton kallar en "äkta 1:a-hands-cookie". Men jag tycker, nu precis som i den diskussion som Fulton och jag haft i en tidigare tråd, att GA-sättet att skapa en cookie på är en "1:a-hands-cookie", och det tycker uppenbarligen webbläsarens säkerhetsinställningar också.

Jag tycker att Javascript-lösningen är tillräckligt bra för mig.

Jo, jag vet hur man skapar en cookie, både server-side och med Javascript.

Men vi diskuterar väl möjligheten att använda cookies för t.ex. besöksstatistik på annan server än den som sidan visas från. Den lösning som de "gamla" statistiktäjnsterna provade var ju att sätta cookien med hjälp av en bild som laddades från den andra servern. Det kallas numera 3-parts-cookie, av de spärras oftast per default i webbläsare numera. GA:s alternativ, då man använder Javascript för att sätta en cookie från den sida där besöken ska räknas, även om statistiken sammanställs av Google, tycker jag är bra. Det är enklare än att upplåta en subdomän att peka om, som ni gör i ert system. Skillnaden är att med GA missar man att sätta cookie på de besökare som inte har Javascript aktiverat.

Åter till ursprungfrågan: För att ge exemepl på kod som kan laddas från tredje-part, men som sätter en cookie från den "besöksräknanade" sidan, så kan i princip vilket exempel som helst användas. jag har lite kod på frisim.com/sokajax.js (i funktionerna GetCookie och SetCookie) som du kan använda, men det finns säkert finare exempel om du googlar på [Javascript set cookie].

Jag tänkte mig det hela ett steg längre egentligen. Jag vet också hur man sätter och läser kakor med javascript och på servern. Men här handlar det om att förmedla vidare förstahandskakan till tredje part, dvs google. De läser alltså av kakan med javascript och skickar informationen vidare till sig själva. Det finns säkerligen en hel del problematik i detta, därav har de (google) krypterat sin javascript kod. om det bara hade varit get/setcookie kod så hade den nog inte varit så hemlig.

Så min fråga är egentligen vilken problematik som uppstår när man läser och skriver "falska" kakor på detta sätt.

Google skickar tillbaka den information de vill lagra, efter det att de läst/skrivit cookien hos klienten genom att läsa en liten (1x1 pixels) bild från deras egen server. De läser denna bild: http://www.google-analytics.com/__utm.gif. I anropet till den kan du skicka med den information du vill ha till din tredje-parts-server.

Ahh... det borde jag ha sett! Nu när du sa det så var det ganska så uppenbart :)

P3P är som sagt en skillnad, i alla fall om man kör IE6...

Om servern skickar en P3P header så får den inverkan på alla kakor. Både de äkta 1:a parts kakorna och de "falska". Och jag kan hålla med om att det kan bli lite konstigt. Den som sätter en P3P header kanske inte borde kunna uttala sig om de falska kakorna.

Jag tror dock att detta i praktiken inte har så stor betydelse. P3P headers används väl normalt endast när man vill sätta 3:e parts kakor? Och fungerar endast på IE6 och IE7.

Men om jag skall återgå lite mer till ämnet så är det väl så att det i slutändan är en fördel med att använda sig av JavaScript för att sätta kakorna. På detta sätt kan man verifiera att det är en riktig besökare man räknar - och behöver inte oroa sig för alla robotar som är ute och surfar. Det borde i slutändan göra resultatet mer korrekt. Visst, många har stängt av JavaScript, men den delen av användare är nog minimal.

Hellre att resultatet visar att besökarna är lite färre än vad det egentligen är, än tvärtom.

Min erfarenhet är att det finns hundratals robotar som endast accessar några sidor då och då. Dessa robotar är svåra att identifiera som robotar. Och har man ett analyssystem som inte kan skilja på dessa robotar och vanliga besökare så visar oftast resultatet att man har flera besökare än man egentligen har...

Använt rätt så är det alltså ett plus att involvera JavaScript vid mätningar.

Jag tycker att det är bättre att räkna för få än att räkna för många. Glädjekalkyler har jag ingen nytta av.

Visst, det finns robotar som kan köra JavaScript. Men dem är inte många, och med lite logik kan man filtrera bort dem enkelt. Som Google Adsense gör. Den enda roboten som kan exekvera JavaScript, som jag känner till, är Googles egen robot. Och den kollar nog inte ens i externa javascript filer. Känner du till flera robotar som klarar av JavaScript?

Därför tror jag att ett system som är lite smart byggt i JavaScript kan garantera att det är en riktig besökare och inte en robot. Men det är klart att det krävs mer än kakor för att verifiera att det är en besökare.