Conversions Google Ads dans n8n : migrer vers la Data Manager API avant que votre pipeline reste bloqué

Si un pipeline n8n qui poussait vos conversions hors ligne vers Google Ads s’est mis à échouer silencieusement depuis la mi-juin, ce n’est pas un bug côté n8n : depuis le 15 juin 2026, Google a fermé l’import de conversions hors ligne (offline conversion import) et les enhanced conversions for leads sur l’API Google Ads classique, au profit d’une API distincte, la Data Manager API. C’est le même mouvement de fond qui pousse depuis plusieurs années les plateformes publicitaires à consolider leurs intégrations autour de données de correspondance de première partie (email et téléphone hashés) plutôt que de cookies tiers : une étude de référence de Goldfarb et Tucker (Privacy Regulation and Online Advertising, Management Science, 2011 — voir sur Google Scholar) avait déjà montré qu’un durcissement de la réglementation sur le suivi publicitaire pouvait faire chuter l’efficacité mesurée des campagnes de plus de 60 % — d’où l’intérêt, pour les annonceurs, de sécuriser un canal de correspondance de première partie qui ne dépend pas des cookies. Ce guide détaille comment reconstruire ce pipeline dans n8n avec la Data Manager API.

Ce qui a changé, concrètement

Deux flux étaient historiquement gérés par ConversionUploadService sur googleads.googleapis.com :

• L’import de conversions hors ligne — un lead qualifié en dur en boutique ou signé en CRM, remonté vers Google Ads plusieurs jours après le clic publicitaire.
• Les enhanced conversions for leads — un envoi complémentaire d’email et de téléphone hashés pour améliorer la correspondance d’une conversion déjà importée.

Les deux sont désormais bloqués sur l’API Google Ads classique et redirigés vers la Data Manager API, un point d’entrée unique conçu par Google pour distribuer une même donnée vers plusieurs produits (Google Ads, Display & Video 360, Google Analytics) sans multiplier les intégrations. Les enhanced conversions pour le web, elles, restent gérées par le tag Google ou Google Tag Manager côté navigateur et ne sont pas concernées par cette bascule — seul le flux API côté serveur change.

Préparer le compte Google Ads

Avant de toucher à n8n, deux réglages côté Google Ads conditionnent tout le reste :

1. Dans Outils et paramètres → Conversions → Paramètres, acceptez les conditions d’utilisation des données client (customer data terms) si ce n’est pas déjà fait — l’API refuse silencieusement les évènements tant que ce consentement n’est pas coché.
2. Notez l’identifiant client Google Ads (customer ID, sans tirets) du compte qui doit recevoir les conversions : c’est lui qui sert de productAccountId dans chaque appel.

Activer la Data Manager API et créer les accès OAuth2

La Data Manager API vit dans Google Cloud, pas dans le Centre développeurs Google Ads :

1. Dans un projet Google Cloud (existant ou dédié), activez l’API Data Manager API depuis la bibliothèque d’APIs.
2. Créez un identifiant OAuth 2.0 Client ID (type « Application Web ») dans API et services → Identifiants, avec pour URI de redirection https://oauth.n8n.cloud/oauth2/callback en Cloud ou l’URL équivalente de votre instance self-hosted.
3. Le scope requis à l’autorisation est https://www.googleapis.com/auth/datamanager — un scope différent de celui utilisé par le node Google Ads natif, donc une nouvelle credential distincte, même si le compte Google est le même.

Configurer la credential dans n8n

Dans n8n, créez une credential de type OAuth2 API (générique) plutôt que la credential « Google Ads OAuth2 API » préconfigurée, qui ne porte pas le bon scope. Renseignez :

• Client ID et Client Secret issus de Google Cloud.
• Authorization URL : https://accounts.google.com/o/oauth2/v2/auth
• Access Token URL : https://oauth2.googleapis.com/token
• Scope : https://www.googleapis.com/auth/datamanager

Connectez-vous une fois pour générer le refresh token, en suivant la même logique que celle détaillée dans notre guide de configuration OAuth2 côté Google. Cette credential servira ensuite dans un node HTTP Request, authentification « Predefined Credential Type » → la credential OAuth2 que vous venez de créer.

Hasher les identifiants utilisateur

La Data Manager API n’accepte que des identifiants hashés en SHA-256, hexadécimal, sur des valeurs normalisées : email en minuscules sans espace, téléphone au format E.164 (+33...). Un node Code avant l’appel API prépare ces champs :

const crypto = require('crypto');

const normalizeEmail = (e) => e.trim().toLowerCase();
const hash = (v) => crypto.createHash('sha256').update(v).digest('hex');

