Your paid media team noticed something last week: Amazon DSP attribution is fragmenting. Conversion reporting looks incomplete. Audiences built from product detail page views aren't refreshing the way they used to. Nobody touched the campaigns. But someone recently migrated the site to a new tag manager setup, and in the process, the consent signal that was passing user preferences to Amazon stopped firing correctly. You're not in violation of GDPR yet — but your campaign data is degrading, and the window before enforcement tightens further is closing.
This is the operational reality of Amazon advertising in 2026. The Amazon Consent Signal (ACS) sits at the intersection of advertising performance and privacy compliance, and getting it wrong costs you on both dimensions simultaneously. This guide explains exactly what ACS is, how it works technically, how it compares to the IAB TCF and Google Consent Mode frameworks, and what a reliable implementation architecture looks like in practice.
What the Amazon Consent Signal Actually Is
The Amazon Consent Signal is Amazon's proprietary framework for communicating user consent status to its advertising ecosystem. It functions similarly in purpose to Google Consent Mode v2 — a structured way to tell an advertising platform what a user has agreed to, so that platform can adjust its data processing behavior accordingly. But ACS is specific to Amazon Ads, covering Amazon DSP, Amazon Marketing Cloud, and Ads Data Manager, and it operates through a technically distinct mechanism.
ACS uses two parameters to communicate consent. The first, amzn_user_data, indicates whether the user has consented to Amazon processing their personal data — such as an advertising identifier — for advertising purposes. The second, amzn_ad_storage, indicates whether the user has consented to Amazon reading or writing advertising cookies or similar technologies on their device. Each parameter accepts either GRANTED or DENIED as its value. When both are GRANTED, Amazon can run campaigns at full capability: targeting, retargeting, conversion attribution, and audience measurement all operate as designed. When either is DENIED, Amazon limits or stops processing that user's data for advertising purposes.
These two parameters are transmitted to Amazon through a first-party cookie called amzn_consent, set on your domain by your consent management platform after a user makes their consent choice. The cookie stores a small JSON object containing the two parameter values, a geo field carrying the ISO 3166 country code where consent was recorded, and a timestamp. Amazon's own ad tags read this cookie automatically when they fire — no additional JavaScript calls or API integrations are required on your end for the browser-side implementation. This architecture differs from Google Consent Mode v2, which relies on gtag('consent', 'update', ...) JavaScript calls rather than a cookie-based signal.
One practical implementation note that catches teams off guard: because the amzn_consent cookie contains JSON, some Web Application Firewalls will flag or block it as a suspicious payload. If you enable ACS in your CMP and then verify in browser DevTools that the cookie isn't being set, a WAF rule is almost always the culprit. Adding an exception for the amzn_consent cookie name resolves it.
Why Amazon Requires Consent Signals
Amazon's consent signal requirement didn't emerge in isolation. It is a direct response to the regulatory pressure that European data protection authorities have applied to advertising ecosystems under the GDPR and the ePrivacy Directive.
The GDPR requires explicit consent before processing personal data for advertising purposes where consent is the chosen lawful basis. That requirement applies to every actor in the advertising supply chain — not just the platform, but the advertiser transmitting data to the platform. When an advertiser sends conversion event data, customer match lists, or behavioral signals to Amazon Ads from EEA or UK users, they are transmitting personal data. The legal obligation to have obtained valid consent for that transmission sits with the advertiser. Amazon's requirement that a verified consent signal accompany that data is how the platform ensures it isn't receiving — and processing — data that was collected without proper legal basis.
Amazon itself faced one of the largest GDPR enforcement actions in history when Luxembourg's CNPD issued a €746 million fine for advertising consent practices in 2021. While Luxembourg's Administrative Court annulled that specific decision in March 2026 and referred it back for re-analysis, the court upheld the underlying principle: using personal data for ad targeting requires proper consent under the GDPR. The ACS requirement reflects Amazon's response to that regulatory environment — building verified consent transmission into its advertising infrastructure so that every data payload carries consent provenance.
The practical consequence of missing or invalid consent signals is not just a compliance problem. Without a valid signal, Amazon cannot process personal data for ad personalization or measurement on behalf of UK and EEA users. That means degraded conversion attribution, reduced addressable audiences for DSP campaigns, and gaps in Amazon Marketing Cloud reporting. For advertisers who rely on Amazon's first-party purchase intent data for retargeting — the core commercial value of Amazon DSP in European markets — the consent signal is what makes that audience targeting legally and operationally available at all.
ACS vs. the IAB Transparency and Consent Framework
Amazon accepts two distinct pathways for meeting its consent signal requirement: ACS itself, or the IAB Transparency and Consent Framework (TCF). Understanding the difference determines which implementation approach is right for your setup.
The IAB TCF is an industry-wide consent signaling standard developed by the Interactive Advertising Bureau Europe. It encodes user consent preferences — including consent for specific vendors and specific processing purposes — into a compressed TC String that is stored in a standardized location and readable by any TCF-registered vendor. Amazon Ads is a registered IAB TCF vendor with the vendor ID 793. If you operate a TCF-certified CMP and Amazon Ads is included in your vendor list with consent properly granted, Amazon automatically reads the TC String when its tags fire and adjusts its behavior accordingly. Your existing TCF implementation may already satisfy Amazon's consent requirement without any ACS-specific configuration. The key check is verifying that Amazon's vendor ID is in your active vendor list and that purpose consents for advertising are mapped correctly.
ACS is the alternative for organizations that don't use TCF — typically smaller publishers, e-commerce sites, and advertisers whose consent management infrastructure isn't built around the IAB framework. ACS is simpler in scope: it communicates consent for Amazon specifically, using the first-party cookie mechanism described above, without requiring the broader TCF vendor and purpose taxonomy. If you already run TCF, adding ACS is redundant. Amazon has explicitly documented that if both signals are present simultaneously, it will use the TCF string and ignore the ACS signal. Sending both is flagged as incorrect in Amazon's own documentation.
The newest layer of complexity is the Global Privacy Platform (GPP), a cross-jurisdictional consent signaling standard that Amazon also accepts as a third valid pathway, primarily relevant for server-side implementations and the Events API. For most web-based advertisers, the practical choice remains TCF or ACS. Understanding how cookie consent management platforms handle both IAB TCF and proprietary consent modes is the starting point for determining which path fits your existing infrastructure.
How Consent Flows Through the Amazon Advertising Stack
The consent signal requirement doesn't apply uniformly to all Amazon advertising touchpoints. Amazon has published separate consent requirements for three distinct data transmission tools, each of which requires its own implementation review.
The Amazon Ad Tag (AAT) is the browser-based JavaScript tag that fires on your website to collect conversion events, page behaviors, and ad interactions. AAT consent is handled through your CMP integration — either TCF strings passed via the addtcfv2 function in the tag, or ACS signals read from the amzn_consent cookie. When a user lands on your site and your CMP fires, it sets the consent cookie before any Amazon tags should load. If tag sequencing is correct, AAT reads the consent state before processing any data.
The Conversions API (CAPI) is a server-side data pipeline that sends conversion events, customer match keys, and offline transaction data from your server or CDP directly to Amazon. Because CAPI operates outside the browser, the consent signal can't be read from a cookie — it must be explicitly included in the API payload. Advertisers sending data through CAPI must transmit TCF, GPP, or ACS consent information alongside each event record. The consent signal in a CAPI payload includes the framework type, the encoded consent string or ACS parameters, and the ISO 3166 country code.
The Events API, currently in open beta with a June 30, 2026 enforcement deadline, takes this architecture a step further. It requires a dedicated consent object within each individual event payload — not at the session level, but at the record level. This is the most granular consent architecture Amazon has deployed, and it makes consent provenance traceable through the entire data pipeline: each event carries its own consent attestation rather than inheriting it from a session-level signal.
The implication for multi-channel advertisers is that a single CMP integration on your website is not sufficient if you're also running CAPI or the Events API. Each data transmission tool requires its own consent signal implementation, and they must be consistent — the same user's consent status needs to be correctly reflected across all three pathways to avoid creating scenarios where consent is granted in the browser but missing from server-side uploads.
Common Implementation Failures and How to Diagnose Them
Most Amazon consent signal problems fall into a small number of identifiable failure patterns, and each has a diagnostic path.
The most common failure is tag sequencing: Amazon tags firing before the CMP has set the amzn_consent cookie. This happens when ad tags are loaded synchronously on page load ahead of the consent banner initialization. The result is that Amazon's tag reads either an absent cookie — which it treats as no consent — or a stale value from a previous session. The fix is ensuring your tag manager triggers Amazon tags only after the CMP's consent-ready event fires. In Google Tag Manager, this means configuring the Amazon tag to use a consent initialization trigger rather than a page view trigger. The same logic applies to any tag manager: the consent state must be established before any downstream vendor tags execute.
Web Application Firewall blocks are the second common failure. As noted above, the JSON format of the amzn_consent cookie can trigger WAF rules. If the cookie isn't appearing in your browser's DevTools storage panel after accepting marketing consent, check your WAF logs for blocked requests. This is particularly common on Cloudflare configurations and AWS WAF setups.
The third category is TCF misconfiguration. If you're relying on TCF to cover your Amazon consent obligations, two things must be true: Amazon Ads (vendor ID 793) must be in your active vendor list, and the relevant purpose consents — Purpose 1 (store or access information on a device) and Purpose 4 (select personalised ads) — must be correctly mapped to Amazon in your CMP vendor configuration. If Amazon's vendor entry is present but purposes aren't correctly assigned, the TC String will indicate that Amazon's vendor is active but without the necessary purpose consents, and Amazon will treat this as a denied signal.
Revocation handling is a subtler failure mode. GDPR requires that consent be as easy to withdraw as it is to give, and that withdrawal take effect promptly. If a user changes their consent preferences mid-session — accepting cookies initially and then revoking via your preference center — the amzn_consent cookie must update to reflect the new state, and any Amazon tags that haven't yet fired must respect it. Tags that have already fired with a GRANTED state present a more complex question: you cannot retroactively un-process data that was legitimately collected, but you should ensure that subsequent requests in the session reflect the revocation. Cookie compliance auditing tools that continuously scan for consent signal integrity across your tag stack help identify whether revocation is propagating correctly.
To diagnose any of these issues systematically, open browser DevTools (Network and Application panels), trigger a page load, inspect the cookies panel for the presence and values of amzn_consent, and check the network requests from Amazon's tag to verify what consent state is being transmitted. CMP-level debugging modes will show you the events being emitted and whether the consent state is correctly reflected in the data layer. For CAPI and Events API implementations, validate that the consent object is present and correctly formatted in your API payloads by logging payloads before they're dispatched.
ACS vs. Google Consent Mode: The Operational Comparison
Marketing operations teams managing both Google and Amazon advertising often ask how ACS and Google Consent Mode v2 relate to each other, and whether a single CMP configuration can cover both. The short answer is yes — but they are distinct technical integrations that must each be configured explicitly.
Google Consent Mode v2 operates through JavaScript API calls: gtag('consent', 'default', {...}) sets the default consent state before any Google tags load, and gtag('consent', 'update', {...}) updates it after the user makes a choice. It carries four parameters — ad_storage, analytics_storage, ad_user_data, and ad_personalization — and governs the behavior of Google's entire tag ecosystem, from GA4 to Google Ads to Floodlight. When a user denies consent in Advanced Mode, Google tags continue to fire but send only cookieless pings: anonymous, non-identifying signals that Google's modeling layer uses to estimate conversion activity in aggregate.
ACS uses a fundamentally different mechanism — the first-party amzn_consent cookie rather than JavaScript API calls. Amazon tags read the cookie rather than listening for a JavaScript event. This difference matters practically: it means the two integrations have no technical dependency on each other. Running both simultaneously does not create conflicts, and a CMP that supports both can manage them from a single consent banner configuration. The user makes one consent choice, and the CMP writes both the amzn_consent cookie for Amazon and emits the gtag consent updates for Google.
The behavioral difference after a denial is also significant. When Google tags run in Advanced Mode with consent denied, they still fire and send limited modeling data. Amazon tags, when consent is DENIED, stop processing personal data for that user entirely — there is no equivalent to Google's cookieless ping mechanism. This means that in European markets with high consent refusal rates, Amazon DSP campaigns face a more direct measurement gap than Google Ads campaigns running Advanced Consent Mode.
Choosing and Configuring a CMP for Amazon Ads Compliance
A CMP that doesn't explicitly support ACS is not a viable consent infrastructure for Amazon advertising in UK and EEA markets. The integration must be natively supported — your CMP needs to know how to translate the user's consent choice into the correctly formatted amzn_consent cookie, map that to the amzn_user_data and amzn_ad_storage parameters, and set the cookie with the correct ISO country code before Amazon's tags can fire.
When evaluating CMP support for ACS, the questions that matter most are: Does the CMP write the amzn_consent cookie automatically when a user makes a marketing consent choice, or does it require custom configuration? Does it handle the TCF pathway if you're already running TCF — and does it correctly suppress ACS when TCF is active to avoid the duplicate signal problem Amazon flags? Does it support server-side consent signal passing for CAPI and Events API use cases, or only browser-side? Does it provide consent audit logs showing that ACS signals were correctly transmitted for each session, which you'd need to produce for a regulatory inquiry?
The geographic requirement adds another dimension. Amazon's consent obligations apply specifically to UK and EEA users — there's no requirement to send ACS signals to Amazon for users in the US or other jurisdictions. Your CMP must support geo-targeted consent rules that apply ACS configuration for European visitors while leaving other traffic unaffected. This is the same geolocation logic required for GDPR cookie consent enforcement generally — European users get the consent banner and the corresponding consent signals; other visitors may receive a different experience based on applicable local law.
Consent logging is not optional. If a data protection authority investigates your advertising practices, you need to demonstrate that valid consent was obtained before each user's data was transmitted to Amazon. Your CMP's audit trail must record the consent state at the time it was given, the mechanism used to obtain it, the timestamp, the user's geographic location, and the version of the consent notice presented. This is the consent evidence layer that turns an ACS implementation from a technical checkbox into a defensible compliance posture.
Frequently Asked Questions
What is an Amazon consent signal?
The Amazon Consent Signal (ACS) is Amazon's proprietary framework for communicating user consent status to its advertising systems. It uses two parameters — amzn_user_data and amzn_ad_storage — stored in a first-party cookie on your domain, to tell Amazon whether a user has consented to data processing and advertising cookie use. Amazon Ads reads this signal before processing any advertising-related data for that user.
Does Amazon Ads require GDPR consent?
Yes, for UK and EEA users. Since February 7, 2025, Amazon has required advertisers transmitting personal data from UK or EEA users to send a verified consent signal — either ACS or an IAB TCF string — alongside that data. A second enforcement deadline of June 30, 2026 covers the Amazon Ad Tag, Conversions API, and Events API. Failing to implement a valid consent signal doesn't just create GDPR exposure; it also causes Amazon to reject or restrict the use of that data for targeting, retargeting, and conversion attribution.
Does Amazon Ads support IAB TCF?
Yes. Amazon Ads is a registered IAB TCF vendor with vendor ID 793. If you operate a TCF-certified CMP with Amazon included in your vendor list and purposes correctly mapped, the TCF string covers your consent obligation to Amazon. You don't need ACS if TCF is already in place and correctly configured. Note that if both TCF and ACS signals are present simultaneously, Amazon uses TCF and ignores ACS — so avoid sending both.
What happens if consent signals fail?
Without a valid consent signal, Amazon treats the user's data as lacking consent authorization and restricts its use for ad personalization and measurement. In practice, this means broken conversion attribution, reduced DSP audience reach in European markets, and gaps in Amazon Marketing Cloud reporting. The campaign itself can still technically serve ads, but operating without measurement and targeting is the equivalent of flying blind on your ad spend.
Can Amazon Ads run without consent for non-EU users?
The ACS requirement applies specifically to personal data from UK and EEA users. For US and other non-EEA traffic, Amazon's consent signal requirement doesn't apply in the same way, though US state privacy laws impose their own opt-out obligations for targeted advertising that may affect how you configure your consent architecture for American audiences.
How do I test whether my Amazon consent signal is working?
Open your browser's DevTools, navigate to the Application panel, and look for the amzn_consent cookie under your domain after accepting marketing consent. Verify that amzn_user_data and amzn_ad_storage are both set to GRANTED. Then reject cookies and reload — both values should change to DENIED. Check the Network panel for requests from Amazon's ad tags to confirm the consent state is being read correctly at tag execution. For CAPI implementations, log the API payload before dispatch to verify the consent object is present and correctly formatted.
How does Amazon consent signaling differ from Google Consent Mode?
Google Consent Mode operates through JavaScript API calls that adjust Google tag behavior dynamically, including sending anonymous cookieless pings when consent is denied in Advanced Mode. ACS operates through a first-party cookie that Amazon's tags read passively. When consent is denied for Amazon, Amazon stops processing that user's data — there's no equivalent to Google's cookieless modeling ping. The two can and should run simultaneously for advertisers using both platforms; they don't conflict and are managed independently within your CMP.
Building Reliable Amazon Consent Governance
The consent signal infrastructure that Amazon's June 30, 2026 deadline demands is not a one-time configuration task — it's a governance function that needs to remain current as your ad tech stack changes.
Every time you add an Amazon advertising integration — a new CAPI connector, an Ads Data Manager upload, an Events API implementation — that integration needs its own consent signal review. Every time you migrate tag management systems, update your CMP configuration, or change your WAF rules, the amzn_consent cookie setup needs to be validated end-to-end. Every time Amazon updates its consent requirements — as it did with the Events API open beta in May 2026 — your implementation needs to be reviewed against the new documentation.
The operational infrastructure that makes this sustainable is the same infrastructure that good consent management governance requires across your full advertising stack: a CMP with native support for platform consent modes, automated cookie scanning that surfaces new tags before they go to production without consent configurations, consent logging that produces audit-ready records, and geo-targeted consent rules that apply the right framework to the right visitors.
Audit your current Amazon consent configuration. Verify that the amzn_consent cookie is being set correctly for UK and EEA visitors. Confirm that your CAPI or Events API implementations include consent objects in their payloads. Validate that your TCF vendor list includes Amazon with the correct purpose consents if you're relying on TCF rather than ACS. The enforcement window is current. The consequences of misconfiguration are both a degraded campaign and a compliance exposure — and in Amazon's advertising ecosystem, those two problems arrive together.
