Hvorfor Amplitude krever samtykke

Standard Amplitude Browser SDK og Amplitude mobile SDK-er gjør langt mer enn å registrere sidevisninger. Ved initialisering setter de en enhets-ID i førstepartslagring, genererer en sesjons-ID, fanger opp referanselenkens opprinnelse, analyserer UTM- og klikkidentifikatorer fra URL-en, og begynner å sette i kø automatisk registrerte hendelser: sidevisninger, elementklikk, skjemainteraksjoner, filnedlastinger, og — i de nyeste utgivelsene — sesjonsavspillinger. De vil også berike disse hendelsene med IP-avledet geolokasjon, brukeragent-avledet enhetsdata og, hvis konfigurert, tredjeparts berikelse fra datapartnere.

Hvert av disse trinnene engasjerer et separat juridisk grunnlag for samtykke. Å lagre en enhets-ID er en lagrings-og-tilgangsoperasjon under artikkel 5(3) i ePrivacy-direktivet, som krever forutgående, fritt gitt, spesifikt, informert og utvetydig samtykke i Det europeiske økonomiske samarbeidsområdet, Storbritannia og enhver jurisdiksjon som har importert samme standard. Å fange opp atferdshendelser knyttet til den identifikatoren er behandling av personopplysninger under GDPR. Berikelse med tredjepartsdata innfører et andre behandlingsansvarlig-forhold. CCPA og CPRA klassifiserer den samme behandlingen som et salg eller en deling med mindre utgiveren har en korrekt avgrenset tjenesteleverandørkontrakt med Amplitude — som er tilgjengelig, men kun hvis integrasjonen er konfigurert til å deaktivere reklamefunksjoner.

Hva Amplitude samler inn før samtykke — og hva du må undertrykke

Den vanligste implementeringsfeil er å behandle Amplitude som et lett analyseverktøy som kan kjøre ved siden av cookiebanneren. Det kan det ikke. Ved et standard amplitude.init()-kall vil SDK-en, ved den første gjengivelsen av siden, skrive minst én informasjonskapsel- eller lokal lagringsoppføring, sende et identify-kall og begynne å bufre hendelser. Intet av dette er tillatt før en bruker har bekreftet aksept av den relevante samtykkekategorien.

En kompatibel integrering må derfor utsette amplitude.init() til CMP har signalisert at analysekategorien for samtykke er innvilget. SDK-en bør ikke lastes inn i det hele tatt fra et samtykke-portert <script>-tag som er avhengig av CMP-ens formål 8 (analyse)- eller formål 1 (lagring og tilgang)-signal, avhengig av hvilken ramme CMP-en eksponerer. Hvis SDK-en må lastes tidligere — for eksempel fordi den er inkludert i applikasjonskoden og ikke kan hentes lat — bør initialiseringsanropet sende defaultTracking: false og optOut: true slik at ingen hendelser sendes ut før samtykke er registrert, og deretter bør en utsatt opt-in-hendelse vende disse flaggene.

Informasjonskapslene og lagringen Amplitude skriver

Browser SDK 2.x skriver som standard én førstepartskapsel kalt AMP_{apiKey}, med et ett-års utløp, som inneholder enhets-IDen og sesjonsmetadata. Eldre versjoner skrev også amplitude_id_{apiKey}. Mobile SDK-er lagrer den samme identifikatoren inne i applikasjonens sandkasselagring. Sesjonsavspilling legger til en andre informasjonskapsel, AMP_MKTG_{apiKey}, og Amplitudes berikelsespartnere kan angi ytterligere tredjeparts informasjonskapsler hvis eksperiment-targeting eller publikumsmoduler er aktivert. Alle disse er ikke-essensielle og krever samtykke.

Kartlegge Amplitude til samtykkeverk

Amplitude implementerer ikke Google Consent Mode v2, IAB TCF eller IAB Global Privacy Platform native. Det er ikke en mangel — Amplitude er en førstepartsanalyseplattform, ikke en reklameteknologileverandør — men det betyr at integrasjonsansvaret ligger hos utgiveren. Mønsteret som fungerer i praksis er å behandle hver Amplitude-modul som en separat samtykkeport og binde den til et spesifikt signal som CMP-en allerede eksponerer.

• Kjerne analytikkhendelser bindes til analyseformålet. I TCF-termer er dette oftest formål 8 (måle innholdsytelse) kombinert med formål 1 (lagre og/eller få tilgang til informasjon). For Google Consent Mode tilsvarer dette analytics_storage.
• Sesjonsavspilling bør ligge bak et strengere signal. Avspilling fanger opp gjengitt DOM, inkludert skjemaverdier med mindre de eksplisitt er maskert, så en separat opt-in for preferences eller functional er passende, og avspilling bør som standard være av selv når analyse er innvilget.
• Publikum, kohorter og tredjeparts berikelse bindes til markedsføringsformålet. I TCF-termer er dette formål 7 (måle annonseytelse) eller formål 9 (anvende markedsundersøkelse). For Google Consent Mode tilsvarer dette ad_storage og ad_user_data.
• Eksperimentering — Amplitude Experiment kan kjøre med anonym, kortvarig tildeling under en legitim interessebasis, men vedvarende tildeling knyttet til en bruker-ID krever det samme samtykket som kjerne-analyse.

Integrasjonsmønsteret som fungerer

