Amazon Ads Stops Processing UK and EEA Data on June 30. The Fix Is a Six-Week Job.
Amazon Ads stops processing UK and EEA user data without a verified consent signal on June 30, 2026. The rule has been live since February 7, 2025, but June 30 is when Amazon actually turns off ingestion for traffic missing an IAB TCF string, a GPP signal, or an Amazon Consent Signal (ACS) cookie. Teams using Amazon Ad Tag, the Conversions API, or the Events API beta have roughly six weeks left.
The clearest summary of the deadline came from PPC Land on May 14, sourced off a LinkedIn flag from BASE CTO Tim Watkinson. The headline he used was "Your data won't work after June 30th," and that is, mechanically, what happens. Amazon does not drop your account. It just stops ingesting events that arrive without a consent payload, and your audience segments, ROAS reporting, and DSP retargeting for UK and EEA traffic start hollowing out from the bottom.
I've watched a lot of teams treat this one like it's a Q4 problem. From what I've seen in agency Slacks, the assumption is that Amazon will quietly extend, the way Google extended the GA4 sunset twice. There's no reason to assume that here. Amazon already gave the industry 16 months between the February 2025 policy turn-on and the June 30 enforcement date, and the Events API moved into open beta with a dedicated consent object baked into the request schema. That's not the behavior of a platform planning to push the deadline.
What actually breaks on June 30
Three Amazon tools are in scope: the Amazon Ad Tag (AAT) on your site, the Conversions API (CAPI) for server-side event forwarding, and the Events API, which is still in open beta but is the one Amazon is clearly steering future integrations toward. Any UK or EEA user event sent through these channels without a consent signal on June 30 onwards gets dropped at the edge.
Dropped doesn't mean errored. It means processed-but-discarded for personalization, measurement, and audience building. Your reporting in DSP and Amazon Marketing Cloud will still show events, but the slice attributable to consented users will be the only one that feeds bidding, lookalikes, or remarketing pools. For UK-heavy advertisers, this is the difference between a working campaign and a campaign that runs on a fraction of its previous signal budget.
Amazon's own consent signal requirements page spells out the obligation in policy terms: any personal information transmitted to Amazon Ads from UK or EEA users must carry an IAB TCF signal or an Amazon Consent Signal. The June 30 date isn't on that page yet, which is part of why teams are missing it. The enforcement language is in the policy. The enforcement date is in the developer comms and the trade press.
The three formats Amazon accepts, and why TCF wins ties
You don't need all three. You need one, paired with a 2-character ISO 3166 country code so Amazon knows which legal regime applies.
The accepted formats are IAB TCF (the European Transparency and Consent Framework string, currently on version 2.3), GPP (the IAB's Global Privacy Protocol, which wraps multiple regional consent strings into one), and ACS (Amazon's proprietary signal that lives as a first-party JSON cookie named amzn_consent with two flags, amzn_user_data and amzn_ad_storage). When multiple signals are present in the same request, Amazon prioritizes TCF over ACS, which matters if your CMP is sending both in a transition window.
Didomi's ACS breakdown covers the consent object structure for advertisers running their own CMPs. The choice between TCF and ACS usually comes down to where you already are. If your consent platform is one of the IAB TCF-certified CMPs (most of the major ones are), TCF is free and instant once you add Amazon as a vendor. If you're on a homegrown banner, ACS is the lower-effort path because the cookie format is fixed and Amazon's documentation publishes the exact JSON shape.
There's a third path that a lot of mid-market advertisers are quietly taking: Usercentrics' ACS integration went GA last year, and Cookiebot, OneTrust, and Didomi all have native ACS support in their UK/EEA configs. If you're already paying for a CMP, the question to ask your account manager this week is "what's the SKU or feature flag I need to enable to start emitting ACS to Amazon by next sprint." If they don't have an answer, that's the signal to escalate.
The Events API beta is the tell
Amazon didn't roll out a beta of a new server-side conversion API in May with no consent object. They rolled out a beta with a consent object embedded at the individual event level, support for 1 to 500 events per request, ISO-8601 timestamps, SHA-256-hashed match keys (except MAID and MATCH_ID), and a 21-day lookback on event freshness. Events older than 21 days are not processed. Custom attributes are capped at 10 per event, plus the three reserved attributes for brand, productId, and category.
That schema is a long-term server-side play. It looks like CAPI but with one important difference: the consent object isn't an envelope wrapped around the batch. It rides with each individual event. Amazon built the contract so that an advertiser can send a mixed batch of consented and unconsented events and have the platform make the per-event decision at ingest. That is not a contract designed for a deadline that's going to slip.
For teams already running Meta CAPI and wondering how this compares, the closest parallel is the Meta Conversions API EMQ setup, where conversion quality is enforced through field-level scoring. Amazon's Events API takes the same per-event posture for consent specifically. Once you understand it as "Meta CAPI for consent, not for match quality," the wiring effort feels familiar.
How to wire this in by June 23
I'd target June 23, not June 30, for an internal go-live. A week of cushion for the inevitable CMP misconfiguration that shows up in DSP reporting as a 30 percent dip in audience match rate for one specific country.
Here's roughly how the work breaks down. Week 1: confirm with your CMP vendor that they emit a TCF string or ACS cookie for UK and EEA visitors and that Amazon is in the vendor list. This is a 30-minute conversation if your CMP is certified, and a multi-week project if it's not. Week 2: update your AAT loader and any server-side CAPI/Events API integration to read the consent signal from the request context and forward it on every outbound event. Week 3: validate in Amazon Marketing Cloud that consented and unconsented events are being correctly tagged. Week 4: monitor and fix.
The non-obvious piece is what to do for the unconsented users. Amazon's deletion endpoint is now spec'd: send a standard event with "Delete" as the event name to remove a user from audience segments within 24 hours, and the platform retains data for a maximum of 13 months. If your CMP supports a "withdraw consent" event, hook it to the Events API delete call. Most teams won't have this in v1, but it's the right architecture to plan toward, especially for any UK consumer brand that's going to get GDPR data subject access requests.
Where this hits hardest
UK retailers, EEA-focused DTC, and any agency that runs Amazon DSP for premium brands with strong European footprints. If you're a US-only advertiser on Amazon Ads, your operational risk on June 30 is essentially zero. If you're running pan-European campaigns, the gap between "we have a CMP banner" and "our consent strings actually reach Amazon's ingest" is the entire ballgame.
One more thing worth noting. The ACS setup guide documents the cookie format and parameter values, but the part most teams trip on isn't the cookie. It's the second leg, the server-side forwarding. The AAT picks up the cookie on the client. The Conversions API does not. Your server tagging stack has to read the consent state at the moment of the event and inject it into the CAPI payload, or the consent never makes it to Amazon. I've seen this miss twice in the last month at agencies who thought "we have a CMP, we're good" and didn't realize CAPI doesn't share cookies with the browser.
Six weeks, three formats, one inbox
If you do nothing else this week, send one email to your CMP account manager and one to your Amazon Ads rep asking, in writing, what your current consent signal coverage looks like for UK and EEA traffic. Get the answer in writing, because if it's wrong, the second week of July is when you'll want a paper trail. The number of teams that find out on July 2 that their CMP was emitting the right banner but not the right downstream signal is going to be larger than anyone is currently forecasting.
I don't think this one ends up as the next GA4 panic, because the scope is narrower. But for the advertisers it does hit, the recovery curve isn't a week. It's the time it takes to rebuild a UK or EEA audience pool from scratch, which on Amazon DSP, given the new ingest cadence, is more like a quarter than a sprint.
