Conversions offline Google Ads & GA4 avec Data Manager API
Qu’est-ce que Data Manager API ?
Data Manager API est une API unifiée créée par Google pour aider les annonceurs à connecter et exploiter leurs données first-party (CRM, point de vente, base de données interne, etc.) à travers l’ensemble des produits publicitaires Google (Google Ads et Google Analytics 4).
Concrètement, elle permet d’envoyer en server-to-server des événements de conversion directement aux serveurs de Google, sans dépendre des restrictions du navigateur.
Depuis octobre 2025, Data Manager API est disponible pour l’ensemble des comptes Google Ads.
Ce que vous allez faire dans ce tutoriel
Voici les 6 grandes étapes que vous allez suivre pour mettre en place Data Manager API depuis votre conteneur GTM Server :
- Authentification : ajouter le service account Addingwell à Google Ads
- Import du tag : importer le template Data Manager API Conversions d’Addingwell dans GTM Server
- Configuration du tag : paramétrer les destinations Google Ads et/ou GA4
- Client Measurement Protocol : réceptionner les requêtes offline côté serveur
- Déclencheur : déclencher le tag sur le bon client/événement
- Vérifier les données : vérifier la remontée des données dans GTM Server et dans Google Ads/GA4
Pourquoi utiliser Data Manager API pour vos conversions ?
L’envoi des conversions via Data Manager API présente plusieurs avantages majeurs qui vont venir compléter votre collecte traditionnelle :
- Une mesure plus fiable et plus complète : en passant par une connexion API server-to-server, on s’affranchit des limitations du navigateur (ad blockers, restrictions cookies, ITP Safari, etc.) qui font perdre une partie des conversions.
- L’intégration de vos données offline : vous pouvez remonter à Google Ads les conversions qui ont lieu en dehors de votre site (ventes en magasin, conversions issues d’un CRM, etc.) pour obtenir une vue complète du ROI de vos campagnes.
- Une meilleure attribution grâce aux données first-party : en envoyant des identifiants first-party hachés (email, téléphone, adresse) en plus du GCLID, Google peut réconcilier la conversion même lorsque le clic d’origine n’est plus disponible (Enhanced Conversions for Leads).
- Une optimisation plus rapide des campagnes : plus le volume et la qualité des signaux de conversion remontés à Google Ads sont élevés, plus les algorithmes de bidding ont de matière pour optimiser vos enchères.
- Le respect de la vie privée : les données personnelles (PII) sont hachées (SHA-256) avant envoi et l’architecture server-side vous donne un contrôle total sur ce qui est transmis à Google.
Les cas d’usage
L’implémentation de Data Manager API depuis votre conteneur GTM Server peut répondre à 4 cas d’usage principaux.
1. Remonter les conversions offline à Google Ads
C’est le cas d’usage historique pour Google Ads : vous souhaitez tracker dans Google Ads des conversions qui ne se produisent pas sur votre site web (un appel téléphonique qui se transforme en vente, une commande finalisée par un commercial, un achat en boutique physique, etc.).
Pour ce cas d’usage, vous utilisez peut-être actuellement l’API Google Ads Offline . Data Manager API est le successeur de cette API, nous vous recommandons fortement de migrer vers cette nouvelle solution.
Le principe : votre CRM, votre point de vente ou votre Customer Data Platform (CDP) envoie l’événement de conversion au conteneur GTM Server. Le tag Data Manager API se charge ensuite de le transmettre à Google Ads sur l’action de conversion de type Website (Import from clicks), en utilisant soit le GCLID (Offline Conversion Tracking classique), soit des données first-party hachées (Enhanced Conversions for Leads) pour matcher la conversion au clic d’origine.

2. Enrichir le tracking online Google Ads avec une source de données additionnelle
Data Manager API peut également être utilisée comme source de données additionnelle pour vos tags Google Ads existants. L’objectif n’est plus de remplacer le tracking online mais de le compléter pour récupérer les conversions perdues côté navigateur.
Le tag Google Ads classique (déclenché depuis le GA4 Client) remonte les conversions online en temps réel. En parallèle, le tag Data Manager API envoie les mêmes conversions depuis votre back-end (au moment où la commande est validée en base, par exemple). Google utilise alors le Transaction ID pour dédupliquer les deux flux.

