Microsoft Ads UTM : vos canaux GA4 ont changé

Vous ouvrez votre rapport d’acquisition GA4 et, depuis le début du mois, votre Paid Search plonge pendant que du Display, du Paid Shopping et du Cross-network apparaissent de nulle part. Vous n’avez rien touché, votre budget Microsoft Ads n’a pas bougé d’un euro, et pourtant la répartition de vos canaux est méconnaissable. Bonne nouvelle tout de suite : vous n’avez pas perdu de trafic. Le 2 septembre 2026, Microsoft Ads a changé son auto-tagging UTM, et une partie de votre trafic a simplement quitté le canal Paid Search de GA4 pour rejoindre d’autres canaux. Cet article vous dit ce qui a bougé exactement, comment le confirmer dans vos propres données, et comment réparer vos groupes de canaux avant la clôture de septembre et avant le Q4.

Le symptôme, en clair

Le changement est en production depuis le 2 septembre. Concrètement, voici les cinq mouvements que vous allez lire dans vos rapports de canaux, tous datés du même jour, tous sans la moindre modification de diffusion réelle :

Votre Paid Search baisse brutalement à partir du 2 septembre. Ce n’est pas une chute de performance, c’est une partie du trafic Microsoft qui déménage.

Du Display apparaît ou gonfle : ce sont vos Audience Ads, qui étaient jusqu’ici comptés en Paid Search.

Du Paid Shopping se met à exister alors que vous n’avez rien changé à vos campagnes Shopping Microsoft.

Du Paid Video peut apparaître si vous diffusez des campagnes vidéo Microsoft.

Du Cross-network surgit, parfois accompagné d’une hausse du trafic non assigné (« Default/Unknown ») : c’est votre Performance Max Microsoft.

Si vous cherchiez « pourquoi mon Paid Search baisse depuis septembre 2026 » ou « d’où sort ce trafic Display », vous êtes au bon endroit. Rien de cassé, une bascule de tagging. Voyons ce qui s’est passé sous le capot.

Ce que Microsoft Ads a changé dans son auto-tagging UTM le 2 septembre

Avant tout, levons le malentendu numéro un du sujet. Chez Google Ads, « auto-tagging » désigne le paramètre gclid, pas les UTM. Ici, Microsoft parle bien d’UTM générés automatiquement : les fameux utm_source, utm_medium et compagnie ajoutés à vos URLs de destination. Ne cherchez donc pas un équivalent gclid cassé, ce n’est pas de ça qu’il s’agit.

Jusqu’au 2 septembre, Microsoft appliquait un tagging universel : toutes les campagnes, quel que soit leur format, arrivaient dans GA4 avec la même signature bing / cpc. Résultat, vos Audience Ads (du display facturé au CPM), vos Shopping Ads et votre Performance Max étaient tous noyés dans le même canal Paid Search que vos campagnes Search classiques. Une moyenne de tout ça ne décrivait honnêtement aucun format.

Depuis le 2 septembre, l’auto-tagging est devenu format-aware : chaque type de campagne porte sa propre combinaison de utm_source, utm_medium et suffixe de campagne, ce qui permet à GA4 de router le trafic dans des canaux distincts. Voici le tableau de correspondance officiel, à lire comme votre grille de décodage :

Format de campagne	`utm_source`	`utm_medium`	Suffixe de campagne	Canal GA4
Search	`bing`	`cpc`	(aucun)	Paid Search
Audience Ads	`msads`	`cpm`	(aucun)	Display
Shopping Ads	`msads`	`cpc`	`shopping`	Paid Shopping
Video	`bing_video`	`cpc`	(aucun)	Paid Video
Performance Max	`msads`	`crossnetwork`	`cross-network`	Cross-network (ou Default/Unknown)

Source : communication e-mail de Microsoft Advertising aux annonceurs du 5 juin 2026, relayée par la presse spécialisée (PPC Land, Search Engine Roundtable). À la date de rédaction, ce mapping n’était pas publié dans une page d’aide indexée : traitez-le comme une annonce officielle, pas comme de la documentation produit gravée dans le marbre. La date d’effet annoncée est le 2 septembre 2026 ; si votre bascule tombe un jour ou deux à côté, ce n’est pas anormal, les déploiements glissent parfois d’un compte à l’autre.

Confirmer la bascule dans vos propres données

La règle chez moi, c’est de ne jamais croire un tableau sur parole quand on peut le vérifier sur son propre compte. Si vous avez l’export GA4 vers BigQuery activé, la requête ci-dessous compte vos sessions Microsoft par utm_source / utm_medium et par jour, autour du 2 septembre. La bascule saute aux yeux : avant, presque tout en bing / cpc ; après, une ventilation sur msads, bing_video et crossnetwork.

SELECT
  event_date,
  collected_traffic_source.manual_source AS utm_source,
  collected_traffic_source.manual_medium AS utm_medium,
  COUNT(DISTINCT CONCAT(
    user_pseudo_id,
    CAST((SELECT value.int_value FROM UNNEST(event_params)
          WHERE key = 'ga_session_id') AS STRING)
  )) AS sessions
