Hvorfor Amplitude kræver samtykke

Standard Amplitude Browser SDK og Amplitude mobilsdk'er gør langt mere end blot at registrere sidevisninger. Ved initialisering angiver de et enhedsidentifikator i førstepartslagring, genererer et sessionsidentifikator, opfanger referenten, analyserer UTM og klikidentifikatorer fra URL'en og begynder at sætte automatisk opfangede begivenheder i kø: sidevisninger, elementklik, formularinteraktioner, fildownloads og — i de nyeste udgivelser — sessionsafspilninger. De vil også berige disse begivenheder med IP-afledt geolokation, brugeragent-afledte enhedsdata og, hvis konfigureret, tredjeparts berigelse fra datapartnere.

Hvert af disse trin involverer et separat samtykkeretsgrundlag. Lagring af et enhedsidentifikator er en lagrings-og-adgangs-operation i henhold til artikel 5(3) i ePrivacy-direktivet, som kræver forudgående, frit givet, specifikt, informeret og utvetydigt samtykke i Det Europæiske Økonomiske Samarbejdsområde, Det Forenede Kongerige og enhver jurisdiktion, der har importeret den samme standard. Opfangning af adfærdsbegivenheder knyttet til dette identifikator er behandling af personoplysninger i henhold til GDPR. Berigelse med tredjepartsdata introducerer et andet kontrollerforhold. CCPA og CPRA klassificerer den samme behandling som et salg eller en deling, medmindre udgiveren har en korrekt afgrænset tjenesteudbyder-kontrakt med Amplitude — som er tilgængelig, men kun hvis integrationen er konfigureret til at deaktivere reklamefunktioner.

Hvad Amplitude indsamler før samtykke — og hvad du skal undertrykke

Den mest almindelige implementeringsfejl er at behandle Amplitude som et let analyseværktøj, der kan køre ved siden af cookiebanneret. Det kan det ikke. Ved et standard amplitude.init()-kald vil SDK'en inden for den første gengivelse af siden skrive mindst én cookie- eller lokallagringspost, sende et identify-kald og begynde at buffere begivenheder. Ingen af disse er tilladt, inden en bruger bekræftende har accepteret den relevante samtykkekategori.

En compliant integration skal derfor forsinke amplitude.init(), indtil CMP'en har signaleret, at analysesamtykkekategorien er blevet tildelt. SDK'en bør slet ikke indlæses fra et samtykke-gated <script>-tag, der afhænger af CMP'ens formål 8 (analyse) eller formål 1 (lagring og adgang) signal, afhængigt af hvilken ramme CMP'en eksponerer. Hvis SDK'en skal indlæses tidligere — for eksempel fordi den er bundlet i applikationskoden og ikke kan hentes dovent — bør initialiseringskaldets overføre defaultTracking: false og optOut: true, så ingen begivenheder udsendes, før samtykke er registreret, og derefter bør en forsinket opt-in-begivenhed vende disse flag.

Cookies og lagring, som Amplitude skriver

Browser SDK 2.x skriver som standard en enkelt førstepartscookie med navnet AMP_{apiKey} med en etårig udløb, der indeholder enhedsidentifikatoren og sessionsmetadata. Ældre versioner skrev også amplitude_id_{apiKey}. Mobilsdk'er bevarer det samme identifikator inde i applikationens sandkasselagring. Sessionsafspilning tilføjer en anden cookie, AMP_MKTG_{apiKey}, og Amplitudes berigelsespartnere kan sætte yderligere tredjeparts cookies, hvis eksperiment-targeting- eller publikumsmodulerne er aktiveret. Alle disse er ikke-essentielle og kræver samtykke.

Kortlægning af Amplitude til samtykkerammer

Amplitude implementerer ikke native Google Consent Mode v2, IAB TCF eller IAB Global Privacy Platform. Det er ikke en defekt — Amplitude er en førstepartsanalyseplatform, ikke en adtech-leverandør — men det betyder, at integrationsansvaret ligger hos udgiveren. Det mønster, der virker i praksis, er at behandle hvert Amplitude-modul som en separat samtykkeport og binde det til et specifikt signal, som CMP'en allerede eksponerer.

• Kerneanalysebegivenheder bindes til analyseformålet. I TCF-termer er dette oftest formål 8 (måle indholdsydelse) kombineret med formål 1 (gemme og/eller få adgang til oplysninger). For Google Consent Mode kortlægger dette til analytics_storage.
• Sessionsafspilning bør ligge bag et strengere signal. Afspilning opfanger det gengivede DOM, inklusive formularværdier, medmindre de er eksplicit maskeret, så en separat preferences eller functional opt-in er passende, og afspilning bør som standard være slået fra, selv når analyse er tildelt.
• Målgrupper, kohorter og tredjeparts berigelse bindes til markedsføringsformålet. I TCF-termer er dette formål 7 (måle annonceringsydelse) eller formål 9 (anvende markedsundersøgelser). For Google Consent Mode kortlægger dette til ad_storage og ad_user_data.
• Eksperimentering — Amplitude Experiment kan køre med anonym, efemer allokering under et legitimt interessegrundlag, men vedvarende allokering bundet til et brugeridentifikator kræver det samme samtykke som kerneanalyse.

Det integrationsmønster, der virker

