Amazon Ads this month published a consolidated set of consent signal requirements covering three core data transmission tools: the Amazon Ad Tag (AAT), the Conversions API (CAPI), and the newly launched Events API open beta. The documentation, which spans several updated pages in the Amazon Ads Support Center and Advanced Tools Center, formalizes obligations for advertisers transmitting personal information from users located in the United Kingdom and the European Economic Area. An enforcement deadline of June 30, 2026 applies. Tim Watkinson, CTO at BASE and a retail media strategy specialist, flagged the deadline directly on LinkedIn this month, writing: "Your Data Won't Work After June 30th."

The changes affect any advertiser using these tools to send conversion events, match keys, or user data to Amazon Ads from UK or EEA markets. Getting consent architecture in place before that date is considerably more manageable than retrofitting compliance into an already-live system after enforcement begins.

The consent obligations apply across all three data transmission pathways. According to the Amazon Ads documentation, if an advertiser transmits or makes available any personal information to Amazon Ads, they must supply a valid consent signal and the country code in which consent was granted. The country code must be a 2-character string in ISO 3166 format - for example, US, GB, or DE. Data uploaded without a country code will be rejected outright.

Three consent signal formats are accepted. The first is the Interactive Advertising Bureau's (IAB) European Transparency and Consent Framework (TCF) signal, which encodes user privacy choices in a compressed string format. The second is the Global Privacy Protocol (GPP), a broader cross-jurisdictional standard. The third is Amazon's own proprietary format, the Amazon Consent Signal (ACS). All three pathways carry the same functional weight, but Amazon has established a clear priority order: if multiple signals are provided simultaneously, Amazon Ads will use TCF and ignore ACS. Sending duplicate signals is explicitly flagged as incorrect in the documentation.

AAT - the Amazon Ad Tag, which fires in the browser and collects HTTP headers, tag-specific data, and advertiser-defined event attributes - is covered under its own consent requirements page. According to the documentation, AAT allows advertisers to understand events that users take on a website in a privacy-safe manner. Advertisers using AAT must send consent via either a third-party or advertiser-owned consent management platform (CMP). For third-party CMPs, Amazon Ads supports many widely used platforms to simplify ACS setup. Advertisers running a self-managed CMP have two paths: they can transmit TCF signals using the addtcfv2 function in the tag, or they can integrate ACS directly through the ACS CMP Integration Guide.

CAPI - the Conversions API - allows advertisers to send real-time and offline conversion event data via server-to-server integration, either directly from an advertiser's server or from a preferred customer data platform (CDP). According to the documentation, CAPI users must use TCF, GPP, or ACS to communicate UK and EEA users' privacy choices. Consented events can be passed via a partner CAPI connector, an advertiser-owned connector, or a mobile measurement partner (MMP). Amazon Ads supports many widely used MMPs for this purpose, and MMP users should refer to their provider's documentation for enabling ACS.

Events API - the new open beta, positioned as a direct evolution from CAPI v1 - goes further than either AAT or CAPI in its data model. It introduces a dedicated consent object within each event payload, allowing advertisers to pass consent information at the individual event level rather than as a session-wide parameter. This is a meaningful architectural difference. In the Events API schema, the consent object accepts three formats: a TCF string, a GPP string, or an Amazon Consent object containing two fields - amznAdStorage and amznUserData - each accepting GRANTED or DENIED as values.

The Events API in detail

The Events API replaces CAPI v1 as Amazon's primary server-side conversion infrastructure. According to the documentation, the API helps Amazon DSP, Streaming TV (STV), and Sponsored Display (SD) advertisers evaluate the effectiveness of their campaigns regardless of where the conversion occurs. Each request can contain between 1 and 500 events, though Amazon recommends sending events as soon as they occur for optimal attribution accuracy. Events with a timestamp more than 21 days in the past will not be processed.

The schema requires several fields that advertisers migrating from CAPI v1 will recognise, alongside additions specific to the new version. Required fields include the event name, conversion type, event source (ANDROID, FIRE_TV, IOS, OFFLINE, WEBSITE, or MEASUREMENT_ATTRIBUTION_PARTNER), event ingestion method (which must be set to SERVER_TO_SERVER), event timestamp in ISO-8601 format, match keys, and country code. Optional fields include dataset name, partner name, currency code, units sold (applicable only for off-Amazon purchases), a value field accepting up to two decimal places, and custom data attributes.

