Google Data Manager API : Guide Complet d'Intégration

Google communique surtout sur l'interface sans code de Data Manager, avec un chiffre marketing bien rodé : +26 % de ROAS incrémental en moyenne pour les annonceurs qui connectent leurs données offline et app, mesure interne Google sur la période avril 2025 à avril 2026, pas une étude indépendante. Cet article laisse l'interface de côté pour se concentrer sur ce qui intéresse un consultant tracking : l'API elle-même, sa vraie structure, son authentification, et comment l'intégrer proprement dans une infrastructure server-side existante.

Historique des versions, pour situer la maturité de l'API

Authentification et mise en route

Le scope OAuth2 requis est https://www.googleapis.com/auth/datamanager. C'est un scope sensible : toute application Google Cloud utilisée pour obtenir des identifiants utilisateur doit passer par la vérification OAuth de Google, sous peine d'afficher un écran de consentement non vérifié à vos utilisateurs. Pour tester rapidement en local avec les Application Default Credentials :

gcloud auth application-default print-access-token --scopes=https://www.googleapis.com/auth/datamanager

Le token obtenu s'utilise ensuite en en-tête Authorization: Bearer sur chaque appel.

La structure d'une Destination

Chaque requête d'ingestion cible une ou plusieurs destinations, avec une structure à 3 champs :

• operatingAccount (obligatoire) : le compte qui reçoit la donnée, avec un accountId et un accountType (GOOGLE_ADS, DISPLAY_VIDEO_ADVERTISER...).

• loginAccount (optionnel) : le compte via lequel vos identifiants accèdent au système. L'API vérifie que le compte Google de vos credentials est bien utilisateur de ce compte de connexion.

• productDestinationId (obligatoire) : l'identifiant précis de la ressource qui reçoit la donnée (ID d'audience, ID d'action de conversion, ID de propriété Analytics...).

Pour un accès direct à un compte Google Ads :

{
  "destinations": [
    {
      "operatingAccount": {
        "accountId": "1234567890",
        "accountType": "GOOGLE_ADS"
      },
      "loginAccount": {
        "accountId": "1234567890",
        "accountType": "GOOGLE_ADS"
      },
      "productDestinationId": "987654321"
    }
  ]
}

Pour un accès via un compte manager (MCC), loginAccount.accountId devient l'ID du compte gestionnaire parent, alors que operatingAccount.accountId reste l'ID du compte client final. Un détail à ne pas manquer : ces en-têtes de compte (login-account, linked-account) servent aux appels de gestion de ressources (créer, mettre à jour, lister), la documentation officielle précise noir sur blanc de ne jamais les définir sur une requête d'IngestionService, où c'est l'objet destinations du corps de la requête qui porte cette information.

Envoyer un événement de conversion, exemple complet

L'endpoint réel est POST https://datamanager.googleapis.com/v1/events:ingest. Exemple complet avec un gclid, un transactionId et le mode validateOnly pour tester sans rien envoyer réellement :

curl -X POST "https://datamanager.googleapis.com/v1/events:ingest" \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token --scopes=https://www.googleapis.com/auth/datamanager)" \
  -H "Content-Type: application/json" \
  -d '{
    "destinations": [{
      "operatingAccount": { "accountId": "1234567890", "accountType": "GOOGLE_ADS" },
      "productDestinationId": "987654321"
    }],
    "validateOnly": true,
    "events": [{
      "eventTimestamp": "2026-09-30T14:22:00Z",
      "eventName": "purchase",
      "transactionId": "CMD-88213",
      "adIdentifiers": {
        "gclid": "CjwKCAiA0KquBhB8EiwAkY-6pxx..."
      }
    }]
  }'

Points à respecter : jusqu'à 2000 événements par requête, eventTimestamp au format RFC 3339, eventName obligatoire pour un événement destiné à GA4, transactionId obligatoire quand l'événement sert de source additionnelle pour une conversion de tag déjà existante (pour permettre la déduplication). Au-delà du gclid, adIdentifiers accepte aussi gbraid et wbraid (conversions iOS), dclid (Display), et un mobileDeviceId pour l'IDFA/AdID. Le consentement se définit au niveau de la requête entière ou événement par événement, ce dernier prenant le pas sur le premier.

Audiences via audienceMembers.ingest

Même logique de destinations, mais jusqu'à 10 000 membres par requête, à envoyer vers des audiences Google Ads, Display & Video 360 ou Google Ad Manager (données Customer Match, identifiants mobiles ou données PAIR). Depuis la v1.5, le UserListService complète l'API pour créer et gérer les listes elles-mêmes, pas seulement y ajouter des membres, et la v1.8 a ajouté RemoveAllAudienceMembers pour vider une liste en un appel plutôt que de retirer les membres un par un.

Les vraies limites de l'outil

Data Manager n'enrichit pas la donnée et n'applique aucune logique de transformation personnalisée, il relaie ce qu'on lui envoie. Il reste cantonné à l'écosystème Google (Google Ads, GA4, DV360, CM360, SA360, Google Ad Manager), aucune destination tierce n'est prévue. Le contrôle de gouvernance et de consentement reste plus limité que ce qu'offre un vrai conteneur server-side, où vous gardez la main sur chaque transformation et chaque règle de routage.

