Third-party cookies verdwijnen. Safari blokkeert ze standaard. Firefox blokkeert ze standaard. Chrome bouwt ze af. Websites die van cookies afhankelijk zijn, verliezen hun trackingmogelijkheden. De toekomst is cookieloos. Dit hoofdstuk behandelt alternatieven: server-side tracking, first-party data en tracking op basis van toestemming die zonder cookies werkt.
Waarom cookies verdwijnen
Cookies zijn bedoeld voor de werking van het web (ingelogd blijven, voorkeuren opslaan). Third-party cookies werden echter surveillancemiddelen. Advertentienetwerken gebruiken ze om gebruikers over websites heen te volgen. Privacyvoorvechters en toezichthouders zagen dat dit in de kern misleidend is. Gebruikers verwachten niet dat ze van site naar site worden gevolgd.
Browsers reageerden. Safari en Firefox blokkeren third-party cookies standaard. Chrome bouwt ze volledig af (het Privacy Sandbox-initiatief). Over een paar jaar werken third-party cookies voor de meeste gebruikers niet meer. Websites die erop leunen, verliezen mogelijkheden.
Dit raakt meer dan alleen advertenties
Ook analytics gebruiken cookies, zowel first-party als third-party. Nu cookies verdwijnen, moet analytics meebewegen. De oplossing: stap over op cookievrije alternatieven die beter werken en sowieso privacyvriendelijker zijn.
Server-side tracking
In plaats van te tracken in de browser met JavaScript en cookies, stuur je events rechtstreeks naar je server. Je server legt de gebeurtenis vast: er is iets gekocht, een pagina bekeken, op een knop geklikt. De gebeurtenis wordt aan de serverkant gelogd, zonder cookies in de browser.
Hoe server-side tracking werkt
Bezoeker klikt op een knop → JavaScript stuurt een event naar je server → de server logt het event → de server stuurt het door naar je analytics-platform. Er zijn geen cookies bij betrokken. De tracking is first-party (jouw domein, jouw controle) en bestand tegen trackingblokkers in de browser.
Voordelen van server-side tracking
Privacyvriendelijk: Geen cookies nodig. Werkt ook als de bezoeker cookies blokkeert. Geen third-party tracking.
Betrouwbaarder: Browserprivacyfuncties raken het niet. Adblockers kunnen het niet blokkeren (het verzoek lijkt op gewoon sitebezoek).
Betere data: Server-side events zijn betrouwbaarder (bezoekers kunnen ze niet tegenhouden). Je krijgt completere data.
Makkelijker aan te passen: Moet je de tracking bijstellen, dan pas je servercode aan. Je hoeft geen code te wijzigen die op miljoenen browsers draait.
Uitdagingen van server-side tracking
Lastiger in te richten: Je hebt serverinfrastructuur en ontwikkelwerk nodig. Je kunt niet zomaar een JavaScript-tag toevoegen.
Sessietracking is nodig: Zonder cookies om bezoekers te herkennen heb je een andere manier nodig om events aan bezoekers te koppelen (sessie-ID's, gebruikers-ID's, gehashte e-mailadressen).
Ondersteuning van de leverancier: Je analytics-platform moet server-side events accepteren. De meeste moderne platforms doen dat, maar oudere systemen vaak niet.
First-party data en directe integratie
In plaats van te vertrouwen op analytics-platforms die data via tags verzamelen, kun je data direct in je eigen systemen verzamelen en via een API naar analytics-platforms sturen. Dit is first-party data, want je bent de eigenaar. Het is conform de regels, want je leunt niet op third-party tracking.
Hoe directe integratie werkt
Je CRM legt klantcontacten vast. Je webshopplatform logt aankopen. Je app volgt gebruikersgedrag. Je stuurt deze data regelmatig via een API naar je analytics-platform. Het analytics-platform verrijkt en analyseert de data. Er zijn geen third-party tags of cookies bij betrokken.
Deze aanpak geeft je volledige controle. Jij bepaalt wat je verstuurt, wanneer je het verstuurt en wie toegang krijgt. Het is de meest privacyvriendelijke aanpak, want hij is transparant en in jouw handen.
Alternatieven voor cookies in de browser
Local storage
Gebruik in plaats van cookies de local storage van de browser om sessie-ID's op te slaan. Local storage blijft bewaard zoals cookies, maar wordt niet bij elk verzoek meegestuurd. Het is efficiënter en iets privater (standaard niet zichtbaar voor servers). Het werkt over paginavernieuwingen en browsersessies heen.
First-party cookies in plaats van third-party cookies
Moet je toch cookies gebruiken, kies dan first-party cookies (door je eigen domein geplaatst) in plaats van third-party cookies (door advertentienetwerken of analytics-leveranciers geplaatst). First-party cookies zijn minder privacygevoelig en lastiger te blokkeren, omdat ze nodig zijn voor de werking van de site.
Nu third-party cookies verdwijnen, stappen zelfs third-party analytics-leveranciers over op first-party cookiemodellen (door jou geleverd, door hen beheerd).
De Privacy Sandbox en FLoC van Google
Google ontwikkelt Privacy Sandbox-technologieën als alternatief voor third-party cookies. Daaronder vallen: FLoC (Federated Learning of Cohorts: gebruikers groeperen op interesses zonder ze te identificeren), de Topics API (gebruikers labelen met onderwerpen zonder te tracken) en de Attribution Reporting API (conversies meten zonder third-party tracking).
Dit is nog experimenteel en wordt nog niet breed gebruikt. Voorlopig zijn de praktische alternatieven: server-side tracking, first-party data en first-party cookies op basis van toestemming.
Een trackingstrategie kiezen voor de cookievrije toekomst
De meeste bedrijven kiezen een hybride aanpak: server-side tracking voor de kernevents (paginaweergaven, conversies, kritieke acties), first-party cookies voor sessiebeheer en first-party data uit directe interacties. Die combinatie werkt zonder cookies die verdwijnen en voldoet van nature aan de privacyregels.
Welke events moet ik als eerste naar server-side tracking verhuizen?
Begin met events met veel waarde: conversies, aankopen, aanmeldingen en belangrijke klikken op knoppen. Die worden het meest geraakt door cookieblokkers en zijn het belangrijkst voor je bedrijfscijfers. Verhuis randevents (paginaweergaven, scrollen) later. Prioriteer op bedrijfsimpact, niet op technische moeilijkheid.
Welke analytics-platforms ondersteunen server-side event tracking?
Google Analytics 4 en de meeste moderne platforms accepteren server-side events via een API. Oudere platforms (Classic Google Analytics) doen dat niet. Controleer de documentatie van je leverancier. Ondersteunt die geen server-side events, plan dan een migratie. Het is een vereiste voor cookieloze analytics.
Hoe herken ik bezoekers zonder cookies of tracking over domeinen heen?
Gebruik server-side identifiers: gebruikers-ID's uit inlogsystemen, gehashte e-mailadressen of sessie-ID's voor niet-ingelogde bezoekers. Die zijn betrouwbaarder dan cookies, omdat ze onder jouw controle staan. Server-side identifiers koppelen events aan bezoekers zonder te leunen op opslag in de browser.
Wat is het prestatieverschil tussen server-side en client-side tracking?
Server-side is iets trager (netwerkverzoek naar je server en daarna naar analytics). Maar de betrouwbaarheid is hoger (geen adblockers, geen bezoekers die het blokkeren). Voor de meeste sites is het verschil niet merkbaar (20-50 ms). De afweging loont voor betere data en naleving van de privacyregels.
Local storage of first-party cookies: wat gebruik ik voor sessietracking?
First-party cookies voor bewaren over pagina's heen, local storage voor logica in de browser. Cookies gaan mee met elk verzoek (eenvoudiger voor integratie met de server). Local storage moet expliciet via JavaScript worden uitgelezen (iets efficiënter). Voor analytics zijn first-party cookies gebruikelijker. Gebruik beide als je beide mogelijkheden nodig hebt.
Hoe stap ik over van cookiegebaseerde naar cookieloze tracking zonder historische data te verliezen?
Laat beide 3 tot 6 maanden naast elkaar draaien (de oude cookiegebaseerde en de nieuwe server-side tracking). Vergelijk de cijfers om te controleren of server-side tracking de events goed vastlegt. Ben je er zeker van, stop dan met de cookiegebaseerde tracking. Je historische data blijft in je analytics-platform staan (die verdwijnt niet als je stopt met verzamelen).