Is server-side implementatie van Google Analytics de oplossing?

Image of Iron Brands

Gepubliceerd op 22 mrt 2023 en bijgewerkt op 16 jan 2024 door Iron Brands

Dit artikel is automatisch vertaald. Ga naar de Engelse versie voor het origineel.

De toekomst van analytics is een discussiepunt dat de laatste maanden meer aandacht heeft gekregen. Dit vloeit voort uit een Europees gedragen opvatting dat Google Analytics in strijd is met de GDPR-wetgeving. Landen als Frankrijk, Italië, Oostenrijk en de laatste tijd ook Finland en Noorwegen hebben publiekelijk verklaard dat Google Analytics onwettig is.

In hun verklaring noemde de Franse gegevensbeschermingsautoriteit (CNIL) een lijst van privacy-compliant opties voor organisaties om te evalueren. Een daarvan is server-side implementatie van Google Analytics. De CNIL is een van Europa's meest gerespecteerde privacy-autoriteiten, dus hun suggestie kreeg enige aandacht van de privacy- en marketinggemeenschappen, en deed sommigen geloven dat het server-side implementeren van Google Analytics een kogelvrije oplossing is voor de juridische problemen van Analytics met gegevensoverdracht.

Server-side implementatie is echter niet zonder nadelen. In deze blog gaan we er dieper op in en proberen we twee vragen te beantwoorden:

Voldoet server-side implementatie van Google Analytics aan de GDPR? En is het de moeite waard om het te implementeren?

  1. Wat zijn client-side en server-side tracking?
  2. Wat zijn de voor- en nadelen van server-side tracking?
  3. Is server-side de oplossing voor de juridische problemen van Google Analytics?
  4. Welke gegevens moeten worden geanonimiseerd?
  5. Hoe presteert Google Analytics server-side?
  6. Zorgt server-side implementatie van Google Analytics echt voor compliance?
  7. Wat zijn de privacygevolgen van server-side analytics?
  8. Is server-side implementatie nodig bij privacy-vriendelijke alternatieven?
  9. Conclusies
Logo of MichelinMichelin chose Simple AnalyticsJoin them

Laten we erin duiken!

Wat zijn client-side en server-side tracking?

Client-side tracking en server-side tracking zijn verschillende manieren om gegevens over gebruikersgedrag te verzamelen en te verwerken.

Client-side tracking (of client-side tagging) verzamelt informatie met behulp van scripts die in de browser van de gebruiker draaien, zoals cookies of pixels. Server-side tracking (of server-side tagging) daarentegen verzamelt de gegevens van de server door verzoeken te loggen en te analyseren. Hierdoor kunnen de gegevens worden verzameld zonder interactie met het apparaat van de gebruiker.

In het geval van Google Analytics is server-side tracking een beetje anders. Google Analytics heeft nog steeds interactie met de browser van de gebruiker door cookies te schrijven en te lezen. De verzamelde gegevens worden echter naar de server gestuurd in plaats van naar Google. De serverbeheerder kan dan beslissen welke gegevens naar Google worden doorgestuurd, en hoe. De server fungeert dus in wezen als een proxy voor de gegevens.

Wat zijn de voor- en nadelen van server-side tracking?

Server-side tracking geeft u meer controle over de informatie die naar uw analytics provider wordt gestuurd - of dat nu Google is of een ander bedrijf. U kunt beslissen of u persoonlijke gegevens al dan niet verstuurt, en of u ze anonimiseert, pseudonimiseert of onversleuteld verstuurt.

Er zijn nog andere voordelen aan server-side implementatie. Uw site zal iets sneller laden omdat het analysescript niet door de browser hoeft te worden geladen. Dit verbetert de gebruikerservaring en kan helpen bij de ranking in zoekmachines. Bovendien worden uw analyses niet negatief beïnvloed door adblocking software, omdat ze niet langer afhankelijk zijn van de interactie met de browserinstellingen van de gebruiker (hoewel cookies van Google Analytics en andere op cookies gebaseerde analysediensten nog steeds kunnen worden geblokkeerd).