Intégration avec un conteneur GTM Server-side

Point de précision important avant de le présenter comme un standard à un client : aucune documentation officielle Google ne décrit d'intégration native entre Data Manager API et GTM Server-side. L'architecture qui consiste à faire transiter la donnée par un conteneur server-side existant, qui la normalise une seule fois puis la distribue vers l'API Data Manager d'un côté et vers d'autres régies (Meta CAPI, TikTok, LinkedIn) de l'autre, est une recommandation d'architecture de consultants tracking, pas une fonctionnalité Google documentée.

Le vrai obstacle : l'authentification OAuth2 sensible

Contrairement à une intégration Meta CAPI ou OpenAI Ads (une clé API statique dans un en-tête), Data Manager exige un token OAuth2 sur le scope sensible datamanager, qui expire au bout d'environ une heure. Le mécanisme standard côté serveur pour obtenir ce token sans interaction humaine est le flux JWT Bearer d'un compte de service, qui repose sur une signature RSA (RS256) de la clé privée du compte de service. Or l'API JavaScript sandboxée de GTM Server n'expose que hmacSha256, une signature symétrique à secret partagé, pas de fonction de signature RSA asymétrique. Concrètement, un tag GTM Server ne peut pas générer lui-même un token OAuth valide pour ce scope, il n'a pas les moyens cryptographiques de le faire dans le bac à sable. C'est le point que la plupart des articles sur le sujet passent sous silence.

L'architecture qui fonctionne en pratique : un proxy léger

La solution consiste à sortir la gestion OAuth du conteneur GTM Server et à la confier à un petit service externe (Cloud Function ou Cloud Run) qui porte le compte de service, gère le cache et le renouvellement du token, et expose un endpoint simple protégé par un secret partagé. Le tag GTM Server appelle ce proxy comme n'importe quel endpoint HTTP classique, sans jamais manipuler l'authentification OAuth lui-même :

// Cloud Function (Node.js) : proxy entre GTM Server et Data Manager
const { GoogleAuth } = require('google-auth-library');
const auth = new GoogleAuth({ scopes: ['https://www.googleapis.com/auth/datamanager'] });

exports.dataManagerProxy = async (req, res) => {
  if (req.headers['x-proxy-secret'] !== process.env.PROXY_SECRET) {
    return res.status(403).send('Forbidden');
  }
  const client = await auth.getClient();
  const accessToken = (await client.getAccessToken()).token;

  const response = await fetch('https://datamanager.googleapis.com/v1/events:ingest', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer ' + accessToken,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(req.body),
  });

  const result = await response.json();
  res.status(response.status).json(result);
};

La librairie officielle google-auth-library gère elle-même la signature RSA et le cache du token en interne, c'est précisément ce que GTM Server ne peut pas faire seul. Le compte de service n'existe que dans cette fonction, jamais exposé côté conteneur.

Le tag côté conteneur GTM Server

Une balise HTML personnalisée (ou un template dédié) construit le payload à partir de la donnée déjà normalisée dans le conteneur, puis appelle le proxy :

const sendHttpRequest = require('sendHttpRequest');
const getAllEventData = require('getAllEventData');
const JSON = require('JSON');

const eventData = getAllEventData();

const payload = {
  destinations: [{
    operatingAccount: { accountId: data.googleAdsAccountId, accountType: 'GOOGLE_ADS' },
    productDestinationId: data.conversionActionId
  }],
  events: [{
    eventTimestamp: new Date(eventData.event_timestamp / 1000).toISOString(),
    eventName: eventData.event_name,
    transactionId: eventData.transaction_id,
    adIdentifiers: { gclid: eventData.gclid }
  }]
};

sendHttpRequest(
  data.proxyUrl,
  (statusCode) => {
    if (statusCode >= 200 && statusCode < 300) {
      data.gtmOnSuccess();
    } else {
      data.gtmOnFailure();
    }
  },
  { headers: { 'Content-Type': 'application/json', 'x-proxy-secret': data.proxySecret }, method: 'POST' },
  JSON.stringify(payload)
);

Le transactionId repris tel quel depuis l'événement source reste la clé de la déduplication : si le même identifiant de commande part aussi vers Google Ads via un tag de conversion classique, Data Manager ne compte pas l'événement deux fois. Cette architecture reste solide en pratique une fois le proxy en place : une seule balise dans le conteneur, une donnée normalisée une fois, et la possibilité d'ajouter Data Manager comme destination supplémentaire à côté de Meta CAPI ou TikTok sans dupliquer la logique métier.

Quand choisir quoi

Trois cas de figure raisonnables selon votre contexte : pour un besoin simple (un flux CRM ou e-commerce à connecter sans développement), l'interface sans code de Data Manager suffit directement, l'API n'apporte rien de plus dans ce cas. Si vous avez déjà une infrastructure server-side en place, appelez l'API Data Manager depuis votre conteneur GTM Server plutôt que de multiplier les intégrations point à point. Si vous distribuez vers plusieurs régies publicitaires au-delà de Google, l'approche server-side complète reste la plus pérenne, Data Manager n'étant qu'une destination parmi d'autres dans ce schéma.

Christophe Dubois

Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.