Match keys - the user and device identifiers used for attribution - must be normalised and hashed using SHA-256 before transmission. MAID (mobile advertising identifier) and MATCH_ID are exceptions to the hashing requirement and are passed in plain form. The API supports multiple identifier types including email, phone number, and rampID. According to the documentation, passing as many identifiers as possible improves match rates. For EU advertisers specifically, the consent object is required when any match key containing personal information is included. This creates a direct technical dependency between privacy compliance and attribution effectiveness: the richer the identity signal, the more pressing the consent requirement.

The dataset concept is a notable addition in the Events API open beta. The documentation describes datasets as groupings of uploaded advertiser data, similar in structure to a data table, with attributes (columns), records (rows), and metadata. Dataset names are immutable once set. A dataset name can be specified at the connector level, with the ability to override at the event level. Advertisers migrating from CAPI v1 have two options: reuse existing conversion definitions by sending the same event name, conversion type, event source, and ingestion method without a dataset name; or create new conversion definitions and datasets by including a new dataset name in the event description. For active campaigns, Amazon recommends retaining old conversion definitions for at least 30 days after migration to ensure conversions within the lookback window continue to be attributed correctly.

There are technical differences between CAPI v1 and the Events API that matter in practice. The Events API offers higher transactions per second (TPS) and a larger batch size of up to 500 events per request, compared with the smaller batch capacity in CAPI v1. The consent object is a new addition in the open beta. The data model has been standardised to align with other Amazon Ads APIs. For advertisers that have implemented both the Amazon Ad Tag (AAT) for client-side events and the Events API for server-side events, de-duplication is required for any event shared across both systems. The mechanism is the eventId field: every shared event must include a consistent eventId to allow Amazon to identify and drop duplicates. De-duplication is not required when distinct event types are being sent from each source without overlap.

The Events API also introduces support for ten custom attributes per event, plus three additional reserved attributes - brand, productId, and category - which describe the product. Custom attributes are available in Amazon Marketing Cloud (AMC). The brand, productId, and category attributes are additionally available in Amazon DSP reporting directly. This makes the Events API a richer data pipeline than a pure conversion tracking tool: it carries product-level context that feeds both measurement and audience tooling.

ACS is Amazon's proprietary consent mechanism, introduced as an alternative to the IAB's TCF for advertisers who do not operate within the TCF framework. It requires three parameters. CountryCode specifies where consent was given in ISO 3166 two-character format. amzn_user_data indicates whether the user has consented to Amazon processing personal data - such as an advertising identifier - for advertising purposes, accepting GRANTED or DENIED. amzn_ad_storage indicates whether the user has consented to Amazon reading or writing advertising cookies or similar technologies on their device, accepting GRANTED, DENIED, or NULL.

For advertisers using JavaScript-based consent management platforms, Amazon has published a dedicated ACS integration guide. The guide describes a JavaScript library hosted at https://c.amazon-adsystem.com/aat/amzn-consent.js that CMP developers or advertisers with self-managed consent banners can import. According to the documentation, when the script loads, all consent settings default to DENIED. They remain at DENIED until the user interacts with the CMP - for example, by clicking Accept - at which point the amznConsent method is called to update the consent state.

The recommended implementation uses what Amazon calls the Builder Pattern. An alternative direct JSON initialisation option is documented but marked as not recommended. Both options set a first-party JS cookie named amzn_consent and trigger a browser event called amznConsentChange. The Amazon Ad Tag (amzn.js) listens to this browser event and checks for the cookie, restricting future event triggers and first-party data collection based on the consent provided. This method will not work if the CMP integration cannot set first-party cookies - an important constraint for publishers or advertisers operating in contexts where first-party cookie setting is restricted.

What advertisers must do

According to the personal information requirements documentation, advertisers transmitting data to Amazon must fulfil several obligations that go beyond technical signal passing. They must publish a clear, concise, and transparent privacy policy on the web properties, apps, and services where personal information will be collected. They must collect affirmative opt-in consent from individuals for Amazon to process their personal information and use cookies for advertising purposes. They must keep records of consent and opt-out choices and provide Amazon with access to those records upon request. They must not pass personally identifiable information such as names, email addresses, or telephone numbers in unprocessed form. They must not transmit personal information from any site, app, or service directed to children under age 13, or the age defined by applicable law. They must not transmit sensitive personal information as defined by applicable law, including financial status or health and medical information.

If personal information shared with Amazon was collected, stored, used, or disclosed in violation of these requirements, the advertiser must immediately cease processing and sharing that data and notify Amazon in writing as soon as possible.