Comment Google Ads traite les données issues d’une source additionnelle
Au sein d’une même action de conversion, Google Ads utilise le transactionId pour dédupliquer les événements provenant de sources différentes (votre tag Google Ads côté site et vos requêtes d’ingestion Data Manager API). Le tableau ci-dessous résume la logique appliquée :
| Scénario | Champ de données | Traitement appliqué |
|---|---|---|
1. Le transactionId correspond à un événement déjà reçu via le tag | conversionValue (avec currencyCode) | Mis à jour. La valeur envoyée par Data Manager API écrase celle initialement enregistrée. |
2. Le transactionId correspond à un événement déjà reçu via le tag | Autres champs (par exemple adIdentifiers.gclid, userData, etc.) | Ignorés. Les autres champs envoyés par la source additionnelle n’écrasent pas les valeurs déjà enregistrées par le tag Google pour les transactions matchées. |
3. Le transactionId ne correspond à aucun événement existant | Toutes les données fournies (userData, conversionValue, currencyCode, etc.) | Création d’une nouvelle conversion. Google tente ensuite de l’attribuer à un clic publicitaire à partir des identifiants fournis (adIdentifiers.gclid ou userData). |
Attention pour les scénarios 1 et 3
Pendant la période d’essai initiale de 14 jours, ces nouvelles conversions apparaissent dans vos rapports mais ne sont pas utilisées pour le bidding. À la fin de cette période, elles deviennent automatiquement biddables.
En pratique, cela signifie que Data Manager API est particulièrement utile pour rattraper les conversions perdues par le tag client-side (à cause d’un ad blocker par exemple) et pour corriger la valeur d’une conversion a posteriori.
3. Remonter les conversions offline à Google Analytics
C’est le cas d’usage historique pour Google Analytics : vous souhaitez tracker dans Google Analytics des conversions d’un utilisateur qui a commencé son parcours sur le site web mais qui le termine en offline (un appel téléphonique qui se transforme en vente, une commande finalisée par un commercial, un achat en boutique physique après une visite sur le site, etc.).
Pour ce cas d’usage, vous utilisez peut-être actuellement l’API Measurement Protocol . Data Manager API est le successeur de cette API, nous vous recommandons fortement de migrer vers cette nouvelle solution.

Le principe : votre CRM, votre point de vente ou votre Customer Data Platform (CDP) envoie l’événement de conversion au conteneur GTM Server. Le tag Data Manager API se charge ensuite de le transmettre à Google Analytics, en utilisant soit le GCLID (Offline Conversion Tracking classique), soit des données first-party hachées (Enhanced Conversions for Leads) pour matcher la conversion au clic d’origine.
4. Enrichir le tracking Google Analytics 4 avec une source de données additionnelle
Le même principe s’applique à Google Analytics 4. Data Manager API peut envoyer des événements GA4 (achats, leads, événements personnalisés) depuis vos systèmes back-end, en complément du tag GA4 server-side.
GA4 utilise lui aussi le Transaction ID pour dédupliquer les événements et n’enregistrer qu’une seule conversion par transaction, garantissant ainsi un reporting fiable malgré les pertes côté client.
La fonctionnalité de source de données additionnelle pour GA4 est disponible uniquement pour les propriétés ajoutées sur allowlist par Google. Pour en faire la demande, remplissez ce formulaire .

