Le catalogue Meta ne reconnaît pas les produits de PrestaShop ? Vérifiez l’ID, les variantes et le Pixel

Si les événements de PrestaShop ne correspondent pas aux produits du catalogue Meta, comparez l’identifiant complet de l’offre avec la valeur envoyée dans content_ids. Le préfixe, le séparateur et le numéro de combinaison comptent. Pour l’intégration, les identifiants 812, ps_812-41 et ps_812_41 désignent des chaînes différentes, même si une personne peut les associer à la même fiche produit.

Ce guide aide à vérifier la coopération entre le flux produit et le Pixel. Les exemples sont démonstratifs, sans données clients. Ils ne constituent ni une capture d’écran d’un compte publicitaire ni une confirmation des résultats de campagne.

Le catalogue, le Pixel et l’API Conversions remplissent des rôles différents

Le catalogue contient les offres : identifiants, noms, photos, prix et disponibilité. Le flux est l’un des moyens de fournir ces données. Le Pixel transmet des événements depuis le navigateur, par exemple la consultation d’un produit ou l’ajout au panier. L’API Conversions permet d’envoyer des événements côté serveur.

Un catalogue correctement récupéré ne prouve pas que les événements font référence aux bonnes offres. De même, la présence d’un événement d’achat ne prouve pas que chaque produit de cet achat a une correspondance dans le catalogue. Déterminez d’abord quelle partie de la connexion vous diagnostiquez.

Vérifiez aussi que vous consultez le bon catalogue et la bonne source d’événements. Avec plusieurs boutiques, un ancien Pixel ou un flux de test, il est possible de comparer des données techniquement correctes provenant de configurations différentes.

Exemple : un produit, deux combinaisons

Prenons un produit avec l’ID 812 et les combinaisons 41 et 42. Le flux exporte les variantes comme des offres distinctes avec le préfixe ps_ et un tiret. Pour la première combinaison, l’identifiant est donc ps_812-41.

Le contrôle le plus simple consiste à copier la valeur de l’offre traitée et celle de l’événement sur deux lignes. Comparez-les caractère par caractère. Ne supprimez pas un préfixe « inutile » avant d’avoir déterminé à quoi se réfèrent les autres intégrations.

Qu’a-t-on vérifié dans les modules PrestaDev ?

Dans le code de Facebook Pixel Pro 1.4.5, il est possible de choisir la manière de construire l’ID et le préfixe optionnel. L’un des chemins crée un ID produit relié à l’ID de combinaison par un tiret, un autre utilise un trait de soulignement. Il existe aussi des modes basés sur d’autres champs. C’est cette configuration qu’il faut comparer à l’export réel, et non la choisir uniquement d’après son nom.

Le code vérifié du flux Meta 2.9.2 enregistre, lors de l’export des combinaisons, g:id sous la forme préfixe + ID produit + tiret + ID combinaison. Avec ce réglage, la variante ps_812_41 envoyée par le Pixel ne sera pas identique à ps_812-41 dans le flux. Dans ce chemin, le flux enregistre le g:item_group_id commun comme ID produit sans préfixe.

Il s’agit d’une confirmation de la manière dont les données sont construites dans les versions de code mentionnées, et non d’une preuve de correspondance sur un compte Meta précis. Après modification des paramètres, il faut toujours vérifier le fichier généré, l’import du catalogue et l’événement réel.

content_ids et content_type doivent être cohérents

content_ids contient les identifiants liés à l’événement. content_type définit la manière de faire référence aux produits ou à leurs groupes. Il ne faut pas remplacer product par product_group uniquement pour faire disparaître un message : cela change la signification des identifiants auxquels l’événement se réfère.

Dans l’exemple présenté, nous choisissons l’offre précise de la variante et content_type: "product". Un jeu de données simplifié pour la consultation d’une variante ressemble à ceci :

{
  "content_ids": ["ps_812-41"],
  "content_type": "product",
  "value": 129.00,
  "currency": "PLN"
}