FROM `votre_projet.analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260826' AND '20260909'
  AND collected_traffic_source.manual_source IN ('bing', 'msads', 'bing_video')
GROUP BY event_date, utm_source, utm_medium
ORDER BY event_date, sessions DESC;

Le champ collected_traffic_source capture la source de trafic manuelle (vos UTM) au niveau de l’événement, exactement ce qui change ici. Remplacez votre_projet.analytics_XXXXXX par votre dataset et adaptez la fenêtre de dates. Si l’export BigQuery n’est pas encore activé chez vous, c’est le moment : notre guide pratique de l’export GA4 vers BigQuery explique comment le brancher, et vous trouverez d’autres briques réutilisables dans notre sélection des requêtes BigQuery indispensables pour analyser GA4.

Pas d’export ? La version interface fonctionne aussi, en moins granulaire. Dans Explorer, montez un tableau libre avec Source de session et Medium de session en lignes, la métrique Sessions, et une plage qui enjambe le 2 septembre. Vous verrez apparaître les lignes msads / cpm, msads / cpc et msads / crossnetwork là où il n’y avait que bing / cpc. C’est la même histoire, racontée par le front.

Piège n°1 : vos groupes de canaux personnalisés

C’est le piège le plus courant, et le plus silencieux. Si vous avez un groupe de canaux personnalisé avec une règle du type « source contient bing et medium = cpc alors Microsoft Ads », cette règle ne capte plus que vos campagnes Search depuis le 2 septembre. Vos Audience Ads (msads / cpm), Shopping (msads / cpc), Video (bing_video) et Performance Max (msads / crossnetwork) sortent purement et simplement du groupe.

La correction est mécanique mais indispensable : relisez chaque règle qui mentionne bing, et élargissez-la pour couvrir msads et bing_video. Si vous voulez un canal « Microsoft Ads » propre, une condition « source contient bing OU source = msads OU source = bing_video » regroupe désormais toute la régie. Ce type de relecture des groupes de canaux fait d’ailleurs partie des points que je vérifie systématiquement dans un audit GA4.

Piège n°2 : Performance Max en « Default/Unknown »

Regardez la dernière ligne du tableau : Performance Max atterrit dans Cross-network ou dans Default/Unknown. La bascule dépend d’un détail : GA4 ne classe un trafic en Cross-network que si le nom de campagne contient cross-network. Sur les groupes de canaux par défaut, c’est géré. Sur un groupe de canaux personnalisé qui ne définit pas explicitement Cross-network, le trafic Performance Max Microsoft n’a nulle part où aller et tombe en non assigné.

Le symptôme, c’est une hausse du trafic « unassigned » calée sur le 2 septembre. La cause, c’est une définition de canal manquante. Le correctif, c’est d’ajouter une règle Cross-network à votre groupe personnalisé (medium = crossnetwork ou nom de campagne contenant cross-network). Si vous voulez creuser la mécanique du trafic non assigné, elle est détaillée dans notre diagnostic des données manquantes dans GA4 : ici, on a le cas d’école « ni bug ni tag cassé, juste un changement de plateforme ».

Piège n°3 : le suffixe de campagne et votre `utm_campaign`

Le shopping de la ligne Shopping Ads, et le cross-network de la ligne Performance Max, sont des suffixes ajoutés au niveau campagne par la plateforme, pas votre utm_campaign à vous. C’est ce suffixe qui déclenche le classement en Paid Shopping et en Cross-network côté GA4, via les règles qui lisent le nom de campagne.

Si vous utilisez des modèles de suivi d’URL maison qui composent déjà votre utm_campaign, vérifiez comment votre valeur et le suffixe Microsoft cohabitent. Dans le pire des cas, vous vous retrouvez avec des noms de campagne dédoublés dans vos rapports, la moitié avec suffixe, l’autre sans. Rien de dramatique, mais autant le voir avant de bâtir un rapport dessus.

Piège n°4 : Microsoft PMax et Google PMax dans le même canal

Le choix de crossnetwork n’est pas un hasard : c’est exactement le medium que Google Ads utilise pour son propre Performance Max. Microsoft s’aligne volontairement sur la convention Google pour que les définitions de canaux de GA4, pensées pour les campagnes Google, classent aussi son PMax. Conséquence directe : après le 2 septembre, votre canal Cross-network mélange le PMax de deux régies.

Pour une lecture « automatisé contre manuel », c’est plutôt une bonne chose. Pour une lecture « performance par régie », c’est trompeur, parce que le canal seul ne vous dit plus qui est qui. La parade est simple : redescendez d’un cran sur la dimension Source (msads pour Microsoft, google pour Google) pour re-séparer les deux au sein du Cross-network. C’est typiquement là que la dimension Source Group de GA4 aide à garder une lecture propre par plateforme sans additionner les variantes à la main.

Le point à ne pas rater : vos imports de coûts

Voici celui qui fait le plus de dégâts et dont personne ne parle. Si vous importez vos coûts Microsoft Ads dans GA4, la jointure se fait sur source / medium. Vos données de coût étaient mappées sur bing / cpc. Depuis le 2 septembre, une grosse partie de vos clics arrive en msads / cpm, msads / cpc ou msads / crossnetwork : le match rate de votre import s’effondre, et vos ROAS par canal se retrouvent faussés dans le mauvais sens, sans erreur visible.

Si vous avez un import de coûts actif, c’est votre priorité numéro un : mettez à jour le mapping source/medium de l’import pour couvrir les nouvelles valeurs. La mécanique de ces imports et leurs pièges de correspondance sont détaillés dans notre article sur l’import des données de campagne dans GA4. Ne remettez pas cette vérification à la clôture, elle contamine directement vos calculs de rentabilité.

Ce qui n’a pas bougé : l’UET

Détail crucial pour la réunion de fin de mois : l’Universal Event Tracking (UET), le tracking de conversion natif de Microsoft, n’est pas concerné par ce changement. L’interface Microsoft Ads affiche donc exactement les mêmes chiffres qu’avant, pendant que GA4 a redistribué son trafic. Autrement dit, l’écart entre ce que raconte Microsoft Ads et ce que raconte GA4 va s’ouvrir, alors que côté Microsoft rien n’a bougé.

Anticipez la phrase « les chiffres ne se réconcilient plus » : ils ne se réconciliaient déjà pas parfaitement, mais là l’écart a une explication précise et datée. Si vous voulez une réconciliation plus robuste entre Microsoft Ads et GA4, elle passe par le server-side et l’API de conversions, sujet que je traite dans le guide Microsoft Ads Conversions API en server-side GTM.

La remédiation, en 6 points

Voici la checklist que je déroulerais sur un compte concerné, dans l’ordre :

Annotez le 2 septembre 2026 dans GA4 (et dans vos outils de BI) comme rupture de série. C’est le geste qui vous évitera de mal lire toutes vos comparaisons période sur période.
Relisez vos groupes de canaux personnalisés et élargissez les règles bing à msads et bing_video (piège n°1), en ajoutant une règle Cross-network (piège n°2).
Mettez à jour votre import de coûts Microsoft pour les nouvelles valeurs source/medium (le point à ne pas rater). Vérifiez le match rate après coup.
Corrigez vos définitions Looker Studio / BI : champs calculés, filtres de dashboards et regroupements qui reposaient sur bing / cpc. Si vos rapports sont automatisés, notre guide pour automatiser son reporting avec Looker Studio et BigQuery vous montrera où sont les champs à toucher.
Prévenez les équipes média avant la clôture et documentez la rupture pour les comparaisons N-1. Un modèle de budget cross-canal construit sur l’ancienne répartition intègre un input faussé : notre article sur la budgétisation cross-canal dans GA4 explique pourquoi.
Rejouez la requête de contrôle une semaine plus tard pour confirmer que la ventilation s’est stabilisée et qu’aucun résidu n’est reparti en non assigné.

Un mot sur le calendrier : cette rupture tombe pile avant le pic de fin d’année, la période la plus scrutée pour les comparaisons N-1. Si vous préparez le Black Friday, corrigez tout ça maintenant, sinon vos benchmarks de saison seront inexploitables. C’est exactement le genre de vérification à cocher dans notre checklist tracking Black Friday 2026.

Ce que la mise à jour corrige vraiment

Soyons honnêtes jusqu’au bout : sur le fond, ce changement est une bonne nouvelle. Mélanger du CPM display et du CPC search sous un même canal Paid Search produisait des moyennes qui ne décrivaient ni l’un ni l’autre. Séparer Audience, Shopping, Video et Performance Max était une vraie amélioration de mesure, attendue depuis longtemps. Le correctif est bon.

Le reproche légitime est ailleurs, et il tient en trois points : aucune rétroactivité (votre historique reste tagué à l’ancienne, la rupture est nette au 2 septembre), aucune annotation automatique dans GA4, et un e-mail « aucune action requise » qui sous-estime franchement l’impact analytics. C’est vrai côté diffusion Microsoft, c’est faux côté reporting. Une rupture de série de mesure devrait être documentée par la plateforme, pas découverte par l’annonceur au moment de sa clôture.

Et c’est la vraie leçon, celle qui reste utile bien après ce cas précis : n’importe quelle plateforme peut changer son tagging du jour au lendemain sans que vos chiffres de diffusion ne bougent. Le réflexe à garder est toujours le même. Une discontinuité datée dans vos canaux, sans changement côté campagne, cherchez d’abord un changement de tagging, confirmez-le sur vos données brutes, annotez, puis réparez vos classifications. Microsoft a documenté le mapping pour GA4 ; pour Adobe Analytics ou un outil maison, c’est à vous de vérifier vos règles de classification. Le rappel de méthode, lui, ne périme pas. Cette bascule Microsoft n’est d’ailleurs que la deuxième rupture de canaux en six mois côté GA4, après le changement d’attribution GA4 de 2026 : raison de plus pour prendre la traçabilité de vos ruptures de mesure au sérieux.