Microsoft Ads UTM Change: Your GA4 Channels Shifted Sept 2

You open your GA4 acquisition report and, since the start of the month, your Paid Search is diving while Display, Paid Shopping and Cross-network appear out of nowhere. You changed nothing, your Microsoft Ads budget has not moved a dollar, yet your channel mix is unrecognizable. Here is the good news up front: you did not lose any traffic. On September 2, 2026, Microsoft Ads changed its UTM auto-tagging, and part of your traffic simply left the GA4 Paid Search channel to land in other channels. This article tells you exactly what moved, how to confirm it in your own data, and how to repair your channel groups before month-end close and before Q4.

The symptom, in plain terms

The change has been live since September 2. Concretely, here are the five moves you will read in your channel reports, all dated the same day, all without any change in actual ad delivery:

Your Paid Search drops sharply from September 2. That is not a performance collapse, it is part of your Microsoft traffic relocating.

Display appears or swells: those are your Audience Ads, which used to be counted as Paid Search.

Paid Shopping starts to exist even though you changed nothing about your Microsoft Shopping campaigns.

Paid Video may show up if you run Microsoft video campaigns.

Cross-network surfaces, sometimes with a rise in unassigned traffic (“Default/Unknown”): that is your Microsoft Performance Max.

If you searched for “why is my Paid Search dropping since September 2026” or “where is this Display traffic coming from,” you are in the right place. Nothing is broken, it is a tagging switch. Let us look under the hood.

What Microsoft Ads changed in its UTM auto-tagging on September 2

First, let us clear up the number-one confusion on this topic. In Google Ads, “auto-tagging” refers to the gclid parameter, not UTMs. Here, Microsoft is talking about automatically generated UTMs: the familiar utm_source, utm_medium and friends appended to your landing page URLs. So do not go hunting for a broken gclid equivalent, that is not what this is about.

Until September 2, Microsoft applied universal tagging: every campaign, whatever its format, arrived in GA4 with the same bing / cpc signature. As a result, your Audience Ads (display billed on a CPM basis), your Shopping Ads and your Performance Max were all buried in the same Paid Search channel as your classic Search campaigns. An average of all that honestly described none of the formats.

Since September 2, auto-tagging has become format-aware: each campaign type carries its own combination of utm_source, utm_medium and campaign suffix, which lets GA4 route the traffic into distinct channels. Here is the official mapping table, to be read as your decoder grid:

Source: Microsoft Advertising’s email to advertisers on June 5, 2026, relayed by the trade press (PPC Land, Search Engine Roundtable). At the time of writing, this mapping was not published in an indexed help page: treat it as an official announcement, not as product documentation set in stone. The announced effective date is September 2, 2026; if your switch lands a day or two off, that is not abnormal, rollouts sometimes drift from one account to another.

Confirm the switch in your own data

