Warum Amplitude eine Einwilligung erfordert

Das standardmäßige Amplitude Browser SDK und die mobilen Amplitude SDKs tun weit mehr als nur Seitenaufrufe zu erfassen. Bei der Initialisierung setzen sie einen Geräteidentifikator im Erstanbieter-Speicher, generieren einen Sitzungsidentifikator, erfassen den Referrer, analysieren UTM- und Klickidentifikatoren aus der URL und beginnen, automatisch erfasste Ereignisse in die Warteschlange einzureihen: Seitenaufrufe, Element-Klicks, Formularinteraktionen, Dateidownloads und — in den neuesten Versionen — Sitzungswiederholungen. Außerdem reichern sie diese Ereignisse mit IP-abgeleiteter Geolokalisierung, User-Agent-abgeleiteten Gerätedaten und, wenn konfiguriert, Drittanbieter-Anreicherung von Datenpartnern an.

Jeder dieser Schritte beinhaltet eine separate Rechtsgrundlage für die Einwilligung. Das Speichern eines Geräteidentifikators ist ein Speicher-und-Zugriffs-Vorgang gemäß Artikel 5(3) der ePrivacy-Richtlinie, der im Europäischen Wirtschaftsraum, dem Vereinigten Königreich und jeder Jurisdiktion, die denselben Standard übernommen hat, eine vorherige, freiwillig erteilte, spezifische, informierte und unmissverständliche Einwilligung erfordert. Das Erfassen von Verhaltensereignissen, die mit diesem Identifikator verknüpft sind, ist die Verarbeitung personenbezogener Daten gemäß DSGVO. Die Anreicherung mit Drittanbieterdaten führt eine zweite Verantwortlichkeitsbeziehung ein. Die CCPA und CPRA klassifizieren dieselbe Verarbeitung als Verkauf oder Weitergabe, es sei denn, der Publisher hat mit Amplitude einen ordnungsgemäß abgegrenzten Dienstanbietervertrag — der verfügbar ist, aber nur wenn die Integration so konfiguriert ist, dass Werbefunktionen deaktiviert werden.

Was Amplitude vor der Einwilligung erfasst — und was Sie unterdrücken müssen

Der häufigste Implementierungsfehler ist es, Amplitude als leichtgewichtiges Analysetool zu behandeln, das neben dem Cookie-Banner laufen kann. Das kann es nicht. Bei einem standardmäßigen amplitude.init()-Aufruf schreibt das SDK beim ersten Rendern der Seite mindestens einen Cookie- oder Lokalspeicher-Eintrag, sendet einen Identify-Aufruf und beginnt mit dem Puffern von Ereignissen. Nichts davon ist erlaubt, bevor ein Nutzer die relevante Einwilligungskategorie ausdrücklich akzeptiert hat.

Eine konforme Integration muss daher amplitude.init() verzögern, bis die CMP signalisiert hat, dass die Analysee­in­wil­li­gungs­ka­te­go­rie gewährt wurde. Das SDK sollte überhaupt nicht aus einem einwilligungsgesteuerten <script>-Tag geladen werden, das vom Zweck-8-Signal (Analyse) oder Zweck-1-Signal (Speicherung und Zugriff) der CMP abhängt, je nachdem, welches Framework die CMP bereitstellt. Wenn das SDK früher geladen werden muss — etwa weil es in den Anwendungscode gebündelt ist und nicht per Lazy-Loading abgerufen werden kann — sollte der Initialisierungsaufruf defaultTracking: false und optOut: true übergeben, damit keine Ereignisse ausgelöst werden, bis die Einwilligung aufgezeichnet wird, und dann sollte ein verzögertes Opt-in-Ereignis diese Flags umkehren.

Die Cookies und der Speicher, den Amplitude schreibt

Browser SDK 2.x schreibt standardmäßig einen einzelnen Erstanbieter-Cookie mit dem Namen AMP_{apiKey} mit einem einjährigen Ablauf, der den Geräteidentifikator und die Sitzungsmetadaten enthält. Ältere Versionen schrieben auch amplitude_id_{apiKey}. Mobile SDKs speichern denselben Identifikator im Sandboxed-Speicher der Anwendung. Session Replay fügt einen zweiten Cookie hinzu, AMP_MKTG_{apiKey}, und Amplitudes Anreicherungspartner können weitere Drittanbieter-Cookies setzen, wenn die Experiment-Targeting- oder Zielgruppen-Module aktiviert sind. Alle diese sind nicht wesentlich und erfordern eine Einwilligung.

