To forskellige opgaver

Når en besøgende træffer et samtykkevalg, skal to adskilte ting ske. For det første skal browseren huske valget, så banneret ikke dukker op igen på hver side, og tags ved, hvad de må. For det andet skal du måske senere kunne bevise, at valget blev truffet, hvad den besøgende fik vist, og hvornår. Disse opgaver løses ofte af forskellige lagringsmekanismer, og at blande dem sammen giver reelle problemer: bannere, der bliver ved med at dukke op, valg, der forsvinder i nogle browsere, eller ingen registrering at fremvise, når nogen spørger.

Denne sammenligning ser på de tre almindelige muligheder — first-party cookies, browserlagring som localStorage og serverregistre over samtykke — og hvor hver passer ind.

Mulighed 1: first-party cookies

Cookies er det traditionelle hjem for samtykketilstand. TCF-CMP'er gemmer almindeligvis samtykkestrengen i en first-party cookie, og mange CMP'er gemmer også deres egne præferencedata i en.

Styrker

• Kan læses af serveren. Cookien sendes med hver anmodning, så serverkode, edge-logik og server-side tagging kan læse valget uden at vente på JavaScript.
• Kan deles på tværs af subdomæner. En cookie sat på dit registrerbare domæne kan dække subdomænerne www, blog og shop.
• Bredt forventet. Mange adtech-integrationer leder efter samtykke i cookies.

Svagheder

• Størrelsesgrænser. Browsere begrænser cookiestørrelsen til omkring 4 KB, og en TCF-streng med mange leverandører plus andre værdier kan nærme sig det.
• Overhead pr. anmodning. Hver anmodning til dit domæne medbringer cookien, også billed- og scriptanmodninger.
• Levetidsgrænser i nogle browsere. Safaris Intelligent Tracking Prevention begrænser cookies oprettet via JavaScript til en maksimal levetid på syv dage. Cookies sat af din egen server i et HTTP-svar behandles generelt mere generøst, dog med undtagelser.

Mulighed 2: localStorage og anden browserlagring

Nogle CMP'er gemmer detaljerede præferencer i localStorage, nogle gange ved siden af en mindre cookie.

Styrker

• Mere plads. Flere megabyte pr. origin, nok til detaljerede valg på leverandørniveau.
• Ingen overhead pr. anmodning. Intet sendes automatisk til serveren.

Svagheder

• Usynlig for serveren. Serverkode og edge-logik kan ikke læse den, så enhver beslutning på serversiden må vente på browseren.
• Bundet til én origin. Lagring på www.example.com er ikke tilgængelig på shop.example.com, så en besøgende kan se banneret igen på hvert subdomæne.
• Kan slettes. Safari kan fjerne lagring, som scripts kan skrive til, inklusive localStorage, for sites, brugeren ikke har interageret med i syv dages browserbrug, og private browsertilstande rydder den typisk, når sessionen slutter.

Mulighed 3: serverregistre over samtykke

Et serverregister er en post, som du eller din CMP-udbyder gemmer hver gang, et valg træffes. Den indeholder som regel en pseudonym identifikator, tidsstemplet, valgene, den viste bannerversion eller politikversion og kontekst som regionen.

Styrker

• Holdbart bevis. Det overlever sletning af cookies og browserbegrænsninger, hvilket gør det til det rette værktøj til at påvise, at samtykke blev indhentet.
• Kan revideres. Du kan rapportere om valg over tid og besvare spørgsmål om bestemte hændelser.
• Potentiale på tværs af enheder. For loggede læsere kan et serverregister synkronisere valg mellem enheder, hvis du forklarer dem det.

Svagheder

• Ingen erstatning for lokal tilstand. Tags i browseren har stadig brug for et hurtigt, lokalt signal; at kalde en server ved hver sidevisning for at slå samtykke op tilføjer latenstid.
• Det er selv personoplysninger. Registre kræver en opbevaringsperiode, adgangskontrol og en plads i din privatlivspolitik.
• Afhængighed af en identifikator. Anonyme besøgende kan kun matches med et register via en identifikator gemt på deres enhed, hvilket fører dig tilbage til lokal lagring.

Sammenligning side om side

• Bedst til at huske valget på nettet: first-party cookies, helst sat af din server for en stabil levetid.
• Bedst til detaljerede præferencedata i browseren: localStorage, parret med en cookie, serveren kan læse.
• Bedst til at bevise valget: serverregistre.
• Dårligste enkeltvalg: kun at stole på localStorage, hvilket gør serveren blind og valget skrøbeligt i nogle browsere.

En praktisk kombineret tilgang

1. Gem det autoritative lokale signal — for eksempel TCF-strengen og en kompakt præferenceopsamling — i en first-party cookie afgrænset til dit registrerbare domæne.
2. Brug kun localStorage til supplerende data, der ikke behøver at nå serveren.
3. Skriv et serverregister for hvert valg, inklusive versionen af det viste banner og den viste politik.
4. Hvis et gemt valg forsvinder, så vis banneret igen i stedet for at antage et tidligere svar.
5. Fastsæt en periode, hvorefter gemte valg spørges igen, og skriv den ind i din politik.

At gemme selve den besøgendes samtykkevalg anses generelt for nødvendigt for at levere den tjeneste, den besøgende har bedt om — at huske sin beslutning — men tjek de retningslinjer, der gælder på dine vigtigste markeder.

Vigtigste pointer

• At huske et valg og at bevise et valg er forskellige opgaver, der kræver forskellig lagring.
• Cookies kan læses af serveren og deles på tværs af subdomæner, men er begrænsede i størrelse og, i Safari, i levetid, når de sættes af script.
• localStorage giver plads, men er usynlig for serveren og kan ryddes af browsere.
• Serverregistre er bevislaget, ikke en erstatning for et lokalt signal.
• Kombinér en server-sat first-party cookie, valgfri browserlagring og serverregistre.