Cookiewet en Google Tracking en Referer

[Anoniem: 310225]

Hey Tweakers,

Voor 1 van mijn klanten heb ik recent een opt-in ingebouwd t.h.v. de cookiewet.

Wat ik die is direct bij binnenkomst kijk ik met javascript/jquery of er een cookie gezet is dat ze akkoord zijn met de cookiewet/opt-in. Wanneer dit niet het geval is stuur ik ze daar naar een cookie akkoord/info pagina.
Dit doe ik met window.location =..
In de URL geef ik dan als parameter de retour-url mee, dus wanneer men akkoord is met de cookies zet ik een cookie dat ze akkoord zijn (zodat ze niet opnieuw naar de akkoord/info pagina gaan) en stuur ik ze weer "terug" naar de pagina waarop ze binnen kwamen.

Ditmaal komen ze de pagina dus binnen met de cookie dat ze akkoord zijn en worden dus niet direct doorgelust. Dus dit keer worden ook de Google Analyics bestanden e.d. ingeladen.

Echter heeft deze klant adwords campagnes en geeft aan dat Google Organic Seach etc niet meer werken omdat de referer nu steeds de cookiepagina is...

Heeft iemand een idee hoe ik de referer kan "spoofen" of op een andere manier toch door kan geven aan Google?

Alvast bedankt!

[Tsjilp]

Waarom stuur je ze naar een andere pagina? Je kan die vraag toch prima met js stellen, en als de gebruiker op ja klikt de nodige scripts inladen? Op die manier houd je je referer in tact.

[Megamind]

Je kan beter een popup maken welke om toestemming vraagt, doen hoef je ook niet te redirecten.

[mauricedb]

Ik weet er niet heel veel vanaf hoor, maar wellicht een idee om met uitsluitingen te werken? Dat bepaalde user-agents/ip's niet doorverwezen worden naar de cookie pagina en dus gewoon direct naar de juiste link gaan.

[Bosmonster]

Tsjilp schreef op maandag 18 februari 2013 @ 09:38:
Waarom stuur je ze naar een andere pagina? Je kan die vraag toch prima met js stellen, en als de gebruiker op ja klikt de nodige scripts inladen? Op die manier houd je je referer in tact.

Omdat dat het hele idee van de makkelijk te implementeren cookie-muur om zeep helpt. Daarmee hoef je juist niet je hele site aan te passen en afhankelijk van je keuzes wel/geen cookies in te laden. Want dat is best een lastige klus met een CMS- of community-driven website waar gebruikers ook externe content in kunnen hangen. (daarom hebben sites als T.NET of Fok een cookiemuur).

mauricedb schreef op maandag 18 februari 2013 @ 10:51:
Ik weet er niet heel veel vanaf hoor, maar wellicht een idee om met uitsluitingen te werken? Dat bepaalde user-agents/ip's niet doorverwezen worden naar de cookie pagina en dus gewoon direct naar de juiste link gaan.

De redirect wil je alleen doen voor normale gebruikers. Voor zoekmachines wil je die hele cookiemuur overslaan.

Maar dat neemt niet weg dat de referrer's niet opgeslagen worden voor advertenties bij derden en dus niet goed geregistreerd worden.

Al met al is een cookiemuur volgens mij niet echt een optie als je referrer's consequent wilt meten. Daarom halen veel sites (Persgroep) ze nu zo snel mogelijk weer weg nu er onduidelijkheid heerst over de noodzaak.

[ Voor 16% gewijzigd door Bosmonster op 18-02-2013 11:21 ]

[Tsjilp]

Omdat dat het hele idee van de makkelijk te implementeren cookie-muur om zeep helpt. Daarmee hoef je juist niet je hele site aan te passen en afhankelijk van je keuzes wel/geen cookies in te laden. Want dat is best een lastige klus met een CMS- of community-driven website waar gebruikers ook externe content in kunnen hangen. (daarom hebben sites als T.NET of Fok een cookiemuur).