Referanseimplementeringen som overlever en regulators gjennomgang har fire bevegelige deler: en CMP som eksponerer en sanntidshendelse når brukeren endrer samtykke, en utsatt SDK-laster som bare henter Amplitude etter at den hendelsen utløses for den relevante kategorien, en sjonsnivå-vakt som respekterer opt-out uten å miste brukerens tidligere anonyme enhets-ID der loven tillater det, og en server-side bro for hendelser som genuint krever innsamling uavhengig av samtykke — som sikkerhetstelemetri eller svindeldeteksjon — ruter gjennom et separat endepunkt med sitt eget juridiske grunnlag.

Nettimplementering

På nettet er det reneste mønsteret å eksponere CMP-ens samtykkestatus via et window.__cmp_consent-objekt eller standard __tcfapi-tilbakeringing, og deretter ha et lite bootstrap-skript som abonnerer på samtykkeendringer. Når analysesamtykke skifter fra false til true, henter bootstrap-en Amplitude SDK fra CDN-en administrert av CMP, kaller amplitude.init(apiKey, undefined, { defaultTracking: true }), og spiller av eventuelle hendelser som ble satt i kø i minnet mens samtykke var på vent. Når samtykke skifter tilbake til false, kaller bootstrap amplitude.setOptOut(true), fjerner AMP_-informasjonskapselen via document.cookie utløp, og fjerner eventuell minnestatus. Det er kritisk at bootstrap aldri initialiserer Amplitude lat i den samme forespørselsstrømmen som bannervisningen — SDK-en må vente på en eksplisitt tildeling.

Mobilimplementering

På iOS er ekvivalenten å holde Amplitude-rammeverket importert, men utsette Amplitude.instance().initialize(apiKey: apiKey) til samtykkeflyten i appen har returnert et positivt analysesignal. ATT-forespørselen er et separat spørsmål: ATT styrer IDFA, mens Amplitudes identifikator er SDK-ens egen UUID lagret i appens sandkasse. Begge krever samtykke i EEA, men de juridiske grunnlagene og forespørslene er distinkte. På Android gjelder den samme logikken med Amplitude.getInstance().initializeApolloClient() eller tilsvarende avhengig av SDK-versjon.

Server-side modus

Amplitude støtter server-side inntak via HTTP V2 API. Server-side hendelser er ikke fritatt fra samtykke — det juridiske grunnlaget følger dataene, ikke transporten — men server-side inntak gir utgiveren full kontroll over hvilke felt som sendes, noe som gjør det lettere å respektere delvis samtykke. Et vanlig mønster er å fange opp et minimalt, bare-essensielt hendelsessett server-side under legitim interesse, og bare berike disse hendelsene med atferdsdetaljer etter at brukeren har innvilget analysesamtykke på klienten.

Validere integrasjonen

Valideringstrinnet er det utgivere oftest hopper over, og regulatorer oftest sjekker. En korrekt integrert Amplitude-distribusjon bør bestå fire kontroller. For det første bør en nettleser med cookie-banneren vist men uten valg gjort produsere null forespørsler til api.amplitude.com eller api.eu.amplitude.com og null AMP_-informasjonskapsler i document.cookie. For det andre bør avvisning av analytikkategorien opprettholde den tilstanden — ingen hendelser, ingen informasjonskapsler, ingen lokale lagringsoppføringer med et AMP_-prefiks. For det tredje bør aksept av analyse produsere én identify etterfulgt av hendelsestrafikk, og AMP_-informasjonskapselen bør vises med et SameSite-attributt konsistent med utgiverens CMP-policy. For det fjerde bør tilbakekalling av samtykke i ettertid umiddelbart stoppe videre hendelser og slette lagrede identifikatorer — en forsinket opprydding er et funn.

Revisjonssporet er viktig separat. Under EDPBs retningslinjer for cookie-banner fra 2023 og de fornyede prioriteringene til arbeidsgruppen for 2026 forventer regulatorer at utgiveren skal kunne bevise, for enhver gitt hendelse i Amplitude-prosjektet, at brukeren som genererte den hadde gitt gyldig samtykke på tidspunktet for registrering. Det krever at CMP-ens samtykkelogg kan spørres etter enhets-ID eller sesjons-ID, og at Amplitude-hendelsesnyttelasten bærer et versjonsfelt for samtykke som kobles tilbake til den loggen. Å lagre samtykke-strengen som en egendefinert brukeregjenskap på hver hendelse er den enkleste måten å gjøre den koblingen reviderbar på.

Velge riktig region og dataoppholdssted

Amplitude driver to produksjonsregioner: USA (api.amplitude.com) og EU (api.eu.amplitude.com). For EEA- og Storbritannia-trafikk er EU-regionen den rette standardverdien — den holder dataene inne i EEA og reduserer overføringsrisikofasaden som Schrems II-avgjørelsen og EU-US Data Privacy Framework har gjort sentral for enhver analysegjennomgang. Å bytte regioner er ikke retroaktivt: eksisterende data forblir der de ble første gang inntatt. For utgivere som planlegger en CMP-utrulling er det derfor verdt å bekrefte regionen før skalering, og verdt å dokumentere valget i personvernmeldingen slik at den lovlige grunnlagskjeden er ren fra innsamling til lagring. En riktig valgt region, kombinert med en korrekt portert SDK og en spørrbar samtykkelogg, er det som gjør en Amplitude-distribusjon fra en regulatorisk risiko til en forsvarlig del av analysestakken.