You have wired up Meta, TikTok, Pinterest, Snapchat, LinkedIn, Microsoft Ads, X and Reddit server-side. One channel is missing from the series, and it is probably the one nobody covers seriously: Amazon Ads. Ever since Amazon started pushing advertisers to measure off-Amazon conversions (DSP, Sponsored Ads, Performance+), the Amazon Ads Conversions API in server-side GTM has become the missing brick in many e-commerce stacks. The problem is that outside the official GitHub repo and Stape’s docs, there is almost no practitioner guide on the topic. This article fills that gap, and it focuses on the three settings that actually decide the quality of your signal: authentication, Event ID deduplication and match keys.
Why send your off-Amazon conversions server-side in 2026
Amazon Ads is no longer just an on-site ad network. With the DSP, Sponsored Ads beyond the marketplace and the AI-driven Performance+ offering, Amazon needs to know what your audiences do on your own site, not only on Amazon. And to feed its automated bidding models, it needs a reliable off-Amazon conversion signal.
The browser pixel alone no longer delivers that signal. Ad blockers and Safari ITP stop client-side tags from firing on a large share of sessions, and consent refusal rates cut into the volume even further. As a result, a structural portion of your purchases never reaches Amazon, and Performance+ optimizes on incomplete data.
The Conversions API answers exactly this problem: your events leave your server container straight for Amazon, without depending on the browser. You win on two fronts, a more complete event volume and richer user data for matching. It is the same logic described in the Meta CAPI server-side GTM guide, applied to the Amazon ecosystem.
Prerequisites before configuring the Amazon Conversions API
Three things must be in place before you start:
- An active server-side GTM container, on Google Cloud or through a host like Stape or Addingwell. If you are not there yet, start with the server-side GTM migration guide, and keep the real cost of server-side in mind.
- Access to Amazon Ads (Campaign Manager / Events Manager) with permission to create a tag and generate credentials. Depending on your setup, you will drive a DSP Advertiser account or a Manager account (format
amzn1.ads1.ma1.<id>). - The Amazon template in your server container. Two options exist: the official
amzn/ads-events-api-gtm-tagtemplate and Stape’s (stape-io/amazon-tag). Both cover the essentials; the official one stays closest to Amazon’s schema, while Stape’s adds a few integration conveniences.
Authentication: OAuth or API token
This is the first structural choice, and it is not trivial. The Amazon tag accepts two modes.
OAuth (Bearer token) relies on an authentication variable (named “Amazon CAPI Auth” in the official template) that provides an access token and a client ID. This mode works with both a DSP Advertiser account and a Manager account. The downside: an OAuth access token expires, so you have to handle its refresh.
The API token is a persistent service token bound to an Ads Data Manager dataset. It only works with a Manager account, but it needs no refresh. For a server-side implementation that should run without babysitting, it is often the more robust choice.
The table below sums up the trade-off:
| Criterion | OAuth (Bearer) | API token |
|---|---|---|
| Account type | DSP Advertiser or Manager | Manager only |
| Token refresh | Required (token expires) | None (persistent token) |
| Bound to | Access token + client ID | Ads Data Manager dataset |
| Best for | Account-driven setups | Autonomous server-side |
Once authentication is in place, fill in the account identity fields: the Advertiser Account ID (under Account access & settings, for a DSP account) or the Manager Account ID in the amzn1.ads1.ma1.<id> format.
Mapping GA4 events to Amazon
The server tag consumes the events flowing through your container, typically GA4 events. In automatic mapping mode, it translates GA4 fields into Amazon’s schema. Here are the mappings that matter:
| GA4 field | Amazon field | Role |
|---|---|---|
event name (purchase) | Conversion Type (Off-Amazon Purchases) | Event type |
transaction_id | Event ID | Deduplication |
value | Event Value | Conversion value |
currency | Currency Code | Currency |
items[].quantity | Units Sold | Units sold |
On the Amazon side, you pick a Conversion Type from the supported values (Add to Cart, Lead, Off-Amazon Purchases, Sign Up, etc.), plus an Event Source (Website, Android, iOS or Offline) and a Country Code in ISO 3166-1 alpha-2 format. Map each business event to the right Conversion Type instead of sending everything as “purchase”, or you will muddy your Amazon reports.
Deduplication with Event ID
This is the setting nobody can afford to miss. If you keep the Amazon pixel client-side (recommended for browser matching) and add the CAPI server-side, Amazon receives the same purchase twice. Without deduplication, you count double.
The rule is simple: both channels must send the same Event ID for the same event. Server-side, map the Event ID field to a stable, unique identifier, ideally the transaction_id (or the order ID from your back office). On the pixel, send exactly the same value. Amazon then recognizes the two hits as a single event and counts the purchase only once.
The classic trap: generating a different random ID on the server and on the client. If the values diverge, deduplication never triggers. Use a single source of truth (the order number) and propagate it into the data layer before either tag fires.
Match keys: hashed email and phone, Match ID and aatToken
Event volume is worthless if Amazon cannot tie your conversions back to users. That is the job of match keys, and this is where server-side pulls ahead.
The tag accepts unhashed PII (email, phone, first name, last name, address components): it normalizes it (lowercased, trimmed) and then hashes it with SHA-256 server-side before sending. So you do not have to hash it yourself, but make sure you feed clean data. Alongside PII, Amazon accepts non-PII identifiers sent as-is: MAID, RAMP ID, Match ID, Real ID, Merkle ID, Kantar ID and the full IP address.
Two identifiers deserve special attention. The Match ID is a privacy-safe, advertiser-generated identifier that connects a single user’s interactions across sessions, devices and channels, without exposing any PII. The aatToken is a first-party Advanced Matching cookie, stored in the browser and automatically included in subsequent events. In practice, the more quality match keys you feed (hashed email plus Match ID plus aatToken), the higher the match rate, and the better the optimization.
The EU/UK case: consent is not optional
This is the point that breaks the most implementations in Europe. For EU and UK Country Codes, the Amazon tag will not fire without consent configured. This is not a log warning, it is a block: no valid consent signal, no event sent.
The tag can consume three forms of signal: TCF v2.2, GPP, or direct Amazon signals (Ad Storage and User Data consent). Concretely, your CMP must expose a usable consent string, and your container must pass it to the tag. If you already handle this in GA4, you are on familiar ground: it is the same mechanism described in the Consent Mode v2 for GA4 guide, and it fits into the tightening EU regulation covered in Digital Omnibus and GA4 consent.
One last useful reflex: Advanced Matching (the aatToken cookie) is itself subject to consent. In Europe, do not rely on it by default, and check what actually leaves once consent is refused.
Testing and verification: the checklist
Before you push the tag to production (that is, remove draft: true on your end and step out of test), run this check:
- Web container Preview: the event (for example
purchase) fires and pushes atransaction_idinto the data layer. - Server container Preview: the Amazon tag receives the event, the Event ID matches the
transaction_id, and the Conversion Type is correct. - Dedup consistency: the client pixel and the server send the same Event ID for the same purchase.
- Match keys: PII fields arrive filled in and clean (email in plain text before server-side hashing, not already double-hashed).
- Consent (EU/UK): with consent granted, the event leaves; with consent refused, it is correctly blocked.
- Amazon Events Manager: conversions appear, with no duplicates, and the right value and currency.
What to take away
The Amazon Ads Conversions API in server-side GTM is nothing exotic once you have pinned down the real decision points. Choose the API token if you want a Manager setup that runs on its own, lock deduplication on a shared transaction_id, stack match keys to strengthen matching, and treat EU/UK consent as a blocking prerequisite rather than an option. Do it properly and you hand Performance+ an off-Amazon signal as reliable as the rest of your CAPI stack. If you have not equipped the other channels yet, the same method applies almost identically: see for example the Reddit Conversions API server-side GTM guide to compare schemas.