Meta Event Match Quality : comment améliorer votre score

L’Event Match Quality (EMQ) est un score sur 10 que Meta attribue à chaque événement de site web que vous envoyez via la Conversions API. Il indique dans quelle mesure les informations client de cet événement permettent de le rapprocher d’un compte Meta. Vous l’améliorez en envoyant davantage d’identifiants pertinents, formatés et hachés comme Meta l’attend.

Ce guide explique ce que mesure le score, quels paramètres d’informations client comptent le plus, les règles de hachage et de normalisation, pourquoi les achats issus des données de commande portent plus d’identifiants que les pages vues, quel score viser et où le vérifier.

Que mesure l’Event Match Quality ?

Meta calcule le score à partir de deux éléments : la qualité des informations client que vous envoyez avec un événement serveur, et la part de ces événements que Meta rapproche d’un compte. Un événement rapproché indique à Meta quelle personne a acheté. Meta peut alors attribuer l’achat à la publicité que cette personne a vue ou sur laquelle elle a cliqué, et montrer vos publicités à des personnes plus susceptibles d’acheter.

Quelques faits tirés de la documentation de Meta orientent la lecture du score :

• Il est calculé par événement. Purchase, AddToCart et PageView ont chacun leur propre score, pour les événements standard comme personnalisés.
• Il ne couvre que les événements serveur. Le score est disponible pour les événements de site web envoyés via la Conversions API avec action_source défini sur website. Les événements envoyés uniquement par le pixel navigateur n’ont pas de score.
• Il utilise les 48 dernières heures. Envoyez les événements régulièrement, sinon le score devient obsolète.

Meta note aussi qu’une meilleure correspondance peut augmenter les conversions supplémentaires qu’il déclare pour votre configuration Conversions API. Un achat que Meta ne peut pas rapprocher est un achat dont vos publicités ne reçoivent pas le crédit.

Quels paramètres d’informations client améliorent le score ?

Meta publie une priorité pour chaque type d’information client. Envoyez chaque paramètre dont vous disposez pour un événement, en commençant par ceux de haute priorité.

L’adresse IP et le user agent ne figurent pas dans la liste de priorités de Meta, mais la documentation développeur de Meta indique qu’envoyer client_ip_address et client_user_agent peut aider à la correspondance. Le user agent est de toute façon obligatoire pour les événements de site web. Les deux doivent être ceux de l’acheteur, pas ceux de votre serveur.

Comment hacher et normaliser les données client ?

Meta exige que les informations de contact soient hachées avec SHA-256 avant l’envoi. Le hachage ne fonctionne que si chaque système écrit la même valeur de la même façon : Meta définit donc une forme normale pour chaque champ. Normalisez d’abord, hachez ensuite.

Dans le code, c’est l’ordre des étapes qui compte :

import { createHash } from 'node:crypto';
const sha256 = (s) => createHash('sha256').update(s).digest('hex');

// Normalize first, then hash.
const em = sha256(' Anna.Berg@Example.com '.trim().toLowerCase());
// hashes "anna.berg@example.com"

const ph = sha256('+1 (415) 555-0134'.replace(/\D/g, ''));
// hashes "14155550134"

const ct = sha256('San Francisco'.toLowerCase().replace(/[^a-z]/g, ''));
// hashes "sanfrancisco"

// Sent as they are, never hashed:
// fbp, fbc, client_ip_address, client_user_agent

Attention aux numéros de téléphone avec un zéro de préfixe national. Un numéro néerlandais écrit +31 (0)6 1234 5678 devient 310612345678 si vous retirez seulement les symboles. La forme correcte est 31612345678. Les valeurs de remplissage sont un autre piège : une adresse e-mail comme noemail@example.com qu’une boutique renseigne pour les commandes d’invités est partagée par de nombreux clients, et ne peut donc pas identifier une personne. N’envoyez plutôt pas ce champ.

Pourquoi les événements serveur issus des données de commande portent-ils plus d’identifiants ?

Une vue de page a lieu avant que le visiteur ne vous ait rien dit. Le navigateur connaît un identifiant de cookie, peut-être un identifiant de clic, une adresse IP et un user agent. Une commande payée est différente : l’acheteur a saisi une adresse e-mail, souvent un numéro de téléphone, un nom et une adresse.

C’est pourquoi un événement Purchase envoyé depuis votre serveur peut obtenir un meilleur score que PageView ou ViewContent. Un événement d’achat qui vient seulement de la page de remerciement porte les identifiants du navigateur, mais pas toujours l’e-mail et le téléphone de la commande.

Tous les paramètres ne peuvent pas atteindre 100% des événements, et c’est normal. Dans l’exemple ci-dessous, l’identifiant de clic figure sur 38% des achats, car seuls les acheteurs arrivés par un clic sur une publicité Meta en ont un.

Quel objectif d’Event Match Quality est réaliste ?

La documentation développeur de Meta indique qu’elle recommande généralement un score de 6.0 ou plus, si possible. Prenez-le comme objectif pour les événements qui portent des données de contact, surtout Purchase. Un Purchase construit à partir des données de la commande porte l’e-mail, l’un des deux paramètres à priorité élevée, et la plupart de ceux à priorité moyenne : c’est donc l’événement pour lequel cet objectif est le plus réaliste. Mesurez-le plutôt que de le supposer : le score dépend aussi de vos clients.