Het belangrijkste nadeel van server-side setups is de omslachtige implementatie. U moet een server vinden als u er nog geen heeft, en deze beveiligen tegen cyberdreigingen. U moet een gebruikersinterface opzetten om de gegevens uit het serverlogboek leesbaar te maken, en een manier vinden om ruis betrouwbaar uit te filteren, wat niet triviaal is. U moet ook de code handmatig bijwerken telkens als uw analytische software een update krijgt.

Bovendien moet u volledige toegang hebben tot het serverlogboek, wat veel serverproviders niet bieden. Dit beperkt uw keuzes als u wilt vertrouwen op een provider (wat voor veel bedrijven de meest betaalbare optie is).

Al met al kost het instellen van Google Analytics server-side veel meer dan een abonnement op een betaalde webanalysedienst die voldoet aan de GDPR. De CNIL merkt zelfs op dat het weglaten van Google Analytics een meer praktische optie kan zijn, vanwege de kosten van een server-side setup.

Ten slotte moet worden opgemerkt dat voor cookies nog steeds toestemming van de gebruiker nodig is, zelfs voor server-side tagging. Dit geldt ook voor Google Analytics en elke andere op cookies gebaseerde analysedienst.

Zullen we wat dieper graven?

Is server-side de oplossing voor de juridische problemen van Google Analytics?

Elke client-side implementatie van Google Analytics stuurt persoonlijke gegevens naar de VS. Dit is de kern van de juridische problemen van Google Analytics met gegevensoverdracht (die we in een andere blog uitvoerig hebben besproken).

Server-side implementatie geeft de serverbeheerder volledige controle over de gegevensverwerking en laat u beslissen welke persoonsgegevens naar Google worden doorgestuurd en welke niet. In theorie zou u Google Analytics server-side kunnen instellen en voorkomen dat Google toegang krijgt tot de persoonsgegevens van bezoekers, waardoor Google Analytics compliant zou zijn.

Maar hoe werkt dit in de praktijk? Welke gegevens mag u niet aan Google doorgeven om Google Analytics GDPR-compliant te maken? En wat zijn de kosten in termen van prestaties?

sergey_brin_and_larry_page_hiding_between_red_network-cables.png De oprichters, Sergey Brin en Larry Page, verschuilen zich achter het internet

Welke gegevens moeten worden geanonimiseerd?

Google Analytics stuurt twee categorieën persoonsgegevens door naar de VS: IP-adressen en cookies. IP-adressen zijn geen groot probleem omdat Google Analytics ze niet echt nodig heeft - in feite verzamelt Google Analytics 4 ze niet en gebruikt ze alleen voor communicatie. U kunt Google Analytics server-side implementeren zonder IP van gebruikers door te sturen naar Google, met weinig of geen impact op de nauwkeurigheid van de inzichten van Google Analytics.

Cookies zijn een ander verhaal. De cookies van Google Analytics bevatten een unieke identificatiecode, Client ID genaamd. Net als IP's zijn Client ID's persoonsgegevens onder de GDPR. ID's moeten echter op de een of andere manier worden verzonden omdat Google Analytics eromheen is gebouwd.

Unieke identificatoren kunnen ookniet worden geanonimiseerd, althans niet in de strikte zin van het woord. De cookies van Google Analytics functioneren omdat ze uniek zijn, en het verwijderen van hun unieke deel (de Client ID) maakt ze volkomen nutteloos. Het beste wat u kunt doen is ze hashen, maar elke hash moet uniek zijn om van enig nut te zijn - u vervangt dus slechts een unieke identificatie door een andere.

