Vérifier les données reçues

Une fois votre balise Meta CAPI configurée, il est crucial de s’assurer :

que votre conteneur serveur transmet correctement les événements à META, depuis le pixel et depuis CAPI.
que le volume des événements reçus par Facebook est cohérent et que la déduplication est effective (Un même évènement reçu depuis le pixel et depuis CAPI ne doit être conservé qu’une seule fois)
de la qualité des données reçues, pour s’assurer que Facebook peut faire correspondre vos évènements les plus cruciaux à un utilisateur META. Pour que Facebook puisse faire cette correspondance avec ses utilisateurs, il faut vous assurer d’envoyer des user-data avec vos évènements.

Vérifier l’envoi des événements

Prévisualisation GTM Server-Side

La première étape consiste à s’assurer que la balise Meta CAPI se déclenche correctement pour les événements spécifiés dans le déclencheur.

Dans la prévisualisation du conteneur serveur, assurez-vous que votre balise Meta CAPI se déclenche pour un événement spécifique (par exemple, dans notre cas, nous vérifions le déclenchement sur l’événement view_item). Confirmez qu’elle apparaît bien dans la section Tags fired et que le statut de la balise est Succeeded.

Vérifier le déclenchement de la balise Meta CAPI en serveur-side

Dans la prévisualisation, cliquez sur la balise Meta CAPI pour vérifier que des requêtes ont bien été envoyées à Meta via l’API de conversion et le pixel.

Notez qu’une requête vers le pixel n’apparaîtra ici que si l’option Send pixel request a été cochée lors de la configuration de la balise

Vérifier l'envoi des données via Meta CAPI et le pixel Facebook côté serveur

Vérifier le volume d’événements reçus

Côté Meta : volume d’événements reçus

Accédez à votre gestionnaire d’évènemenents Facebook. Puis cliquez sur l’onglet Overview. Les événements reçus par Meta apparaissent ici, pour les sources de données Pixel+CAPI.

Côté Meta : volume pixel, volume CAPI et déduplication

Puisque vous avez implémenté le double suivi de vos évènements via le pixel et via Meta CAPI, il faut dorénavant vous assurer que les évènements:

proviennent bien des deux sources de données, à la fois depuis le pixel ET depuis Meta CAPI.
sont bien dédupliqués. Il faut vous assurer que Facebook est capable de reconnaitre un même évènement reçu par le pixel et par CAPI, et qu’un seul de ces évènements sera conservé. C’est ce qu’on appelle la déduplication.

Cliquez sur un évènement donné depuis l’onglet Overview. Dans notre exemple, nous allons vérifier que notre implémentation est fonctionnelle sur l’évènement Purchase:

Ici nous voyons bien que les deux sources de données sont actives, et que Meta reçoit correctement des évènements Purchase à la fois depuis le pixel (183 évènements depuis le Browser) et depuis Meta CAPI (230 évènements depuis le Server).

Le nombre d’événements reçus depuis le Pixel (=navigateur) devrait rester relativement stable : l’ajout de la source de tracking Meta CAPI ne devrait pas impacter le volume de données reçu via le navigateur. Vous devriez donc constater un nombre d’évènements plus ou moins similaire pour cette source de donnée pixel.

En revanche, le nombre d’évènements reçus depuis le serveur (Meta CAPI) doit être supérieur au nombre d’évènements du pixel. Si vous constatez entre 5 à 20% d’évènements supplémentaires pour CAPI, votre set-up est bon. Si le volume de données reçus via le serveur est au delà, votre set-up est à vérifier.

Si vous constatez un volume plus élevé d’évènement provenant du Pixel que de CAPI, cela signifie qu’il vous reste une autre implémentation du Pixel sur le site, et que vous recevez les évènements du Pixel en doublon. Il faut alors bien vérifier d’ou provient ce deuxième Pixel. Vous avez peut-être oublié de le désactiver depuis votre conteneur GTM WEB par exemple, ou peut-être que le pixel existe encore via une implémentation en dur dans le code du site (à vérifier avec votre équipe de développeurs)

Il faut maintenant nous assurer que ces évènements envoyés à Facebook sont bien dédupliqués, en cliquant sur le bouton View Details, puis en cliquant sur l’onglet Event Deduplication :

Vérifier la déduplication des évènements dans le gestionnaire de publicités Facebook

Nous voyons ici que la déduplication est bien effective, aucun souci n’est detecté. Les Event ID sont bien envoyés à 100% depuis le Pixel et à 100% depuis la Conversion API, ce qui permet une déduplication parfaite.

Enfin l’information Overlap nous donne le pourcentage d’évènements contenant une clé de déduplication, et qui reçus à la fois depuis l’API de conversion et depuis le pixel . Dans notre exemple, cela signifie que :

76,56% des évènements reçus ont été envoyés conjointement par les deux sources de données, avec un même Event ID. Tous ces évènements sont donc dédupliqués.
79,07% des évènements reçus ont été envoyés conjointement par les deux sources de données, avec un même FBP (ID de Navigateur Facebook, envoyé automatiquement quand il est présent). Tous ces évènements sont donc dédupliqués.

Côté Addingwell via Events Monitoring : événements envoyés avec succès

Cliquez sur l’onglet Events Monitoring depuis votre container Addingwell. Sélectionnez la période de temps souhaitée, puis cliquez sur la carte du tag Meta CAPI.

Vérifier les requêtes Meta Conversion API sur le container Addingwell via Events Monitoring

Cet écran vous fournit les détails des événements envoyés par votre serveur à la Meta Conversion API, ainsi que le pourcentage de réussite de chaque événement (100 % de succès pour tous les événements dans cet exemple).