N’attendez pas le même score pour chaque événement. PageView, ViewContent et AddToCart n’ont souvent aucune donnée de contact, car la plupart des visiteurs sont anonymes jusqu’au checkout. Un score plus bas pour eux est normal, et ce n’est pas une raison de collecter les adresses e-mail plus tôt que vos visiteurs ne veulent les donner.

Ne courez pas non plus après un 10. Le score dépend aussi de la part d’événements que Meta parvient à associer, et une partie échappe à votre contrôle : certains de vos acheteurs n’ont pas de compte Meta, ou y ont utilisé une autre adresse e-mail. Le consentement compte aussi. Dans ROASaurus, quand Respect visitor consent est activé, un visiteur qui refuse les cookies marketing n’a ni identifiant de clic ni identifiant visiteur stocké : la commande payée part donc avec les données de commande hachées ainsi que l’adresse IP et le user agent de la commande, mais sans fbc ni fbp. Plus il y a de refus, moins il y a d’identifiants par événement. Notre page d’aide sur le consentement explique ce réglage.

La bonne question n’est pas de savoir si votre score est élevé, mais s’il a changé. Comparez chaque événement avec son propre historique après chaque modification de votre thème, de votre checkout ou de votre suivi.

Comment vérifier l’Event Match Quality dans Events Manager ?

1. Ouvrez votre jeu de données

   Allez dans Events Manager et sélectionnez le nom et l’identifiant de votre pixel ou de votre jeu de données.

2. Ouvrez les détails de l’événement

   Trouvez l’événement, par exemple Purchase, et cliquez sur View details.

3. Lisez l’onglet Event matching

   Il affiche le score, la part des événements qui portent des informations client, et des conseils pour améliorer la correspondance.

4. Consultez Diagnostics

   L’onglet Diagnostics d’Events Manager liste les problèmes de vos événements et des recommandations pour les corriger.

5. Vérifiez à nouveau après deux jours

   Le score utilise les 48 dernières heures d’événements : une correction n’apparaît donc pleinement qu’environ deux jours plus tard.

Les autres onglets de la même page sont utiles aussi. Event coverage compare vos événements serveur à vos événements pixel, Event deduplication indique la part des événements qui portent une clé de déduplication comme l’identifiant d’événement, et Data freshness montre à quelle vitesse vos événements serveur arrivent. Si vous êtes encore en train de configurer la partie serveur, commencez par notre guide de la Meta Conversions API.

Pourquoi mon Event Match Quality est-il bas ?

Quand un événement obtient un score plus bas que prévu, voici les causes habituelles :

• Le serveur envoie sa propre adresse IP. Si les événements passent par votre serveur ou un serveur de balises, celui-ci doit transmettre l’adresse IP et le user agent qu’il a enregistrés auprès de l’acheteur, pas les siens.
• Le fbclid est perdu. L’identifiant de clic ne figure que dans l’URL de la page d’arrivée. Si rien ne l’enregistre à ce moment-là, il a disparu au moment du checkout. Conservez-le exactement tel qu’il arrive, car il est sensible à la casse.
• Les données de contact sont hachées sans normalisation, ou envoyées non hachées.
• Les identifiants du navigateur sont hachés. Un fbp ou un fbc haché ne peut pas être associé.
• Les achats viennent uniquement du navigateur. Un événement de la page de remerciement n’a souvent pas l’e-mail ni le téléphone que contient la commande. Envoyer l’achat depuis la commande règle ce problème.

Comment ROASaurus envoie les informations client

ROASaurus construit l’événement Purchase à partir de la commande dans votre boutique, il porte donc les données de contact de la commande. L’e-mail, le téléphone, le prénom et le nom, la ville, la région, le code postal et le pays sont normalisés et hachés avec SHA-256. L’identifiant client de la boutique et l’identifiant visiteur ROASaurus sont envoyés hachés comme external_id. L’adresse IP, le user agent, l’URL de la page et fbp sont rattachés depuis la visite de l’acheteur, et fbc est construit à partir du fbclid que le script de votre boutique enregistre quand le visiteur arrive.

Un événement sans fbc, fbp, e-mail, téléphone ni adresse IP est ignoré, car Meta ne peut pas l’associer. La page de l’intégration Meta liste chaque champ envoyé, et le suivi côté serveur explique comment les commandes sont associées au clic publicitaire. Pour suivre le score, la page Tracking health lit chaque jour l’Event Match Quality de chaque pixel Meta et déclenche une alerte quand le score de Purchase passe sous votre minimum, 6,0 par défaut.

Sources

1. Meta Business Help Center: About Event Match Quality
2. Meta for Developers: Customer Information Parameters
3. Meta for Developers: Verifying Your Setup
4. Meta Business Help Center: View server event details in Meta Events Manager
5. Meta for Developers: Best Practices - Conversions API

Dans ROASaurus

• Intégration Meta
• Suivi côté serveur
• Aide : connecter Meta

À lire aussi