Conversions API Meta dans n8n : tracking server-side sans dépendre du pixel

Un bloqueur de publicité, une politique de cookies stricte ou la simple expiration d'un cookie tiers suffisent à faire disparaître une conversion aux yeux du Pixel Meta installé sur un site. Le problème n'est pas anecdotique : Garrett Johnson, Scott Shriver et Shaoyin Du ont montré, dans une étude publiée dans Marketing Science (2020), qu'une publicité affichée à un utilisateur ayant refusé le suivi comportemental se vend en moyenne 52 % moins cher aux enchères — une perte de valeur directement liée à la dégradation du signal de mesure. La Conversions API (CAPI) de Meta répond à ce problème en envoyant l'évènement de conversion directement depuis votre serveur, sans dépendre de ce que le navigateur du visiteur laisse passer. Ce guide montre comment construire ce pipeline dans n8n, du webhook de commande jusqu'à l'appel à l'API Graph.

Pourquoi la Conversions API change la donne

Le Pixel Meta s'exécute dans le navigateur du visiteur : un bloqueur de publicité, le mode navigation privée, ou une politique de cookies tiers restrictive (ITP sur Safari, par exemple) peuvent empêcher l'évènement de partir avant même qu'il n'atteigne les serveurs de Meta. La CAPI contourne cette dépendance en envoyant le même type d'évènement — un achat, une inscription, l'ajout au panier — directement depuis votre backend ou votre instance n8n, un canal qu'aucun bloqueur côté client ne peut intercepter.

Cette fiabilité a un effet mesurable sur la qualité de l'attribution publicitaire elle-même. Dans une analyse portant sur quinze expériences publicitaires menées chez Facebook et plus de 500 millions d'observations, Brett Gordon, Florian Zettelmeyer, Neha Bhargava et Dan Chapsky ont montré, dans A Comparison of Approaches to Advertising Measurement (Marketing Science, 2019), que les méthodes de mesure non expérimentales peinent à retrouver l'effet causal réel d'une campagne dès que le signal d'entrée est incomplet ou biaisé. Un flux de conversions plus complet et plus fiable — ce que la CAPI apporte face à un Pixel seul — ne corrige pas tout, mais réduit directement la part du signal manquant sur laquelle ces biais de mesure s'appuient.

Comment fonctionne la Conversions API

Concrètement, la CAPI est un endpoint HTTP : un POST vers https://graph.facebook.com/v26.0/{pixel-id}/events (vérifiez la version en vigueur dans la documentation Meta au moment de l'implémentation — les versions de l'API Graph sont dépréciées régulièrement), avec un jeton d'accès système en paramètre. Le corps de la requête contient un tableau data[] où chaque évènement précise :

• event_name — Purchase, Lead, CompleteRegistration, ou un nom personnalisé ;
• event_time — timestamp Unix de l'action réelle, pas de l'envoi à l'API ;
• event_id — identifiant unique partagé avec le Pixel pour le dédoublonnage (voir plus bas) ;
• action_source — website dans la grande majorité des cas d'usage e-commerce ;
• user_data — les identifiants de la personne, hashés (voir Étape 2) ;
• custom_data — value, currency, content_ids, selon l'évènement.

Le dédoublonnage par event_id

Si le Pixel capture déjà une partie des conversions côté navigateur, envoyer la même conversion une seconde fois via la CAPI la ferait compter deux fois — sauf à partager un event_id identique entre les deux envois. Meta rapproche alors les deux évènements et n'en garde qu'un pour les statistiques et l'optimisation des campagnes. Dans un workflow n8n, le plus simple est de générer cet identifiant une fois (un UUID, via le node Crypto en opération Generate — détaillé dans notre guide du node Crypto) et de le transmettre au script du Pixel côté front en même temps qu'à l'appel serveur.

Construire le workflow dans n8n

Étape 1 — Déclencher sur l'évènement de conversion réel

Le workflow démarre sur l'évènement métier qui constitue la conversion : un webhook de commande validée (Shopify, WooCommerce — voir notre guide de connexion Shopify et notre article sur l'automatisation des commandes e-commerce), ou un webhook de paiement confirmé côté Stripe comme décrit dans notre article sur les webhooks Stripe et relances de paiement. L'essentiel est de déclencher l'envoi sur la confirmation réelle de l'action (paiement capturé, pas simple création de commande), pour ne pas polluer les statistiques publicitaires avec des conversions jamais finalisées.

Étape 2 — Normaliser et hasher les données utilisateur

