Varför Amplitude kräver samtycke

Standard-SDK:n för Amplitude Browser och Amplitude mobilSDKer gör mycket mer än att registrera sidvisningar. Vid initiering sätter de en enhetsidentifierare i förstapartslagring, genererar en sessionsidentifierare, fångar refereraren, tolkar UTM och klickidentifierare från URL:en, och börjar köa automatiskt registrerade händelser: sidvisningar, elementklick, formulärinteraktioner, filnedladdningar och — i de senaste utgåvorna — sessionsuppspelningar. De berikar också dessa händelser med IP-härledd geolokalisering, user-agent-härledd enhetsdata och, om konfigurerat, tredjepartsanrikning från datapartners.

Vart och ett av dessa steg engagerar en separat rättslig grund för samtycke. Att lagra en enhetsidentifierare är en lagrings-och-åtkomstoperation under artikel 5(3) i ePrivacy-direktivet, vilket kräver föregående, fritt givet, specifikt, informerat och otvetydigt samtycke inom Europeiska ekonomiska samarbetsområdet, Storbritannien och alla jurisdiktioner som har importerat samma standard. Att fånga beteendehändelser kopplade till den identifieraren är behandling av personuppgifter under GDPR. Berikande med tredjepartsdata introducerar ett andra kontrollantförhållande. CCPA och CPRA klassificerar samma behandling som en försäljning eller delning om inte utgivaren har ett korrekt avgränsat tjänsteleverantörsavtal med Amplitude — vilket är tillgängligt, men bara om integrationen är konfigurerad för att inaktivera annonsfunktioner.

Vad Amplitude samlar in innan samtycke — och vad du måste undertrycka

Det vanligaste implementationsfelet är att behandla Amplitude som ett lättviktigt analysverktyg som kan köra bredvid cookie-bannern. Det kan det inte. Vid ett standardanrop för amplitude.init() kommer SDK:n, inom den första renderingen av sidan, att skriva minst en cookie eller lokalt lagringspost, skicka ett identifieringsanrop och börja buffra händelser. Inget av det är tillåtet innan en användare uttryckligen har accepterat relevant samtyckeskategori.

En kompatibel integration måste därför fördröja amplitude.init() tills CMP har signalerat att samtyckeskategorin för analys har beviljats. SDK:n bör inte laddas alls från en samtyckesskyddad <script>-tagg som är beroende av CMP:s syfte 8 (analys) eller syfte 1 (lagring och åtkomst)-signal, beroende på vilket ramverk CMP:n exponerar. Om SDK:n måste laddas tidigare — till exempel för att den är buntad i applikationskoden och inte kan hämtas lazily — bör initialiseringsanropet skicka defaultTracking: false och optOut: true så att inga händelser sänds ut tills samtycke registreras, och sedan bör en fördröjd opt-in-händelse vända dessa flaggor.

Cookies och lagring som Amplitude skriver

Browser SDK 2.x skriver som standard en enda förstapartscookie med namnet AMP_{apiKey}, med ett ettårs utgångsdatum, som innehåller enhetsidentifieraren och sessionsmetadata. Äldre versioner skrev även amplitude_id_{apiKey}. Mobila SDKer bevarar samma identifierare inuti applikationens sandboxade lagring. Sessionsuppspelning lägger till en andra cookie, AMP_MKTG_{apiKey}, och Amplitudes anrikningspartners kan sätta ytterligare tredjepartscookies om experimentsyftnings- eller målgruppsmodulerna är aktiverade. Alla dessa är icke-väsentliga och kräver samtycke.

Kartläggning av Amplitude mot samtyckesramverk

Amplitude implementerar inte nativt Google Consent Mode v2, IAB TCF eller IAB Global Privacy Platform. Det är inte en brist — Amplitude är en förstapartsanalysplattform, inte en leverantör av annonsteknologi — men det innebär att integrationsansvaret vilar på utgivaren. Mönstret som fungerar i praktiken är att behandla varje Amplitude-modul som en separat samtyckesgrind och binda den till en specifik signal som CMP:n redan exponerar.

• Käranalytiska händelser binds till analyssyftet. I TCF-termer är detta vanligtvis syfte 8 (mäta innehållsprestanda) kombinerat med syfte 1 (lagra och/eller komma åt information). För Google Consent Mode mappar detta till analytics_storage.
• Sessionsuppspelning bör stå bakom en strängare signal. Uppspelning fångar renderad DOM, inklusive formulärvärden om de inte explicit maskas, så en separat preferences eller functional opt-in är lämplig, och uppspelning bör vara avstängd som standard även när analys beviljas.
• Målgrupper, kohorter och tredjepartsanrikning binds till marknadsföringssyftet. I TCF-termer är detta syfte 7 (mäta annonsprestanda) eller syfte 9 (tillämpa marknadsundersökning). För Google Consent Mode mappar detta till ad_storage och ad_user_data.
• Experimentering — Amplitude Experiment kan köra med anonym, efemär allokering under en berättigad intressebasis, men beständig allokering kopplad till en användaridentifierare kräver samma samtycke som käranalys.

Integrationsmönstret som fungerar

