Pixel ChatGPT Ads et Conversions API : installer le suivi des conversions
Dernière mise à jour : 24 août 2026, vérifié à partir de la documentation officielle OpenAI. Les noms d'événements et de paramètres cités ici viennent de la documentation développeur d'OpenAI, ils sont susceptibles d'évoluer pendant la bêta.
Sans mesure de conversion, une campagne ChatGPT Ads reste aveugle : vous savez ce que vous dépensez, pas ce que vous obtenez. Et surtout, vous ne pouvez pas activer l'optimisation à la conversion. Cette page couvre les deux méthodes officielles, le pixel navigateur et la Conversions API côté serveur, et la façon de les faire cohabiter. Le cadre général est dans notre guide ChatGPT Ads.
Moteurs IA concernés par cette page
- ChatGPT
Pourquoi la mesure est un prérequis, pas une option
Trois raisons, dont une bloquante :
- Bloquante : l'optimisation à la conversion (oCPC) exige que le suivi soit déjà configuré, avec le pixel JavaScript, la Conversions API, ou les deux. Sans signal, le système n'a rien à optimiser.
- Le reporting d'Ads Manager comprend une colonne conversions qui reste vide si rien n'est branché.
- Le calcul de votre coût par acquisition dépend entièrement de cette donnée : sans elle, vous pilotez au CPC, c'est-à-dire à la dépense, pas au résultat.
Le principe général posé par OpenAI est simple : vous créez une source de données (data source) dans Ads Manager, puis vous lui envoyez des événements de conversion via le pixel, l'API, ou les deux.
Pixel ou Conversions API : lequel choisir ?
| Pixel JavaScript | Conversions API | |
|---|---|---|
| Où il s'exécute | Dans le navigateur du visiteur | Sur votre serveur, uniquement |
| Mise en place | Un script à poser dans le head | Développement côté back-end |
| Robustesse | Sensible aux bloqueurs et aux restrictions navigateur | OpenAI la présente comme une source plus fiable que le pixel seul |
| Recommandation OpenAI | Point de départ | À utiliser quand c'est possible, pour des données plus précises |
La réponse pragmatique n'est pas « l'un ou l'autre » mais « les deux, avec déduplication ». Le pixel se pose en une heure et fait vivre les campagnes tout de suite ; l'API se branche ensuite et sécurise la mesure durablement.
Installer le pixel de mesure
Le pixel de mesure ChatGPT Ads est un SDK navigateur destiné à mesurer les événements de votre site attribuables à des publicités dans ChatGPT. Le script se charge de manière asynchrone depuis https://bzrcdn.openai.com/sdk/oaiq.min.js, à placer dans la section <head>, puis s'initialise avec votre identifiant de pixel :
oaiq("init", { pixelId: "VOTRE-PIXEL-ID" });
Le paramètre pixelId est obligatoire, il se crée dans Ads Manager. Un paramètre debug facultatif écrit l'activité du SDK dans la console du navigateur, utile pendant la phase de recette.
Toute la mesure passe ensuite par une commande unique : oaiq("measure", nomEvenement, donneesEvenement, options).
Les événements standard, les événements personnalisés et leurs contraintes
Chaque événement standard attend un objet de données dont le champ type doit correspondre. La documentation développeur d'OpenAI les regroupe ainsi :
| Famille | Événements | Champ type attendu |
|---|---|---|
| Commerce | order_created, items_added, checkout_started | contents |
| Contenu | page_viewed, contents_viewed | contents |
| Lead et inscription | lead_created, registration_completed, appointment_scheduled | customer_action |
| Abonnement | subscription_created, trial_started | plan_enrollment |
Pour les événements de type contents, les champs documentés incluent amount, currency et un tableau contents composé d'entrées avec id, name, content_type et quantity. Les événements de type plan_enrollment attendent un plan_id. La documentation précise d'utiliser des valeurs entières pour amount et quantity.
Quand aucun événement standard ne correspond, un événement personnalisé se déclare avec un troisième argument et un objet d'options :
oaiq("measure", "custom", { type: "custom" }, { custom_event_name: "quote_requested" })
Les noms d'événements personnalisés doivent respecter des règles précises : de 1 à 64 caractères, uniquement des lettres, chiffres, tirets bas et tirets, et commencer et finir par un caractère alphanumérique.
Attention à une limite structurante : un événement personnalisé ne peut pas servir d'objectif d'optimisation oCPC. Si votre conversion métier doit piloter l'optimisation, il faut la faire remonter comme événement standard.
Brancher la Conversions API côté serveur
L'API s'utilise depuis votre serveur, exclusivement. Les points de mise en œuvre documentés :
- Vous créez une source de conversion web et son Pixel ID via le point d'entrée
POST /conversions/pixels. - Vous générez une clé capable d'envoyer des événements côté serveur pour le compte publicitaire courant.
- Cette clé doit être stockée dans un gestionnaire de secrets côté serveur. La documentation est catégorique : ne jamais la placer dans du code navigateur, dans des variables d'environnement visibles côté client, dans des journaux ou dans un dépôt de code.
- L'API accepte des lots allant jusqu'à 1 000 événements. Point critique pour votre gestion d'erreurs : si un seul événement du lot échoue, le lot entier échoue.
Cette dernière règle mérite d'être traitée dès la conception : un lot rejeté en bloc à cause d'un champ mal formé sur une commande peut faire disparaître 999 conversions valides de votre reporting.
Dédupliquer pixel et API : la règle à ne pas rater
Si vous envoyez la même conversion depuis le pixel et depuis la Conversions API, il faut le dire au système, sinon vous la comptez deux fois. La méthode documentée :
- Réutiliser la même valeur comme id côté API et comme event_id côté pixel.
- Envoyer les deux événements avec le même Pixel ID.
- Pour les événements personnalisés, utiliser le même custom_event_name des deux côtés.
Côté pixel, cela ressemble à : oaiq("measure", "order_created", {...}, { event_id: "order_12345" }). La correspondance s'appuie sur le Pixel ID, le nom de l'événement et l'event_id ; pour un événement personnalisé, le custom_event_name remplace le nom de l'événement dans cette logique.
En pratique : utilisez votre identifiant de commande ou de lead comme clé de déduplication, c'est la seule valeur naturellement disponible des deux côtés.
oppref : le préserver jusqu'à la conversion, pas seulement le capturer
Le pixel capture oppref, la référence de clic d'OpenAI, et la stocke dans un cookie de premier niveau (__oppref). Documenter sa capture ne suffit pas : la documentation officielle insiste sur un point que beaucoup d'implémentations ratent, oppref doit être préservé à travers les redirections et la navigation jusqu'à la page où la conversion est réellement mesurée. Un tunnel de paiement qui passe par un sous-domaine de paiement, une redirection après un formulaire, ou un panier qui change de domaine perdent le cookie en cours de route si rien n'est prévu pour le faire suivre.
Second point souvent manqué : la Conversions API ne capture pas oppref pour vous, contrairement au pixel. Si vous appelez l'API côté serveur, c'est à votre code d'aller chercher la valeur d'oppref (typiquement déposée par le pixel dans un cookie ou transmise en paramètre d'URL) et de l'inclure explicitement dans l'appel, quand elle est disponible. Sans cette étape, un événement envoyé uniquement par l'API perd le lien avec le clic publicitaire qui l'a précédé.
L'architecture recommandée par OpenAI tient en trois parts : le pixel sur chaque page pour capturer oppref et les événements légers, la Conversions API pour les événements à forte valeur envoyés depuis votre back-end (là où vous avez la commande, et où rien ne peut bloquer l'appel), et les deux canaux qui envoient la même conversion avec le même event_id.
L'advanced matching automatique
L'advanced matching automatique (AAM) sert à rattacher des conversions à vos annonces lorsqu'aucun identifiant de clic n'est disponible. Le pixel détecte automatiquement les informations client reconnaissables dans les formulaires et autres sources de votre site, les normalise et les hache en SHA-256 directement dans le navigateur. La documentation précise qu'aucune donnée brute n'est transmise.
Vous pouvez aussi fournir vous-même des identifiants hachés dans l'objet user à l'initialisation : email_sha256, phone_number_sha256, external_id_sha256, first_name_sha256, last_name_sha256, ainsi que des champs non hachés country, city, region et postal_code.
Cette fonctionnalité touche à des données personnelles : son activation doit être arbitrée avec votre responsable de la protection des données, en particulier en Europe.
Consentement, RGPD et pilotage du pixel
Le SDK expose une commande de consentement, à appeler avant l'initialisation pour bloquer la mesure tant que l'utilisateur n'a pas accepté :
oaiq("consent", false); puis oaiq("init", { pixelId: "..." }); puis oaiq("consent", true); une fois le consentement obtenu.
Deux points à retenir. D'abord, le consentement vaut true par défaut, sauf s'il est explicitement mis à false ou si un refus a été enregistré : sur un site européen, il faut donc appeler explicitement oaiq("consent", false) en amont plutôt que de compter sur le comportement par défaut. Ensuite, quand la valeur est false, les événements de mesure ne sont pas envoyés.
Un paramètre opt_out permet par ailleurs d'exclure un événement de la personnalisation au niveau utilisateur ; sa valeur par défaut est false. Le SDK gère également un identifiant respectueux de la vie privée, oppref, capturé depuis l'URL et stocké dans un cookie __oppref.
Rappel de contexte : les publicités personnalisées ne sont pas disponibles au lancement dans l'Espace économique européen ni en Suisse. Cela ne dispense en rien de gérer le consentement pour la mesure elle-même.
Content Security Policy : les domaines à autoriser
Cause de panne silencieuse la plus fréquente sur les sites qui appliquent une CSP stricte : le SDK est bloqué avant même de s'initialiser. Les directives documentées :
| Directive | Source à autoriser | Rôle |
|---|---|---|
| script-src | https://bzrcdn.openai.com | Chargement du SDK |
| connect-src | https://bzr.openai.com et https://bzrcdn.openai.com | Envoi et récupération des événements |
| img-src | https://bzr.openai.com | Repli par requête image |
Si le pixel ne remonte rien alors que le code est bien en place, ouvrez la console avec le paramètre debug activé : une erreur CSP y apparaît immédiatement.
Ce que le pixel ne sait pas faire
Une limite explicite, à connaître avant de concevoir votre plan de marquage : le pixel de mesure ne prend pas en charge les événements app_installed et app_opened. Ces événements doivent être envoyés côté serveur, via la Conversions API.
OpenAI documente par ailleurs des intégrations avec des partenaires de mesure, y compris des partenaires de mesure mobile (MMP), pour les annonceurs dont la conversion se produit dans une application.
Autre point d'attention : l'utilisation de plusieurs Pixel IDs sur un même site demande une configuration particulière, documentée séparément par OpenAI.
Attribution : ce qui est compté, et comment
OpenAI évalue les événements de conversion au regard des événements configurés pour votre campagne et de la fenêtre d'attribution applicable. Deux règles à connaître :
- L'attribution post-clic utilise la fenêtre de clic configurée.
- Les conversions post-impression (view-through) utilisent une fenêtre fixe d'un jour après une impression éligible, indépendante de votre fenêtre de clic.
Et la règle de lecture qui évite les erreurs de calcul : la colonne Conversions principale ne contient que les conversions post-clic. Les conversions post-impression sont un reporting supplémentaire distinct qui, selon OpenAI, ne doit pas être ajouté aux conversions ni utilisé pour des métriques de performance de base comme le CPA.
Checklist de recette avant de lancer
- Source de données créée dans Ads Manager, Pixel ID récupéré.
- Script chargé dans le head, initialisation appelée avec le bon Pixel ID.
- Consentement câblé avant l'init sur les sites européens.
- Événements standard déclenchés aux bons endroits, avec le bon champ type.
- Déduplication en place si vous doublez avec l'API : même valeur en id et event_id, même Pixel ID.
- CSP mise à jour pour les trois directives.
- Mode debug activé le temps de la recette, puis désactivé.
- Page d'atterrissage accessible à OAI-AdsBot : une page bloquée peut faire refuser l'annonce, indépendamment de la qualité du marquage. Notre checker de page d'atterrissage ChatGPT Ads vérifie ce point.
- Un seul événement standard actif retenu comme objectif si vous visez l'oCPC, sachant qu'il ne sera plus modifiable après création de la campagne.
Questions fréquentes
Le suivi des conversions est-il obligatoire sur ChatGPT Ads ?
La Conversions API récupère-t-elle oppref toute seule ?
Faut-il choisir entre le pixel et la Conversions API ?
Comment éviter de compter une conversion deux fois ?
Un événement personnalisé peut-il servir d'objectif oCPC ?
Le pixel respecte-t-il le consentement de l'utilisateur ?
Mon pixel ne remonte rien, que vérifier en premier ?
Comment mesurer une installation d'application ?
Quelle est la fenêtre d'attribution ?
Score SEO, score GEO, performance et responsive : 49 analyses techniques, verdict AI Overviews immédiat.
Guides liés
ChatGPT Ads : guide complet 2026 pour faire de la publicité sur ChatGPT
Comment fonctionne ChatGPT Ads, où c'est disponible, comment créer un compte, structurer une campagne, cibler par context hints et estimer son budget : le guide de référence, mis à jour en continu.
Lire le guidePrix ChatGPT Ads : enchères, budgets et coût réel d'une campagne
Combien coûte vraiment une campagne ChatGPT Ads : les trois modèles d'enchère, l'enchère de départ recommandée par OpenAI, le budget quotidien minimum et la facturation par seuil.
Lire le guideChatGPT Ads pour l'e-commerce : campagnes à partir d'un flux produit
Connecter son catalogue à ChatGPT Ads : les trois méthodes d'envoi de flux, l'expiration des articles, le champ is_ads_eligible et la différence avec les résultats produits organiques.
Lire le guide