Je zult linksom of rechtsom je site moeten aanpassen, omdat je nu standaard cookies accepteert. Dus ik zie de hoeveelheid meerwerk niet echt.

Wijzelf gebruiken een (eigen) script wat we extern inladen welke checked of cookies geaccepteerd worden, zo ja: laad scripts in; zo nee: toon popup met keuzes. Redirect is nergens voor nodig.

[GlowMouse]

Je kunt bij al die redirects telkens de originele referer apart meesturen (als GET parameter bijvoorbeeld), en dan via _setReferrerOverride aan Google Analytics voeren.

zie https://developers.google...ker_._setReferrerOverride

[André]

GlowMouse schreef op dinsdag 19 februari 2013 @ 12:09:
Je kunt bij al die redirects telkens de originele referer apart meesturen (als GET parameter bijvoorbeeld), en dan via _setReferrerOverride aan Google Analytics voeren.

zie https://developers.google...ker_._setReferrerOverride

Dat is inderdaad een prima methode, maar je mist dan nog wel de andere manier waarop mensen binnen kunnen komen: zonder referrer maar met campagne tags of de Google AdWords autocodering.

Ik zou bij binnenkomst de referral, campagne tags (utm_source, enz) en de autocodering (gclid=) opslaan. En als men dan de cookies accepteert redirecten naar de betreffende pagina, daar de campagne codes of autocodering weer in de URL plaatsen en de referrer met setReferrerOverride aangeven. Dan zou je een complete meting moeten hebben.

Voordeel is dat wanneer mensen pas later in het bezoek accepteren je alsnog de juiste bron aan Google Analytics kunt voeren.

[ Voor 6% gewijzigd door André op 19-02-2013 12:42 ]

[Bosmonster]

Tsjilp schreef op dinsdag 19 februari 2013 @ 12:03:
[...]


Je zult linksom of rechtsom je site moeten aanpassen, omdat je nu standaard cookies accepteert. Dus ik zie de hoeveelheid meerwerk niet echt.

Wijzelf gebruiken een (eigen) script wat we extern inladen welke checked of cookies geaccepteerd worden, zo ja: laad scripts in; zo nee: toon popup met keuzes. Redirect is nergens voor nodig.

Je snapt het idee achter de cookiemuur niet. Daarmee hoef je dus niks aan te passen op je site. Je redirect (vanuit de server!) naar een pagina die geen cookies zet met alleen melding dat je cookies moet accepteren om naar de site te gaan. Meer mogelijkheden heb je niet (zoals het niet accepteren, dan kun je simpelweg de site niet bezoeken, vandaar de muur).

Jouw methode die je beschrijft werkt met kleine scripts in een gecontroleerde omgeving, maar is praktisch ondoenlijk in een grotere site waar gebruikers/bezoekers zelf vanalles kunnen plaatsen. Een simpele afbeelding van een ander domein kan namelijk al een cookie zetten. Om over dingen als YouTube embedding bijvoorbeeld maar niet te beginnen. Het gaat dus wat verder dan wat conditioneel scripts inladen.

[EnnaN]

Los van wie hier cookiemuur snapt: je kunt jouw "snel klaar idee" ook prima doen zonder een redirect. Het probleem is dat je via een andere url gaat. Als je alles met javascript afhandeld in je template, voor je de body van je site laadt, dan heb je geen rare redirects nodig

Je template gaat nu dus niet zeggen "if geen toestemming, ga naar pagina", maar "if geen toestemming, toon cookiepopup (en nog niets anders)". Geen grote veranderingen, wel probleem weg.

(heb je er trouwens over nagedacht wat dit hele systeem met je (google) indexering doet?)

[Bosmonster]

Ik heb het systeem van de cookiemuur niet bedacht he. De eerste die ermee kwam was Fok, als ik me niet vergis en er volgden als snel vele andere sites met dezelfde methodiek, zoals Persgroep (o.a. Tweakers.net).

