To ulike oppgaver

Når en besøkende tar et samtykkevalg, må to adskilte ting skje. For det første må nettleseren huske valget, slik at banneret ikke dukker opp igjen på hver side og taggene vet hva de har lov til. For det andre må du kanskje senere bevise at valget ble tatt, hva den besøkende fikk se og når. Disse oppgavene løses ofte av ulike lagringsmekanismer, og å forveksle dem skaper reelle problemer: bannere som stadig dukker opp igjen, valg som forsvinner i enkelte nettlesere, eller ingen registrering å vise fram når noen spør.

Denne sammenligningen ser på de tre vanlige alternativene — first-party-informasjonskapsler, nettleserlagring som localStorage og serverposter over samtykke — og hvor hvert passer.

Alternativ 1: first-party-informasjonskapsler

Informasjonskapsler er det tradisjonelle hjemmet for samtykketilstand. TCF-CMP-er lagrer vanligvis samtykkestrengen i en first-party-informasjonskapsel, og mange CMP-er lagrer også sine egne preferansedata i en.

Styrker

• Lesbar for serveren. Informasjonskapselen sendes med hver forespørsel, slik at serverkode, edge-logikk og server-side tagging kan lese valget uten å vente på JavaScript.
• Kan deles på tvers av underdomener. En informasjonskapsel satt på det registrerbare domenet ditt kan dekke underdomenene www, blog og shop.
• Bredt forventet. Mange adtech-integrasjoner leter etter samtykke i informasjonskapsler.

Svakheter

• Størrelsesgrenser. Nettlesere begrenser størrelsen på informasjonskapsler til rundt 4 KB, og en TCF-streng med mange leverandører pluss andre verdier kan nærme seg det.
• Overhead per forespørsel. Hver forespørsel til domenet ditt bærer informasjonskapselen, også bilde- og skriptforespørsler.
• Levetidsgrenser i enkelte nettlesere. Safaris Intelligent Tracking Prevention begrenser informasjonskapsler opprettet via JavaScript til en maksimal levetid på sju dager. Informasjonskapsler satt av din egen server i et HTTP-svar behandles generelt mer sjenerøst, men det finnes unntak.

Alternativ 2: localStorage og annen nettleserlagring

Noen CMP-er lagrer detaljerte preferanser i localStorage, noen ganger ved siden av en mindre informasjonskapsel.

Styrker

• Mer plass. Flere megabyte per origin, nok til detaljerte valg på leverandørnivå.
• Ingen overhead per forespørsel. Ingenting sendes automatisk til serveren.

Svakheter

• Usynlig for serveren. Serverkode og edge-logikk kan ikke lese den, så enhver beslutning på serversiden må vente på nettleseren.
• Bundet til én origin. Lagring på www.example.com er ikke tilgjengelig på shop.example.com, så en besøkende kan se banneret igjen på hvert underdomene.
• Kan slettes. Safari kan fjerne lagring som skript kan skrive til, inkludert localStorage, for nettsteder brukeren ikke har interagert med på sju dagers nettleserbruk, og private nettlesermoduser tømmer den vanligvis når økten avsluttes.

Alternativ 3: serverposter over samtykke

En serverpost er en oppføring som du eller CMP-leverandøren din lagrer hver gang et valg tas. Den inneholder vanligvis en pseudonym identifikator, tidsstempelet, valgene, bannerversjonen eller policyversjonen som ble vist, og kontekst som regionen.

Styrker

• Varig bevis. Den overlever sletting av informasjonskapsler og nettleserbegrensninger, noe som gjør den til det rette verktøyet for å vise at samtykke ble innhentet.
• Kan revideres. Du kan rapportere om valg over tid og svare på spørsmål om bestemte hendelser.
• Potensial på tvers av enheter. For innloggede lesere kan en serverpost synkronisere valg mellom enheter, hvis du forklarer dem det.

Svakheter

• Ikke en erstatning for lokal tilstand. Tagger i nettleseren trenger fortsatt et raskt, lokalt signal; å kalle en server ved hver sidevisning for å slå opp samtykke øker ventetiden.
• Den er selv personopplysninger. Poster trenger en oppbevaringsperiode, tilgangskontroll og en plass i personvernerklæringen din.
• Avhengighet av en identifikator. Anonyme besøkende kan bare knyttes til en post via en identifikator lagret på enheten deres, noe som bringer deg tilbake til lokal lagring.

Sammenligning side ved side

• Best for å huske valget på nettet: first-party-informasjonskapsler, helst satt av serveren din for en stabil levetid.
• Best for detaljerte preferansedata i nettleseren: localStorage, parret med en informasjonskapsel serveren kan lese.
• Best for å bevise valget: serverposter.
• Dårligste enkeltvalg: å stole kun på localStorage, noe som gjør serveren blind og valget skjørt i enkelte nettlesere.

En praktisk kombinert tilnærming

1. Lagre det autoritative lokale signalet — for eksempel TCF-strengen og en kompakt preferansepost — i en first-party-informasjonskapsel avgrenset til det registrerbare domenet ditt.
2. Bruk localStorage bare til tilleggsdata som ikke trenger å nå serveren.
3. Skriv en serverpost for hvert valg, inkludert versjonen av banneret og policyen som ble vist.
4. Hvis et lagret valg forsvinner, vis banneret på nytt i stedet for å anta et tidligere svar.
5. Fastsett en periode for ny forespørsel om lagrede valg og skriv den inn i policyen din.

Å lagre selve den besøkendes samtykkevalg regnes generelt som nødvendig for å levere tjenesten den besøkende har bedt om — å huske beslutningen sin — men sjekk veiledningen som gjelder i hovedmarkedene dine.

Viktigste poenger

• Å huske et valg og å bevise et valg er ulike oppgaver som trenger ulik lagring.
• Informasjonskapsler kan leses av serveren og deles på tvers av underdomener, men er begrenset i størrelse og, i Safari, i levetid når de settes av skript.
• localStorage gir plass, men er usynlig for serveren og kan tømmes av nettlesere.
• Serverposter er bevislaget, ikke en erstatning for et lokalt signal.
• Kombiner en serversatt first-party-informasjonskapsel, valgfri nettleserlagring og serverposter.