ChatGPT Ads : comment remonter vos conversions offline pour nourrir l'enchère (guide 2026)

Ce qui change en septembre 2026 : ChatGPT Ads n’est plus seulement un canal à mesurer, c’est un algorithme à nourrir. Depuis l’été, la régie d’OpenAI propose une enchère optimisée aux conversions (oCPC) qui apprend de ce que vous lui remontez. Et comme chez Google, l’algorithme ira chercher exactement ce que vous lui déclarez. Si vous lui déclarez des formulaires, il vous trouvera des formulaires.

Les publicités ChatGPT sont visibles par les utilisateurs français depuis le 24 août 2026, et l’accès self-service à l’Ads Manager a suivi une semaine plus tard, le 31 août. La plupart des annonceurs en sont encore à la première question : est-ce que ce canal fonctionne. C’est la bonne question, mais elle en cache une plus urgente : est-ce que vous êtes en mesure d’y répondre.

Parce que par défaut, non. Un clic payant ChatGPT arrive dans Google Analytics au milieu du trafic organique de ChatGPT, et l’algorithme d’OpenAI n’apprend que du formulaire, jamais de la vente. Voici comment refermer les deux trous.

1. Capter le clic : le paramètre oppref

Quand un utilisateur clique sur une annonce ChatGPT, OpenAI ajoute un paramètre à l’URL de destination : oppref. C’est un identifiant de clic chiffré, l’équivalent du gclid de Google Ads ou du fbclid de Meta.

https://votre-site.fr/devis?oppref=gAAAAAb123...

La documentation OpenAI décrit le mécanisme du pixel de mesure : il lit oppref dans l’URL de la page d’atterrissage et le stocke dans un cookie first-party nommé __oppref. Vous verrez parfois passer un second paramètre, olref. Il n’est documenté nulle part chez OpenAI à ce jour. Captez-le si vous voulez le stocker, mais ne construisez rien dessus.

Le piège que personne ne voit venir

ChatGPT ajoute déjà utm_source=chatgpt.com sur les liens sortants de ses réponses organiques. Résultat : un clic publicitaire arrivé sans UTM sur votre site ressemble à s’y méprendre à une citation organique. Dans votre outil d’analytics, les deux se retrouvent dans le même seau, et votre budget publicitaire disparaît dans le trafic gratuit.

Deux conséquences pratiques.

Ajoutez des UTM statiques à toutes vos annonces. La convention qui fonctionne est utm_source=chatgpt et utm_medium=cpc. Ne reprenez surtout pas chatgpt.com comme source : c’est précisément la valeur que porte l’organique, vous fusionneriez les deux canaux au lieu de les séparer. OpenAI propose également des macros dynamiques ({campaign_id}, {ad_group_id}, {ad_id}, {ad_account_id}) pour obtenir la granularité campagne sans maintenir vos UTM à la main.

Pointez vos annonces directement sur la page finale. Toute redirection 301 ou 302, tout raccourcisseur de lien, toute réécriture d’URL par votre CMS risque d’effacer la query string, donc l’oppref, avant qu’il ne soit capté. C’est un problème de terrain régulièrement remonté par les praticiens du tracking. Un hop de redirection et l’identifiant de clic n’existe plus.

Notez la hiérarchie : oppref n’est apposé que sur un clic d’annonce, alors que les UTM peuvent être portés par n’importe quel lien. Un outil d’attribution qui capte le paramètre de clic sait donc distinguer le payant de l’organique même sans UTM. Un outil qui ne lit que les UTM en est incapable. C’est la même différence qu’entre lire le gclid et se fier à utm_medium=cpc.

2. Ce que l’enchère automatique fait vraiment de vos conversions

OpenAI a annoncé le 24 juillet 2026 un objectif de campagne « Conversions » avec enchère oCPC, déployé dans les semaines qui ont suivi. C’est ce qui transforme le sujet : vos conversions ne servent plus seulement à établir un rapport, elles pilotent l’achat média.

La documentation d’OpenAI est explicite sur le mécanisme : l’oCPC combine l’événement de conversion que vous avez sélectionné avec la qualité de l’annonce, sa pertinence, la probabilité de clic et la probabilité de conversion, pour favoriser les clics les plus susceptibles de produire cet événement.

Lisez cette phrase une deuxième fois, parce qu’elle contient une information que beaucoup d’annonceurs vont découvrir trop tard.

La valeur ne pilote pas l’enchère

Le schéma d’événement accepte un champ amount (avec la devise associée). Vous pouvez donc envoyer le montant d’un contrat. Mais nulle part la documentation ne dit que ce montant influence l’enchère : le signal d’optimisation décrit est une probabilité de conversion, c’est-à-dire un signal binaire. L’événement a eu lieu, ou non.

