Suivi des conversions OpenAI Ads pour WooCommerce

Comment le suivi des achats WooCommerce doit fonctionner avec OpenAI Ads, y compris les ID de commande, les valeurs de conversion, les événements navigateur et serveur, le consentement et la configuration PixelBridge prévue.

Dernière mise à jour: 8 septembre 2026. Rédigé par PixelBridge team.

Le suivi des achats WooCommerce pour OpenAI Ads doit déclencher un événement purchase après confirmation de la commande, pas lorsqu’un acheteur ouvre le checkout ou ajoute un produit au panier. L’événement doit porter un identifiant de commande, une valeur de conversion et une devise lorsque c’est autorisé, et un ID d’événement partagé si la même conversion est aussi envoyée via la Conversions API. Le consentement de mesure doit être accordé avant qu’un événement navigateur ou serveur quitte le site. PixelBridge est conçu pour le faire depuis WordPress. Le hook du plugin n’est pas encore disponible.

À quoi sert cette intégration

WooCommerce enregistre déjà les commandes, totaux, détails client et statuts de commande. La mesure OpenAI Ads a besoin d’un événement de conversion qui représente cet achat, afin que les rapports publicitaires puissent relier une commande payée ou confirmée à l’activité de campagne.

PixelBridge est un plugin WordPress indépendant pour cette couche de mesure. Ce n’est pas un produit OpenAI ou WooCommerce officiel, et il ne crée pas de campagnes. Le connecteur WooCommerce est l’une des premières intégrations prévues. Tant qu’il n’est pas publié, rien sur cette page n’est une fonctionnalité de plugin qui fonctionne.

Pour la configuration de la boutique elle-même, partez de la documentation officielle WooCommerce. Pour le contrat de mesure publicitaire, utilisez la documentation Measurement Pixel d’OpenAI et la documentation Conversions API. Les noms d’événements et les champs obligatoires peuvent changer. Confirmez-les dans la documentation officielle d’OpenAI avant de traiter un payload comme définitif.

Comment le suivi des achats doit fonctionner

Un événement d’achat utile est une action commerciale terminée. Dans WooCommerce, cela signifie généralement qu’une commande existe et a atteint un statut que votre boutique traite comme réel, comme processing ou completed, selon le moyen de paiement.

La séquence prévue est :

  1. L’acheteur termine le checkout.
  2. WooCommerce crée une commande et lui attribue un identifiant.
  3. Si le consentement de mesure est accordé, un événement purchase navigateur peut se déclencher sur l’état de commande reçue ou de remerciement.
  4. Si la Conversions API est activée, WordPress peut envoyer un événement serveur correspondant après confirmation de la commande en PHP.
  5. Les deux payloads partagent un ID d’événement afin que la mesure OpenAI Ads puisse les traiter comme une seule conversion.

Ne déclenchez pas purchase sur :

  • Les pages vues produit
  • L’ajout au panier
  • Le chargement de la page de checkout
  • Les paiements échoués ou annulés
  • Les commandes brouillon créées dans l’administration qui n’ont jamais été passées par un client

Une page vue sur une URL produit ou panier reste un événement page_viewed si vous mesurez les pages vues. Ce n’est pas un achat. Voir événements de conversion pour la différence entre ces types d’événements.

Identifiants de commande

Chaque événement d’achat a besoin d’un identifiant de commande stable. WooCommerce en a déjà un : l’ID de commande, et souvent un numéro de commande séparé si vous utilisez un plugin de numérotation personnalisé.

L’identifiant est utile pour trois tâches :

  • Débogage : vous pouvez relier un événement de mesure à une commande WooCommerce.
  • Déduplication : les événements navigateur et serveur peuvent pointer vers la même commande.
  • Opérations ultérieures : si la gestion des remboursements est ajoutée, la commande d’origine est la clé de jointure.

Utilisez l’identifiant qui ne changera pas après le checkout. Si votre boutique affiche un numéro de commande formaté aux clients, décidez si la mesure utilise l’ID interne ou le numéro visible par le client, puis gardez ce choix cohérent sur les événements navigateur et serveur.

Ne générez pas un nouvel ID aléatoire sur la page de remerciement si un événement serveur enverra aussi l’ID de commande. Les deux côtés ne ressembleraient plus à la même conversion.

