[nicclas]

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.

[nicclas]

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].

[Blackex]

Originally posted by nicclas@Jun 29 2006, 12:58
Å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.

[nicclas]

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.

[Blackex]

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

[jimmie]

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

[Blackex]

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.

[Blackex]

Originally posted by Fulton@Jul 5 2006, 00:36
Ledsen, men att säga att en Javascript skapad cookie är en garanti på en "riktig besökare" är fel. Om man räknar ut antalet besökare som har Javascript avstängt så betyder det ett mindre antal besökare om inte cookien kommer från servern. Med en servercookie så blir det rätt. Det finns robotar som kan köra Javascript varför logik krävs hos datainsamlaren att filtrera dessa.

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.