GA4 Measurement Protocol dans n8n : envoyer des conversions en server-side

Un visiteur qui bloque les scripts tiers, une fenêtre de navigation privée, ou simplement un cookie _ga supprimé avant la conversion : ce sont autant d'achats, d'inscriptions ou de leads que gtag.js ne verra jamais atteindre Google Analytics 4. Garimella, Kostakis et Mathioudakis ont mesuré ce phénomène dans une étude présentée à la conférence ACM Web Science (2017) : sur un large échantillon de sites d'actualité, les bloqueurs de publicité les plus courants empêchent également le chargement des scripts d'analytics, pas seulement des publicités elles-mêmes. Le Measurement Protocol de GA4 répond au même problème que la Conversions API de Meta détaillée dans notre guide de tracking server-side Meta : envoyer l'évènement directement depuis votre serveur, sans dépendre de ce que le navigateur laisse passer. Ce guide construit ce pipeline dans n8n, du webhook de conversion jusqu'à l'appel à l'API.

Le Measurement Protocol en une minute

Contrairement à la Data API (qui lit des rapports déjà collectés — voir notre guide de rapport GA4 automatique), le Measurement Protocol écrit de nouveaux évènements directement dans une propriété GA4. C'est un simple endpoint HTTP : un POST vers https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=VOTRE_SECRET, avec un corps JSON qui décrit un ou plusieurs évènements.

Le measurement_id se récupère dans GA4 sous Admin → Flux de données → votre flux web (format G-XXXXXXX). L'api_secret se génère dans le même écran, section Measurement Protocol API secrets → Créer. Ces deux valeurs suffisent à authentifier l'appel — aucun credential Google Cloud complexe, contrairement à la Data API en lecture.

Étape 1 — Stocker le secret comme credential n8n

Le secret ne doit jamais être collé en dur dans un node HTTP Request : créez un credential générique (Header Auth ou variable d'environnement chiffrée) qui le porte, avec la même discipline que celle détaillée dans notre guide sur la sécurisation des credentials et clés API. Le measurement_id, lui, n'est pas secret et peut voyager en paramètre d'URL classique dans le node.

Étape 2 — Récupérer le client_id côté navigateur

Le Measurement Protocol exige un client_id qui identifie le visiteur — sans lui, GA4 rejette l'évènement. Ce n'est pas un identifiant à inventer côté serveur : il existe déjà dans le cookie _ga posé par gtag.js, au format GA1.2.123456789.1699999999. Le client_id correspond à l'avant-dernier segment (123456789.1699999999) : un petit script front le lit et le transmet avec le formulaire ou l'appel qui déclenche la conversion, exactement comme le fbc/fbp de Meta doit être capturé côté front avant d'atteindre n8n.

function getGa4ClientId() {
  const match = document.cookie.match(/_ga=GA\d\.\d\.(\d+\.\d+)/);
  return match ? match[1] : null;
}

Étape 3 — Déclencher le workflow sur la conversion réelle

Comme pour tout envoi de tracking server-side, le déclencheur doit être l'action métier confirmée, pas sa simple création : un webhook de commande validée (voir nos guides de connexion Shopify et d'automatisation des commandes e-commerce), ou un webhook de paiement confirmé côté Stripe comme détaillé dans notre article sur les webhooks Stripe et relances de paiement. Un webhook qui repart deux fois pour la même transaction doit être filtré en amont, sur le même principe que l'idempotence des webhooks.

Étape 4 — Construire le payload d'évènement

Un node Set assemble le corps JSON attendu par l'endpoint. Pour un achat e-commerce :

{
  "client_id": "{{ $json.ga_client_id }}",
  "events": [{
    "name": "purchase",
    "params": {
      "transaction_id": "{{ $json.order_id }}",
      "value": {{ $json.order_total }},
      "currency": "EUR",
      "items": [
        {
          "item_id": "{{ $json.product_sku }}",
          "item_name": "{{ $json.product_name }}",
          "price": {{ $json.product_price }},
          "quantity": {{ $json.quantity }}
        }
      ]
    }
  }]
}

