La documentation de la Microsoft Ads Conversions API fait une quarantaine d’écrans, et 90 % ne servent qu’à décrire des cas limites. Voici les six champs qui décident vraiment si vos conversions remontent, plus le piège que tout le monde va se prendre en server-side. Depuis le 18 août 2026, Microsoft Advertising a enfin publié la doc complète de sa Conversions API (CAPI) : schémas d’événements, authentification, gestion d’erreurs. C’est le dernier grand canal payant à passer en server-to-server, et pour l’instant les seuls contenus disponibles sont des pages produit d’éditeurs. Ce guide donne le chemin complet en server-side GTM, et il tranche l’erreur d’architecture que le réflexe sGTM vous pousse à commettre.
Avertissement utile avant de commencer : la CAPI de Microsoft est en bêta sur invitation, provisionnée compte par compte via votre account manager. La doc bouge encore. Traitez ce guide comme une base solide, pas comme une gravure dans le marbre, et vérifiez le statut de vos champs au moment où vous branchez.
Ce que Microsoft a publié le 18 août 2026
Concrètement, Microsoft ouvre le même modèle que Meta ou LinkedIn avant lui : un endpoint server-to-server qui reçoit vos événements de conversion en complément du tag navigateur. La nouveauté, c’est la documentation officielle. On connaît désormais le schéma exact du payload, le mode d’authentification par token, les codes de retour et les règles de batch.
Ce qui reste en bêta : l’accès (il faut être provisionné), et quelques champs dont le comportement peut évoluer. Ce qui est déjà stable et exploitable : l’endpoint, la structure des événements, la déduplication avec UET, et la gestion de l’attribution via msclkid. C’est largement suffisant pour monter un setup propre dès maintenant si votre compte est éligible.
Pourquoi s’y intéresser tout de suite ? Parce que Microsoft Advertising est le canal B2B qui monte, notamment avec les placements publicitaires dans les réponses génératives de Copilot. Or c’est précisément là que la mesure browser-only est la plus faible. Si vous cherchez à cadrer ce trafic issu des assistants, le sujet croise directement celui du suivi du trafic IA dans GA4.
CAPI ne remplace pas UET, il le double
Premier réflexe à corriger : la Conversions API n’est pas un remplaçant du tag UET, c’est un complément serveur. L’architecture recommandée par Microsoft, et la seule qui tienne la route, garde le UET côté client dans le navigateur et ajoute la CAPI côté serveur depuis votre conteneur sGTM. Les deux décrivent le même événement, Microsoft les reçoit en double, puis les réconcilie.
Le principe est identique à ce que vous connaissez déjà si vous avez branché Meta CAPI et sa déduplication ou LinkedIn Conversions API. Un signal navigateur pour la couverture et le remarketing, un signal serveur pour la robustesse face aux bloqueurs et aux refus de consentement. Enlever l’un des deux dégrade l’ensemble.
| Brique | Où elle s’exécute | Rôle |
|---|---|---|
| UET tag | Navigateur (web GTM) | Capte l’événement client, gère l’ID Sync et le remarketing |
| Conversions API | Serveur (sGTM) | Rejoue le même événement, enrichi des données first-party |
| Déduplication | Côté Microsoft | Fusionne les deux sources via eventId et même tagId |
| Attribution | Côté Microsoft | Rattache la conversion au clic via msclkid |
Les prérequis
Trois choses avant d’écrire la moindre ligne de configuration. Un, un compte provisionné pour la bêta CAPI (sans ça, l’endpoint vous répondra 401). Deux, votre UET tag ID, le même identifiant numérique que celui déjà posé dans votre conteneur web. Trois, un token d’autorisation.
Le token se génère dans l’interface Microsoft Advertising : UET, puis Set up tagging, puis Use Conversions API, puis Copy Token. Pour ceux qui automatisent, il existe aussi l’appel POST /CampaignManagement/v13/UetTagAuthKey/Query. Ce token part dans le header Authorization: Bearer <ApiToken> de chaque requête. Traitez-le comme un secret : il vit côté serveur, jamais dans le navigateur.
Et bien sûr, il vous faut un vrai conteneur server-side hébergé. Si vous n’avez pas encore franchi le pas, commencez par le guide pour migrer vers le GTM server-side.
Le setup sGTM
Deux voies. La plus rapide : le template Stape « Microsoft Ads UET Conversion API », qui encapsule l’appel et vous laisse mapper les champs dans l’interface GTM. La plus contrôlée : un tag HTTP direct qui envoie le payload à la main.
L’endpoint est le suivant :
POST https://capi.uet.microsoft.com/v1/{tagId}/events
Authorization: Bearer <ApiToken>
Content-Type: application/json
Le payload s’organise en trois niveaux. Au niveau requête, vous avez data (le tableau d’événements), continueOnValidationError et dataProvider. Au niveau événement, les champs qui comptent : eventType, eventTime, eventId, eventName, eventSourceUrl, adStorageConsent. Il existe deux eventType, pageLoad et custom, reliés entre eux par un pageLoadId. Puis viennent userData (données de matching) et customData (valeur monétaire et détails de transaction).
Côté batch, Microsoft accepte jusqu’à 1 000 événements par requête, mais préfère le temps réel. Les réponses à connaître : 200 quand tout passe, 400 sur une erreur de validation, 401 quand le token ou le provisioning coince.
La déduplication, le réglage à ne pas rater
C’est le même piège que sur toutes les CAPI : si la dédup est mal réglée, Microsoft compte vos conversions en double ou en rejette une partie. La règle est simple. Le tag UET navigateur et l’appel CAPI serveur doivent envoyer le même eventId, le même eventName, et pointer vers le même tagId. Ces trois conditions réunies, Microsoft comprend qu’il s’agit d’une seule conversion et fusionne les sources.
En pratique, générez l’eventId une seule fois côté navigateur (par exemple un UUID posé au moment de l’événement), poussez-le dans le dataLayer, puis transmettez-le au conteneur serveur pour qu’il rejoue exactement la même valeur. La faute classique : laisser le serveur régénérer son propre identifiant. Deux identifiants différents, et la fusion n’a jamais lieu.
L’attribution : capturer et rejouer le msclkid
Le msclkid est à Microsoft ce que le gclid est à Google : l’identifiant de clic qui rattache la conversion à la campagne. Sa fenêtre de rétention est de 90 jours. Votre job consiste à le capturer à l’arrivée sur le site (il arrive en paramètre d’URL), à le stocker, puis à le rejouer dans le userData de chaque événement CAPI.
Sans msclkid, Microsoft se rabat sur un matching probabiliste à partir des autres signaux (em pour l’email haché, ph pour le téléphone, clientIpAddress, clientUserAgent). Ça fonctionne, mais l’attribution est nettement plus faible. Rejouer le msclkid est le geste qui rapporte le plus pour l’effort le plus faible.
Le piège : l’ID Sync reste client-side
Voici la partie que personne n’a encore écrite, et l’erreur que le réflexe sGTM va vous faire commettre. En server-side, on a tendance à vouloir tout basculer côté serveur. Avec Microsoft, c’est une faute. L’ID Sync doit rester dans le navigateur.
L’ID Sync, c’est l’appel client à c.bing.com/c.gif qui pose et synchronise les identifiants publicitaires : Red3 vaut BACID_<CID>, VID correspond à l’anonymousId, UID est optionnel. Cet appel alimente le remarketing dynamique de Microsoft. Si vous passez tout côté serveur et que vous coupez l’ID Sync navigateur, vous perdez la capacité à recibler, et votre matching se dégrade.
Le point le plus facile à rater, et le plus coûteux : le VID de l’ID Sync doit correspondre à l’anonymousId que vous envoyez en CAPI. Si les deux valeurs divergent, Microsoft ne rattache pas l’utilisateur serveur à son profil navigateur, et vous cumulez les deux problèmes, remarketing cassé et matching amputé. Retenez la règle : UET et ID Sync côté client, CAPI côté serveur, et un anonymousId unique partagé entre les deux.
Consentement et Consent Mode v2
Chaque événement CAPI porte un champ adStorageConsent, qui reflète l’état du consentement publicitaire de l’utilisateur. Il s’articule directement avec votre implémentation de Consent Mode. Si vous avez déjà câblé les signaux de consentement pour Google, la logique se transpose : l’état accordé ou refusé du stockage publicitaire doit remonter dans adStorageConsent. Pour la mécanique complète des signaux, voyez le guide Consent Mode v2 pour GA4 et Google Ads.
Ne codez pas cet état en dur. Un adStorageConsent toujours à « accordé » vous expose sur le plan réglementaire et fausse la lecture de Microsoft. Reliez-le à votre CMP.
Checklist de validation
Avant de considérer votre setup comme fonctionnel, vérifiez dans l’ordre : le compte est provisionné et l’endpoint répond 200 ; le token part bien en header serveur et jamais dans le navigateur ; l’eventId, l’eventName et le tagId sont identiques entre UET et CAPI ; le msclkid est capturé et rejoué ; l’ID Sync tourne toujours côté client ; le VID de l’ID Sync égale l’anonymousId envoyé en CAPI ; l’adStorageConsent est branché sur votre CMP.
Faut-il y aller maintenant ?
| Situation | Verdict |
|---|---|
| Compte provisionné, budget Microsoft significatif, sGTM déjà en place | Oui, foncez : la fenêtre concurrentielle est ouverte |
| Fort trafic B2B, forte exposition aux refus de consentement | Oui : c’est là que le gain serveur est le plus net |
| Pas encore provisionné pour la bêta | Demandez l’accès à votre account manager, préparez le conteneur en attendant |
| Pas de conteneur server-side du tout | Commencez par le sGTM, la CAPI viendra ensuite |
| Budget Microsoft marginal | Attendez la sortie de bêta, le jeu n’en vaut pas la chandelle |
La CAPI Microsoft est encore jeune et mouvante, mais l’ossature est là et le terrain est vide. Un setup propre aujourd’hui, c’est-à-dire UET client plus CAPI serveur, dédup par eventId, msclkid rejoué et ID Sync laissé côté navigateur, vous met en avance sur un canal que la plupart de vos concurrents mesurent encore au navigateur seul. Si votre compte est éligible, c’est le moment de câbler.