Comment Google Analytics traite les données issues d’une source additionnelle
Dans un même événement et une même propriété, Google Analytics utilise le transactionId pour dédupliquer l’événement provenant de différentes sources (comme votre tag GA4 serveur et le tag Data Manager API Conversions by Addingwell).
Le fait que Google Analytics utilise le transactionId pour dédupliquer les événements ne veut pas dire que vous ne pouvez envoyer que des événements purchase avec un identifiant de commande. Vous pouvez tout aussi bien envoyer un événement close_convert_lead avec un identifiant de lead, ou un événement custom_event avec un identifiant unique généré par votre système back-end. Tant que le transactionId est le même pour les deux sources, Google Analytics ne comptera qu’un seul événement.
Préparer le projet Data Manager API
La mise en place technique de Data Manager API côté serveur est relativement simple, il n’y a qu’un tag à configurer dans votre conteneur GTM Server. En revanche, la vraie complexité du projet réside dans la remontée de données offline sur votre endpoint serveur via le standard du measurement protocol pour la construction des requêtes.
Voici une liste (non exhaustive) de questions à se poser en amont pour préparer votre projet Data Manager API et garantir sa réussite :
- Est-ce que le système offline qui héberge la donnée de conversion (CRM, POS, e-commerce, etc.) est capable d’envoyer une requête HTTP au conteneur GTM Server au moment où la conversion se produit ?
- Est-ce que je souhaite envoyer les conversions en temps réel ou en batch (par exemple une fois par jour) ? Est-ce que mon système offline est capable de faire l’un ou l’autre ou les deux ?
- Est-ce que les conversions que je souhaite envoyer à Google Ads ont un
transaction_idet est-ce que cetransaction_idest accessible dans mon système offline ? (l’idée ici est de pouvoir faire le lien entre les conversions envoyées en online et celles envoyées par Data Manager API en offline pour éviter les doublons dans Google Ads dans le cadre du cas d’usage numéro 2) - Comment je fais le rapprochement de la conversion avec le clic publicitaire d’origine (GCLID) ? (champs cachés dans un formulaire, stockage navigateur, stockage serveur avec Firestore, etc.)
Pré-requis
Avant d’implémenter Data Manager API, assurez-vous d’avoir :
- Un conteneur GTM Server configuré et opérationnel (sur Addingwell ou sur votre propre infrastructure).
- Un flux de données envoyées du web vers le conteneur server-side
- Une action de conversion Google Ads créée et correctement paramétrée selon votre cas d’usage (Website pour les conversions online, Website avec Import from clicks pour les conversions offline) et/ou une propriété Google Analytics 4.
- Pour les Enhanced Conversions for Leads : avoir accepté les conditions d’utilisation des Enhanced Conversions et activé la fonctionnalité dans Google Ads (Goals → Settings → Enhanced conversions for leads).
Authentification avec Data Manager API
Pour permettre à votre conteneur GTM Server de communiquer avec Data Manager API, vous devez configurer l’authentification avec votre service account Addingwell.
Récupérer le service account dans Addingwell
Rendez-vous dans votre container Addingwell, cliquez sur le menu Tagging Server puis copiez le service account.
Le service account est un compte technique (une adresse email de la forme …@….iam.gserviceaccount.com) que votre conteneur GTM Server utilise pour s’authentifier auprès de Google. C’est cette identité — et non votre compte personnel — qui enverra les conversions à Google Ads : il faut donc l’autoriser explicitement dans votre compte.

Ajouter le service account à Google Ads
Cette étape est à réaliser uniquement si vous souhaitez envoyer vos conversions à Google Ads.
Une fois l’adresse email du service account récupérée, rendez-vous dans Admin → Access and security de votre compte Google Ads, cliquez sur le bouton +, collez l’adresse du service account et attribuez-lui le rôle Standard. Ce rôle est nécessaire pour autoriser l’import de conversions ; un accès en lecture seule ne suffirait pas. L’accès est actif immédiatement, aucune validation par email n’est requise côté service account.

Ajouter le service account à Google Analytics 4
Cette étape est à réaliser uniquement si vous souhaitez envoyer vos événements à Google Analytics 4.
Une fois l’adresse email du service account récupérée, rendez-vous dans Admin → Property settings -> Property access management de votre propriété GA4, cliquez sur le bouton + puis Add users.

Collez l’adresse du service account et attribuez-lui le rôle Editor.