Valeurs de conversion

Une conversion d’achat est bien plus utile lorsqu’elle inclut une valeur et une devise. Les sources typiques dans WooCommerce sont le total de la commande et la devise de la boutique.

Planifiez la valeur avec soin :

  • Décidez si la valeur inclut la taxe, la livraison et les frais.
  • Utilisez la même règle sur les événements navigateur et serveur.
  • Envoyez la devise de la boutique, pas une valeur de repli codée en dur, sauf si la commande elle-même est dans une autre devise.
  • N’envoyez pas de valeur pour une commande impayée ou échouée.

La valeur n’est pas la même chose que le chiffre d’affaires dans les rapports de votre boutique. Les totaux WooCommerce peuvent inclure des remises, des remboursements plus tard, ou des ajustements multi-devises. La mesure OpenAI Ads ne verra que ce que vous envoyez. Gardez le mapping simple et documentez-le pour votre équipe.

Si le consentement ou votre politique de confidentialité n’autorise pas l’envoi de la valeur, omettez-la plutôt que de deviner. Un événement d’achat sans valeur est encore une conversion. Une valeur inventée est pire que pas de valeur.

Événements navigateur

L’événement navigateur est l’appel purchase côté client après le chargement du pixel. Sur WooCommerce, l’endroit naturel est la page de commande reçue, après que WooCommerce a affiché une commande réussie.

Un événement navigateur prévu doit attendre :

  1. Que le pixel OpenAI Ads s’initialise avec votre Pixel ID.
  2. Le consentement de mesure, si votre site l’exige.
  3. La preuve que cette page appartient à une vraie commande, pas à un modèle de remerciement générique sans objet de commande.

Les pages de remerciement sont faciles à rater. Certains thèmes chargent le même modèle pour les paiements échoués. Certains plugins de checkout remplacent le point de terminaison de commande reçue du cœur. Certains caches servent une page de remerciement sans contexte de commande. L’intégration doit lire l’objet de commande WooCommerce, pas supposer que toute visite de /checkout/order-received/ est un achat.

Les événements navigateur peuvent être bloqués par des extensions, des navigateurs stricts, des règles de Content Security Policy ou une bannière de consentement qui n’accorde jamais la mesure. C’est pourquoi un événement serveur fait partie de la conception. C’est un complément, pas un moyen d’ignorer le consentement. Voir le guide Pixel OpenAI Ads pour WordPress pour le chargement du pixel lui-même.

Événements côté serveur

La Conversions API envoie la même conversion depuis WordPress après confirmation de la commande en PHP. C’est utile lorsque la page de remerciement ne se charge jamais, que l’acheteur ferme l’onglet, ou que le pixel navigateur est bloqué.

Un événement serveur WooCommerce prévu doit se déclencher depuis un hook du cycle de vie de la commande, pas depuis un callback wp_footer générique. Le hook doit représenter une commande confirmée. Les moyens de paiement diffèrent : certains marquent la commande comme processing immédiatement, d’autres attendent un webhook. L’intégration doit suivre le statut qui signifie « cet achat est réel » pour cette passerelle.

Les événements serveur ont encore besoin de :

  • Le Pixel ID
  • Le nom d’événement (purchase)
  • L’identifiant de commande
  • La valeur et la devise lorsque c’est autorisé
  • L’ID d’événement partagé
  • Les données d’attribution telles que oppref lorsqu’elles sont disponibles
  • La même règle de consentement que l’événement navigateur

La connexion Conversions API du plugin fait partie des fonctionnalités Pro prévues et n’est pas encore disponible publiquement. Lisez Conversions API et la documentation officielle Conversions API pour le contrat de champs actuel.

Déduplication

Si vous envoyez à la fois un événement navigateur et un événement serveur pour une commande WooCommerce, la mesure OpenAI Ads a besoin d’un moyen de voir qu’il s’agit de la même action. C’est un ID d’événement partagé.

Le modèle prévu est :

  1. WordPress génère ou stocke un ID d’événement pour la commande.
  2. L’événement navigateur inclut cet ID.
  3. L’événement serveur inclut le même ID.
  4. Les deux événements utilisent le même Pixel ID et le même nom d’événement.