Als extra beveiliging stelt de CNIL voor de hashes regelmatig te wijzigen. De autoriteit beschouwt het roteren van hashes als een vorm van pseudonimisering - iets dat niet echt anoniem is, maar toch enige bescherming biedt voor de gegevens. Sterke pseudonimisering wordt in feite genoemd als een mogelijke waarborg voor gegevensoverdracht door de Europese Raad voor gegevensbescherming (de instelling waar alle Europese gegevensbeschermingsautoriteiten zetelen). Maar er is een prijs te betalen.

Hoe presteert Google Analytics server-side?

Dat hangt ervan af. Google Analytics baseert zijn inzichten op gedetailleerde gegevens over de online activiteit van websitebezoekers. Hoe meer gegevens u het geeft, hoe beter het presteert. Als u het alle gegevens geeft die het client-side zou verzamelen, zal het net zo goed presteren als een client-side setup (en mogelijk iets beter omdat ad-blockers minder een probleem zullen zijn). Aan de andere kant maakt dit server-side implementatie net zo ingrijpend als client-side setups, wat het hele doel om Google Analytics server-side te implementeren teniet doet. Anderzijds zal het achterhouden van bepaalde gegevens om privacyredenen de prestaties van de tool negatief beïnvloeden.

Met de eerder genoemde Client ID's kan Google bezoekers volgen door meerdere gebeurtenissen, sessies en pageviews aan dezelfde persoon te koppelen. Als u bijvoorbeeld twee keer dezelfde website bezoekt, leest Google Analytics uw klant-ID en telt u slechts één keer als een unieke bezoeker.

Helaas kan Google Analytics de metriek niet koppelen aan een individuele bezoeker nadat zijn ID opnieuw is gelezen. Dit heeft aanzienlijke gevolgen voor de nauwkeurigheid en het detailniveau van de inzichten van Google Analytics. Bijvoorbeeld, nadat u de hashes roteert, krijgen terugkerende gebruikers een nieuwe hash en worden ze door Google Analytics opnieuw geteld als unieke bezoekers, dus uw unieke bezoekers-metriek gaat in wezen het raam uit.

Zorgt server-side implementatie van Google Analytics echt voor compliance?

Laten we zeggen dat u door de zure appel heen bijt. U neemt de moeite om Google Analytics server-side te implementeren. U neemt de suggesties van de CNIL letterlijk: de enige persoonlijke informatie die uw server doorstuurt zijn gehashte Client ID's, en die hashes worden regelmatig geroteerd. Voldoet u aan de regels voor gegevensoverdracht van de GDPR?

Misschien.