Il s’agit d’un extrait de données d’un événement d’exemple, et non d’un code d’implémentation complet ni d’une requête API. Les types des champs content_ids, content_type, value et currency peuvent être vérifiés dans le SDK officiel de Meta — CustomData. Pour le diagnostic d’un compte précis, vérifiez également les messages actuels du Gestionnaire d’événements.

Après avoir changé de variante, effectuez un nouveau test

Un ID correct lors de la première ouverture de la page ne suffit pas. Le thème peut changer de variante sans recharger le document. L’intégration des événements doit utiliser les données correspondant à l’action actuelle, au lieu de rester sur la combinaison par défaut.

1. Choisissez un produit avec au moins deux combinaisons présentes dans le flux.
2. Notez leurs identifiants complets à partir du fichier et du catalogue après import.
3. Ouvrez le produit dans une session de test contrôlée, avec les bons paramètres de consentement.
4. Vérifiez les données de l’événement concernant la première variante.
5. Changez de combinaison et ajoutez la variante sélectionnée au panier.
6. Comparez l’ID, la quantité, la valeur et la devise de l’événement avec le panier actuel.
7. Vérifiez que la même action n’est pas également envoyée par une deuxième installation du Pixel, par exemple via un autre module ou un gestionnaire de balises.

N’interprétez pas l’absence d’événement comme une erreur du catalogue avant d’avoir vérifié les consentements, le blocage des scripts et la configuration de la source d’événements. L’envoi de données côté serveur exige également une configuration correcte de la confidentialité ; le CAPI ne doit pas être considéré comme un moyen de contourner la décision de l’utilisateur.

La valeur et la devise constituent un contrôle distinct

Des ID identiques ne confirment pas un montant correct. Pour un événement produit, vérifiez le prix de la combinaison sélectionnée, et pour un achat, la définition convenue de la valeur de la commande entière. Ne comparez pas une unité avec le total du panier ni un montant hors taxes avec un montant TTC sans avoir déterminé comment fonctionne l’implémentation.

La devise doit correspondre à la valeur envoyée. Pour une boutique multidevise, effectuez un test distinct après son changement. Si les données proviennent d’une commande, comparez-les à la commande enregistrée, et non au prix catalogue actuel relevé plus tard.

Correspondance produit et déduplication d’achat

La déduplication reconnaît deux copies du même événement envoyées depuis le navigateur et le serveur. Elle ne sert pas à relier des variantes de produit. Dans le SDK officiel de Meta, il est indiqué que, pour les événements correspondants, le eventID côté navigateur doit correspondre au event_id côté serveur, et que le nom de l’événement est également utilisé dans le processus. Source : Meta — description de Event et setEventId.

Un event_id fixe égal à l’ID produit serait une mauvaise idée pour différents achats de ce produit. À l’inverse, des identifiants d’événement cohérents ne corrigeront pas un content_ids erroné. Vérifiez ces deux éléments séparément. Si vous analysez également GA4, utilisez le guide existant sur la mesure des achats.

Par quoi commencer pour corriger l’intégration ?

Choisissez un produit et conservez trois données : l’ID dans la boutique, l’ID importé dans le catalogue et l’ID de l’événement. Déterminez le format, modifiez le bon paramètre, actualisez la source nécessaire et refaites le test. Ne modifiez pas en même temps le préfixe, le séparateur, la manière d’exporter les variantes et plusieurs installations du Pixel — cela rendra plus difficile l’identification de la correction qui a résolu le problème.

Vérifiez la cohérence du format d’ID dans les deux intégrations : Facebook Pixel Pro et flux de produits XML pour Meta. Leur configuration doit découler du même modèle de catalogue. Une correspondance correcte est un élément de la qualité des données, et non une garantie de rentabilité des publicités.

Vérification de fond : 13 septembre 2026. Le code de Facebook Pixel Pro 1.4.5, du flux Meta 2.9.2 ainsi que les définitions publiques du SDK officiel de Meta ont été vérifiés. Aucune publication ni aucun achat test n’ont été effectués sur le compte publicitaire du client.