Configuration serveur de Meta CAPI : déduplication et Event Match Quality

La configuration de l’API Conversions Meta (CAPI) via GTM server-side nécessite deux configurations distinctes pour fonctionner correctement : la déduplication des événements (pour éviter le double comptage quand le Pixel navigateur et CAPI server-side sont tous deux actifs) et le mapping des données utilisateur (pour l’attribution via les scores Event Match Quality). GA4 dispose d’un Client préinstallé et fonctionne avec une configuration minimale ; ce n’est pas le cas de Meta CAPI.

Ce dont vous avez besoin avant de commencer

• Un identifiant de Pixel Meta depuis votre Business Manager
• Un token d’accès CAPI — utilisez des tokens system user, pas des tokens utilisateur personnels. Les tokens personnels expirent quand quelqu’un quitte le compte Business Manager ; les tokens system user persistent. Un token échu est une défaillance silencieuse qui arrête tous les événements Meta server-side sans aucune erreur visible dans le navigateur.
• Le template communautaire Meta CAPI installé dans votre conteneur serveur depuis la galerie de templates

Déduplication des événements

Meta recommande d’exécuter simultanément le Pixel navigateur et CAPI. Le Pixel navigateur envoie des événements quand JavaScript s’exécute ; CAPI server-side envoie des événements depuis votre serveur. Chaque conversion est enregistrée deux fois — une fois par chaque source de signal — et Meta compterait les deux comme des conversions séparées sans déduplication.

La déduplication requiert que les deux sources envoient un event_id partagé pour la même occurrence d’événement. Meta associe ensuite les événements dans une fenêtre de 48 heures et les déduplique. Quand cela fonctionne correctement, Events Manager affiche « 1 événement de 2 sources » plutôt que deux comptages d’événements séparés.

Voici comment le câbler :

Étape 1 : conteneur web. Installez le template de variable Unique Event ID (disponible dans la galerie de templates communautaires) dans votre conteneur web. Cela génère un UUID pour chaque événement. Ajoutez cet identifiant comme paramètre d’événement dans vos tags GA4 — conventionnellement nommé event_id :

// Dans votre tag GA4, ajoutez un paramètre d'événement personnalisé :
// Nom du paramètre : event_id
// Valeur : {{Unique Event ID}}

Étape 2 : conteneur serveur. Le tag Meta CAPI reçoit les données d’événement GA4 entrantes (qui incluent désormais event_id dans les paramètres d’événement). Configurez le tag pour lire event_id depuis Event Data et le transmettre comme champ event_id à l’API de Meta.

Étape 3 : Pixel navigateur. Assurez-vous que l’appel fbq('track', ...) du Pixel Meta inclut également le même event_id. Si vous déclenchez le Pixel via le conteneur GTM web, utilisez la même variable Unique Event ID. Si le Pixel est codé en dur dans votre HTML, vous aurez besoin d’un mécanisme différent pour passer l’identifiant.

La fenêtre de déduplication de 48 heures de Meta est généreuse, mais l’event_id doit être identique caractère par caractère. Même une différence de casse brise la correspondance.

Score Event Match Quality

Votre score Event Match Quality (EMQ) apparaît dans Meta Events Manager et détermine à quel point Meta peut attribuer vos événements CAPI aux utilisateurs Facebook/Instagram. Des scores plus élevés signifient une meilleure attribution. Visez 6,0 ou plus. Les scores inférieurs à 4,0 indiquent généralement un problème de configuration, pas seulement des données manquantes.

L’EMQ est déterminé par le nombre de signaux d’identité utilisateur que vous envoyez avec chaque événement. Les signaux que Meta utilise, dans l’ordre approximatif d’importance :

Le hachage SHA-256 est géré par le template de tag CAPI — vous fournissez les valeurs brutes et il hache avant d’envoyer. N’envoyez jamais de données personnelles non hachées aux serveurs de Meta.

Vous n’avez pas besoin de tous les signaux pour un bon score EMQ. L’e-mail seul peut vous faire passer dans la plage 6+. L’essentiel est que mapper les champs de données utilisateur auxquels vous avez réellement accès vaut la peine — cela affecte directement le nombre de vos conversions server-side qui sont attribuées aux bonnes campagnes.

Transmission des cookies _fbp et _fbc

Deux cookies spécifiques à Meta sont critiques pour l’attribution et souvent manqués dans les implémentations server-side :

_fbp (Facebook Browser ID) : défini par le Pixel Meta sur votre domaine. Identifie une session navigateur. Quand un utilisateur clique sur une publicité Meta, ce cookie est mis à jour pour inclure les informations de clic.

_fbc (Facebook Click ID) : capture l’identifiant de clic fbclid depuis les liens de publicités Meta. Ce cookie est ce qui permet l’attribution au clic — sans lui, les événements CAPI server-side ne peuvent correspondre que via les données utilisateur, pas via le clic publicitaire spécifique qui a généré la visite.

Dans une configuration GTM server-side, ces cookies sont envoyés depuis le navigateur vers votre conteneur serveur avec chaque requête (car ce sont des cookies first-party sous votre domaine). Mais vous devez explicitement configurer le tag Meta CAPI pour les lire depuis les cookies de la requête entrante et les transmettre à Meta.

Dans votre conteneur serveur, créez deux variables Cookie :

• Nom de variable : fbp, Nom du cookie : _fbp
• Nom de variable : fbc, Nom du cookie : _fbc

Mappez ensuite ces variables vers les champs fbp et fbclid (ou fbc) dans la configuration de votre tag Meta CAPI. Sans ce mapping, les cookies existent dans la requête mais ne sont jamais transmis.

Mise en conformité du consentement

Meta CAPI est un tag non-Google, ce qui signifie qu’il ne lit pas automatiquement les signaux du Consent Mode de Google. Il se déclenche sans condition à moins que vous ne construisiez des vérifications de consentement explicites dans vos conditions de déclenchement.

Pour les utilisateurs de l’EEE ayant refusé le consentement, votre tag Meta CAPI ne doit pas se déclencher. Construisez cela en ajoutant des conditions au déclencheur du tag CAPI qui vérifient l’état de consentement décodé depuis la requête entrante. Cela signifie généralement vérifier que ad_storage et ad_user_data sont tous deux accordés avant que le tag se déclenche.

C’est une exigence de conformité, pas une bonne pratique. Déclencher des événements CAPI pour des utilisateurs ayant refusé leur consentement viole le RGPD et les propres conditions d’utilisation des données de Meta.

Vérification de la configuration

Meta Events Manager affiche les événements entrants en quasi temps réel (typiquement un délai de 1 à 2 minutes). Lors de la vérification de votre implémentation :

1. La déduplication des événements fonctionne — Events Manager affiche « de 2 sources » pour les événements où le Pixel et CAPI se déclenchent tous deux
2. Le score EMQ est visible — apparaît par événement dans Events Manager après quelques jours de données
3. _fbc arrive — pour les sessions provenant de clics publicitaires Meta, le détail de la qualité de correspondance affiche « click ID » comme signal correspondant

La défaillance silencieuse la plus courante est l’expiration du token d’accès. Si les événements CAPI cessent d’apparaître dans Events Manager mais que les événements Pixel continuent, le token est presque certainement le problème. Les tokens system user avec les permissions appropriées n’expirent pas, ce qui est la raison pour laquelle ils sont préférables aux tokens d’accès personnels.