My rule is never to take a table on faith when I can verify it on my own account. If you have the GA4 export to BigQuery enabled, the query below counts your Microsoft sessions by utm_source / utm_medium and by day, around September 2. The switch is obvious: before, almost everything in bing / cpc; after, a spread across msads, bing_video and 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 `your_project.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;

The collected_traffic_source field captures the manual traffic source (your UTMs) at the event level, exactly what changes here. Replace your_project.analytics_XXXXXX with your dataset and adjust the date window. If the BigQuery export is not enabled yet on your side, now is the time: our practical guide to the GA4 to BigQuery export explains how to wire it up, and you will find other reusable building blocks in our roundup of essential BigQuery queries for GA4.

No export? The interface version works too, just less granular. In Explore, build a free-form table with Session source and Session medium as rows, the Sessions metric, and a range straddling September 2. You will see msads / cpm, msads / cpc and msads / crossnetwork rows appear where there was only bing / cpc. Same story, told by the front end.

Trap #1: your custom channel groups

This is the most common trap, and the quietest. If you have a custom channel group with a rule like “source contains bing and medium = cpc then Microsoft Ads,” that rule now captures only your Search campaigns since September 2. Your Audience Ads (msads / cpm), Shopping (msads / cpc), Video (bing_video) and Performance Max (msads / crossnetwork) drop straight out of the group.

The fix is mechanical but essential: review every rule that mentions bing, and widen it to cover msads and bing_video. If you want a clean “Microsoft Ads” channel, a condition “source contains bing OR source = msads OR source = bing_video” now captures the whole platform. This kind of channel-group review is one of the items I systematically check in a GA4 audit.

Trap #2: Performance Max in “Default/Unknown”

Look at the last row of the table: Performance Max lands in Cross-network or in Default/Unknown. The switch hinges on one detail: GA4 only classifies traffic as Cross-network if the campaign name contains cross-network. On the default channel groups, that is handled. On a custom channel group that does not explicitly define Cross-network, Microsoft Performance Max traffic has nowhere to go and falls into unassigned.

The symptom is a rise in “unassigned” traffic pinned to September 2. The cause is a missing channel definition. The fix is to add a Cross-network rule to your custom group (medium = crossnetwork, or campaign name containing cross-network). If you want to dig into the mechanics of unassigned traffic, they are laid out in our GA4 missing data diagnosis: here you have the textbook case of “no bug, no broken tag, just a platform change.”

Trap #3: the campaign suffix and your utm_campaign

The shopping in the Shopping Ads row, and the cross-network in the Performance Max row, are suffixes appended at the campaign level by the platform, not your own utm_campaign. It is that suffix which triggers the Paid Shopping and Cross-network classification in GA4, through the rules that read the campaign name.

If you use homegrown URL tracking templates that already compose your utm_campaign, check how your value and Microsoft’s suffix coexist. In the worst case, you end up with duplicated campaign names in your reports, half with the suffix, half without. Nothing dramatic, but better to catch it before you build a report on top of it.

Trap #4: Microsoft PMax and Google PMax in the same channel

The choice of crossnetwork is no accident: it is exactly the medium Google Ads uses for its own Performance Max. Microsoft deliberately aligns with the Google convention so that GA4’s channel definitions, designed for Google campaigns, also classify its PMax. Direct consequence: after September 2, your Cross-network channel blends the PMax of two platforms.

For an “automated versus manual” reading, that is rather a good thing. For a “performance by platform” reading, it is misleading, because the channel alone no longer tells you who is who. The workaround is simple: drop one level down to the Source dimension (msads for Microsoft, google for Google) to re-separate the two within Cross-network. This is exactly where the GA4 Source Group dimension helps you keep a clean per-platform reading without summing variants by hand.

The one not to miss: your cost imports

Here is the one that does the most damage and that nobody talks about. If you import your Microsoft Ads cost into GA4, the join is on source / medium. Your cost data was mapped to bing / cpc. Since September 2, a large share of your clicks arrives as msads / cpm, msads / cpc or msads / crossnetwork: the match rate of your import collapses, and your per-channel ROAS ends up skewed the wrong way, with no visible error.

If you have an active cost import, this is your number-one priority: update the import’s source/medium mapping to cover the new values. The mechanics of these imports and their matching traps are detailed in our article on GA4 campaign data import. Do not push this check to close, it directly contaminates your profitability math.

What did not change: UET

A crucial detail for the end-of-month meeting: Universal Event Tracking (UET), Microsoft’s native conversion tracking, is not affected by this change. So the Microsoft Ads interface shows exactly the same numbers as before, while GA4 has redistributed its traffic. In other words, the gap between what Microsoft Ads says and what GA4 says will widen, even though nothing moved on the Microsoft side.

Anticipate the “the numbers no longer reconcile” line: they were not reconciling perfectly before either, but now the gap has a precise, dated explanation. If you want a more robust reconciliation between Microsoft Ads and GA4, it runs through server-side and the conversions API, a topic I cover in the guide on Microsoft Ads Conversions API with server-side GTM.

Remediation, in 6 steps

Here is the checklist I would run on an affected account, in order:

1. Annotate September 2, 2026 in GA4 (and in your BI tools) as a series break. That is the move that keeps you from misreading every period-over-period comparison.
2. Review your custom channel groups and widen bing rules to msads and bing_video (trap #1), adding a Cross-network rule (trap #2).
3. Update your Microsoft cost import for the new source/medium values (the one not to miss). Check the match rate afterward.
4. Fix your Looker Studio / BI definitions: calculated fields, dashboard filters and groupings that relied on bing / cpc. If your reports are automated, our guide on automating reporting with Looker Studio and BigQuery will show you where the fields to touch are.
5. Warn the media teams before close and document the break for year-over-year comparisons. A cross-channel budget model built on the old split feeds on a skewed input: our article on cross-channel budgeting in GA4 explains why.
6. Re-run the control query a week later to confirm the split has stabilized and no residue has drifted back into unassigned.

A word on timing: this break falls right before the year-end peak, the most scrutinized period for year-over-year comparisons. If you are prepping Black Friday, fix all of this now, otherwise your seasonal benchmarks will be unusable. It is exactly the kind of check to tick off in our Black Friday 2026 tracking checklist.

What the update actually fixes

Let us be honest all the way through: on the substance, this change is good news. Mixing CPM display and CPC search under a single Paid Search channel produced averages that described neither. Separating Audience, Shopping, Video and Performance Max was a real measurement improvement, long overdue. The fix is good.

The legitimate criticism is elsewhere, and it comes down to three points: no retroactivity (your history stays tagged the old way, the break is sharp at September 2), no automatic annotation in GA4, and a “no action required” email that plainly understates the analytics impact. It is true on Microsoft’s delivery side, it is false on the reporting side. A measurement series break should be documented by the platform, not discovered by the advertiser at close.

And that is the real lesson, the one that stays useful well beyond this specific case: any platform can change its tagging overnight without your delivery numbers moving at all. The reflex to keep is always the same. A dated discontinuity in your channels, with no change on the campaign side, look first for a tagging change, confirm it on your raw data, annotate, then repair your classifications. Microsoft documented the mapping for GA4; for Adobe Analytics or a homegrown tool, it is on you to check your classification rules. The method itself does not expire. This Microsoft switch is, after all, only the second channel break in six months on the GA4 side, after the 2026 GA4 attribution change: all the more reason to take the traceability of your measurement breaks seriously.