Suivi des conversions ChatGPT Ads : pixel OpenAI, Conversions API et consentement

Ce qui a changé en 2026 pour les annonceurs

OpenAI a ouvert la mesure des conversions en mai 2026, avec deux briques publiées ensemble : un pixel de mesure qui s’exécute dans le navigateur, et une Conversions API qui reçoit les évènements depuis votre serveur. En juin 2026 sont arrivées les campagnes optimisées pour la conversion (oCPC, présentées en bêta ouverte dans la documentation) : vous payez toujours au clic, mais la diffusion est orientée vers les internautes susceptibles de réaliser l’évènement de conversion choisi.

Le 18 août 2026, OpenAI a annoncé l’extension des annonces ChatGPT à 31 pays européens, dont la France. La diffusion a démarré le 24 août, d’abord par l’intermédiaire de partenaires (équipe commerciale d’OpenAI, agences, partenaires technologiques), puis l’accès en libre-service par l’Ads Manager a suivi. Les annonces ne s’affichent qu’aux utilisateurs des offres Free et Go ; les abonnés Plus, Pro et Enterprise n’en voient pas.

Conséquence pratique pour une boutique PrestaShop ou WooCommerce : une campagne oCPC exige un suivi des conversions déjà en place et un évènement de conversion actif, choisi à la création et non modifiable ensuite. Sans mesure fiable, vous achetez des clics sans savoir lesquels vendent, et l’algorithme n’a rien pour apprendre.

Le pixel de mesure OpenAI : ce qu’il fait dans le navigateur

Le pixel est un SDK JavaScript, oaiq.min.js, initialisé avec votre Pixel ID. Il envoie des évènements par l’appel oaiq("measure", nom, données, options). Quand un internaute arrive depuis une annonce, l’URL de la page d’atterrissage porte un paramètre oppref : le pixel le lit et le range dans un cookie first-party __oppref, valable 30 jours à compter de la dernière écriture. Il pose aussi un cookie __obref, identifiant aléatoire du navigateur conservé 365 jours.

La documentation décrit aussi l’advanced matching : e-mail, téléphone, identifiant client, prénom et nom peuvent être transmis sous forme d’empreintes SHA-256, après une normalisation précise (e-mail en minuscules sans espaces, téléphone réduit à ses chiffres, etc.). Un mode automatique existe, qui détecte ces informations sur la page sans que les données brutes ne partent chez OpenAI.

Il existe enfin une balise image sans JavaScript, utile en repli dans un bloc noscript ou pour une conversion au chargement de page. Elle est limitée : un évènement par requête, pas d’objet utilisateur, et elle ne capte pas oppref d’elle-même. Pour une boutique, c’est un complément, jamais la solution principale.

La Conversions API : la même vente, envoyée depuis le serveur

La Conversions API reçoit des requêtes POST sur le point d’entrée /v1/events?pid=<PIXEL-ID> du domaine de collecte d’OpenAI, authentifiées par une clé API distincte, obtenue elle aussi dans l’onglet conversions de l’Ads Manager. Une requête peut regrouper jusqu’à 1 000 évènements ; si un seul évènement est invalide, tout le lot est refusé. Chaque évènement porte un id, un type (order_created, items_added…), un horodatage timestamp_ms qui doit refléter le moment réel de la conversion et ne pas remonter à plus de sept jours, l’URL source et, dans un objet data, le montant, la devise et le contenu de la commande.

Deux détails pèsent lourd. Le montant s’exprime en entier, dans l’unité mineure de la devise : 59,90 € s’envoient 5990. Et le champ validate_only permet de tester un appel sans rien enregistrer : c’est le mode validation, à utiliser avant toute mise en production.

Pourquoi doubler le pixel ? Parce qu’une partie des évènements navigateur n’arrive jamais : bloqueurs, navigation privée, page de confirmation fermée trop tôt, paiement terminé chez le prestataire sans retour sur la boutique. Le serveur, lui, sait qu’une commande a été validée. OpenAI recommande explicitement d’utiliser les deux ensemble.

Déduplication : une vente, pas deux

Quand la même commande part du navigateur et du serveur, OpenAI la reconnaît comme un seul évènement si trois éléments coïncident : le même Pixel ID, le même nom d’évènement et le même identifiant, appelé event_id dans les options du pixel et id dans la Conversions API. C’est le premier reçu qui est retenu ; les suivants sont ignorés.

La difficulté est d’ordre pratique : l’identifiant doit être connu des deux côtés. Je le génère au moment où la commande est créée, je le stocke avec elle, et je le réinjecte dans la page de confirmation pour le pixel comme dans l’appel serveur. J’évite d’y mettre le numéro de commande en clair : un identifiant opaque suffit et n’expose rien.

Consentement et RGPD : ce qu’il faut régler avant la première vente

Le pixel OpenAI dépose des cookies publicitaires et transmet des données de navigation à un tiers : en France, cela demande le consentement préalable du visiteur, comme pour le pixel Meta ou Google Ads. Point d’attention propre à ce pixel : d’après la documentation, son consentement vaut vrai par défaut tant qu’on ne l’a pas mis à faux. Il faut donc soit appeler oaiq("consent", false) avant l’initialisation, soit ne charger le script qu’après accord. Je fais les deux : le script n’est pas chargé avant consentement, et l’état est mis à faux par sécurité.

Avec tarteaucitron.js, le pixel se déclare comme un service personnalisé qui ne s’exécute qu’à l’acceptation. Avec Axeptio, Cookiebot, Didomi, CookieYes ou Complianz, le chargement est conditionné à la finalité marketing ou à un fournisseur déclaré dans l’outil. Quand la bannière publie les signaux du mode consentement de Google, l’état du stockage publicitaire peut servir de déclencheur.

Côté serveur, la même règle s’applique : j’enregistre l’état du consentement avec la commande, et la Conversions API n’envoie rien pour un visiteur qui a refusé. Les e-mails et téléphones ne partent jamais en clair, uniquement en empreinte SHA-256. La documentation prévoit aussi un champ opt_out par évènement, et précise qu’OpenAI n’utilise pas, à ce jour, les données du pixel pour de la personnalisation individuelle. Enfin, le traitement doit apparaître dans votre politique de confidentialité et votre registre : c’est à vous, ou à votre DPO, d’arbitrer la base légale ; je vous fournis la description technique exacte de ce qui est envoyé.

Et le gestionnaire de balises ?

Passer par Google Tag Manager côté navigateur ou par un conteneur serveur est possible, et c’est parfois le bon choix quand une boutique a déjà toute sa mesure centralisée. Mais sur PrestaShop et WooCommerce, l’information fiable, la commande validée avec son montant et son état de consentement, se trouve dans la boutique elle-même. Envoyer la conversion serveur depuis le hook de validation de commande supprime une couche, et donc une source de décalage. Je choisis selon ce qui est déjà en place : l’objectif est une seule source de vérité, pas un empilement d’outils.

Pour les principes communs à toutes les plateformes publicitaires, la page sur les évènements e-commerce qui comptent et celle sur le pixel Meta et l’API de conversions détaillent la même logique pixel plus serveur. Les sources officielles utilisées ici sont la documentation du pixel de mesure, celle de la Conversions API, la liste des évènements pris en charge et celle de la balise image.