Met Javascript is over het algemeen geen oplossing, omdat je dan dus al niet meer kunt garanderen dat die pagina geen cookies zet. Jij zegt "doe dat met javascript voor de body is geladen", maar daar heb je helemaal geen controle over. Je moet de melding vanuit de server geven via een pagina die gegarandeerd geen cookies zet. Bovendien moet je er rekening mee houden dat bezoeker op alle mogelijke pagina's van je site binnen kunnen komen.

Ik leg alleen uit hoe en waarom er door grote (community-driven) websites vaak wordt gekozen voor de muur. Het is een relatief goedkope en zekere manier om aan de wetgeving te voldoen.

Dat er bepaalde nadelen aankleven is inmiddels ook wel duidelijk, maar het is dus een afweging die je moet maken. Wat betreft Google indexing maakt het niet uit overigens. Doordat je het vanuit de server regelt kun je spiders eenvoudig wel doorlaten.

[ Voor 39% gewijzigd door Bosmonster op 26-02-2013 11:51 ]

[EnnaN]

Sorry hoor, maar dat is gewoon niet waar. Je haalt met "methodiek" 2 dingen door elkaar. Functionaliteit (laad niets tot 'ok') en implementatie (hoe doe je dat).

Tuurlijk kun je wel garanderen dat een pagina geen cookies zet. Als je geen javascript wil gebruiken is dat prima. Daar gaat het namelijkl niet om. Het gaat er om dat je niet wil redirecten.

Je weet het kennelijk allemaal erg goed, maar heb je wel je eigen voorbeelden bekeken? Ga eens naar fok, en kijk naar je url balk. Zie je daar een andere url met parameters?

[Bosmonster]

EnnaN schreef op dinsdag 26 februari 2013 @ 12:18:
Sorry hoor, maar dat is gewoon niet waar. Je haalt met "methodiek" 2 dingen door elkaar. Functionaliteit (laad niets tot 'ok') en implementatie (hoe doe je dat).

Tuurlijk kun je wel garanderen dat een pagina geen cookies zet. Als je geen javascript wil gebruiken is dat prima. Daar gaat het namelijkl niet om. Het gaat er om dat je niet wil redirecten.

Verrijk me dan met meer dan loze kreten en geef aan hoe jij dat dan voor je ziet. Hoe ga je een willekeurige pagina serveren en garanderen dat die geen cookies zet zonder aanpassingen aan die pagina zelf?

Je weet het kennelijk allemaal erg goed, maar heb je wel je eigen voorbeelden bekeken? Ga eens naar fok, en kijk naar je url balk. Zie je daar een andere url met parameters?

Ik doe mijn best en ben hier inderdaad het afgelopen jaar intensief mee bezig geweest in veel verschillende scenario's voor veel verschillende klanten.

Wat ze bij Fok doen is de cookie-pagina serveren op iedere url, ipv de opgevraagde pagina. Daarna wordt door geredirect naar de uiteindelijke pagina wanneer de acceptatie-cookie is gezet (zelfde url in dit geval). Of je die pagina serveert op de huidige url en daarna redirect of eerst redirect en daarna weer terug doet er niet toe natuurlijk. Het komt op hetzelfde neer: er zit een cookie-loze cookie-melding-pagina tussen de request en de uiteindelijke acceptatie.

[André]

Er is wat voor beide oplossingen te zeggen, ik ben het wel met EnnaN eens dat het prima zonder een tussenpagina kan, dus alleen met een javascript popup. De voorwaarde hierbij is wel dat jij als webdeveloper exact weet welke scripts/cookies zich waar bevinden zodat je weet welke je nog niet moet laden. Voor een normale site zul je dat wel weten, maar op een site waar 100'en mensen scripts/ads/elementen kunnen plaatsen van allerlei partijen die van alles doormeten is dat een stuk lastiger. Dan zal een tussenpagina waarop je via een serverside redirect komt effectiever/veiliger zijn.

[Bosmonster]

Uiteraard is dat altijd een methode die de voorkeur geniet als het mogelijk is, daar torn ik ook niet aan. Maar de discussie ging simpelweg over de werking van een cookiemuur.

[EnnaN]