Ce rôle est nécessaire pour autoriser l’import des événements ; un accès en lecture seule ne suffirait pas. L’accès est actif immédiatement, aucune validation par email n’est requise côté service account.
Mise en place de Data Manager API
Importer le tag dans GTM Server
Cliquez ici pour télécharger le tag Data Manager API et cliquez sur l’icône de téléchargement pour récupérer le fichier.
Le tag Data Manager API n’est pour l’instant pas disponible dans la galerie de templates de GTM : il s’agit d’un template maintenu par Addingwell que vous devez importer manuellement dans votre conteneur. Le fichier template.tpl que vous téléchargez contient l’intégralité du tag — à la fois l’interface de configuration que vous verrez dans GTM et la logique d’envoi des données vers Data Manager API.

Rendez-vous ensuite dans l’onglet Templates du conteneur serveur, puis, dans la section Tag templates, cliquez sur New.

Cliquez ensuite sur les trois petits points en haut à droite, puis sélectionnez Import.

Sélectionnez ensuite le fichier template.tpl récemment téléchargé, puis cliquez sur Save.

Configurer le tag Data Manager API
Créez un nouveau tag dans Google Tag Manager Server-Side et sélectionnez le template Data Manager API que vous venez d’importer.

Le principe : une API, plusieurs destinations
L’idée derrière Data Manager API, c’est de fournir un point d’entrée unique pour envoyer un événement à plusieurs produits Google en même temps. Là où auparavant il fallait une connexion à Google Ads Offline et une connexion au Measurement Protocol de GA4 (chacun avec sa propre authentification, son propre format, ses propres endpoints), Data Manager API centralise tout via une seule requête.
Une destination, c’est la description d’un endroit où l’événement doit être envoyé. Concrètement, ça répond à la question : « à quel compte, sur quelle propriété, pour quelle action de conversion cet événement doit-il être comptabilisé ? »
Une même requête peut contenir plusieurs destinations. C’est ce qui permet, par exemple, d’envoyer un événement purchase à la fois vers une action de conversion Google Ads et vers une propriété GA4 en un seul appel API.
Google Ads Destinations
Remplissez cette section uniquement si vous souhaitez envoyer vos conversions à Google Ads.
Operating Customer ID et Customer ID : Entrez dans ces deux champs l’identifiant du compte Google Ads sur lequel vous souhaitez envoyer les conversions. (exemple : 123-456-7890)

Conversion ID : Entrez ici l’identifiant de votre action de conversion Google Ads. Lorsque vous êtes à l’intérieur de votre action de conversion, vous pouvez le retrouver dans l’URL de votre navigateur après ctId=. (exemple : 1234567890)

Google Analytics Destinations
Remplissez cette section uniquement si vous souhaitez envoyer vos événements à Google Analytics 4.
Property ID : Entrez ici l’identifiant de votre propriété Google Analytics 4. Allez dans Admin → Property details → Property ID pour le retrouver. (exemple : 453232504)

Measurement ID : Entrez ici l’identifiant de mesure de votre flux de données Google Analytics 4. Allez dans Admin → Data Streams → Web → Measurement ID pour le retrouver. (exemple : G-1234567890)