Referenceimplementeringen, der overlever en tilsynsmyndigheds gennemgang, har fire bevægelige dele: en CMP, der eksponerer en realtidsbegivenhed, når brugeren ændrer samtykke, en forsinket SDK-indlæser, der kun henter Amplitude, efter at denne begivenhed er affyret for den relevante kategori, en sessions-niveau-vagt, der respekterer fravalg uden at miste brugerens tidligere anonyme enhedsidentifikator, hvor loven tillader det, og en serverside-bro til begivenheder, der genuint kræver indsamling uanset samtykke — såsom sikkerhedstelemetri eller svindeldetektering — rutet gennem et separat slutpunkt med sit eget retsgrundlag.

Webimplementering

På nettet er det reneste mønster at eksponere CMP'ens samtykkestatus via et window.__cmp_consent-objekt eller standard __tcfapi-tilbagekald, og derefter have et lille bootstrap-script, der abonnerer på samtykkeændringer. Når analysesamtykke skifter fra false til true, henter bootstrappet Amplitude SDK fra CMP-administreret CDN, kalder amplitude.init(apiKey, undefined, { defaultTracking: true }) og afspiller alle begivenheder, der var i kø i hukommelsen, mens samtykket var afventende. Når samtykke skifter tilbage til false, kalder bootstrappet amplitude.setOptOut(true), rydder AMP_-cookien via document.cookie-udløb og fjerner eventuel in-memory-tilstand. Kritisk set må bootstrappet aldrig dovne initialisere Amplitude i det samme anmodningsflow som bannergengivelse — SDK'en skal vente på en eksplicit tildeling.

Mobilimplementering

På iOS er tilsvarende at holde Amplitude-frameworket importeret, men forsinke Amplitude.instance().initialize(apiKey: apiKey), indtil in-app-samtykkeforløbet har returneret et positivt analysesignal. ATT-prompten er et separat anliggende: ATT styrer IDFA, mens Amplitudes identifikator er SDK'ens eget UUID gemt i app-sandkassen. Begge kræver samtykke i EØS, men retsgrundlagene og prompterne er adskilte. På Android gælder den samme logik med Amplitude.getInstance().initializeApolloClient() eller tilsvarende afhængigt af SDK-versionen.

Serverside-tilstand

Amplitude understøtter serverside-indtagelse via HTTP V2 API. Serverside-begivenheder er ikke fritaget for samtykke — retsgrundlaget følger data, ikke transporten — men serverside-indtagelse giver udgiveren fuld kontrol over, hvilke felter der sendes, hvilket gør det nemmere at respektere delvist samtykke. Et almindeligt mønster er at opfange et minimalt, kun-essensielt begivenhedssæt serverside under legitimt interesse og kun berige disse begivenheder med adfærdsdetaljer, efter at brugeren har tildelt analysesamtykke på klienten.

Validering af integrationen

Valideringstrinnet er det, som udgivere oftest springer over, og som tilsynsmyndigheder oftest kontrollerer. En korrekt integreret Amplitude-implementering bør bestå fire kontroller. For det første bør en browser med samtykkebanneret vist, men uden valg foretaget, producere nul anmodninger til api.amplitude.com eller api.eu.amplitude.com og nul AMP_-cookies i document.cookie. For det andet bør afvisning af analysekategorien fastholde denne tilstand — ingen begivenheder, ingen cookies, ingen lokallagringsposter med et AMP_-præfiks. For det tredje bør accept af analyse producere en enkelt identify efterfulgt af begivenhedstrafik, og AMP_-cookien bør fremstå med et SameSite-attribut, der er konsekvent med udgiverens CMP-politik. For det fjerde bør tilbagetrækning af samtykke efterfølgende straks stoppe yderligere begivenheder og rydde gemte identifikatorer — forsinket oprydning er et fund.

Revisionssporet er vigtigt separat. Under EDPB's 2023 cookiebanner-retningslinjer og de fornyede 2026 taskforce-prioriteter forventer tilsynsmyndigheder, at udgiveren er i stand til at bevise for enhver given begivenhed i Amplitude-projektet, at den bruger, der genererede den, havde givet gyldigt samtykke på tidspunktet for opfangning. Dette kræver, at CMP'ens samtykkelogfil kan forespørges på enhedsidentifikator eller sessionsidentifikator, og at Amplitude-begivenhedsnytteLasten bærer et samtykke-versionsfelt, der peger tilbage til den log. At gemme samtykkestrengen som en brugerdefineret brugeregenskab på hver begivenhed er den enkleste måde at gøre dette link revisionssporbart på.

Valg af den rigtige region og dataopbevaring

Amplitude driver to produktionsregioner: USA (api.amplitude.com) og EU (api.eu.amplitude.com). For EØS- og UK-trafik er EU-regionen den rigtige standard — den holder data inden for EØS og reducerer den overførselsrisikovlade, som Schrems II-dommen og EU-US Data Privacy Framework har gjort central for enhver analytikgennemgang. Skift af regioner er ikke tilbagevirkende: eksisterende data forbliver der, hvor de først blev indsamlet. For udgivere, der planlægger en CMP-udrulning, er det derfor værd at bekræfte regionen inden skalering og dokumentere valget i privatlivsmeddelelsen, så retsgrundlagskæden er ren fra indsamling til lagring. En korrekt valgt region, kombineret med et korrekt afgrænset SDK og en forespørgbar samtykkelogfil, er det, der forvandler en Amplitude-implementering fra en regulatorisk risiko til en forsvarlig del af analysstacken.