return [{
  json: {
    ...$json,
    email_hash: hash(normalizeEmail($json.email)),
    phone_hash: hash($json.phone.replace(/[^0-9+]/g, '')),
  },
}];

Le node Crypto en opération Hash (SHA256, sortie HEX) — voir notre guide du node Crypto — fait le même calcul sans écrire de code, si vous préférez rester sur des nodes standards. Ne hashez que l’email et le téléphone : le transactionId (identifiant du lead ou de la commande côté CRM) et le GCLID restent en clair, ce sont des identifiants techniques, pas des données personnelles au même titre.

Construire et envoyer l’évènement

Un node HTTP Request en POST vers https://datamanager.googleapis.com/v1/events:ingest, avec l’en-tête x-goog-user-project positionné sur l’ID du projet Google Cloud, porte un corps qui identifie la destination puis l’évènement :

{
  "destinations": [{
    "productDestinationId": "GOOGLE_ADS",
    "productAccountId": "1234567890"
  }],
  "events": [{
    "transactionId": "deal-48213",
    "eventTimestamp": "2026-08-13T09:15:00Z",
    "userData": {
      "userIdentifiers": [
        { "emailAddress": "{{ $json.email_hash }}" },
        { "phoneNumber": "{{ $json.phone_hash }}" }
      ]
    },
    "adIdentifiers": { "gclid": "{{ $json.gclid }}" },
    "conversionValue": { "value": "{{ $json.montant }}", "currencyCode": "EUR" }
  }]
}

Ce squelette couvre le cas courant d’un lead qualifié en CRM plusieurs jours après le clic. Le schéma complet du corps de requête — champs optionnels de consentement, évènements d’audience distincts de events:ingest — est documenté sur la référence officielle de la méthode events.ingest ; vérifiez-y tout champ qui ne figure pas ci-dessus avant de généraliser à un gros volume, les schémas d’API Google évoluant vite sur ce produit récent.

Éviter les envois en double

Un CRM qui déclenche deux fois le même webhook de changement de statut enverrait sinon deux fois la même conversion. Le principe est identique à celui décrit dans notre article sur l’idempotence des webhooks : vérifier dans une table (Supabase, ou une Data Table n8n) si le transactionId a déjà été envoyé avant de déclencher l’appel, plutôt que de compter uniquement sur une éventuelle déduplication côté Google.

Vérifier et industrialiser

Sous Outils et paramètres → Conversions → Diagnostics, Google Ads affiche le statut de réception des évènements avec un délai de quelques heures. Pour un import initial d’historique CRM plutôt qu’un flux unitaire, découpez l’envoi en lots avec un node Loop Over Items : la Data Manager API accepte plusieurs évènements dans le même tableau events, mais mieux vaut rester sur des lots de quelques centaines pour isoler facilement un échec partiel plutôt que de renvoyer un fichier entier en cas d’erreur. Si votre workflow enchaîne plusieurs appels rapprochés, la gestion des erreurs 429 et des retries suit la même logique que celle détaillée dans notre guide sur les limites de débit des API IA, transposable telle quelle à une API publicitaire.

Ce qui ne change pas

Si votre instance n8n appelle par ailleurs l’API Google Ads classique pour d’autres opérations — mettre en pause des campagnes sous-performantes ou générer un reporting Google Ads et Meta Ads — ces flux ne sont pas concernés par la bascule : seul l’import de conversions change de porte d’entrée. Les deux credentials (Google Ads OAuth2 classique pour le reporting, OAuth2 générique scope datamanager pour les conversions) cohabitent sans conflit dans la même instance.

En résumé

Depuis le 15 juin 2026, l’import de conversions hors ligne et les enhanced conversions for leads vers Google Ads passent obligatoirement par la Data Manager API : un nouveau point de terminaison (events:ingest), un nouveau scope OAuth2 (datamanager), mais le même schéma de nodes n8n que pour la Conversions API de Meta ou de LinkedIn — HTTP Request, hashage SHA-256, déduplication par identifiant métier. Si ce pipeline alimente déjà un flux de qualification de leads entrants piloté par n8n, la migration se limite à remplacer un node HTTP Request par un autre, sans toucher au reste du workflow. Et si vous devez garder une trace exploitable de chaque conversion transmise à un tiers publicitaire — utile en cas de contrôle RGPD sur le traitement de données de contact — les workflows de journalisation Supabase du Pack Conformité & Audit (149 €) suivent le même principe que celui décrit dans notre article sur la piste d’audit RGPD avec Supabase, appliqué ici à un flux de conversions publicitaires plutôt qu’à une donnée personnelle interne.