Event Source
Choisissez ici la source de vos événements de conversion parmi les options suivantes :
- WEB : pour les cas d’usage 2 et 4 présentés plus haut
- APP : pour les événements de conversion provenant d’une application mobile
- IN_STORE : pour les événements de conversion provenant d’un point de vente physique (potentiellement les cas d’usage 1 et 3 présentés plus haut si la source de données est un point de vente)
- MESSAGE : pour les événements de conversion provenant d’une messagerie.
- PHONE : pour les événements de conversion provenant d’un appel téléphonique.
- OTHER
Validate Only (Test Mode)
Renseignez cette valeur à true si vous souhaitez uniquement valider vos événements de conversion sans que Google Ads ne les utilise pour l’attribution. Cela peut être utile pour tester votre configuration avant de commencer à envoyer des données réelles. Vous verrez ainsi les erreurs de l’API s’il y en a, sans que cela n’affecte vos données de conversion dans Google Ads si toutefois votre requête est valide.
N’oubliez pas de configurer Validate Only à false une fois que vous êtes prêt à envoyer vos conversions à Google Ads/GA4, sinon vos données de conversion ne seront pas prises en compte.
Encoding
Ici c’est une notion un peu plus technique, c’est l’encodage utilisé par sha256 lors du hachage des données utilisateur.
Si vous ne savez pas quoi mettre, laissez la valeur par défaut HEX.
Gérer le Google Consent Mode
Data Manager API vous permet de transmettre l’état du consentement de l’utilisateur pour chaque conversion. C’est particulièrement important dans l’espace économique européen : les signaux de consentement conditionnent la façon dont Google peut utiliser vos données pour l’attribution et l’optimisation.
Le tag expose deux paramètres de consentement dans le groupe Request-Level Consent Settings :
- Ad User Data → mappé sur
consent.adUserDatadans le payload Data Manager API - Ad Personalization → mappé sur
consent.adPersonalizationdans le payload Data Manager API
Chaque paramètre accepte l’une des valeurs suivantes :
Event Data(valeur par défaut) : le tag lit automatiquement l’état du consentement dans l’événement entrant (eventData.consent.ad_user_dataeteventData.consent.ad_personalization)CONSENT_STATUS_UNSPECIFIED: le consentement n’est pas renseignéCONSENT_GRANTED: l’utilisateur a donné son consentementCONSENT_DENIED: l’utilisateur a refusé
Ces valeurs peuvent être renseignées en dur dans le tag (par exemple CONSENT_GRANTED si tous vos événements offline proviennent d’utilisateurs consentants), ou dynamiquement grâce à l’option Event Data qui lit le consentement envoyé dans le payload. C’est cette seconde approche, plus fiable, que nous détaillons ci-dessous.
Envoyer les signaux du Consent Mode dans le payload
Ajoutez un objet consent dans les params de votre événement, avec l’état du consentement de l’utilisateur au moment de la conversion :
"consent": {
"ad_user_data": "CONSENT_GRANTED",
"ad_personalization": "CONSENT_DENIED"
}Vous pouvez envoyer directement les valeurs attendues par le tag (CONSENT_GRANTED, CONSENT_DENIED). Si votre système source envoie d’autres valeurs (par exemple granted / denied ou true / false), le tag les comprendra automatiquement et fera le mapping vers les valeurs attendues.
| Valeur source | Valeur cible |
|---|---|
granted | CONSENT_GRANTED |
denied | CONSENT_DENIED |
true | CONSENT_GRANTED |
false | CONSENT_DENIED |
CONSENT_GRANTED | CONSENT_GRANTED |
CONSENT_DENIED | CONSENT_DENIED |
Les valeurs granted / denied / true / false sont acceptées indifféremment en chaîne de caractères ou en booléen, sans tenir compte de la casse. Toute autre valeur (ou une valeur absente) est convertie en CONSENT_STATUS_UNSPECIFIED.
Si vous ne renseignez pas ces champs, le consentement reste à CONSENT_STATUS_UNSPECIFIED. Dans l’espace économique européen, nous vous recommandons de toujours transmettre une valeur explicite (CONSENT_GRANTED ou CONSENT_DENIED) pour rester conforme et permettre à Google d’exploiter au mieux vos conversions.
Configurer le client Measurement Protocol
Cette partie est un extrait de notre documentation complète sur les événements offline.
Pour réceptionner les requêtes offline côté GTM Server, vous devez configurer un client Measurement Protocol. Pour cela, créez un nouveau client dans votre conteneur GTM Server et sélectionnez le client Measurement Protocol (GA4).
Même si l’API Measurement Protocol est aujourd’hui dépréciée, notez ici que nous utilisons le Measurement Protocol comme standard pour construire la requête envoyée à GTM Server. Le client Measurement Protocol (GA4) est donc nécessaire pour que GTM Server puisse correctement comprendre la requête.

Sélectionnez ensuite le client Measurement Protocol (GA4).

Une fois le client ajouté, configurez-le avec le chemin d’activation /mp/collect. Le choix du chemin d’activation est arbitraire mais il doit être cohérent avec l’URL que vous utiliserez pour envoyer vos événements de conversion à GTM Server.

