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. (opens in a new tab) 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 Tag Health : requêtes en succès

Cliquez sur l'onglet Tag Health depuis votre Container Addingwell. Commencez par vérifier le nombre de requêtes effectuées pour Meta Conversions API sur une période donnée, ainsi que le pourcentage de succès de ces requêtes. Cliquez sur Meta Conversion API pour obtenir plus de détails.

Vérifier les requêtes Meta Conversion API sur le Container Adddingwell

Cet écran vous fournit les détails des événements envoyés par votre serveur à Meta Conversion API, ainsi que le pourcentage de succès des requêtes, qui est de 100 % dans notre exemple.

Pourcentage de succès dans les requêtes Meta Conversions API sur le Container Adddingwell

Si vos requêtes ne sont pas à 100% de succès, vous pouvez approfondir en récupérant les logs de ces requêtes erreurs. Cliquez sur l'onglet Logs et cliquez ensuite sur les Logs de l'API Meta.

Détail des logs sur les requêtes Meta Conversions API via le Container Adddingwell

Par exemple, dans les logs d'erreurs de notre compte, l'erreur la plus fréquente (118 occurrences) est liée à un prix de produit qui n'est pas un nombre. Il est nécessaire de modifier cette quantité envoyée par le site depuis le datalayer pour éviter cette erreur. De votre côté, vous pouvez vérifier vos 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 Adddingwell

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

Envoyer vos événements de conversion à la plateforme Meta est une première étape importante, mais vous pouvez améliorer ce processus en ajoutant des données utilisateur (comme un email, un numéro de téléphone, ou des noms et prénoms) à ces événements. Ces données permettent à Meta de faire correspondre les informations envoyées depuis votre serveur à un utilisateur réel dans leur base de données.

Cela permet à Meta de :

Mieux attribuer les conversions reçues, en identifiant des conversions qui autrement n'auraient pas été attribuées aux campagnes Facebook/Instagram.
Optimiser davantage vos enchères de campagnes, grâce à des données plus qualitatives. Pour suivre notre méthodologie pour un envoi fiable de données utilisateur en server-side, consultez notre documentation sur le sujet

Côté Addingwell via Data Monitoring

Cliquez sur le menu Data monitoring depuis votre Container Addingwell. Cet écran affiche toutes les données utilisateur traitées par votre client GA4 et mises à disposition de vos événements côté serveur. Par exemple, vous pouvez voir que les données d'email sont présentes dans 23,4 % des événements réceptionnés côté serveur. Pour vérifier la liste des événements où les données d'email utilisateur sont bien transmises, cliquez sur l'icône de recherche pour obtenir plus de détails.

Vérifier la qualité des données reçues Data monitoring Addingwell

Sur cet écran, vous pouvez voir le pourcentage de présence des données utilisateur email dans vos événements côté serveur.

Vérifier la qualité des données utilisateurs dans Addingwell

Dans notre exemple, les données d'email utilisateur sont présentes dans 100 % des événements purchase, mais seulement dans 38,3 % des événements add_to_cart. Cela est cohérent avec notre entonnoir d'achat, car l'email n'est pas disponible pour tous les utilisateurs à l'étape d'ajout au panier.

Les données envoyées sont ici de qualité, car les événements contiennent bien les données utilisateur souhaitées et disponibles.

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 ?