Zuordnung von Amplitude zu Einwilligungsrahmen

Amplitude implementiert nicht nativ Google Consent Mode v2, IAB TCF oder IAB Global Privacy Platform. Das ist kein Defekt — Amplitude ist eine Erstanbieter-Analyseplattform, kein AdTech-Anbieter — bedeutet aber, dass die Integrationsverantwortung beim Publisher liegt. Das in der Praxis funktionierende Muster besteht darin, jedes Amplitude-Modul als separates Einwilligungsgate zu behandeln und es an ein spezifisches Signal zu binden, das die CMP bereits bereitstellt.

• Kern-Analyseereignisse sind an den Analysezweck gebunden. In TCF-Begriffen ist dies am häufigsten Zweck 8 (Messung der Inhaltsleistung) kombiniert mit Zweck 1 (Speichern und/oder Zugreifen auf Informationen). Für Google Consent Mode entspricht dies analytics_storage.
• Session Replay sollte hinter einem strengeren Signal liegen. Replay erfasst das gerenderte DOM einschließlich Formularwerte, sofern nicht explizit maskiert, daher ist ein separates Opt-in für preferences oder functional angemessen, und Replay sollte standardmäßig deaktiviert sein, selbst wenn Analyse gewährt wurde.
• Zielgruppen, Kohorten und Drittanbieter-Anreicherung sind an den Marketingzweck gebunden. In TCF-Begriffen ist dies Zweck 7 (Messung der Werbeleistung) oder Zweck 9 (Anwendung von Marktforschung). Für Google Consent Mode entspricht dies ad_storage und ad_user_data.
• Experimentierung — Amplitude Experiment kann mit anonymer, flüchtiger Zuweisung auf Grundlage berechtigter Interessen ausgeführt werden, aber dauerhafte Zuweisung, die an einen Nutzeridentifikator gebunden ist, erfordert dieselbe Einwilligung wie die Kernanalyse.

Das Integrationsmuster, das funktioniert

Die Referenzimplementierung, die die Überprüfung einer Aufsichtsbehörde besteht, hat vier bewegliche Teile: eine CMP, die ein Echtzeit-Ereignis auslöst, wenn der Nutzer die Einwilligung ändert, einen verzögerten SDK-Loader, der Amplitude nur lädt, nachdem dieses Ereignis für die relevante Kategorie ausgelöst wurde, eine Schutzschicht auf Sitzungsebene, die das Opt-out respektiert, ohne den früheren anonymen Geräteidentifikator des Nutzers zu verlieren, wo das Gesetz es erlaubt, und eine serverseitige Brücke für Ereignisse, die unabhängig von der Einwilligung wirklich eine Erfassung erfordern — wie Sicherheitstelemetrie oder Betrugserkennung — die über einen separaten Endpunkt mit eigener Rechtsgrundlage geleitet werden.

Web-Implementierung

Im Web ist das sauberste Muster, den Einwilligungsstatus der CMP über ein window.__cmp_consent-Objekt oder den Standard-__tcfapi-Callback bereitzustellen und dann ein kleines Bootstrap-Skript Einwilligungsänderungen abonnieren zu lassen. Wenn die Analyseeinwilligung von false auf true wechselt, lädt der Bootstrap das Amplitude SDK vom CMP-verwalteten CDN, ruft amplitude.init(apiKey, undefined, { defaultTracking: true }) auf und spielt alle Ereignisse nach, die während der ausstehenden Einwilligung im Speicher in der Warteschlange standen. Wenn die Einwilligung zurück auf false wechselt, ruft der Bootstrap amplitude.setOptOut(true) auf, löscht den AMP_-Cookie über den document.cookie-Ablauf und entfernt jeden In-Memory-Zustand. Entscheidend ist, dass der Bootstrap Amplitude niemals lazy im selben Anforderungsfluss wie das Banner-Rendering initialisieren darf — das SDK muss auf eine explizite Gewährung warten.

Mobile Implementierung

Auf iOS besteht das Äquivalent darin, das Amplitude-Framework importiert zu lassen, aber Amplitude.instance().initialize(apiKey: apiKey) zu verzögern, bis der In-App-Einwilligungsfluss ein positives Analysesignal zurückgegeben hat. Die ATT-Aufforderung ist ein separates Anliegen: ATT regelt den IDFA, während Amplitudes Identifikator die eigene UUID des SDKs ist, die im App-Sandbox gespeichert ist. Beide erfordern im EWR eine Einwilligung, aber die Rechtsgrundlagen und Aufforderungen sind unterschiedlich. Auf Android gilt dieselbe Logik mit Amplitude.getInstance().initializeApolloClient() oder dem Äquivalent je nach SDK-Version.

