Två olika uppgifter

När en besökare gör ett samtyckesval måste två separata saker ske. För det första måste webbläsaren komma ihåg valet så att bannern inte dyker upp igen på varje sida och taggar vet vad de får göra. För det andra kan du senare behöva bevisa att valet gjordes, vad besökaren fick se och när. De här uppgifterna sköts ofta av olika lagringsmekanismer, och att blanda ihop dem orsakar verkliga problem: banners som fortsätter att dyka upp, val som försvinner i vissa webbläsare, eller ingen post att visa upp när någon frågar.

Den här jämförelsen tittar på de tre vanliga alternativen — förstapartscookies, webbläsarlagring som localStorage och serversidiga samtyckesposter — och var var och en passar.

Alternativ 1: förstapartscookies

Cookies är samtyckestillståndets traditionella hem. TCF-CMP:er lagrar vanligtvis samtyckessträngen i en förstapartscookie, och många CMP:er lagrar också sina egna preferensdata i en.

Styrkor

• Läsbara av servern. Cookien skickas med varje förfrågan, så serversidig kod, edgelogik och serversidig taggning kan läsa valet utan att vänta på JavaScript.
• Delbara mellan underdomäner. En cookie som sätts på din registrerbara domän kan täcka underdomänerna www, blog och shop.
• Allmänt förväntade. Många integrationer inom annonsteknik letar efter samtycke i cookies.

Svagheter

• Storleksgränser. Webbläsare begränsar cookiestorleken till cirka 4 KB, och en TCF-sträng med många leverantörer plus andra värden kan närma sig det.
• Förfrågningsoverhead. Varje förfrågan till din domän bär cookien, inklusive bild- och skriptförfrågningar.
• Livslängdsgränser i vissa webbläsare. Safaris Intelligent Tracking Prevention begränsar cookies som skapas via JavaScript till en maximal livslängd på sju dagar. Cookies som sätts av din egen server i ett HTTP-svar behandlas i allmänhet mer generöst, även om det finns undantag.

Alternativ 2: localStorage och annan webbläsarlagring

Vissa CMP:er lagrar detaljerade preferenser i localStorage, ibland vid sidan av en mindre cookie.

Styrkor

• Mer utrymme. Flera megabyte per origin, tillräckligt för detaljerade val på leverantörsnivå.
• Ingen förfrågningsoverhead. Inget skickas automatiskt till servern.

Svagheter

• Osynlig för servern. Serversidig kod och edgelogik kan inte läsa den, så varje serversidigt beslut måste vänta på webbläsaren.
• Bunden till en origin. Lagring på www.example.com är inte tillgänglig på shop.example.com, så en besökare kan se bannern igen på varje underdomän.
• Utsatt för radering. Safari kan ta bort skriptskrivbar lagring, inklusive localStorage, för webbplatser som användaren inte interagerat med under sju dagars webbläsaranvändning, och privata surfningslägen rensar den vanligtvis när sessionen tar slut.

Alternativ 3: serversidiga samtyckesposter

En serversidig post är en post som du eller din CMP-leverantör lagrar varje gång ett val görs. Den innehåller vanligtvis en pseudonym identifierare, tidsstämpeln, valen, den visade banner- eller policyversionen och kontext som region.

Styrkor

• Hållbart bevis. Den överlever cookierensning och webbläsarbegränsningar, vilket gör den till rätt verktyg för att visa att samtycke inhämtats.
• Granskningsbar. Du kan rapportera om val över tid och svara på frågor om specifika händelser.
• Potential över enheter. För inloggade läsare kan en serverpost synkronisera val mellan enheter, om du förklarar det för dem.

Svagheter

• Ingen ersättning för lokalt tillstånd. Taggar i webbläsaren behöver fortfarande en snabb, lokal signal; att anropa en server vid varje sidvisning för att slå upp samtycke ger fördröjning.
• Den är i sig personuppgifter. Poster behöver en lagringstid, åtkomstkontroller och en plats i ditt integritetsmeddelande.
• Beroende av identifierare. Anonyma besökare kan bara matchas mot en post via en identifierare lagrad på deras enhet, vilket för dig tillbaka till lokal lagring.

Sammanfattning sida vid sida

• Bäst för att komma ihåg valet på webben: förstapartscookies, helst satta av din server med stabil livslängd.
• Bäst för detaljerade preferensdata i webbläsaren: localStorage, i par med en cookie som servern kan läsa.
• Bäst för att bevisa valet: serversidiga poster.
• Sämsta enskilda val: att bara förlita sig på localStorage, vilket gör servern blind och valet skört i vissa webbläsare.

Ett praktiskt kombinerat tillvägagångssätt

1. Lagra den auktoritativa lokala signalen — till exempel TCF-strängen och en kompakt preferenspost — i en förstapartscookie som gäller din registrerbara domän.
2. Använd localStorage bara för kompletterande data som inte behöver nå servern.
3. Skriv en serversidig post för varje val, inklusive versionen av den visade bannern och policyn.
4. Om ett lagrat val försvinner, visa bannern igen i stället för att anta ett tidigare svar.
5. Ange en period för förnyad fråga för lagrade val och dokumentera den i din policy.

Att lagra själva besökarens samtyckesval betraktas i allmänhet som nödvändigt för att leverera den tjänst besökaren bad om — att komma ihåg deras beslut — men kontrollera den vägledning som gäller på dina huvudmarknader.

Viktigaste lärdomarna

• Att komma ihåg ett val och att bevisa ett val är olika uppgifter som kräver olika lagring.
• Cookies är läsbara av servern och delbara mellan underdomäner men begränsade i storlek och, i Safari, livslängd när de sätts av skript.
• localStorage erbjuder utrymme men är osynlig för servern och kan rensas av webbläsare.
• Serversidiga poster är bevislagret, inte en ersättning för en lokal signal.
• Kombinera en serversatt förstapartscookie, valfri webbläsarlagring och serverposter.