Bosmonster schreef op dinsdag 26 februari 2013 @ 13:21:
[...]
Verrijk me dan met meer dan loze kreten en geef aan hoe jij dat dan voor je ziet. Hoe ga je een willekeurige pagina serveren en garanderen dat die geen cookies zet zonder aanpassingen aan die pagina zelf?

Leek me wel duidelijk, maar als je het uitgeschreven wilt:

Je serveert een pagina zonder de evil content, en pas na de klik laad je die in. Dat kan met javascript. dat kan met een redirect. dat kan met een reload. dat kan met allemaal dingen.
Je kan dus inderdaad zoals jij doet redirecten naar een andere pagina, en dan terugsturen oid. kan allemaal,

Mij lijkt het beste om dit te doen


1. Pagina wordt opgevraagd. je checkt op cookietoestemming voor je iets toont.
2 a Als je die hebt, laad je de pagina. => klaar
2 b. Als je die niet hebt, laad (dus niet redirect, maar gewoon laden uit je backend) de cookiewall. => naar 3
3. Als toestemming gegeven wordt wil je de pagina tonen. Dit kan door het met een AJAX call in te laden, door te reloaden (je komt via punt 1 bij 2a terecht), etc. Punt is dat het niet hoeft via een andere URL.


bodemlijn is dat als je geen andere URL gebruikt dat nog niet hoeft te betekenen dat je eerst je pagina inlaadt, wat jij schijnt te denken.

[Bosmonster]

Dat denk ik niet, dus denk dat daar ook het misverstand zit. Waar het alleen om ging was dat als je niet zeker weet wat op de pagina staat dat cookies zet, je beter een hele andere pagina waar je wel zeker van bent, kunt serveren. Of je dat op dezelfde url doet of niet doet er niet toe. Het komt er bij de cookiemuur op neer dat je pas de werkelijke site geserveerd krijgt als je cookies geaccepteerd hebt, op welke url dan ook.

[EnnaN]

Bosmonster schreef op woensdag 27 februari 2013 @ 11:57:
Dat denk ik niet, dus denk dat daar ook het misverstand zit.

Jawel, dat denk je dus wel zie maar je volgende zin laat dat heel duidelijk zien

Waar het alleen om ging was dat als je niet zeker weet wat op de pagina staat dat cookies zet, je beter een hele andere pagina waar je wel zeker van bent, kunt serveren.

Je serveert een pagina. Maar die pagina heeft ANDERE content als er nog geen toestemming is. Content die JIJ controleert, en die dus geen cookies zet. Maar NIET een pagina met een andere url.

Of je dat op dezelfde url doet of niet doet er niet toe. Het komt er bij de cookiemuur op neer dat je pas de werkelijke site geserveerd krijgt als je cookies geaccepteerd hebt, op welke url dan ook.

Jamaar dat doet er dus WEL toe. Omdat je probleem is dat je met referring zit enzo. Dus als je NIETS doet met redirect etc, dan heb je je probleem ook niet.

Dus dan heb je een cookiewall zonder je initiele probleem. Dat was toch het doel van dit topic?

[Bosmonster]

Volgens mij zijn we compleet afgedwaald

Als dat het doel achter de discussie was: ja, je kunt met javascript op dezelfde url een hoop bereiken. AJAX en een document.write, als meest eenvoudige oplossing. Zonder javascript zie ik wat dat betreft even geen optie en ben ik dus benieuwd naar je oplossing.

Mijn originele opmerking was overigens om Tsjilp het basale idee achter de cookiemuur uit te leggen en ging niet over hoe je de referrer daarmee kon behouden. Jij viel vervolgens over de term "redirecten" in die uitleg, maar die term was alleen gekozen om het principe uit te leggen dat je andere content toont, in tegenstelling tot proberen met javascript cookies te voorkomen.

Volgens mij bedoelen we uiteindelijk dus gewoon hetzelfde, maar ben ik voor benieuwd naar hoe jij dat exact zou oplossen. Dan hebben we misschien weer een interessante oplossingsgerichte discussie.