Why Amplitude requires consent

The default Amplitude Browser SDK and the Amplitude mobile SDKs do far more than record pageviews. On initialisation they set a device identifier in first-party storage, generate a session identifier, capture the referrer, parse UTM and click identifiers from the URL, and begin queueing autocaptured events: page views, element clicks, form interactions, file downloads, and — in the latest releases — session replays. They will also enrich those events with IP-derived geolocation, user-agent-derived device data, and, if configured, third-party enrichment from data partners.

Each of those steps engages a separate consent legal basis. Storing a device identifier is a storage-and-access operation under Article 5(3) of the ePrivacy Directive, which requires prior, freely given, specific, informed, and unambiguous consent in the European Economic Area, the United Kingdom, and any jurisdiction that has imported the same standard. Capturing behavioural events tied to that identifier is processing of personal data under the GDPR. Enriching with third-party data introduces a second controller relationship. The CCPA and CPRA classify the same processing as a sale or share unless the publisher has a properly scoped service-provider contract with Amplitude — which is available, but only if the integration is configured to disable advertising features.

What Amplitude collects before consent — and what you must suppress

The most common implementation mistake is treating Amplitude as a lightweight analytics tool that can run alongside the cookie banner. It cannot. On a default amplitude.init() call the SDK will, within the first paint of the page, write at least one cookie or local storage entry, send an identify call, and begin buffering events. None of that is permissible before a user has affirmatively accepted the relevant consent category.

A compliant integration must therefore delay amplitude.init() until the CMP has signalled that the analytics consent category has been granted. The SDK should not be loaded at all from a consent-gated <script> tag that depends on the CMP's purpose 8 (analytics) or purpose 1 (storage and access) signal, depending on which framework the CMP exposes. If the SDK must be loaded earlier — for example because it is bundled into the application code and cannot be lazily fetched — the initialisation call should pass defaultTracking: false and optOut: true so that no events are emitted until consent is recorded, and then a deferred opt-in event should flip those flags.

The cookies and storage Amplitude writes

The Browser SDK 2.x writes a single first-party cookie named AMP_{apiKey} by default, with a one-year expiry, containing the device identifier and session metadata. Older versions also wrote amplitude_id_{apiKey}. Mobile SDKs persist the same identifier inside the application's sandboxed storage. Session replay adds a second cookie, AMP_MKTG_{apiKey}, and Amplitude's enrichment partners may set additional third-party cookies if the experiment-targeting or audiences modules are enabled. All of these are non-essential and require consent.

Mapping Amplitude to consent frameworks

Amplitude does not natively implement Google Consent Mode v2, the IAB TCF, or the IAB Global Privacy Platform. That is not a defect — Amplitude is a first-party analytics platform, not an ad-tech vendor — but it does mean the integration responsibility sits with the publisher. The pattern that works in practice is to treat each Amplitude module as a separate consent gate and bind it to a specific signal the CMP already exposes.

• Core analytics events bind to the analytics purpose. In TCF terms this is most commonly purpose 8 (measure content performance) combined with purpose 1 (store and/or access information). For Google Consent Mode this maps to analytics_storage.
• Session replay should sit behind a stricter signal. Replay captures rendered DOM, including form values unless explicitly masked, so a separate preferences or functional opt-in is appropriate, and replay should default to off even when analytics is granted.
• Audiences, cohorts, and third-party enrichment bind to the marketing purpose. In TCF terms this is purpose 7 (measure ad performance) or purpose 9 (apply market research). For Google Consent Mode this maps to ad_storage and ad_user_data.
• Experimentation — Amplitude Experiment can run with anonymous, ephemeral allocation under a legitimate-interest basis, but persistent allocation tied to a user identifier requires the same consent as core analytics.

The integration pattern that works

The reference implementation that survives a regulator's review has four moving parts: a CMP that exposes a real-time event when the user changes consent, a deferred SDK loader that only fetches Amplitude after that event fires for the relevant category, a session-level guard that respects opt-out without losing the user's prior anonymous device identifier where the law permits, and a server-side bridge for events that genuinely require collection regardless of consent — such as security telemetry or fraud detection — routed through a separate endpoint with its own legal basis.

Web implementation

On the web, the cleanest pattern is to expose the CMP's consent state via a window.__cmp_consent object or the standard __tcfapi callback, then have a small bootstrap script subscribe to consent changes. When analytics consent flips from false to true, the bootstrap fetches the Amplitude SDK from the CMP-managed CDN, calls amplitude.init(apiKey, undefined, { defaultTracking: true }), and replays any events that were queued in memory while consent was pending. When consent flips back to false, the bootstrap calls amplitude.setOptOut(true), clears the AMP_ cookie via document.cookie expiry, and removes any in-memory state. Critically, the bootstrap must never lazily initialise Amplitude in the same request flow as the banner render — the SDK must wait for an explicit grant.

Mobile implementation

On iOS the equivalent is to keep the Amplitude framework imported but defer Amplitude.instance().initialize(apiKey: apiKey) until the in-app consent flow has returned a positive analytics signal. The ATT prompt is a separate concern: ATT governs the IDFA, while Amplitude's identifier is the SDK's own UUID stored in the app sandbox. Both require consent in the EEA, but the legal bases and prompts are distinct. On Android the same logic applies with Amplitude.getInstance().initializeApolloClient() or the equivalent depending on SDK version.

Server-side mode

Amplitude supports server-side ingestion via the HTTP V2 API. Server-side events are not exempt from consent — the legal basis follows the data, not the transport — but server-side ingestion does give the publisher full control over which fields are sent, which makes it easier to honour partial consent. A common pattern is to capture a minimal essential-only event set server-side under legitimate interest, and only enrich those events with behavioural detail after the user has granted analytics consent on the client.

Validating the integration

The validation step is the one that publishers most often skip and regulators most often check. A correctly integrated Amplitude deployment should pass four checks. First, a browser with the consent banner shown but no choice made should produce zero requests to api.amplitude.com or api.eu.amplitude.com and zero AMP_ cookies in document.cookie. Second, declining the analytics category should keep that state — no events, no cookies, no local storage entries with an AMP_ prefix. Third, accepting analytics should produce a single identify followed by event traffic, and the AMP_ cookie should appear with a SameSite attribute consistent with the publisher's CMP policy. Fourth, withdrawing consent after the fact should immediately stop further events and clear stored identifiers — a delayed cleanup is a finding.

The audit trail matters separately. Under the EDPB's 2023 cookie banner guidelines and the renewed 2026 task force priorities, regulators expect the publisher to be able to prove, for any given event in the Amplitude project, that the user who generated it had given valid consent at the moment of capture. That requires the CMP's consent log to be queryable by device identifier or session identifier, and the Amplitude event payload to carry a consent-version field that ties back to that log. Storing the consent string as a custom user property on every event is the simplest way to make that link auditable.

Choosing the right region and data residency

Amplitude operates two production regions: the US (api.amplitude.com) and the EU (api.eu.amplitude.com). For EEA and UK traffic the EU region is the right default — it keeps the data inside the EEA and reduces the transfer-risk surface that the Schrems II decision and the EU-US Data Privacy Framework have made central to any analytics review. Switching regions is not retroactive: existing data stays where it was first ingested. For publishers planning a CMP rollout it is therefore worth confirming the region before scaling, and worth documenting the choice in the privacy notice so the lawful basis chain is clean from collection through to storage. A correctly chosen region, paired with a correctly gated SDK and a queryable consent log, is what turns an Amplitude deployment from a regulatory risk into a defensible part of the analytics stack.