Waarom Amplitude toestemming vereist

De standaard Amplitude Browser SDK en de Amplitude mobiele SDK's doen veel meer dan paginaweergaven registreren. Bij initialisatie stellen ze een apparaat-ID in in de opslag van de eerste partij, genereren ze een sessie-ID, leggen ze de verwijzer vast, parseren ze UTM- en klikidentificatoren uit de URL en beginnen ze automatisch vastgelegde gebeurtenissen in de wachtrij te plaatsen: paginaweergaven, elementkliks, formulierinteracties, bestandsdownloads en — in de nieuwste versies — sessieherspelingen. Ze verrijken die gebeurtenissen ook met IP-afkomstige geolocatie, user-agent-afkomstige apparaatgegevens en, indien geconfigureerd, verrijking van derden van datapartners.

Elk van die stappen brengt een afzonderlijke juridische grondslag voor toestemming met zich mee. Het opslaan van een apparaat-ID is een opslag- en toegangsoperatie onder artikel 5, lid 3, van de ePrivacy-richtlijn, waarvoor in de Europese Economische Ruimte, het Verenigd Koninkrijk en elke jurisdictie die dezelfde norm heeft overgenomen, voorafgaande, vrij gegeven, specifieke, geïnformeerde en ondubbelzinnige toestemming is vereist. Het vastleggen van gedragsgebeurtenissen die aan dat ID zijn gekoppeld, is de verwerking van persoonsgegevens onder de GDPR. Verrijking met gegevens van derden introduceert een tweede verwerkingsverantwoordelijke-relatie. De CCPA en CPRA classificeren dezelfde verwerking als een verkoop of deling, tenzij de uitgever een correct afgebakend dienstverleningscontract met Amplitude heeft — dat beschikbaar is, maar alleen als de integratie is geconfigureerd om advertentiefuncties uit te schakelen.

Wat Amplitude vóór toestemming verzamelt — en wat u moet onderdrukken

De meest voorkomende implementatiefout is Amplitude behandelen als een lichtgewicht analysetool die naast de cookiebanner kan draaien. Dat kan niet. Bij een standaard amplitude.init()-aanroep schrijft de SDK bij de eerste render van de pagina minstens één cookie- of lokale opslagvermelding, verstuurt een identify-aanroep en begint met het bufferen van gebeurtenissen. Niets van dat alles is toelaatbaar voordat een gebruiker de relevante toestemmingscategorie uitdrukkelijk heeft geaccepteerd.

Een conforme integratie moet daarom amplitude.init() uitstellen totdat het CMP heeft gesignaleerd dat de toestemmingscategorie voor analyse is verleend. De SDK mag helemaal niet worden geladen vanuit een toestemmingsblokkeerend <script>-tag dat afhankelijk is van het doel 8 (analyse)- of doel 1 (opslag en toegang)-signaal van het CMP, afhankelijk van welk raamwerk het CMP blootstelt. Als de SDK eerder moet worden geladen — bijvoorbeeld omdat het in de applicatiecode is gebundeld en niet lui kan worden opgehaald — moet de initialisatieaanroep defaultTracking: false en optOut: true doorgeven zodat er geen gebeurtenissen worden uitgezonden totdat toestemming is vastgelegd, waarna een uitgestelde opt-in-gebeurtenis die vlaggen moet omzetten.

De cookies en opslag die Amplitude schrijft

De Browser SDK 2.x schrijft standaard één eerste-partij-cookie met de naam AMP_{apiKey}, met een vervaldatum van één jaar, die de apparaat-ID en sessiemetadata bevat. Oudere versies schreven ook amplitude_id_{apiKey}. Mobiele SDK's bewaren dezelfde identifier in de sandboxopslag van de applicatie. Sessieherspeling voegt een tweede cookie toe, AMP_MKTG_{apiKey}, en Amplitude-verrijkingspartners kunnen aanvullende cookies van derden instellen als de modules voor experiment-targeting of doelgroepen zijn ingeschakeld. Al deze zijn niet-essentieel en vereisen toestemming.