Le bloc user_data accepte l'email (em) et le téléphone (ph) du client, mais uniquement sous forme hashée en SHA-256, après normalisation : email en minuscules et sans espaces, téléphone au format E.164 sans le signe +. Un node Code placé juste après le déclencheur prépare ces champs :

const crypto = require('crypto');

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

const email = hash($json.customer_email);
const phone = hash($json.customer_phone.replace(/[^0-9]/g, ''));

return [{ json: { ...$json, em: email, ph: phone } }];

Le node Crypto en opération Hash (SHA256, sortie HEX) fait exactement le même calcul sans code, si vous préférez rester sur des nodes standards — les deux approches sont équivalentes et le choix dépend surtout du nombre de champs à traiter en une passe. À l'inverse, l'adresse IP du client, le user-agent et les cookies fbc/fbp (identifiants de clic et de navigateur Meta, capturés côté front) doivent voyager en clair : les hasher les rendrait inutilisables pour le rapprochement d'identité que Meta effectue de son côté.

Étape 3 — Construire le payload et appeler l'API

Un node Set assemble le JSON final au format attendu par la CAPI, puis un node HTTP Request (ou le node Facebook Graph API natif de n8n, qui gère nativement le credential et la version d'API) envoie la requête :

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1754812800,
    "event_id": "{{ $json.event_id }}",
    "action_source": "website",
    "event_source_url": "{{ $json.checkout_url }}",
    "user_data": {
      "em": ["{{ $json.em }}"],
      "ph": ["{{ $json.ph }}"],
      "client_ip_address": "{{ $json.client_ip }}",
      "client_user_agent": "{{ $json.user_agent }}",
      "fbc": "{{ $json.fbc }}",
      "fbp": "{{ $json.fbp }}"
    },
    "custom_data": {
      "currency": "EUR",
      "value": "{{ $json.order_total }}",
      "content_ids": {{ $json.product_ids }}
    }
  }]
}

Le jeton d'accès système se stocke comme un credential n8n dédié, jamais collé en dur dans le node — la même discipline que celle détaillée dans notre guide sur la sécurisation des credentials et clés API. Comme pour tout appel API externe, un webhook de commande qui repart deux fois pour la même transaction (relivraison réseau, double clic) doit être filtré en amont : le principe est identique à celui de l'idempotence des webhooks, appliqué ici à l'envoi vers Meta plutôt qu'au traitement métier.

Étape 4 — Vérifier avec l'outil Test Events

Avant de publier le workflow, ajoutez temporairement un champ test_event_code au payload — visible dans l'onglet Test Events du gestionnaire d'évènements Meta, propre à votre compte publicitaire. L'évènement apparaît alors en quelques secondes dans l'interface Meta, avec le détail des champs reçus et des éventuels avertissements (email mal formaté, event_id manquant). Une fois la validation faite, retirez ce champ : sa présence en production ferait sortir l'évènement des statistiques réelles.

Bonnes pratiques et pièges fréquents

• Ne jamais hasher l'IP, le user-agent, fbc ou fbp — ces champs doivent rester en clair, à l'inverse des identifiants personnels.
• Générer l'event_id une seule fois par conversion et le transmettre identique au Pixel front et à l'appel serveur, sous peine de compter chaque conversion deux fois dans les rapports Meta.
• Déclencher sur la confirmation réelle, pas sur la création d'une commande qui pourrait encore être annulée ou impayée.
• Séparer clairement environnement de test et production : un test_event_code oublié en production fait disparaître silencieusement des conversions réelles des statistiques.
• Le même schéma général — envoi côté serveur, identifiants hashés, dédoublonnage par identifiant partagé — s'applique presque à l'identique aux Enhanced Conversions de Google Ads et à l'Events API de TikTok : une fois le premier pipeline construit dans n8n, les suivants réutilisent la même structure de nodes avec un endpoint et un format de payload différents.

En résumé

Construire un pipeline de Conversions API dans n8n tient en quatre briques : un déclencheur sur la conversion réelle (webhook de commande ou de paiement confirmé), une normalisation et un hashage SHA-256 des identifiants personnels, un appel HTTP structuré vers l'API Graph avec un event_id partagé avec le Pixel, et une vérification via l'outil Test Events avant mise en production. Rien de tout cela ne demande de service tiers payant : un node Webhook, un node Crypto ou Code, et un node HTTP Request suffisent. Si votre instance n8n gère déjà vos commandes e-commerce ou vos webhooks de paiement, ajouter cet envoi CAPI ne prend qu'un nœud de plus dans un workflow existant plutôt qu'une nouvelle intégration à partir de zéro.