Déclencher le tag Data Manager API
Une fois le client Measurement Protocol (GA4) configuré, vous pouvez créer un déclencheur pour votre tag Data Manager API. Pour cela, créez un nouveau déclencheur de type Custom et renseignez le nom de l’événement que vous souhaitez utiliser pour déclencher le tag (dans cet exemple, nous avons choisi purchase) et le nom du client utilisé (dans cet exemple, nous avons choisi MP).

Ajoutez ensuite ce déclencheur à votre tag Data Manager API.

Exemple de payload à envoyer à votre endpoint GTM Server
Cette partie est un extrait de notre documentation complète sur les événements offline.
Pour tester la configuration du tag Data Manager API, vous pouvez envoyer un événement de conversion de test à votre endpoint GTM Server. Voici un exemple de payload JSON que vous pouvez utiliser pour tester l’envoi d’un événement purchase à Google Ads et/ou à GA4 via Data Manager API.
Il est important ici d’utiliser le même chemin d’activation que celui configuré dans le client Measurement Protocol (GA4) de votre conteneur GTM Server. Dans cet exemple, nous avons choisi /mp/collect.
POST https://<votre-endpoint-gtm-server>/mp/collect{
"events": [{
"name": "purchase",
"params": {
"gclid": "123",
"transaction_id": "12345", // must be at least 5 characters long
"value": "30",
"currency": "EUR",
"user_id": "1234567890",
"items": [{
"item_id": "SKU_12345",
"item_name": "Stan and Friends Tee",
"affiliation": "Google Merchandise Store",
"coupon": "SUMMER_FUN",
"currency": "EUR",
"discount": 2.22,
"index": 0,
"item_brand": "Google",
"item_category": "Apparel",
"item_category2": "Adult",
"item_category3": "Shirts",
"item_category4": "Crew",
"item_category5": "Short sleeve",
"item_list_id": "related_products",
"item_list_name": "Related Products",
"item_variant": "green",
"location_id": "ChIJIQBpAG2ahYAR_6128GcTUEo",
"price": 10.01,
"google_business_vertical": "retail",
"quantity": 3
}],
"client_id": "1234567890.1234567890",
"user_data": {
"email_address": "[email protected]",
"phone_number": "+33627362122",
"address": {
"first_name": "John",
"last_name": "Doe",
"postal_code": "75000",
"city": "Paris",
"country": "FR"
}
}
}
}]
}Correspondance entre les eventData et le payload Data Manager API
Vous n’envoyez pas directement le format attendu par Data Manager API : vous envoyez un événement au format Measurement Protocol / GA4 (les eventData ci-dessus), et c’est le tag qui se charge de le transformer en requête Data Manager API. Le tableau ci-dessous détaille cette correspondance, champ par champ, pour vous aider à construire vos propres requêtes.
Les données personnelles (email, téléphone, prénom, nom) sont automatiquement hachées en SHA-256 par le tag : vous les envoyez en clair dans vos eventData, et elles ressortent hachées dans le payload Data Manager API. Vous pouvez aussi envoyer directement des valeurs déjà hachées, dans ce cas-là elles ne seront pas hachées à nouveau.
Événement
event_name→eventNamepurchase).eventTimestampeventSourceWEB, IN_STORE, etc.), pas dans les eventData.user_id→userIdclient_id→clientIdcid.Identifiants publicitaires
gclid→adIdentifiers.gclidgbraid→adIdentifiers.gbraidwbraid→adIdentifiers.wbraidTransaction
value→conversionValuecurrency→currencyEUR).transaction_id→transactionIdDonnées utilisateur
user_data.email_addressouuser_data.email→userData.userIdentifiers[].emailAddressuser_data.phone_numberouuser_data.phone→userData.userIdentifiers[].phoneNumber+33627362122).user_data.address[0].first_name→userData.userIdentifiers[].address.givenNameuser_data.address[0].last_name→userData.userIdentifiers[].address.familyNameuser_data.address[0].country→userData.userIdentifiers[].address.regionCodeFR), non haché.user_data.address[0].postal_code→userData.userIdentifiers[].address.postalCodePanier (cartData)
items[].item_id→cartData.items[].itemIditems[].merchant_product_id→cartData.items[].merchantProductIditem_id.items[].quantity→cartData.items[].quantityitems[].price→cartData.items[].unitPriceitems[].{item_name, affiliation, coupon, …}→cartData.items[].additionalItemParameters[]item_name, affiliation, coupon, discount, index, item_brand, item_category…) sont repris tels quels sous forme de paires parameterName / value.items[].discount→cartData.transactionDiscountParamètres additionnels
taxoucouponoushippingoucreative_nameoucreative_slotoupromotion_idoupromotion_name→additionalEventParameters[]parameterName / value.Propriétés utilisateur
new_customeroucustomer_type→userProperties.customerTypenew_customer (true/false) est traduit en NEW / RETURNING ; customer_type est repris en majuscules.Consentement
consent.ad_user_data→consent.adUserDataCONSENT_GRANTED / CONSENT_DENIED (voir la section Consent Mode).consent.ad_personalization→consent.adPersonalizationCONSENT_GRANTED / CONSENT_DENIED (voir la section Consent Mode).La plupart de ces champs peuvent aussi être renseignés ou surchargés directement dans la configuration du tag (GCLID, email, nom, code pays, etc.). Une valeur définie dans le tag est prioritaire sur celle présente dans les eventData.
Envoi du payload à GTM Server avec Postman
Nous vous recommandons d’utiliser un outil comme Postman pour tester l’envoi de cette requête à votre endpoint GTM Server. Assurez-vous de remplacer l’URL par celle de votre endpoint GTM Server et de configurer la méthode HTTP sur POST.