Referensimplementationen som överlever en tillsynsmyndighets granskning har fyra rörliga delar: en CMP som exponerar en händelse i realtid när användaren ändrar samtycke, en fördröjd SDK-laddare som bara hämtar Amplitude efter att den händelsen utlöses för relevant kategori, en skydd på sessionsnivå som respekterar opt-out utan att förlora användarens tidigare anonyma enhetsidentifierare där lagen tillåter, och en server-side brygga för händelser som verkligen kräver insamling oavsett samtycke — som säkerhetstelemetri eller bedrägeridetiktion — routad genom en separat slutpunkt med sin egen rättsliga grund.

Webb-implementation

På webben är det renaste mönstret att exponera CMP:ns samtyckestillstånd via ett window.__cmp_consent-objekt eller det standardiserade __tcfapi-återanropet, och sedan ha ett litet bootstrap-skript som prenumererar på samtyckesändringar. När analys-samtycke växlar från false till true hämtar bootstrap Amplitude SDK från CMP-hanterad CDN, anropar amplitude.init(apiKey, undefined, { defaultTracking: true }), och spelar upp alla händelser som var köade i minnet medan samtycke väntade. När samtycke växlar tillbaka till false anropar bootstrap amplitude.setOptOut(true), rensar AMP_-cookien via document.cookie-utgång och tar bort eventuellt minnestillstånd. Avgörande är att bootstrap aldrig lazily ska initialisera Amplitude i samma begärandeflöde som banner-renderingen — SDK:n måste vänta på ett uttryckligt beviljande.

Mobil implementation

På iOS är motsvarigheten att hålla Amplitude-ramverket importerat men skjuta upp Amplitude.instance().initialize(apiKey: apiKey) tills in-app-samtyckesflödet har returnerat en positiv analyssignal. ATT-prompten är en separat fråga: ATT styr IDFA, medan Amplitudes identifierare är SDK:ns eget UUID lagrat i applikationens sandbox. Båda kräver samtycke i EEA, men de rättsliga grunderna och prompterna är distinkta. På Android gäller samma logik med Amplitude.getInstance().initializeApolloClient() eller motsvarigheten beroende på SDK-version.

Server-side-läge

Amplitude stödjer server-side inmatning via HTTP V2 API. Server-side-händelser är inte undantagna från samtycke — den rättsliga grunden följer datan, inte transporten — men server-side inmatning ger utgivaren full kontroll över vilka fält som skickas, vilket gör det lättare att respektera partiellt samtycke. Ett vanligt mönster är att fånga en minimal uppsättning enbart-essentiella händelser server-side under legitimt intresse, och bara berika dessa händelser med beteendedetaljer efter att användaren har beviljat analysamtycke på klienten.

Validering av integrationen

Valideringssteget är det som utgivare oftast hoppar över och tillsynsmyndigheter oftast kontrollerar. En korrekt integrerad Amplitude-driftsättning bör klara fyra kontroller. Först bör en webbläsare med samtyckesbannen visad men inget val gjort producera noll förfrågningar till api.amplitude.com eller api.eu.amplitude.com och noll AMP_-cookies i document.cookie. Andra bör avvisandet av analytikkategorin behålla det tillståndet — inga händelser, inga cookies, inga lokala lagringsposter med ett AMP_-prefix. Tredje bör accepterandet av analys producera en enda identify följt av händelsetrafik, och AMP_-cookien bör visas med ett SameSite-attribut konsekvent med utgivarens CMP-policy. Fjärde bör återkallande av samtycke i efterhand omedelbart stoppa ytterligare händelser och rensa lagrade identifierare — en fördröjd rensning är ett fynd.

Revisionsspåret spelar roll separat. Under EDPBs riktlinjer för cookie-banners från 2023 och de förnyade arbetsgruppsprioriteringarna för 2026 förväntar sig tillsynsmyndigheter att utgivaren ska kunna bevisa, för varje given händelse i Amplitude-projektet, att användaren som genererade den hade givit giltigt samtycke vid insamlingstillfället. Det kräver att CMP:ns samtyckeslogg är frågningsbar med enhetsidentifierare eller sessionsidentifierare, och att Amplitude-händelsens nyttolast bär ett samtyckesversionsfält som kopplar tillbaka till den loggen. Att lagra samtyckssträngen som en anpassad användaregenskap på varje händelse är det enklaste sättet att göra den länken revideringsbar.

Att välja rätt region och dataresidency

Amplitude driver två produktionsregioner: USA (api.amplitude.com) och EU (api.eu.amplitude.com). För EEA- och UK-trafik är EU-regionen rätt standard — den håller datan inuti EEA och minskar transferrisk-ytan som Schrems II-beslutet och EU-US Data Privacy Framework har gjort central i varje analysgenomgång. Att byta region är inte retroaktivt: befintlig data stannar där den först matades in. För utgivare som planerar en CMP-utrullning är det därför värt att bekräfta regionen innan skalning, och värt att dokumentera valet i integritetsmeddelandet så att den rättsliga grundkedjan är ren från insamling till lagring. En korrekt vald region, parad med en korrekt begränsad SDK och en frågningsbar samtyckeslogg, är det som förvandlar en Amplitude-driftsättning från en regulatorisk risk till en försvarbar del av analysstacken.