Sans cet ID partagé, une page de remerciement réussie plus un hook serveur réussi peut ressembler à deux achats. Avec lui, un événement navigateur bloqué peut encore laisser une conversion serveur valide.

Ne réutilisez pas un ID d’événement pour des commandes différentes. Ne créez pas un nouvel ID à chaque actualisation de la page de remerciement. La commande est l’unité de conversion.

Consentement

Le suivi des achats reste de la mesure publicitaire. Si votre cadre juridique la traite comme optionnelle, l’intégration WooCommerce ne doit pas charger le pixel, déclencher un achat navigateur, ou envoyer un événement Conversions API tant que la permission requise n’existe pas.

Le consentement n’est pas un réglage WooCommerce. Il vient généralement d’une bannière cookies ou d’un plugin de consentement. PixelBridge est conçu pour lire cet état plutôt que d’ajouter une seconde bannière. Voir consentement.

Quelques pièges spécifiques à WooCommerce :

  • Le checkout peut se terminer pendant que la bannière n’a pas encore de réponse.
  • Certaines boutiques accordent le consentement statistiques mais pas le consentement marketing ou de mesure.
  • Les événements serveur doivent suivre la même permission que les événements navigateur. Un hook PHP n’est pas une faille.

Cette page est un guide d’implémentation, pas un conseil juridique.

Remboursements

WooCommerce peut rembourser une commande en totalité ou en partie. Les événements de remboursement ou d’ajustement OpenAI Ads ne sont pas encore pris en charge par PixelBridge.

Tant que le support des remboursements n’existe pas :

  • N’envoyez pas un second purchase avec une valeur négative comme solution de repli.
  • Ne supprimez pas l’événement d’achat d’origine de vos propres journaux en supposant que les rapports publicitaires suivront.
  • Traitez l’achat d’origine comme la conversion qui a été envoyée, puis attendez un mapping de remboursement documenté.

Si des événements de remboursement sont ajoutés plus tard, ils devront référencer l’identifiant de commande d’origine et suivre les règles officielles de mesure OpenAI Ads. Ce travail n’est pas publié.

Configuration prévue

Lorsque l’intégration WooCommerce sera publiée, le chemin WordPress prévu est :

  1. Installez PixelBridge lorsque le plugin sera disponible. La fiche publique n’est pas encore en ligne. Voir installation.
  2. Saisissez votre Pixel ID OpenAI Ads.
  3. Activez le suivi des achats WooCommerce dans les réglages du plugin.
  4. Choisissez le statut de commande qui doit compter comme achat pour vos moyens de paiement.
  5. Décidez si les événements navigateur, serveur, ou les deux doivent se déclencher.
  6. Confirmez les règles de consentement avant qu’un événement soit autorisé.
  7. Passez une commande de test sur un site de staging et vérifiez le diagnostic.

En attendant, ne collez pas de JavaScript d’achat dans un modèle de remerciement WooCommerce en supposant qu’il correspondra au futur plugin. Un test manuel temporaire est possible, mais ce n’est pas l’intégration prise en charge.

Dépannage

Si un achat WooCommerce n’apparaît pas dans la mesure OpenAI Ads, parcourez le problème dans cet ordre :

  1. Confirmez que l’intégration est effectivement publiée. Si cette page indique encore bientôt disponible, le hook n’est pas en ligne.
  2. Confirmez que le Pixel ID correspond au compte publicitaire.
  3. Confirmez que l’acheteur a atteint une commande confirmée, pas un écran de checkout ou de paiement échoué.
  4. Accordez le consentement de mesure et réessayez.
  5. Vérifiez si la page de remerciement est en cache sans contexte de commande.
  6. Vérifiez si un plugin de checkout personnalisé a remplacé le flux de commande reçue du cœur.
  7. Si des événements navigateur et serveur sont prévus, confirmez qu’ils partagent un ID d’événement.
  8. Inspectez le diagnostic et le guide de dépannage.

Une valeur oppref manquante ne signifie pas toujours que le suivi a échoué. Cela peut signifier que la visite ne venait pas d’une publicité OpenAI. Voir attribution oppref.

Associé

Guides associés