Concrètement : il n’y a aujourd’hui ni tROAS, ni maximisation de la valeur de conversion sur ChatGPT Ads. Envoyer 40 000 euros sur un contrat plutôt que 400 euros sur un autre n’apprendra pas à l’algorithme à chercher les gros contrats. Toutes les stratégies de value-based bidding que vous appliquez sur Google Ads sont, pour l’instant, sans effet ici.

Ce n’est pas une raison pour ne pas remonter la valeur. Elle reste indispensable à votre pilotage et à vos rapports, et le jour où OpenAI ouvrira l’enchère à la valeur, votre historique sera déjà là. Mais ne construisez pas votre stratégie d’enchère dessus.

La conséquence stratégique est nette : puisque seul compte le fait qu’un événement ait eu lieu, tout se joue sur le choix de l’événement que vous déclarez.

3. Choisir son événement : la décision la plus lourde, et elle est irréversible

C’est le point que la documentation d’OpenAI énonce sans détour, et qui mérite d’être affiché en grand : vous ne pouvez pas modifier l’objectif de campagne ni l’événement de conversion sélectionné après la création. Pour optimiser sur un autre événement, il faut créer une nouvelle campagne.

Autrement dit, une erreur de choix ne se corrige pas, elle se jette.

La taxonomie disponible

OpenAI documente treize entrées d’événements, dont deux réservées au mobile (app_installed, app_opened) et une entrée custom pour les événements libres. Les événements web standard utiles au lead gen sont :

Deux points d’attention. D’abord, order_created est cadré comme un achat finalisé, pensé pour l’e-commerce. Ensuite, les événements personnalisés ne sont pas éligibles à l’oCPC selon les praticiens qui ont documenté la beta : l’objectif de campagne n’accepte que des événements standard. Ce point n’est pas formulé tel quel dans la documentation publique, mais celle-ci ne présente effectivement que des événements standard comme cible d’optimisation.

Le mur du B2B et du lead gen local

Faites le compte. Vous vendez une prestation qui se signe trois à huit semaines après le premier contact, sans transaction en ligne. Quel événement standard décrit une vente signée dans votre métier ?

Aucun. order_created parle d’un achat e-commerce, et le seul candidat qui décrit votre entrée de tunnel est lead_created, soit le formulaire soumis. La régie la plus récente du marché vous ramène donc à la métrique de surface que tout le monde cherche à quitter depuis cinq ans.

Il existe un contournement, et il faut le présenter pour ce qu’il est : un usage détourné, non documenté comme tel par OpenAI. Rien n’empêche techniquement d’envoyer un lead_created au moment de la signature plutôt qu’au moment du formulaire, avec la valeur du contrat dans amount. L’algorithme apprend alors sur vos clients, pas sur vos curieux. C’est exactement la logique de l’import de conversions offline sur Google Ads.

Sauf qu’il ne faut pas s’arrêter là, parce que ce contournement a un défaut que la plupart des guides passent sous silence.

L’arbitrage que personne ne pose : justesse contre fraîcheur

Descendre dans le tunnel améliore la justesse du signal et dégrade tout le reste. Un formulaire soumis est un signal immédiat, fréquent, et faux. Une vente signée est un signal juste, rare, et lent. Entre les deux, chaque étage du tunnel échange de la vérité contre de la vitesse et du volume.

C’est un vrai problème, pas une précaution rhétorique. Un algorithme d’enchère apprend d’autant mieux que sa boucle de rétroaction est courte. Si vos signatures tombent six semaines après le clic, l’algorithme a passé six semaines à enchérir sans ce signal. Et si vous signez quelques contrats par mois, il n’aura jamais assez de matière pour apprendre quoi que ce soit.

Sur Google Ads, cet arbitrage se contourne : la Dual-Event Strategy consiste à envoyer en parallèle un signal précoce pour le volume et un signal tardif pour la qualité, sur deux actions de conversion distinctes. Sur ChatGPT Ads, ce contournement n’existe pas. La documentation d’OpenAI est explicite : une campagne oCPC dispose d’exactement un événement standard actif comme objectif d’optimisation, et il est verrouillé à la création.

Il faut donc trancher, une seule fois, sans possibilité de correction.

La bonne question n’est pas « formulaire ou signature ». C’est : quel est l’étage le plus bas de mon tunnel qui produit encore assez d’événements, assez vite ?

Pour du lead gen local ou du B2B à cycle court, ce point d’équilibre se situe rarement à la signature. Il se situe généralement au milieu du tunnel, sur un lead qualifié, un rendez-vous obtenu ou un devis envoyé. Ces événements arrivent en quelques jours plutôt qu’en quelques semaines, ils sont dix fois plus nombreux que les signatures, et ils sont infiniment mieux corrélés au chiffre d’affaires qu’un simple formulaire rempli. La taxonomie standard propose d’ailleurs appointment_scheduled, qui correspond exactement à cette logique.