Amplitude koppelen aan toestemmingsraamwerken

Amplitude implementeert Google Consent Mode v2, het IAB TCF of het IAB Global Privacy Platform niet van nature. Dat is geen gebrek — Amplitude is een eerste-partij-analyseplatform, geen advertentietechnologieleverancier — maar het betekent wel dat de integratieverantwoordelijkheid bij de uitgever ligt. Het patroon dat in de praktijk werkt, is elk Amplitude-module te behandelen als een afzonderlijke toestemmingspoort en deze te koppelen aan een specifiek signaal dat het CMP al blootstelt.

• Kernanalysegebeurtenissen koppelen aan het analysedoel. In TCF-termen is dit het meest gebruikelijk doel 8 (meten van inhoudsprestaties) gecombineerd met doel 1 (opslaan en/of toegang tot informatie). Voor Google Consent Mode wordt dit gekoppeld aan analytics_storage.
• Sessieherspeling moet achter een strenger signaal zitten. Herspeling legt gerenderde DOM vast, inclusief formulierwaarden tenzij expliciet gemaskeerd, dus een aparte opt-in voor preferences of functional is gepast, en herspeling moet standaard uitstaan, zelfs wanneer analyse is verleend.
• Doelgroepen, cohorten en verrijking van derden koppelen aan het marketingdoel. In TCF-termen is dit doel 7 (meten van advertentieprestaties) of doel 9 (marktonderzoek toepassen). Voor Google Consent Mode wordt dit gekoppeld aan ad_storage en ad_user_data.
• Experimentatie — Amplitude Experiment kan met anonieme, tijdelijke toewijzing op basis van gerechtvaardigde belangen draaien, maar persistente toewijzing gekoppeld aan een gebruikers-ID vereist dezelfde toestemming als kernanalyse.

Het integratiepatroon dat werkt

De referentie-implementatie die een toezichthouderscontrole doorstaat, heeft vier bewegende delen: een CMP dat een realtimegebeurtenis blootstelt wanneer de gebruiker toestemming wijzigt, een uitgestelde SDK-lader die Amplitude alleen ophaalt nadat die gebeurtenis voor de relevante categorie is geactiveerd, een beveiliging op sessieniveau die opt-out respecteert zonder de eerder anonieme apparaat-ID van de gebruiker te verliezen waar de wet dit toestaat, en een server-side brug voor gebeurtenissen die werkelijk verzameld moeten worden ongeacht toestemming — zoals beveiligingstelemetrie of fraudedetectie — gerouteerd via een apart eindpunt met zijn eigen juridische grondslag.

Webimplementatie

Op het web is het schoonste patroon de toestemmingsstatus van het CMP bloot te stellen via een window.__cmp_consent-object of de standaard __tcfapi-callback, en vervolgens een klein bootstrap-script toestemmingswijzigingen te laten abonneren. Wanneer analysetoestemming van false naar true omschakelt, haalt het bootstrap de Amplitude SDK op van het door het CMP beheerde CDN, roept amplitude.init(apiKey, undefined, { defaultTracking: true }) aan en speelt eventuele gebeurtenissen opnieuw af die in het geheugen stonden te wachten terwijl toestemming in behandeling was. Wanneer toestemming terugschakelt naar false, roept het bootstrap amplitude.setOptOut(true) aan, wist de AMP_-cookie via document.cookie-vervaldatum en verwijdert eventuele in-memory staat. Cruciaal: het bootstrap mag Amplitude nooit lui initialiseren in dezelfde aanvraagstroom als de bannerweergave — de SDK moet wachten op een expliciete verlening.

Mobiele implementatie

