Vos conversions ChatGPT Ads vont être comptées deux fois, et votre trafic payant va se retrouver classé en organique dans GA4. Ce n’est pas une hypothèse : c’est ce qui arrive par défaut quand on branche la régie sans réfléchir à la mesure. Depuis le 24 août 2026, ChatGPT Ads est ouvert à 31 marchés européens dont la France, et le libre-service via Ads Manager arrive dans la foulée. Vous allez donc devoir tracker les conversions ChatGPT Ads cette semaine, pas dans trois mois. Ce guide vous donne le setup complet de praticien en server-side GTM : le pixel oaiq côté navigateur, l’OpenAI Conversions API côté serveur, la déduplication qui casse tout si on la rate, et surtout la partie que personne ne traite, séparer proprement le payant de l’organique dans GA4.
Ce qui a changé le 24 août 2026
OpenAI a annoncé le 18 août l’arrivée de ChatGPT Ads dans 31 pays européens (Allemagne, France, Espagne, Italie, Suède, Pays-Bas, Autriche, entre autres). Trois choses à retenir avant de sortir la carte bleue :
- L’accès se fait d’abord par les équipes OpenAI Ads Solutions, les agences et les partenaires technologiques. Le libre-service par Ads Manager est annoncé pour la fin de l’été, donc septembre 2026.
- Les publicités ne s’affichent que sur les offres Free et Go. Plus, Pro et Enterprise restent sans pub. Votre audience payante ChatGPT est donc, par construction, l’audience gratuite.
- En Europe, le ciblage est contextuel au lancement. La sélection des annonces repose sur le sujet de la conversation en cours, une localisation approximative, le type d’appareil, l’heure et la langue. L’historique des conversations et la mémoire ne sont pas utilisés.
Ce dernier point n’est pas un détail réglementaire de plus : il change complètement la façon dont vous devez penser votre mesure, on y revient à la fin.
La stack de mesure OpenAI en une image
OpenAI propose exactement la même architecture que Meta ou TikTok, deux canaux pour le même événement :
- Le Measurement Pixel (
oaiq) : un SDK navigateur qui charge depuisbzrcdn.openai.com, s’initialise avec votre Pixel ID et envoie un événement à chaque conversion viaoaiq("measure", ...). - La Conversions API (CAPI) : un endpoint serveur à serveur (
https://bzr.openai.com/v1/events) qui envoie les mêmes conversions depuis votre backend. OpenAI la décrit noir sur blanc comme une source de mesure plus fiable que le pixel seul.
Les deux parlent le même langage : les mêmes noms d’événements standard et les mêmes structures de données. Si vous avez déjà posé Meta CAPI, vous êtes en terrain connu ; le principe de la déduplication Meta CAPI et de l’Event Match Quality est identique ici, seuls les noms de champs changent.
Voici les événements standard supportés au moment où j’écris ces lignes :
| Événement | Type de données | Pour |
|---|---|---|
page_viewed | contents | Vue d’une page importante |
contents_viewed | contents | Vue d’un produit, article ou contenu |
items_added | contents | Ajout au panier |
checkout_started | contents | Début de commande |
order_created | contents | Achat finalisé |
lead_created | customer_action | Formulaire de lead |
appointment_scheduled | customer_action | Rendez-vous ou démo |
registration_completed | customer_action | Inscription terminée |
subscription_created | plan_enrollment | Abonnement payant démarré |
trial_started | plan_enrollment | Essai gratuit démarré |
Détail qui compte : les montants s’envoient en entiers, dans l’unité mineure de la devise (donc 12999 pour 129,99 EUR), et un amount s’accompagne toujours d’un currency. C’est une source classique de valeurs de conversion fausses par facteur 100.
Étape 1 : le pixel en GTM web
Vous pouvez coller le snippet OpenAI en dur dans le <head>, mais autant le piloter proprement depuis GTM web. La logique est simple : un tag chargeur qui pose le SDK et l’init, puis un tag par événement déclenché sur vos events du dataLayer GA4 existants.
Le snippet d’init officiel ressemble à ça :
<script>
(function (w, d, s, u) {
if (w.oaiq) return;
var q = function () { q.q.push(arguments); };
q.q = [];
w.oaiq = q;
var js = d.createElement(s); js.async = true; js.src = u;
var f = d.getElementsByTagName(s)[0];
f.parentNode.insertBefore(js, f);
})(window, document, "script", "https://bzrcdn.openai.com/sdk/oaiq.min.js");
oaiq("init", { pixelId: "<VOTRE-PIXEL-ID>" });
</script>
Le Pixel ID se crée dans l’onglet Conversions d’Ads Manager. Ensuite, sur chaque conversion, vous mappez votre event dataLayer vers un oaiq("measure", ...). Pour un achat :
oaiq("measure", "order_created", {
type: "contents",
amount: 12999,
currency: "EUR",
contents: [{ id: "SKU-123", quantity: 1, amount: 12999 }]
}, { event_id: "{{DLV - transaction_id}}" });
Retenez ce event_id : c’est lui qui va servir à la déduplication. On y arrive.
Si vous utilisez un template communautaire (Stape et consorts ont publié des templates OpenAI pour GTM web et serveur), le principe reste le même, ils ne font qu’emballer ces appels.
Étape 2 : l’OpenAI Conversions API en sGTM
Côté serveur, vous rejouez le même événement depuis votre conteneur GTM server-side. Si vous n’avez pas encore de conteneur serveur, commencez par migrer vers le GTM server-side, c’est le prérequis. Pour le choix de l’hébergeur, mon comparatif Stape, Addingwell et Taggrs tranche la question.
L’appel CAPI ressemble à ça (envoyé uniquement depuis votre serveur, jamais le navigateur) :
curl -X POST "https://bzr.openai.com/v1/events?pid=<PIXEL-ID>" \
-H "Authorization: Bearer <API-KEY>" \
-H "Content-Type: application/json" \
--data '{
"events": [{
"id": "order_12345",
"type": "order_created",
"timestamp_ms": 1773892800000,
"action_source": "web",
"source_url": "https://shop.example.com/confirmation",
"user": {
"obref": "<VALEUR_COOKIE___obref>",
"emails_sha256": ["<sha256>"],
"external_ids_sha256": ["<sha256>"]
},
"data": { "type": "contents" }
}]
}'
Trois champs méritent votre attention. action_source vaut web pour les conversions site. source_url est obligatoire pour les événements web. Et user.obref est la pièce maîtresse de l’attribution : c’est la valeur du cookie first-party __obref posé côté navigateur. Vous le lisez dans le navigateur, vous l’envoyez à votre serveur, et vous le repassez tel quel dans user.obref. Ne le modifiez jamais. Il existe aussi un identifiant au niveau événement, oppref, à passer sans le transformer si OpenAI vous le fournit.
Pour l’enrichissement, hachez les identifiants en SHA-256 (email normalisé en minuscules et sans espaces, etc.) et n’envoyez jamais de donnée brute. Là encore, c’est la logique de matching que vous connaissez déjà si vous avez posé Microsoft Ads Conversions API en server-side.
Étape 3 : la déduplication, le point qui casse tout
Voici la règle exacte, celle qui décide si votre mesure est juste ou fausse. La clé de déduplication d’OpenAI est : Pixel ID + event_name + id. OpenAI garde le premier événement reçu pour une clé donnée et ignore les suivants.
Concrètement, pour que le pixel et la CAPI ne comptent pas deux fois le même achat :
- Utilisez le même Pixel ID des deux côtés.
- Envoyez le même nom d’événement (
order_created=order_created). - Faites correspondre l’
event_iddu pixel et l’idde la CAPI, à l’identique.
Pixel web (oaiq) | Conversions API | |
|---|---|---|
| Identifiant de dédup | event_id (dans les options) | id (métadonnée de l’événement) |
| Nom d’événement | 2e argument de measure | champ type |
| Pixel ID | init({ pixelId }) | paramètre pid de l’URL |
| Doit correspondre ? | Oui, les trois | Oui, les trois |
Mon conseil de terrain : prenez votre numéro de commande (transaction_id) comme id, pas un identifiant généré aléatoirement. Un ID aléatoire posé côté client ne survivra pas à un rechargement de la page de confirmation ni à un envoi serveur décalé, et vous vous retrouvez avec deux id différents pour le même achat, donc un doublon. Le numéro de commande, lui, est stable, unique et disponible des deux côtés. Pour les événements sans transaction (un lead, par exemple), générez l’ID une seule fois côté serveur et propagez-le.
Étape 4 : séparer le payant de l’organique dans GA4
C’est la partie que personne ne traite, et c’est la plus importante. J’ai déjà montré que le canal « AI Assistant » de GA4 rate une large part des sessions IA. Le problème s’aggrave avec ChatGPT Ads : votre trafic payant ChatGPT va arriver avec chatgpt.com en referral, exactement comme votre trafic organique ChatGPT, et GA4 va tout empiler dans le même sac. Vous paierez pour des clics que vous ne saurez pas distinguer de vos visites gratuites.
Le referral ne suffit pas. La seule solution fiable, c’est un plan de taggage UTM strict sur toutes vos annonces ChatGPT Ads, avec au minimum :
utm_source=chatgpt.comutm_medium=cpc(oupaid_ai, tant que vous êtes cohérent)utm_campaign=<nom_campagne>
Ensuite, dans GA4, créez un groupe de canaux personnalisé qui isole « ChatGPT Ads » sur la base de ce couple source/medium, pour ne pas le laisser retomber dans le canal organique « AI Assistant ». Si cette mécanique de regroupement ne vous parle pas, la dimension Source Group de GA4 explique comment GA4 range vos sources. Et pour tout le contexte du trafic IA (payant comme organique), c’est le prolongement direct de mon guide sur tracker le trafic ChatGPT, Gemini et Claude dans GA4. Si vous vendez en ligne, le suivi des ventes déclenchées par ChatGPT est traité en détail dans commerce agentique : tracker les ventes ChatGPT dans GA4.
Ce que le RGPD change vraiment en Europe
Au lancement européen, le ciblage ChatGPT Ads est contextuel : sujet de la conversation, localisation approximative, appareil, heure, langue. Pas d’historique, pas de mémoire. En pratique, cela veut dire que les audiences personnalisées et les imports CRM, qui reposent sur des données inter-sessions, ne sont pas votre levier au lancement.
La conséquence est contre-intuitive mais décisive : le signal de conversion que vous renvoyez est quasiment le seul levier d’optimisation dont dispose l’algorithme. Sur Meta, un ciblage riche peut compenser un signal moyen. Ici, non. La Conversions API n’est donc pas un confort d’expert, c’est la condition de performance de vos campagnes. Une CAPI propre et bien dédupliquée pèse plus lourd sur ChatGPT Ads que sur n’importe quelle autre régie.
Consentement : aucune exemption possible
Soyons clairs sur un point souvent mal compris. Le pixel oaiq et le cookie __obref posés sur votre site servent une finalité publicitaire. En France comme dans l’UE, cela veut dire consentement obligatoire, sans exemption possible. Peu importe que ChatGPT serve des annonces contextuelles de son côté : sur votre site, vous faites du tracking publicitaire, donc vous demandez le consentement.
Le pixel OpenAI intègre nativement un contrôle de consentement. Vous initialisez à false, et vous passez à true seulement après accord :
oaiq("consent", false);
oaiq("init", { pixelId: "<VOTRE-PIXEL-ID>" });
// après consentement publicitaire de l'utilisateur :
oaiq("consent", true);
Câblez ce signal sur votre CMP, exactement comme votre ad_storage en Consent Mode. Côté serveur, appliquez la même règle : ne lisez et ne transmettez le cookie __obref que si le consentement est accordé. Pour aligner tout ça, voyez Consent Mode v2 dans GA4 et Google Ads et, pour l’échéance qui rebat les cartes, le Digital Omnibus et sa règle des 6 mois.
Vérifier et débugger
Avant de laisser tourner, deux passages obligés. En GTM web, l’option debug: true du pixel logue toute l’activité du SDK dans la console du navigateur ; c’est là que vous vérifiez que oaiq("measure", ...) part avec le bon event_id. En sGTM, le mode Preview du conteneur serveur vous montre la requête CAPI sortante et sa réponse. Envoyez d’abord vos tests avec validate_only: true dans le payload CAPI : OpenAI valide la structure sans enregistrer l’événement, parfait pour se rassurer sans polluer les données. Enfin, contrôlez la remontée dans le dashboard OpenAI, en gardant en tête qu’un délai est normal.
ChatGPT Ads : faut-il y aller maintenant ?
Encadré honnête. ChatGPT Ads en Europe, c’est neuf, contextuel, et sans exclusion de requêtes pour l’instant. Les retours du marché américain, plus mûr, pointent des CPC élevés sur les intentions à forte valeur, mais des CPM souvent plus bas que le Search classique. Autrement dit : intéressant sur des intentions de découverte et de comparaison, hasardeux si vous cherchez du volume à bas coût.
Mon avis : si vous vendez un produit ou un service que les gens comparent avant d’acheter, testez, mais seulement après avoir posé la mesure décrite ici. Sans CAPI propre et sans séparation payant/organique dans GA4, vous allez piloter à l’aveugle sur le canal où le signal de conversion est justement le nerf de la guerre. Si vous n’avez ni conteneur serveur ni plan de taggage carré, ce n’est pas prématuré d’avancer, c’est prématuré de dépenser.
La bonne nouvelle : la régie va bouger, mais le triptyque pixel, CAPI et déduplication restera la base pendant au moins un an. Posez-le proprement une fois, et vous serez prêt le jour où le libre-service ouvre vraiment les vannes.