Vous avez branché Meta, TikTok, Pinterest, Snapchat, LinkedIn, Microsoft Ads, X et Reddit en server-side. Il manque un canal à la série, et c’est probablement celui dont personne ne parle sérieusement : Amazon Ads. Depuis qu’Amazon pousse ses annonceurs à mesurer les conversions off-Amazon (DSP, Sponsored Ads, Performance+), l’Amazon Ads Conversions API en server-side GTM est devenue la brique manquante de beaucoup de stacks e-commerce. Le souci, c’est qu’à part le repo GitHub officiel et la doc de Stape, il n’existe quasiment aucun guide de praticien sur le sujet. Cet article comble ce trou, et il se concentre sur les trois réglages qui décident vraiment de la qualité de votre signal : l’authentification, la déduplication par Event ID et les match keys.
Pourquoi envoyer vos conversions off-Amazon en server-side en 2026
Amazon Ads n’est plus seulement une régie on-site. Avec la DSP, les Sponsored Ads hors marketplace et l’offre Performance+ orientée IA, Amazon a besoin de savoir ce que font vos audiences sur votre propre site, pas seulement sur Amazon. Et pour nourrir ses modèles d’enchères automatiques, il lui faut un signal de conversion off-Amazon fiable.
Or ce signal, le pixel navigateur seul ne le fournit plus. Les adblockers et l’ITP de Safari empêchent les tags client-side de se déclencher sur une part importante des sessions, et les taux de refus du consentement amputent encore le volume. Résultat, une partie structurelle de vos achats ne remonte jamais à Amazon, et Performance+ optimise sur des données trouées.
La Conversions API répond exactement à ce problème : vos événements partent de votre conteneur serveur vers Amazon, sans dépendre du navigateur. Vous gagnez sur deux tableaux, un volume d’événements plus complet et des données utilisateur plus riches pour le matching. C’est la même logique que celle décrite dans le guide Meta CAPI server-side GTM, transposée à l’écosystème Amazon.
Prérequis avant de configurer l’Amazon Conversions API
Trois éléments doivent être en place avant de commencer :
- Un conteneur server-side GTM actif, sur Google Cloud ou via un hébergeur comme Stape ou Addingwell. Si vous n’y êtes pas encore, commencez par le guide GTM server-side : pourquoi et comment migrer, et gardez en tête le coût réel du server-side.
- Un accès à Amazon Ads (Campaign Manager / Events Manager) avec les droits pour créer un tag et générer des credentials. Selon votre setup, vous piloterez un compte DSP Advertiser ou un compte Manager (format
amzn1.ads1.ma1.<id>). - Le template Amazon dans votre conteneur serveur. Deux options existent : le template officiel
amzn/ads-events-api-gtm-taget celui de Stape (stape-io/amazon-tag). Les deux couvrent l’essentiel ; l’officiel colle au plus près du schéma Amazon, celui de Stape ajoute quelques conforts d’intégration.
Authentification : OAuth ou API token
C’est le premier choix structurant, et il n’est pas anodin. Le tag Amazon accepte deux modes.
L’OAuth (Bearer token) repose sur une variable d’authentification (nommée “Amazon CAPI Auth” dans le template officiel) qui fournit un access token et un client ID. Ce mode fonctionne aussi bien avec un compte DSP Advertiser qu’avec un compte Manager. Contrepartie, un access token OAuth expire : vous devez gérer son rafraîchissement.
L’API token est un token de service persistant, rattaché à un dataset Ads Data Manager. Il ne fonctionne qu’avec un compte Manager, mais il ne nécessite aucun refresh. Pour une implémentation server-side qui doit tourner sans babysitting, c’est souvent le choix le plus robuste.
Le tableau ci-dessous résume le compromis :
| Critère | OAuth (Bearer) | API token |
|---|---|---|
| Type de compte | DSP Advertiser ou Manager | Manager uniquement |
| Rafraîchissement du token | Requis (le token expire) | Aucun (token persistant) |
| Rattachement | Access token + client ID | Dataset Ads Data Manager |
| Idéal pour | Setups pilotés côté compte | Server-side autonome |
Une fois l’authentification en place, renseignez les champs d’identité du compte : l’Advertiser Account ID (sous Account access & settings, pour un compte DSP) ou le Manager Account ID au format amzn1.ads1.ma1.<id>.
Mapping des événements GA4 vers Amazon
Le tag serveur consomme les événements qui transitent par votre conteneur, typiquement des événements GA4. En mode de mapping automatique, il traduit les champs GA4 vers le schéma Amazon. Voici les correspondances qui comptent :
| Champ GA4 | Champ Amazon | Rôle |
|---|---|---|
nom d’événement (purchase) | Conversion Type (Off-Amazon Purchases) | Type d’événement |
transaction_id | Event ID | Déduplication |
value | Event Value | Valeur de la conversion |
currency | Currency Code | Devise |
items[].quantity | Units Sold | Quantité vendue |
Côté Amazon, vous choisissez un Conversion Type parmi les valeurs prévues (Add to Cart, Lead, Off-Amazon Purchases, Sign Up, etc.), ainsi qu’un Event Source (Website, Android, iOS ou Offline) et un Country Code au format ISO 3166-1 alpha-2. Alignez chaque événement business sur le bon Conversion Type plutôt que de tout envoyer en “purchase”, sous peine de brouiller vos rapports Amazon.
Déduplication par Event ID
C’est le réglage que personne ne doit rater. Si vous gardez le pixel Amazon côté client (recommandé pour le matching navigateur) et que vous ajoutez la CAPI côté serveur, Amazon reçoit deux fois le même achat. Sans déduplication, vous comptez double.
La règle est simple : les deux canaux doivent envoyer le même Event ID pour un même événement. Côté serveur, mappez le champ Event ID sur un identifiant stable et unique, l’idéal étant le transaction_id (ou l’order ID de votre back-office). Côté pixel, envoyez exactement la même valeur. Amazon reconnaît alors les deux hits comme un seul événement et ne compte l’achat qu’une fois.
Le piège classique : générer un ID aléatoire différent côté serveur et côté client. Si les valeurs divergent, la dédup ne se déclenche pas. Utilisez une source de vérité unique (le numéro de commande) et propagez-la dans le data layer avant que les deux tags ne se déclenchent.
Match keys : email et téléphone hashés, Match ID et aatToken
Le volume d’événements ne sert à rien si Amazon ne peut pas rattacher vos conversions à des utilisateurs. C’est le rôle des match keys, et c’est là que le server-side prend l’avantage.
Le tag accepte de la PII non hashée (email, téléphone, prénom, nom, éléments d’adresse) : il la normalise (minuscules, espaces retirés) puis la hashe en SHA-256 côté serveur avant l’envoi. Vous n’avez donc pas à hasher vous-même, mais assurez-vous de fournir des données propres. À côté de la PII, Amazon accepte des identifiants non-PII envoyés tels quels : MAID, RAMP ID, Match ID, Real ID, Merkle ID, Kantar ID et l’adresse IP complète.
Deux identifiants méritent une attention particulière. Le Match ID est un identifiant privacy-safe généré par l’annonceur, qui relie les interactions d’un même utilisateur entre sessions, appareils et canaux, sans exposer de PII. Le aatToken est un cookie first-party de l’Advanced Matching, stocké dans le navigateur et automatiquement inclus dans les événements suivants. En pratique, plus vous fournissez de match keys de qualité (email hashé plus Match ID plus aatToken), meilleur est le taux de correspondance, donc meilleure est l’optimisation.
Le cas EU/UK : le consentement n’est pas optionnel
C’est le point qui casse le plus d’implémentations en Europe. Pour les Country Codes de l’UE et du Royaume-Uni, le tag Amazon ne se déclenche pas sans consentement configuré. Ce n’est pas un avertissement dans les logs, c’est un blocage : pas de signal de consentement valide, pas d’événement envoyé.
Le tag sait consommer trois formes de signal : le TCF v2.2, le GPP, ou les signaux Amazon directs (consentement Ad Storage et User Data). Concrètement, votre CMP doit exposer une chaîne de consentement exploitable, et votre conteneur doit la transmettre au tag. Si vous travaillez déjà le sujet dans GA4, vous êtes en terrain connu : c’est la même mécanique que celle décrite dans le guide Consent Mode v2 pour GA4, et elle s’inscrit dans le durcissement réglementaire européen détaillé côté Digital Omnibus et consentement GA4.
Un dernier réflexe utile : l’Advanced Matching (le cookie aatToken) est lui aussi soumis au consentement. En Europe, ne comptez pas dessus par défaut, et vérifiez ce qui part réellement une fois le consentement refusé.
Tester et vérifier : la checklist
Avant de passer le tag en production (donc de retirer draft: true de votre côté et de sortir de la bêta de test), déroulez cette vérification :
- Preview du conteneur web : l’événement (par exemple
purchase) se déclenche et pousse bien untransaction_iddans le data layer. - Preview du conteneur serveur : le tag Amazon reçoit l’événement, l’Event ID correspond au
transaction_id, et le Conversion Type est le bon. - Cohérence de dédup : le pixel client et le serveur envoient le même Event ID pour le même achat.
- Match keys : les champs PII arrivent renseignés et propres (l’email en clair avant hashage serveur, pas déjà hashé deux fois).
- Consentement (EU/UK) : avec consentement accordé, l’événement part ; avec consentement refusé, il est bien bloqué.
- Events Manager Amazon : les conversions apparaissent, sans doublon, avec la bonne valeur et la bonne devise.
Ce qu’il faut retenir
L’Amazon Ads Conversions API en server-side GTM n’a rien de sorcier une fois qu’on a identifié les vrais points de bascule. Choisissez l’API token si vous voulez un setup Manager qui tourne seul, verrouillez la déduplication sur un transaction_id partagé, empilez les match keys pour muscler le matching, et traitez le consentement EU/UK comme un prérequis bloquant et non comme une option. Faites-le proprement et vous rendez à Performance+ un signal off-Amazon aussi fiable que le reste de votre stack CAPI. Si vous n’avez pas encore équipé les autres canaux, la même méthode s’applique presque à l’identique : voyez par exemple le guide Reddit Conversions API server-side GTM pour comparer les schémas.