Op iOS is het equivalent het Amplitude-raamwerk geïmporteerd te houden maar Amplitude.instance().initialize(apiKey: apiKey) uit te stellen totdat de in-app-toestemmingsstroom een positief analysesignaal heeft teruggegeven. De ATT-prompt is een afzonderlijke kwestie: ATT regelt de IDFA, terwijl Amplitude's identifier de eigen UUID van de SDK is die is opgeslagen in de app-sandbox. Beide vereisen toestemming in de EEA, maar de juridische grondslagen en prompts zijn afzonderlijk. Op Android geldt dezelfde logica met Amplitude.getInstance().initializeApolloClient() of het equivalent afhankelijk van de SDK-versie.

Server-side modus

Amplitude ondersteunt server-side opname via de HTTP V2 API. Server-side gebeurtenissen zijn niet vrijgesteld van toestemming — de juridische grondslag volgt de gegevens, niet het transport — maar server-side opname geeft de uitgever volledige controle over welke velden worden verzonden, waardoor het eenvoudiger is om gedeeltelijke toestemming te respecteren. Een veelgebruikt patroon is om een minimale, alleen-essentiële-gebeurtenissenset server-side te verzamelen onder gerechtvaardigde belangen, en die gebeurtenissen pas te verrijken met gedragsdetails nadat de gebruiker analysetoestemming op de client heeft verleend.

De integratie valideren

De validatiestap is de stap die uitgevers het vaakst overslaan en toezichthouders het vaakst controleren. Een correct geïntegreerde Amplitude-implementatie moet vier controles doorstaan. Ten eerste moet een browser met de getoonde toestemmingsbanner maar zonder gemaakte keuze nul verzoeken aan api.amplitude.com of api.eu.amplitude.com produceren en nul AMP_-cookies in document.cookie. Ten tweede moet het weigeren van de analysecategorie die toestand handhaven — geen gebeurtenissen, geen cookies, geen lokale opslagvermeldingen met een AMP_-voorvoegsel. Ten derde moet het accepteren van analyse één identify produceren gevolgd door gebeurtenisverkeer, en de AMP_-cookie moet verschijnen met een SameSite-attribuut dat consistent is met het CMP-beleid van de uitgever. Ten vierde moet het intrekken van toestemming achteraf onmiddellijk verdere gebeurtenissen stoppen en opgeslagen identificatoren wissen — een vertraagde opruiming is een bevinding.

Het auditspoor is afzonderlijk van belang. Onder de EDPB-cookiebannerrichtlijnen van 2023 en de vernieuwde taskforce-prioriteiten van 2026 verwachten toezichthouders dat de uitgever voor elke gebeurtenis in het Amplitude-project kan bewijzen dat de gebruiker die de gebeurtenis genereerde, op het moment van vastlegging geldige toestemming had gegeven. Dat vereist dat het CMP-toestemmingslogboek opvraagbaar is op apparaat-ID of sessie-ID, en dat de Amplitude-gebeurtenislading een veld met de toestemmingsversie bevat dat terugverwijst naar dat logboek. Het opslaan van de toestemmingsstring als aangepaste gebruikerseigenschap bij elke gebeurtenis is de eenvoudigste manier om die koppeling controleerbaar te maken.

De juiste regio en gegevensresidentie kiezen

Amplitude heeft twee productieregio's: de VS (api.amplitude.com) en de EU (api.eu.amplitude.com). Voor EEA- en VK-verkeer is de EU-regio de juiste standaard — het houdt gegevens binnen de EEA en verkleint het overdrachtsrisicooppervlak dat de Schrems II-uitspraak en het EU-VS-gegevensprivacyraamwerk centraal hebben gesteld in elke analysecontrole. Van regio wisselen is niet retroactief: bestaande gegevens blijven waar ze voor het eerst zijn ingevoerd. Voor uitgevers die een CMP-uitrol plannen, is het dan ook de moeite waard de regio te bevestigen vóór opschaling, en de keuze in de privacymelding te documenteren zodat de keten van juridische grondslagen van verzameling tot opslag sluitend is. Een correct gekozen regio, gecombineerd met een correct afgeschermde SDK en een opvraagbaar toestemmingslogboek, is wat een Amplitude-implementatie verandert van een regelgevingsrisico in een verdedigbaar onderdeel van de analysestack.