Zoals we hebben uitgelegd, zijn geroteerde hashes gepseudonimiseerde gegevens. Pseudonimisering is goed omdat het de identificatie van persoonsgegevens onwaarschijnlijk maakt (dat wil zeggen: het maakt het moeilijk te achterhalen aan wie de gegevens toebehoren). Deze techniek wordt soms gebruikt door concurrenten van Google Analytics om de privacy te beschermen - Fathom en Plausible doen dit bijvoorbeeld (wij van Simple Analytics hoeven niet te hashen omdat we helemaal geen IP's opslaan).

Als een entiteit echter veel gegevens beheert, kan zij deze samenvoegen om gepseudonimiseerde gegevens te identificeren. Een techniek die fingerprinting wordt genoemd.

Als u bijvoorbeeld actief bent op Reddit, is uw Reddit-gebruikersnaam waarschijnlijk een geestig pseudoniem. Maar als je genoeg informatie post over je leeftijd, baan, geboorteplaats, enzovoort, zal het uiteindelijk mogelijk zijn voor andere Redditors om te achterhalen wie je bent. (Ja, dit voorbeeld is te simpel, maar je begrijpt wat ik bedoel).

Cross-linking van databases is hetzelfde, maar dan op grotere schaal: iemand voegt enorme databases samen, en met een beetje AI-zwarte magie kunnen pseudonieme gegevens soms opnieuw worden geïdentificeerd.

Dus hoe veilig zijn de persoonsgegevens van uw bezoekers nadat u ze hasht en doorstuurt naar Google?

Wel, Google beheert enkele van de grootste bestaande databanken met persoonsgegevens. Het kan vertrouwen op uitzonderlijke knowhow en geavanceerde technologie. Het heeft ook een sterke prikkel om databases aan elkaar te koppelen omdat reclame zijn belangrijkste bron van inkomsten is, en profilering is waar het echte geld zit.

Ook al kan een bezoeker niet worden geïdentificeerd op basis van zijn hash alleen, Google zou deze gegevens kunnen combineren met gegevens die elders zijn verzameld - bijvoorbeeld via het Google-account van een bezoeker, via Google API's, of via advertentietrackers op Android-toestellen(AAID). Dit is waarschijnlijk genoeg om veel bezoekers identificeerbaar te maken. Dit betekent op zijn beurt dat hashes nog steeds persoonsgegevens kunnen zijn onder de GDPR, zelfs als de server ze draait.

Voor de duidelijkheid: we beweren niet dat Google gepseudonimiseerde en geanonimiseerde gegevens opnieuw identificeert. Google zegt dat het dat niet doet. Volgens ons suggereert de staat van dienst van het bedrijf op het gebied van privacy enige voorzichtigheid.

We beweren ook niet dat roterende hashes persoonsgegevens zijn in het door ons beschreven scenario. Dat moeten rechtbanken en autoriteiten bepalen. Maar er kan zeker van worden uitgegaan dat zij dat zijn: in hun beslissingen tegen Google Analytics hebben sommige gegevensbeschermingsautoriteiten (waaronder de CNIL zelf) immers erkend dat de kwestie van de kruisidentificatie relevant was voor de zaken. Dit is een goede reden om op je hoede te zijn.

Conclusie: het is onduidelijk of een server-side implementatie van Google Analytics naleving van de GDPR-regels voor gegevensoverdracht garandeert - zelfs als u alle mogelijke voorzorgsmaatregelen neemt.

Wat zijn de privacygevolgen van server-side analytics?

Server-side analytics heeft interessante gevolgen voor de privacy. Op papier is het potentieel privacyvriendelijker omdat u precies kunt bepalen welke gegevens u wilt verzamelen en of u deze wilt delen.

Het verzamelen van gegevens zou echter minder transparant kunnen zijn. Met server-side analytics kunt u persoonlijke gegevens rechtstreeks vanuit uw serverlogboek bewerken. Uw gebruikers hebben geen idee dat dit gebeurt omdat ze niet gewoon hun browserinstellingen kunnen openen en hun cookies kunnen controleren.

Kortom, transparantie is de sleutel tot een correcte implementatie van server-side tracking. Gebruikers hebben het recht te weten welke persoonsgegevens worden verwerkt voor webanalyse en op welke rechtsgrondslag. Het is aan u om server-side analytics op een transparante en conforme manier te implementeren.

Server-side analytics heeft ook gevolgen voor de toestemming. Zoals wij hebben uitgelegd, is voor de cookies van Google Analytics toestemming vereist, zelfs wanneer de software server-side wordt geïmplementeerd. Hetzelfde geldt voor alle webanalysesoftware die cookies gebruikt: voor alle niet-essentiële cookies is toestemming nodig volgens de ePrivacy-richtlijn, ongeacht of de analytics-software client-side of server-side wordt geïmplementeerd.

Met server-side tagging kunt u ook andere gegevens verzamelen zonder interactie met de browser van de gebruiker. Maar dit betekent niet dat er geen toestemming nodig is.

Het wordt hier een beetje ingewikkeld, maar als vuistregel geldt: als de gegevens die u verzamelt u in staat stellen een gebruiker te onderscheiden van al uw bezoekers, dan moet u die gegevens alleen met toestemming verzamelen, omdat er hoogstwaarschijnlijk toestemming nodig is. Dit geldt zelfs als u deze gegevens niet gebruikt om gebruikers te onderscheiden: alleen al het feit dat u ze kunt gebruiken maakt ze tot persoonsgegevens en maakt toestemming naar alle waarschijnlijkheid verplicht.

Aan de andere kant kunt u sommige statistieken zonder toestemming verzamelen, op voorwaarde dat ze u niet in staat stellen een gebruiker te identificeren - zelfs wanneer ze gekoppeld zijn aan andere statistieken. Het kan bijvoorbeeld geen kwaad om interacties van uw server te verzamelen en deze te gebruiken voor analyses, zolang u met deze gegevens geen gebruikers kunt traceren.

Kortom: als de gegevens u in staat stellen te volgen, neem dan het zekere voor het onzekere en vraag om toestemming.

Is server-side implementatie nodig bij privacy-vriendelijke alternatieven?

Dat hangt af van de dienst. In het geval van Google Analytics pakt server-side implementatie juridische problemen met regels voor gegevensoverdracht aan. Als een privacyvriendelijk alternatief geen persoonsgegevens doorstuurt naar de VS, dan is een server-side implementatie niet nodig om te voldoen aan de regels voor gegevensoverdracht.

Server-side analytics biedt echter nog andere voordelen voor naleving. Zo kunt u bijvoorbeeld IP-adressen redigeren voordat u ze doorstuurt. Als u een alternatief voor Google Analytics overweegt, moet u de juridische documentatie ervan nauwkeurig bestuderen en de mogelijke voordelen van server-side implementatie voor die specifieke dienst overwegen.

In het specifieke geval van Simple Analytics is server-side implementatie niet nodig, omdat wij geen persoonsgegevens van uw bezoekers verzamelen of deze buiten de EU doorsturen.

Conclusies

Samengevat:

  • Client-ID's onversleuteld naar Google doorsturen of statische hashes gebruiken zijn in feite hetzelfde als Google Analytics client-side implementeren en maken Google Analytics niet in overeenstemming met de regels voor gegevensoverdracht;
  • Client-ID's helemaal niet verzenden maakt Google Analytics volledig nutteloos;
  • Roterende hashes verlammen de prestaties van Google Analytics en zorgen nog steeds niet voor 100% naleving van de regels voor gegevensoverdracht, omdat de gebruiker nog steeds identificeerbaar kan zijn;
  • Al deze opties zijn lastig te implementeren.

strange-game-dont-play.png

Al met al lijkt server-side implementatie van Google Analytics geen haalbare oplossing. Het is te duur voor kleine bedrijven om te implementeren, zorgt ervoor dat de tool slechter presteert dan de concurrentie, en garandeert niet volledig dat de gegevensoverdracht 100% GDPR-conform is.

De kern van het probleem is dat Google Analytics geen privacyvriendelijke tool is. Het is ontworpen om fijnmazige informatie te verzamelen door bezoekers agressief te volgen. Proberen Google Analytics op een privacyvriendelijke manier te implementeren druist in tegen het ontwerp zelf. Daarom is het veel werk en levert het slechte resultaten op.

Uiteraard zijn we bevooroordeeld ten opzichte van onze eigen oplossing, maar overstappen naar een privacy-vriendelijke dienst is makkelijker, goedkoper en leidt tot betere prestaties dan het server-side implementeren van Google Analytics. Bij Simple Analytics geloven we in een onafhankelijk internet dat vriendelijk is voor websitebezoekers. We zorgen ervoor dat het nog steeds mogelijk is voor website-eigenaren om de inzichten te krijgen die ze nodig hebben zonder de wet te overtreden. Als dit resoneert met je, voel je vrij om ons eens te proberen!

GA4 is complex. Probeer Simple Analytics

GA4 is als in de cockpit van een vliegtuig zitten zonder een pilotenlicentie

Start 14-dagen proefperiode