Le champ transaction_id joue le même rôle que l'event_id de la Conversions API Meta : c'est lui qui permet à GA4 de rapprocher cet envoi serveur avec l'évènement purchase que gtag.js a peut-être déjà envoyé côté navigateur, et de ne compter la conversion qu'une seule fois. S'il existe, un user_id (identifiant interne du compte client, pas une donnée personnelle brute) peut s'ajouter au niveau racine du payload pour affiner le rapprochement cross-device.

Étape 5 — Appeler l'API et valider avec l'endpoint de debug

Un node HTTP Request en POST envoie ce payload vers https://www.google-analytics.com/mp/collect?measurement_id=...&api_secret=.... Avant toute mise en production, pointez temporairement le même node vers https://www.google-analytics.com/mp/debug/mp/collect : cet endpoint accepte le payload identique mais renvoie une validation détaillée (champ manquant, type incorrect, évènement non reconnu) au lieu de l'enregistrer dans les rapports — contrairement à l'endpoint de production, qui accepte silencieusement un payload mal formé sans jamais faire apparaître l'évènement dans l'interface GA4, ce qui rend le débogage a posteriori très difficile.

Respecter le consentement, pas seulement contourner les bloqueurs

Le Measurement Protocol contourne les bloqueurs techniques côté navigateur, mais pas les obligations RGPD : si un visiteur a refusé les cookies de mesure d'audience, l'appel serveur ne doit tout simplement pas partir. La méthode la plus fiable est de stocker le statut de consentement au moment où il est recueilli (dans la même table applicative que la commande ou le lead) et de conditionner le node HTTP Request dessus avec un IF en amont — le même réflexe que celui détaillé dans notre guide du registre des traitements RGPD avec n8n, appliqué ici au tracking publicitaire plutôt qu'au registre lui-même.

Pour les équipes qui doivent pouvoir justifier ce qui a été transmis à Google et quand, journaliser chaque appel dans une table Supabase dédiée (évènement, client_id, transaction_id, statut de consentement, réponse de l'API) reprend exactement le patron de piste d'audit du workflow « Enregistrement d'audit dans Supabase » du Pack Conformité & Audit — un sub-workflow appelé en Execute Sub-workflow après chaque envoi, plutôt qu'un node Supabase dupliqué dans chaque automatisation de tracking.

Bonnes pratiques et pièges fréquents

• Toujours lire le client_id dans le cookie _ga existant, jamais en générer un nouveau côté serveur : un client_id inventé crée un visiteur fantôme qui ne rejoint aucune session déjà connue de GA4.
• Réutiliser le même transaction_id entre gtag.js et le Measurement Protocol pour éviter de compter chaque achat deux fois dans les rapports.
• Valider systématiquement via /debug/mp/collect avant publication : l'endpoint de production n'affiche aucune erreur explicite, il ignore simplement les évènements mal formés.
• Conditionner l'envoi au consentement réel, stocké au moment de la conversion — jamais supposé.
• Ne pas transmettre de données personnelles identifiables (email, nom) dans les params : le Measurement Protocol n'a pas de mécanisme de hashage dédié comme la Conversions API Meta, et Google interdit explicitement l'envoi de PII dans les paramètres d'évènement.

En résumé

Un pipeline Measurement Protocol dans n8n repose sur cinq briques : un client_id lu dans le cookie _ga existant et transmis au serveur, un déclencheur sur la conversion réellement confirmée, un payload JSON structuré avec un transaction_id partagé avec gtag.js, un appel POST vers l'endpoint GA4 validé au préalable via /debug/mp/collect, et une vérification du consentement avant tout envoi. Si votre instance n8n gère déjà les webhooks de commande ou de paiement de vos automatisations e-commerce, ce tracking server-side s'ajoute comme un nœud de plus dans un workflow existant, sans nouvelle intégration à construire de zéro.