Ensuite, ouvrez votre preview GTM Server en cliquant sur Preview.

Cliquez ensuite sur les 3 petits points en haut à droite de la fenêtre de preview et sélectionnez Send requests manually.

Copiez ensuite le token de preview.

Ajoutez le token de preview dans l’onglet Headers de Postman avec la clé x-gtm-server-preview.
Ce token relie votre requête Postman à votre session de debug : c’est lui qui permet à votre événement d’apparaître dans la fenêtre de preview au lieu d’être traité silencieusement comme du trafic de production. Sans ce header, vous ne verrez rien remonter dans la preview.

Vérifier les données envoyées à Data Manager API
Maintenant que vous avez configuré votre tag Data Manager API et que vous avez envoyé un événement de conversion de test à votre endpoint GTM Server avec l’aide de Postman, il est temps de vérifier que vos données sont correctement reçues dans un premier temps dans la preview GTM Server et ensuite dans les plateformes (Google Ads, Google Analytics 4).
Dans la preview GTM Server
Afin de vérifier que vos événements de conversion sont correctement envoyés à Data Manager API, vous pouvez utiliser le mode preview de Google Tag Manager Server. Assurez-vous de configurer l’option Validate Only à true pour ne pas envoyer de données réelles à Google Ads pendant vos tests.
La première chose à vérifier est que votre événement est bien reçu dans la preview GTM Server. Ensuite, cliquez sur l’événement purchase dans la liste des événements reçus et vérifiez que le tag Data Manager API est déclenché avec succès.

Cliquez ensuite sur le tag Data Manager API pour vérifier que le tag envoie bien une requête à Data Manager API.

Ensuite cliquez sur la requête envoyée à Data Manager API pour vérifier que les données envoyées correspondent bien à vos attentes.
Vous pouvez notamment vérifier que les identifiants de destination (Google Ads et/ou GA4) sont corrects, que le GCLID est bien présent, que le transaction_id est correct et que les données utilisateur sont correctement hachées.

