Passer au contenu principal

Meta Ads

Meta Pixel + Conversions API (CAPI) pour améliorer l'Attribution

En résumé

  • Dédupliquez avec un event_id identique côté navigateur (Pixel) et côté serveur (CAPI) — idéalement l’order_id.
  • Envoyez value + currency sur tous les événements avec une valeur économique (optimisation à la valeur).
  • Visez un EMQ ≥ 7 en multipliant les identifiants (email, téléphone, external_id, etc.).
    • Un EMQ (Event Match Quality) est un score de qualité de 0 à 10 que Meta attribue à vos événements (Pixel/CAPI). C’est un indicateur de diagnostic, pas un KPI de performance en soi. Vous le voyez par type d’événement dans Events Manager.
  • Passez fbp et fbc du client vers le serveur.
  • Standardisez avec (SS)GTM : générez l’event_id une seule fois (dataLayer), réutilisez-le côté Pixel et CAPI, et vérifiez la mention “Deduplicated” dans Events Manager.

Pourquoi c’est critique pour la mesure et l’optimisation

Sans déduplication robuste, les conversions sont double-comptées. La conséquence ? ROAS et CPA biaisés, signaux d’apprentissage dégradés, algorithmes moins performants (Value Optimization).

Un EMQ élevé améliore l’appariement utilisateur, accélère la phase d’apprentissage, et augmente la couverture de retargeting et de modélisation.

Les 6 fondamentaux d’un setup Pixel + CAPI fiable

1. Déduplication Pixel/CAPI : même event_id (obligatoire)

  • Requis : l’exact même event_id entre l’event envoyé par le navigateur (Pixel) et l’event serveur (CAPI).
  • Recommandé : utilisez un identifiant stable par conversion (ex. order_id) et ne le transformez pas différemment entre client et serveur.
  • À contrôler : dans Events Manager, les paires Browser/Server doivent apparaître comme “Deduplicated” (et non “Received ×2”).

2. Valeur & devise : indispensables pour la Value Optimization

  • Pour chaque événement à valeur (ex. Purchase), envoyez :
    • value : montant exact issu du système de commande,
    • currency : ISO 4217 (ex. EUR).
  • Sans ces paramètres, l’optimisation à la valeur se dégrade (signaux incohérents).

3. EMQ (Event Match Quality) : ciblez 7–10

  • L’EMQ mesure la capacité d’appariement d’un événement à un utilisateur en fonction des identifiants fournis.
  • Plus le score est haut, mieux l’apprentissage fonctionne. Suivez l’EMQ par type d’événement et itérez sur les identifiants manquants.

4. Advanced Matching : multipliez les identifiants

  • Activez Advanced Matching côté Pixel et répliquez les mêmes champs côté serveur (hachés) : email, téléphone, prénom/nom, external_id.
  • Consistance des formats (normalisation, trimming) = meilleur EMQ.

5. fbp et fbc : ne les oubliez pas

  • fbp = ID navigateur (cookie).
  • fbc = ID de clic (click-id) lorsqu’un utilisateur arrive via une publicité Meta.
  • Récupérez-les côté client et relayez-les côté serveur : ils améliorent l’appariement et aident la déduplication selon les intégrations.

6. Bonnes pratiques GTM / Server-Side GTM

  • Générez l’event_id une seule fois (au moment de la conversion), stockez-le en dataLayer, réutilisez-le dans le tag Pixel et dans la requête CAPI.
  • Nom des événements : alignez event_name entre Pixel et CAPI (ex. Purchase).
  • Monitoring : vérifiez dans Events Manager → statut Browser/Server, déduplication, EMQ, paramètres manquants.

Implémentation (pas à pas)

A. Data layer (client)

  1. Au déclenchement de la conversion (ex. page de confirmation), créez un event_id unique (order_id).
  2. Push event_id, value, currency, identifiants utilisateur disponibles (si consentis) dans le dataLayer.
  3. Exposez fbp/fbc (lecture cookies/URL) pour réutilisation serveur.

B. Pixel (navigateur)

  1. Dans le tag Meta Pixel (GTM), mappez event_id, value, currency, et activez Advanced Matching en passant les identifiants normalisés.
  2. Déclencheur : sur l’événement de conversion (ex. confirmation d’achat).
  3. Tests : utilisez un test event code pour valider la remontée en direct.

C. CAPI (serveur)

  1. En Server-Side GTM (ou via votre backend), retrouvez le dataLayer (ou sa version serveur) pour réutiliser le même event_id.
  2. Incluez value, currency, fbp, fbc, les champs d’Advanced Matching (hachés si requis).
  3. Envoyez l’event serveur avec le même event_name et un event_time cohérent.

Checklist production

  1. Générer un event_id unique par conversion → injecter dans dataLayer → réutiliser côté Pixel et CAPI.
  2. Envoyer value (source commande) + currency ISO (ex. EUR) sur chaque Purchase.
  3. Activer Advanced Matching (email / phone / external_id) côté Pixel et refléter côté CAPI.
  4. Capturer & relayer fbp et fbc du navigateur vers le serveur.
  5. Auditer l’EMQ par event dans Events Manager → viser ≥ 7 et compléter les champs manquants.

Contrôles dans Events Manager

  • Deduplication status : “Deduplicated” attendu pour les paires Browser/Server.
  • Paramètres : alerte si value/currency absents sur Purchase.
  • EMQ : surveillez la moyenne et la distribution par événement ; ciblez 7–10.
  • Appariement : validez la présence de fbp/fbc et des champs d’Advanced Matching.

Erreurs fréquentes & correctifs

  • event_id différent entre Pixel et CAPI → centralisez sa génération et chaînez le même identifiant des deux côtés.
  • value/currency manquants → mappez-les depuis la commande (source de vérité), normalisez les formats.
  • event_name non aligné (ex. Purchase vs purchase) → uniformisez la casse et la nomenclature.
  • Identifiants utilisateur inconsistants (espaces, majuscules, encodage) → normalisez avant hachage.
  • Oubli de fbp/fbc → lisez cookies/URL en client, passez-les au serveur.

FAQ

Comment choisir l’event_id ?
Un identifiant stable et unique par conversion (souvent order_id). Évitez les formats différents entre client et serveur.

Puis-je dédupliquer sans event_id ?
Non. Meta nécessite le même event_id pour associer les événements Browser/Server et éviter le double comptage.

L’EMQ est bas (< 7) : par où commencer ?
Normalisez et enrichissez les champs d’Advanced Matching (email, phone, external_id), ajoutez fbp/fbc, corrigez les formats.

value/currency sont-ils obligatoires ?
Pour la Value Optimization, oui. Sans eux, l’algorithme apprend sur des signaux incomplets.

GTM vs Server-Side GTM ?
GTM facilite le client. SS-GTM ajoute robustesse et contrôle serveur (latence, sécurité, gouvernance des données). L’idéal : les deux, avec un event_id centralisé.