Trois repères pour choisir :

• Vous signez plusieurs dizaines d’affaires par mois avec un cycle de quelques jours. Optimisez sur la signature, vous avez le volume et la fraîcheur.
• Vous signez quelques affaires par mois avec un cycle de plusieurs semaines. Optimisez sur l’étage intermédiaire, RDV ou lead qualifié, et gardez la signature pour votre pilotage.
• Vous démarrez et vous n’avez aucun historique. Optimisez sur l’étage intermédiaire également. Un algorithme qui apprend sur un signal imparfait mais nourri battra toujours un algorithme qui attend un signal parfait qui n’arrive jamais.

Dans les deux derniers cas, continuez à remonter vos signatures. Selon les praticiens qui ont documenté la beta, les événements autres que celui choisi comme objectif sont acceptés et alimentent le reporting sans influencer l’enchère. Ce point n’est pas formulé explicitement dans la documentation publique, vérifiez-le dans votre interface avant de construire dessus. Vous garderez ainsi la vérité commerciale pour vos arbitrages de budget, même si l’algorithme, lui, optimise sur un signal plus précoce.

Le prérequis que tout le monde rate

Un dernier point, et c’est celui qui rend inutile tout le reste s’il est manqué.

Votre conversion ne sera rattachée au clic d’origine que si ce clic est encore dans la fenêtre d’attribution. La documentation d’OpenAI indique que l’attribution post-clic suit la fenêtre configurée sur le compte, mais elle ne publie ni sa valeur par défaut, ni ses bornes. Les sources spécialisées se contredisent d’ailleurs entre sept et trente jours, sans qu’aucune ne cite de texte officiel.

Conséquence pratique : allez lire cette valeur dans votre propre interface avant de lancer, et élargissez-la si votre cycle de vente le dépasse. Une signature remontée à J+45 sur une fenêtre restée à sept jours ne sera rattachée à aucun clic, quelle que soit la qualité de votre plomberie technique.

4. Remonter les conversions : la Conversions API d’OpenAI

Voici le contrat technique, tel que documenté par OpenAI.

L’endpoint.

POST https://bzr.openai.com/v1/events?pid=<PIXEL-ID>
Authorization: Bearer <API-KEY>

Les données utilisateur sont hachées. Chaque valeur est normalisée, encodée en UTF-8, passée en SHA-256, et envoyée sous forme de chaîne hexadécimale de 64 caractères en minuscules. Cela concerne les emails, les téléphones, les identifiants externes et les noms.

Les envois se font par lots de 1 000 événements maximum. Attention au détail qui coûte cher en production : si un seul événement du lot échoue, le lot entier échoue. Une adresse email mal normalisée peut faire tomber 999 conversions valides avec elle. Prévoyez une validation en amont et une reprise unitaire en cas d’échec.

La déduplication repose sur le triplet Pixel ID, event_name et id. C’est le champ id qui porte votre clé d’idempotence, et non un champ event_id distinct comme chez Meta. Utilisez un identifiant stable côté votre système, typiquement l’identifiant de l’opportunité, pour qu’un rejeu ne crée jamais de doublon.

La contrainte qui décide de tout : sept jours

Le champ timestamp_ms porte le moment de la conversion. La documentation est catégorique : il doit se situer dans les sept derniers jours, et pas plus de dix minutes dans le futur.

Attention à ne pas se tromper sur ce que cette règle contraint. Elle ne porte pas sur l’ancienneté du clic. Un clic peut remonter à plusieurs semaines, la fenêtre d’attribution le couvre. Ce qui doit être récent, c’est la conversion elle-même par rapport au moment où vous l’envoyez.

En clair : quand un commercial passe une affaire en « signé », vous avez sept jours pour le dire à OpenAI. Passé ce délai, l’API refuse l’événement, et cette conversion ne nourrira jamais l’algorithme.

Cela disqualifie l’export mensuel. Un fichier de ventes remonté en fin de mois arrive systématiquement hors délai pour les trois premières semaines. La seule architecture qui tient est un déclenchement automatique au changement de statut, avec au minimum une synchronisation quotidienne.

L’architecture qui fonctionne

Trois pièces, dans cet ordre.

1. Capter et stocker oppref côté serveur, à la soumission du formulaire. Le cookie __oppref est posé en JavaScript, il subit donc le plafond de sept jours imposé par l’ITP de Safari. Sur un cycle de vente de plusieurs semaines, il aura disparu du navigateur bien avant la signature. Ce que vous stockez dans votre base au moment du contact, en revanche, ne s’efface pas.
2. Attacher l’identifiant à l’opportunité commerciale, et le faire voyager avec elle tout au long du cycle.
3. Déclencher la remontée sur l’événement métier, au passage au statut gagné, et non sur un calendrier.