Si vos requêtes n’affichent pas un taux de succès de 100 %, vous pouvez analyser plus en détail les erreurs en consultant les logs. Cliquez sur l’onglet Logs, puis sélectionnez les logs de l’API Meta.

Détail des logs sur les requêtes Meta Conversions API via le container Addingwell

Par exemple, dans les logs d’erreurs de notre compte, l’erreur la plus fréquente (118 occurrences) concerne un prix de produit qui n’est pas un nombre. Il est alors nécessaire de corriger cette valeur envoyée depuis le dataLayer du site. De votre côté, consultez vos propres logs pour identifier et corriger les erreurs reçues.

Vérification des logs sur les requêtes en erreur pour Meta Conversions API via le container Addingwell

Vérifier la qualité des données reçues

Envoyer vos événements de conversion à la plateforme Meta est une première étape importante. Vous pouvez aller plus loin en ajoutant des données utilisateur (comme l’email, le numéro de téléphone, ou les nom et prénom) à ces événements. Ces données permettent à Meta d’associer les événements reçus à un utilisateur réel dans leur base de données.

Cela permet à Meta de :

Mieux attribuer les conversions reçues, en identifiant celles qui n’auraient autrement pas été rattachées à vos campagnes Facebook/Instagram.
Optimiser les performances de vos campagnes, grâce à des signaux utilisateurs de meilleure qualité.

Pour suivre notre méthodologie sur l’envoi fiable des données utilisateur côté serveur, consultez notre documentation dédiée.

Côté Addingwell via Events Monitoring

Cliquez sur le menu Events Monitoring depuis votre container Addingwell. Cet écran affiche toutes les données utilisateur traitées par votre client GA4 et mises à disposition pour vos événements côté serveur.

Prenons l’exemple de l’événement purchase : en cliquant sur le nom de l’événement, vous pouvez vérifier les paramètres disponibles pour cet événement spécifique.

Vérification des paramètres attachés à un événement purchase en server-side

Sur cet écran, vous pouvez voir le pourcentage de présence des données utilisateur, comme l’email, dans vos événements purchase, ainsi que le taux de couverture de chaque paramètre.

Vérification des données utilisateur attachées à un événement Meta en server-side

Dans notre exemple, les données email sont présentes dans 100 % des événements purchase.

Les données envoyées sont donc de qualité, car les événements contiennent bien les informations utilisateur attendues et disponibles à cette étape du parcours client.

Côté Meta : vérifier le Match Quality (= Qualité de correspondance)

Meta propose plus de détails sur la qualité des données reçues dans l’onglet Match Quality. Meta attribue ici un score sur 10 pour chaque évènement, cette note indique si les paramètres user-data sont bien présents sur cet évènement. Plus les données user-data envoyées dans un événement sont nombreuses, plus le score Match quality sera élevé.

Si vous envoyez des données utilisateurs complètes sur un événement Purchase, votre score sera élevé. Sur un événement PageView (qui contient peu ou pas de données utilisateurs), votre score sera plus bas.

L’idée ici n’est pas d’obtenir un score de 10/10 sur chaque évènement mais de voir pour chacun d’entre eux s’il y a des données utilisateurs supplémentaires que vous pourriez envoyer dans vos paramètres pour améliorer la qualité de correspondance.

Nous allons maintenant pouvoir vérifier sur un évènement de type Pageview si nous pouvons améliorer le Match Quality en vérifiant les paramètres partagés sur cet évènement.

Les paramètres partagés (ou shared parameters)

Paramètres partagés dans le gestionnaire d'événements de Meta

Voici l’interprétation de la capture précédente pour chaque paramètre :

Nom du paramètre	Interprétation
1. Adresse e-mail	L’adresse email est présente dans 29,05% des événements `PageView`. Sur le site de notre exemple, l’adresse email n’est accessible que lorsque l’utilisateur est connecté, pour être ensuite transmis dans les `user_data`. Tout semble donc normal.
2. Adresse IP	L’adresse IP est une donnée technique présente dans les requêtes HTTP.
3. Agent utilisateur	Envoyé automatiquement.
4. Numéro de téléphone	Transféré dans les `user_data` lorsqu’un utilisateur est connecté. Tout est normal.
5. ID navigateur (fbp)	Envoyé automatiquement lorsque le cookie `_fbp` est présent.
6. Genre	L’information sur le genre de l’utilisateur est présent dans 25,28% des événements `PageView`. Sur le site de notre exemple, cette information n’est disponible que lorsque l’utilisateur est connecté, ce qui semble normal.
7. Code postal	Transféré dans les `user_data` lorsqu’un utilisateur est connecté. Tout est normal.
8. Date de naissance	Transféré dans les `user_data` lorsqu’un utilisateur est connecté. Tout est normal.
9. Pays	Transféré dans les `user_data` lorsqu’un utilisateur est connecté. Tout est normal.
10. Prénom	Transféré dans les `user_data` lorsqu’un utilisateur est connecté. Tout est normal.
11. Nom de famille	Transféré dans les `user_data` lorsqu’un utilisateur est connecté. Tout est normal.
12. Ville	Transféré dans les `user_data` lorsqu’un utilisateur est connecté. Tout est normal.
13. ID du clic (fbc)	Envoyé lorsque l’utilisateur vient d’une publicité donc lorsque le cookie `_fbc` est présent. C’est pour cette raison que la couverture est très basse.

Félicitations

Vous avez terminé la configuration de Meta CAPI, et vous avez vérifié que vos données sont bien transmises à Meta et que les données sont bien qualititatives.

Si vous avez rencontré le moindre problème durant ces étapes, n’hésitez pas à contacter notre équipe support.

Cette page vous a-t-elle été utile ?