Voici le corps de la requête formaté correctement :
{
"encoding": "HEX",
"destinations": [
{
"operatingAccount": {
"accountType": "GOOGLE_ADS",
"accountId": "1234567890"
},
"loginAccount": {
"accountType": "GOOGLE_ADS",
"accountId": "1234567890"
},
"productDestinationId": "1234567890"
}
],
"consent": {
"adUserData": "CONSENT_STATUS_UNSPECIFIED",
"adPersonalization": "CONSENT_STATUS_UNSPECIFIED"
},
"events": [
{
"eventTimestamp": "2026-07-09T14:05:59+00:00",
"eventSource": "WEB",
"eventName": "purchase",
"userId": "123",
"adIdentifiers": {
"gclid": "123"
},
"clientId": "1234567890.1234567890",
"conversionValue": "30",
"currency": "EUR",
"transactionId": "12345",
"userData": {
"userIdentifiers": [
{
"emailAddress": "36d6de708b54f80f4e673d0a09bc1e21c8fb52b267b9afbe812f8000b1ab9590"
},
{
"phoneNumber": "f0054832a91eda16350883be5ac5b9729f2b2c62b5529207f94e1e5d88d2027c"
},
{
"address": {
"givenName": "96d9632f363564cc3032521409cf22a852f2032eec099ed5967c0d000cec607a",
"familyName": "799ef92a11af918e3fb741df42934f3b568ed2d93ac1df74f1b8d41a27932a6f",
"regionCode": "FR",
"postalCode": "75000"
}
}
]
},
"cartData": {
"items": [
{
"merchantProductId": "SKU_12345",
"itemId": "SKU_12345",
"quantity": "3",
"unitPrice": 10.01,
"additionalItemParameters": [
{
"parameterName": "item_name",
"value": "Stan and Friends Tee"
},
{
"parameterName": "affiliation",
"value": "Google Merchandise Store"
},
{
"parameterName": "coupon",
"value": "SUMMER_FUN"
},
{
"parameterName": "discount",
"value": "2.22"
},
{
"parameterName": "item_brand",
"value": "Google"
},
{
"parameterName": "item_category",
"value": "Apparel"
},
{
"parameterName": "item_category2",
"value": "Adult"
},
{
"parameterName": "item_category3",
"value": "Shirts"
},
{
"parameterName": "item_category4",
"value": "Crew"
},
{
"parameterName": "item_category5",
"value": "Short sleeve"
},
{
"parameterName": "item_list_id",
"value": "related_products"
},
{
"parameterName": "item_list_name",
"value": "Related Products"
}
]
}
],
"transactionDiscount": 2.22
}
}
],
"validateOnly": true
}Vérifier dans Google Ads
Une fois que vous êtes satisfait des requêtes envoyées à Data Manager API, vous pouvez passer le paramètre validateOnly à false. Cela aura pour effet de comptabiliser réellement les conversions dans Google Ads.
Une fois que vos requêtes sont envoyées avec validateOnly à false, vous pouvez vérifier dans Google Ads que les données sont bien reçues.
Notez ici que si vous venez de créer votre action de conversion dans Google Ads, vous devrez attendre plusieurs heures avant de voir votre action de conversion passer en statut Active.

Vérifier dans Google Analytics 4
Selon nos tests, il n’y a pas de moyen de voir les remontées Data Manager API dans le DebugView de GA4 pour vérifier la réception et le contenu des événements. La seule manière de vérifier que les événements sont bien reçus par GA4 est d’attendre quelques heures et de vérifier dans les rapports que les événements sont bien comptabilisés.

Félicitations !
Félicitations ! Vous avez maintenant tout en main pour envoyer vos conversions à Google Ads et GA4 via Data Manager API depuis votre conteneur GTM Server. Pour résumer, la mise en place se déroule en quelques grandes étapes : configurer l’authentification avec le service account Addingwell, importer et paramétrer le tag Data Manager API, mettre en place le client Measurement Protocol (GA4) pour réceptionner vos requêtes offline, déclencher le tag sur le bon événement, puis tester le tout avec Postman avant de passer validateOnly à false.
Au-delà de la configuration technique, gardez en tête que la réussite de votre projet repose surtout sur la qualité des données que vous remontez : un transaction_id cohérent entre vos flux online et offline pour éviter les doublons, un GCLID ou des données first-party de bonne qualité pour rattacher la conversion au clic d’origine, et un envoi fiable depuis votre système source (CRM, POS, e-commerce). C’est cette rigueur en amont qui vous permettra d’obtenir une mesure complète et une optimisation efficace de vos campagnes.
Si vous avez une question ou rencontrez un blocage lors de votre implémentation, n’hésitez pas à envoyer un mail à notre équipe support.