C’est exactement la même architecture que pour l’import de conversions offline Google Ads ou pour Meta CAPI. La bonne nouvelle : si vous avez déjà cette plomberie, l’ajout de ChatGPT Ads est une quatrième destination, pas un nouveau chantier.

5. Deux points de vigilance sur une régie qui bouge vite

La correspondance avancée automatique. Déployée en même temps que l’oCPC, elle utilise des données client hachées pour améliorer l’attribution, et s’active automatiquement passé un délai de désinscription de dix jours. Si votre politique de données impose un choix explicite, vérifiez ce réglage plutôt que de le subir.

Les conversions view-through. OpenAI a introduit récemment les conversions attribuées à une impression, sur une fenêtre fixe d’un jour. La documentation est claire sur leur statut, et il vaut la peine de le citer : les conversions view-through servent au reporting uniquement, tandis que le CPA, le taux de conversion post-clic, l’enchère, la facturation et l’optimisation restent fondés sur le clic. Quand une conversion est éligible aux deux, le clic l’emporte.

Autrement dit, elles ne perturbent pas votre optimisation, mais elles gonflent vos chiffres de rapport. Si votre volume de conversions déclaré augmente d’un coup sans que vos ventes bougent, regardez cette ligne avant de conclure que vos campagnes se sont améliorées.

Plus largement, cette régie évolue de mois en mois. Le seuil de dépense minimum est passé de 200 000 dollars par mois en début d’année à zéro en mai. Ce qui est vrai aujourd’hui aura bougé au prochain trimestre : traitez ce guide comme un état des lieux daté, pas comme une documentation stable.

6. Votre checklist

1. Ajoutez utm_source=chatgpt et utm_medium=cpc sur toutes vos annonces, et jamais chatgpt.com comme source.
2. Pointez chaque annonce sur l’URL finale, sans redirection.
3. Vérifiez que votre formulaire enregistre oppref côté serveur, et pas seulement dans un cookie.
4. Lisez la fenêtre d’attribution post-clic configurée sur votre compte, et élargissez-la si votre cycle de vente la dépasse.
5. Choisissez l’étage du tunnel le plus bas qui garde du volume et de la fraîcheur, pas forcément la signature. Ce choix est définitif.
6. Assurez-vous que votre process commercial met les statuts à jour dans les sept jours suivant l’événement. C’est votre vrai facteur limitant, et il est humain, pas technique.
7. Remontez vos signatures et leur valeur même si elles ne sont pas votre événement d’optimisation : c’est ce qui vous permettra d’arbitrer vos budgets sur autre chose que des formulaires.

Où en est Sevya sur ce sujet

Par transparence, parce que ce blog n’a d’intérêt que si les informations qu’il donne sont vérifiables.

Ce qui est livré : Sevya capte oppref sur ses trois voies d’entrée (le script de tracking, le webhook d’ingestion et le connecteur Magnétis) et identifie la source « ChatGPT Ads » comme quatrième régie, aux côtés de Google Ads, Meta et Microsoft. L’identifiant est stocké côté serveur avec le lead, il survit donc à l’expiration du cookie et reste disponible à la signature, des semaines après le clic.

Ce qui ne l’est pas : le connecteur de remontée vers la Conversions API d’OpenAI n’est pas encore en production. Aujourd’hui, Sevya vous dit qu’un client signé vient de ChatGPT Ads, et remonte automatiquement vos conversions vers Google Ads et Meta. La boucle vers OpenAI est au développement.

Si vous démarrez sur ChatGPT Ads maintenant, la priorité n’est de toute façon pas la remontée : c’est la captation. Un identifiant de clic non capté est définitivement perdu, alors qu’une conversion pourra toujours être remontée le jour où le connecteur existera, à condition d’avoir gardé le lien entre le clic et le client.

Sources : documentation développeur OpenAI Ads (pixel de mesure, Conversions API, événements supportés, campagnes optimisées aux conversions, référence d’API) et annonce officielle d’expansion européenne du 24 août 2026. Ne sont pas documentés publiquement par OpenAI à la date de publication, et sont signalés comme tels dans le texte : la fonction du paramètre olref, la durée de vie du cookie __oppref, la valeur par défaut et les bornes de la fenêtre d’attribution post-clic, la non-éligibilité des événements personnalisés à l’oCPC, l’acceptation en reporting des événements autres que l’objectif, tout seuil de volume d’apprentissage et tout délai de traitement des conversions remontées. Cette régie évolue vite : vérifiez ces points dans votre interface avant de vous engager.