Envoyer les achats WooCommerce à ChatGPT Ads via la Conversions API

Dans le navigateur, le Measurement Pixel envoie les vues produit, les ajouts au panier, les débuts de commande et l'achat. Quand WooCommerce confirme qu'une commande est payée, l'achat part aussi de votre serveur via l'OpenAI Conversions API, avec le même ID d'événement, pour qu'OpenAI ne le compte qu'une fois.

Le Measurement Pixel s'exécute dans le navigateur de l'acheteur. C'est le seul endroit où l'on voit les vues produit et l'activité du panier, mais cela signifie aussi qu'un événement est perdu chaque fois que la page ou le script ne va pas jusqu'au bout :

• Un bloqueur de contenu ou un outil de protection de la vie privée empêche le chargement du script du pixel.
• Le client ferme l'onglet après avoir payé, avant l'affichage de la page « Commande reçue ».
• Le paiement est confirmé plus tard (virement bancaire, certaines passerelles avec redirection), alors que le client a quitté le site.
• Un chargement de page lent ou interrompu fait échouer la requête.

Dans chacun de ces cas, WooCommerce enregistre bien la commande. Un événement d'achat côté serveur part de cette commande : aucune de ces situations ne l'empêche d'être envoyé.

Votre serveur envoie à OpenAI une requête HTTPS authentifiée contenant un ou plusieurs événements. La requête est adressée à votre Pixel ID et autorisée par une clé Conversions API, tous deux générés dans l'onglet des conversions d'Ads Manager (documentation de l'OpenAI Conversions API, en anglais).

Envoyez-le quand WooCommerce marque la commande comme payée, et non quand la page « Commande reçue » s'affiche. Lier l'événement au statut de la commande plutôt qu'à une page vue signifie que :

• Il se déclenche une seule fois par commande, quel que soit le nombre de rechargements de la page de remerciement.
• Avec les moyens de paiement différés, l'achat part au moment où le paiement est réellement confirmé.
• Les commandes non payées, échouées ou abandonnées ne sont pas remontées comme des achats.

1. Commande validée

   Commande créée dans WooCommerce

2. Paiement confirmé

   La commande atteint un statut payé

3. Achat envoyé

   order_created depuis votre serveur

4. Résultat enregistré

   Accepté, relancé ou en échec

Si un achat est envoyé à la fois par le navigateur et par le serveur, OpenAI doit pouvoir savoir qu'il s'agit d'un seul et même achat. D'après sa documentation, OpenAI déduplique à partir de votre Pixel ID, du champ event_name et du champ id : il retient le premier événement reçu pour une même clé et ignore les doublons qui arrivent ensuite.

L'ID d'événement doit donc être identique sur les deux canaux. Sur WooCommerce, la méthode fiable consiste à le dériver de la commande, que connaissent à la fois la page « Commande reçue » et le serveur, plutôt que de générer dans le navigateur un ID aléatoire que le serveur ne verra jamais. Le guide Pixel vs Conversions API explique comment les deux canaux s'articulent.

OpenAI refuse les événements situés hors d'une fenêtre de temps donnée : selon sa documentation, l'horodatage doit se situer dans les 7 derniers jours et au plus 10 minutes dans le futur. Deux conséquences pour une boutique :

• Envoyez l'heure d'achat d'origine, et non l'heure de la tentative ; sinon, un événement relancé indique un achat plus tardif qu'en réalité.
• Corrigez rapidement les envois en échec. Une commande dont l'heure d'achat remonte à plus de 7 jours ne peut plus être envoyée.

L'API accepte aussi des lots de 1 000 événements au maximum, et si un seul événement du lot échoue, c'est tout le lot qui échoue : une commande mal formée peut en bloquer d'autres si l'implémentation regroupe les envois sans précaution.

La documentation d'OpenAI demande de réutiliser le même ID lorsqu'on relance une conversion ou qu'on l'envoie par une autre intégration. Elle ne publie en revanche aucun calendrier de relance : la politique de relance relève de l'implémentation. Une politique raisonnable distingue :

Quelle que soit la politique, un échec doit être visible quelque part. Sans suivi commande par commande, une intégration en panne ressemble à s'y méprendre à une semaine de ventes calme.

L'envoi côté serveur ne permet pas de contourner le consentement. Le pixel lui-même n'envoie aucun signal de mesure lorsque le consentement est refusé (documentation du Measurement Pixel), et un achat côté serveur doit respecter l'état de consentement enregistré pour la commande concernée. Sous WordPress, la WordPress Consent API est le moyen le plus courant pour une bannière de consentement de partager cet état avec les autres extensions.

Pixel for ChatGPT Ads est un plugin WooCommerce qui n'envoie que l'achat côté serveur. Voici ce qu'il fait à chacune des étapes ci-dessus :

Agrandir la capture d'écran

Fermer

Vues produit, ajouts au panier et débuts de commande restent des événements navigateur. La page Pixel ChatGPT Ads pour WooCommerce liste chaque événement et d'où il part.