The Applicable Law definition in the documentation explicitly names the General Data Protection Regulation (Regulation (EU) 2016/679) as well as its UK implementation following the country's departure from the European Union on 31 January 2020.

Why this matters for the marketing community

The consent documentation published today sits at the intersection of two pressures that have been building for years. Privacy regulation in Europe has consistently moved toward stricter enforcement and more granular consent requirements. At the same time, server-side measurement infrastructure - represented here by the Events API - has become the primary response to signal loss caused by ad blockers, browser privacy settings, and third-party cookie deprecation.

The challenge for advertisers is that server-side tools like the Events API are substantially more powerful than browser-based tags precisely because they bypass the browser. That same power is what makes the consent question more consequential. An event sent server-to-server reaches Amazon regardless of whether the user has installed an ad blocker. Consent governance, then, is not just a regulatory obligation - it is the mechanism by which users retain meaningful control over data that would otherwise flow invisibly.

PPC Land has previously covered Amazon's broader consent compliance pressure from a regulatory direction, including the Irish Council for Civil Liberties' July 2025 letter to the European Commission demanding enforcement action over Amazon's consent practices under the Digital Markets Act and GDPR.

The Events API's consent object - requiring TCF, GPP, or ACS at the individual event level - represents a technical architecture that makes consent provenance traceable through the data pipeline. The ADM integration guide published on May 1, 2026 showed that Amazon's data infrastructure already carries consent flags at the member record level within Ads Data Manager. The Events API extends that pattern to real-time conversion events, aligning the consent model across both batch-uploaded first-party data and live server-side event streams.

For practitioners managing campaigns across the UK and EEA, the practical implication is that each of the three Amazon data transmission tools requires a distinct implementation review. AAT requires a CMP integration. CAPI requires a partner, advertiser-owned, or MMP connector configured to pass consent signals. The Events API requires a consent object in each event payload. None of these are defaults that work out of the box - all require active configuration. The Microsoft consent signal mandate that took effect in May 2025 offers a useful reference point: Microsoft's enforcement cycle showed that platforms are moving toward hard rejections of unconsented data, not just advisory warnings.

The data retention rules also warrant attention. According to the Data Privacy and Security FAQ, Amazon Ads systems including AAT retain data for no longer than 13 months in general. Advertisers requesting user data deletion must submit a deletion request and stop sending data from opted-out users going forward. The deletion event is sent as a standard event firing with "Delete" as the event name - via the JavaScript tag or an image tag. Users are removed from all audience segments created using Amazon Advertising tag traffic within 24 hours of receiving a deletion request.

For larger advertisers using Customer Data Platforms to feed the Events API, the documentation specifies that CDPs, agencies, and other partners must allow customers to include dataset names as an optional value at the connector level, with the ability to override at the event level. This ensures that consent and data governance settings flow through from the advertiser's own infrastructure rather than being set at the intermediary layer without the advertiser's awareness.

Timeline

Summary

Who: Amazon Ads, addressing all advertisers using the Amazon Ad Tag (AAT), Conversions API (CAPI), or the new Events API to transmit data from users located in the United Kingdom and the European Economic Area.

What: A consolidated set of consent signal requirements that formalizes obligations to pass a valid consent signal - either IAB TCF, Global Privacy Protocol (GPP), or Amazon's proprietary Amazon Consent Signal (ACS) - alongside a two-character ISO 3166 country code, whenever personal information is transmitted to Amazon Ads from UK or EEA markets. The Events API open beta introduces a dedicated consent object within each individual event payload, a more granular architecture than the session-level approach used by older tools.

When: The documentation was published this month, May 2026, coinciding with the open beta availability of the Events API. The enforcement deadline is June 30, 2026, after which unconsented data from UK and EEA users will not be processed.

Where: The requirements apply globally wherever Amazon Ads is used, but the consent obligations are specifically triggered by the geographic location of the end user - any personal data originating from a UK or EEA user requires a valid consent signal and country code before it can be transmitted to Amazon Ads.

Why: Regulatory obligations under the General Data Protection Regulation and its UK equivalent require that advertisers demonstrate a lawful basis for processing personal data. Sending conversion events or match keys without valid consent exposes advertisers to compliance risk. The Events API's event-level consent object makes that compliance technically enforceable at the data pipeline layer, not just as a policy obligation, connecting consent provenance directly to the signal Amazon uses for attribution and audience creation.

Share this article
The link has been copied!