Twee verschillende taken

Wanneer een bezoeker een toestemmingskeuze maakt, moeten er twee afzonderlijke dingen gebeuren. Ten eerste moet de browser de keuze onthouden, zodat de banner niet op elke pagina terugkomt en tags weten wat ze mogen doen. Ten tweede moet je later misschien aantonen dat de keuze is gemaakt, wat de bezoeker te zien kreeg en wanneer. Deze taken worden vaak door verschillende opslagmechanismen uitgevoerd, en ze door elkaar halen veroorzaakt echte problemen: banners die blijven terugkomen, keuzes die in sommige browsers verdwijnen, of geen registratie om te tonen wanneer iemand erom vraagt.

Deze vergelijking bekijkt de drie gangbare opties — first-party cookies, browseropslag zoals localStorage en serverrecords van toestemming — en waar elke past.

Optie 1: first-party cookies

Cookies zijn van oudsher de plek voor de toestemmingsstatus. TCF-CMP's slaan de toestemmingsstring gewoonlijk op in een first-party cookie, en veel CMP's bewaren hun eigen voorkeursgegevens er ook in.

Sterke punten

• Leesbaar voor de server. Het cookie wordt bij elk verzoek meegestuurd, zodat servercode, edgelogica en server-side tagging de keuze kunnen lezen zonder op JavaScript te wachten.
• Deelbaar over subdomeinen. Een cookie dat op je registreerbare domein is geplaatst, kan de subdomeinen www, blog en shop dekken.
• Algemeen verwacht. Veel adtech-integraties zoeken toestemming in cookies.

Zwakke punten

• Groottebeperkingen. Browsers begrenzen de cookiegrootte op ongeveer 4 KB, en een TCF-string met veel leveranciers plus andere waarden kan daar dichtbij komen.
• Overhead per verzoek. Elk verzoek naar je domein draagt het cookie mee, ook afbeeldings- en scriptverzoeken.
• Maximale levensduur in sommige browsers. De Intelligent Tracking Prevention van Safari beperkt cookies die via JavaScript zijn gemaakt tot een maximale levensduur van zeven dagen. Cookies die je eigen server in een HTTP-respons plaatst, worden over het algemeen ruimer behandeld, hoewel er uitzonderingen zijn.

Optie 2: localStorage en andere browseropslag

Sommige CMP's slaan gedetailleerde voorkeuren op in localStorage, soms naast een kleiner cookie.

Sterke punten

• Meer ruimte. Meerdere megabytes per origin, genoeg voor gedetailleerde keuzes op leveranciersniveau.
• Geen overhead per verzoek. Er wordt niets automatisch naar de server gestuurd.

Zwakke punten

• Onzichtbaar voor de server. Servercode en edgelogica kunnen het niet lezen, dus elke beslissing aan de serverkant moet op de browser wachten.
• Gebonden aan één origin. Opslag op www.example.com is niet beschikbaar op shop.example.com, dus een bezoeker kan de banner op elk subdomein opnieuw zien.
• Kan worden verwijderd. Safari kan door scripts beschrijfbare opslag, inclusief localStorage, verwijderen voor sites waarmee de gebruiker zeven dagen browsergebruik lang niets heeft gedaan, en privé-browsemodi wissen het doorgaans aan het einde van de sessie.

Optie 3: serverrecords van toestemming

Een serverrecord is een vermelding die jij of je CMP-aanbieder opslaat telkens wanneer een keuze wordt gemaakt. Het bevat gewoonlijk een gepseudonimiseerde identifier, het tijdstip, de keuzes, de getoonde versie van de banner of het beleid en context zoals de regio.

Sterke punten

• Duurzaam bewijs. Het overleeft het wissen van cookies en browserbeperkingen, waardoor het het juiste middel is om aan te tonen dat toestemming is verkregen.
• Controleerbaar. Je kunt rapporteren over keuzes in de tijd en vragen over specifieke gebeurtenissen beantwoorden.
• Potentieel over meerdere apparaten. Bij ingelogde lezers kan een serverrecord keuzes tussen apparaten synchroniseren, als je dat aan hen uitlegt.

Zwakke punten

• Geen vervanging voor lokale status. Tags in de browser hebben nog steeds een snel, lokaal signaal nodig; bij elke paginaweergave een server raadplegen om toestemming op te zoeken voegt latentie toe.
• Het zijn zelf persoonsgegevens. Records hebben een bewaartermijn, toegangscontroles en een plek in je privacyverklaring nodig.
• Afhankelijkheid van een identifier. Anonieme bezoekers kunnen alleen aan een record worden gekoppeld via een identifier die op hun apparaat is opgeslagen, wat je terugbrengt bij lokale opslag.

Vergelijking naast elkaar

• Het beste om de keuze op het web te onthouden: first-party cookies, bij voorkeur door je server geplaatst voor een stabiele levensduur.
• Het beste voor gedetailleerde voorkeursgegevens in de browser: localStorage, gecombineerd met een cookie dat de server kan lezen.
• Het beste om de keuze aan te tonen: serverrecords.
• Slechtste enkele keuze: alleen op localStorage vertrouwen, wat de server blind laat en de keuze in sommige browsers kwetsbaar maakt.

Een praktische gecombineerde aanpak

1. Sla het gezaghebbende lokale signaal — bijvoorbeeld de TCF-string en een compact voorkeursrecord — op in een first-party cookie dat is afgebakend tot je registreerbare domein.
2. Gebruik localStorage alleen voor aanvullende gegevens die de server niet hoeven te bereiken.
3. Schrijf voor elke keuze een serverrecord, inclusief de versie van de getoonde banner en het beleid.
4. Als een opgeslagen keuze verdwijnt, toon de banner dan opnieuw in plaats van een eerder antwoord aan te nemen.
5. Stel een termijn in waarna opgeslagen keuzes opnieuw worden gevraagd en leg die vast in je beleid.

Het opslaan van de toestemmingskeuze van de bezoeker zelf wordt over het algemeen gezien als noodzakelijk om de dienst te leveren waar de bezoeker om vroeg — zijn beslissing onthouden — maar controleer de richtlijnen die in je belangrijkste markten gelden.

Belangrijkste inzichten

• Een keuze onthouden en een keuze aantonen zijn verschillende taken die verschillende opslag vragen.
• Cookies zijn leesbaar voor de server en deelbaar over subdomeinen, maar beperkt in grootte en, in Safari, in levensduur wanneer ze door een script zijn geplaatst.
• localStorage biedt ruimte maar is onzichtbaar voor de server en kan door browsers worden gewist.
• Serverrecords vormen de bewijslaag, geen vervanging voor een lokaal signaal.
• Combineer een door de server geplaatst first-party cookie, optionele browseropslag en serverrecords.