Serverseitiger Modus

Amplitude unterstützt serverseitige Aufnahme über die HTTP V2 API. Serverseitige Ereignisse sind nicht von der Einwilligung ausgenommen — die Rechtsgrundlage folgt den Daten, nicht dem Transport — aber die serverseitige Aufnahme gibt dem Publisher vollständige Kontrolle darüber, welche Felder gesendet werden, was es einfacher macht, eine partielle Einwilligung zu respektieren. Ein gängiges Muster ist es, serverseitig einen minimalen, nur wesentlichen Ereignissatz unter berechtigtem Interesse zu erfassen und diese Ereignisse erst dann mit Verhaltensdetails anzureichern, nachdem der Nutzer auf dem Client eine Analyseeinwilligung erteilt hat.

Validierung der Integration

Der Validierungsschritt ist derjenige, den Publisher am häufigsten überspringen und den Regulierungsbehörden am häufigsten überprüfen. Eine korrekt integrierte Amplitude-Implementierung sollte vier Prüfungen bestehen. Erstens sollte ein Browser mit angezeigtem Einwilligungsbanner, aber ohne getroffene Entscheidung null Anfragen an api.amplitude.com oder api.eu.amplitude.com und null AMP_-Cookies in document.cookie erzeugen. Zweitens sollte das Ablehnen der Analysekategorie diesen Zustand beibehalten — keine Ereignisse, keine Cookies, keine Lokalspeicher-Einträge mit einem AMP_-Präfix. Drittens sollte das Akzeptieren von Analyse ein einzelnes identify gefolgt von Ereignisdatenverkehr erzeugen, und der AMP_-Cookie sollte mit einem SameSite-Attribut erscheinen, das mit der CMP-Richtlinie des Publishers übereinstimmt. Viertens sollte das nachträgliche Widerrufen der Einwilligung sofort weitere Ereignisse stoppen und gespeicherte Identifikatoren löschen — eine verzögerte Bereinigung ist ein Befund.

Der Prüfpfad ist separat wichtig. Gemäß den EDPB-Richtlinien für Cookie-Banner aus dem Jahr 2023 und den erneuerten Prioritäten der Taskforce für 2026 erwarten Regulierungsbehörden, dass der Publisher für jedes beliebige Ereignis im Amplitude-Projekt nachweisen kann, dass der Nutzer, der es erzeugt hat, zum Zeitpunkt der Erfassung eine gültige Einwilligung erteilt hatte. Dies erfordert, dass das Einwilligungsprotokoll der CMP nach Geräteidentifikator oder Sitzungsidentifikator abgefragt werden kann und dass die Amplitude-Ereignis-Nutzlast ein Einwilligungs-Versionsfeld trägt, das auf dieses Protokoll zurückverweist. Das Speichern des Einwilligungsstrings als benutzerdefinierte Nutzereigenschaft bei jedem Ereignis ist der einfachste Weg, diesen Link auditierbar zu machen.

Auswahl der richtigen Region und Datenspeicherung

Amplitude betreibt zwei Produktionsregionen: USA (api.amplitude.com) und EU (api.eu.amplitude.com). Für EWR- und UK-Datenverkehr ist die EU-Region der richtige Standard — sie hält die Daten im EWR und reduziert die Übertragungsrisikofläche, die das Schrems-II-Urteil und der EU-US-Datenschutzrahmen zum zentralen Punkt jeder Analyseüberprüfung gemacht haben. Das Wechseln von Regionen ist nicht rückwirkend: Bestehende Daten verbleiben dort, wo sie zuerst aufgenommen wurden. Für Publisher, die einen CMP-Rollout planen, lohnt es sich daher, die Region vor der Skalierung zu bestätigen und die Wahl in der Datenschutzerklärung zu dokumentieren, damit die Rechtsgrundlagenkette von der Erfassung bis zur Speicherung sauber ist. Eine korrekt gewählte Region, kombiniert mit einem korrekt abgesicherten SDK und einem abfragbaren Einwilligungsprotokoll, ist das, was eine Amplitude-Implementierung von einem regulatorischen Risiko in einen vertretbaren Teil des Analyse-Stacks verwandelt.