Microsoft Advertising's Conversions API: What It Is, Who Can Get It, and What Breaks First

For years the answer to "why am I still tracking Microsoft Ads with just a UET tag?" was simply that there was nothing else. That changed quietly in August 2026, when Microsoft Advertising published full documentation for a Conversions API. If you run Microsoft alongside Meta and Google, this is the platform catching up to where the others have been for a while. It is also, for most advertisers reading this today, not yet something you can turn on.

What was actually announced

Microsoft published complete Conversions API documentation on 18 August 2026, covering event schemas, authentication and error handling. The reference material carries a slightly earlier last-updated date, which tells you the work had been going on for a while before it became public.

The product itself is described as a pilot. Microsoft provisions it per account, advertisers cannot enable it themselves, and there is no published general availability date. That last detail matters for planning: there is no announced timeline to wait for, so treating this as a Q4 project would be a mistake. If somebody tells you they are rolling it out for you next week, the reasonable question is which specific account got approved.

What it does, once you have it, is the same thing every other Conversions API does. It accepts conversion and customer interaction data sent directly from your systems rather than from a browser: website events, CRM events, offline sales, and mobile events through a single connection.

Why a server-side API matters at all

A UET tag is a browser tag, and browser tags lose data in four ways that have nothing to do with how well you installed them. Ad blockers prevent them loading. Tracking prevention shortens the life of the cookies they set. Consent tools withhold them until a visitor actively agrees. And conversions that happen away from the website, on a phone call or an invoice weeks later, were never visible to a browser in the first place.

Sending events from your server sidesteps all four. Your database knows a sale happened regardless of what the visitor's browser did, and it knows about the sale that closed on a call. This is the same argument that made Meta's Conversions API standard practice, laid out in more depth in server-side versus browser-side tracking.

Be realistic about the size of the prize

Here is the part that vendors selling you an implementation will skip. The benefit of a Conversions API is proportional to how much data the browser was losing, and Microsoft's audience loses less than Meta's.

Microsoft Advertising skews older, more desktop, and heavily toward work machines, because a large share of its inventory is Bing search on corporate Windows devices where the default browser was never changed. That population runs fewer ad blockers than a young mobile-first Meta audience, and desktop Edge and Chrome apply less aggressive tracking prevention than Safari on an iPhone. The cookie-loss problem that makes server-side tracking transformative on Meta is genuinely smaller here.

The gain is real. It is not the same gain. Expect a lift in matched conversions rather than a step change, and be suspicious of anyone promising Meta-sized improvements on a Microsoft account.

There is one exception worth naming. If your Microsoft conversions include offline outcomes, long B2B sales cycles, or phone-driven business, the value is much higher, because those conversions were never available to a browser tag at any consent rate. For those accounts this is the difference between measuring form fills and measuring revenue.

The deduplication trap, which is the real risk

Every advertiser who adds a server-side API alongside an existing browser tag meets the same problem, and it has sunk more accounts than any configuration error. Once both the UET tag and the Conversions API report the same conversion, the platform needs a way to recognise them as one event rather than two.

Get that wrong and every conversion counts twice. Your conversion volume doubles overnight. Your cost per acquisition halves. The dashboard shows the best month the account has ever had, and there is nothing wrong with the ads at all. Bidding then optimises against a number that is systematically twice reality, and because the error is proportional it looks perfectly stable, which is exactly why nobody catches it.

Meta advertisers learned this the hard way over about two years. Google advertisers learned it after them. Microsoft advertisers are next in the queue, and the pattern is documented in detail in how to fix duplicate events between pixel and CAPI, which is worth reading before you implement rather than after.

The principle is platform-agnostic even though the field names are not: both copies of the same conversion need to carry a shared, stable identifier that is unique to that transaction, generated once and passed to both the browser tag and the server call. An order ID works well because it is naturally unique and already exists. A timestamp does not, because two people can buy in the same second. Check Microsoft's own documentation for the exact field, since that is the detail most likely to change while the product is in pilot.

What to prepare while you wait

You cannot enable this yet, but almost all of the work that makes it valuable can be done now, and none of it is wasted if your pilot access never arrives.

1. Capture and store click identifiers. Microsoft appends its own click ID to ad traffic. Read it from the landing page URL on arrival and store it against the lead or order in your database, not only in a browser cookie. An identifier you did not capture is unrecoverable later, and every week without this is permanently weaker data. This is the same discipline described in the fbc click ID guide, applied to a different platform.
2. Decide where your conversions live.Server-side tracking sends events from a system you control, which means you need to know which system is the authority on "a sale happened". For most businesses that is the ecommerce platform or the CRM, not the website.
3. Generate a unique transaction identifier today. If your checkout or form does not already produce one and expose it to both the browser and the server, add it now. It costs nothing, it is useful immediately for reconciliation, and it is the thing dedup will depend on later.
4. Write down your current baseline. Record what Microsoft reports for a normal month against what your backend actually recorded. Without that number you will have no way to tell whether the API improved your measurement or simply started double counting it.

Is your UET setup even the bottleneck?

Before you queue up for pilot access, it is worth establishing whether browser-side data loss is actually what is limiting your Microsoft performance. On plenty of accounts it is not, and a Conversions API will not fix the thing that is.

Three checks, in order of how often they turn something up:

• Is the conversion you optimise toward the right one? A surprising number of accounts are bidding against a pageview, a button click or a scroll event created years ago to get bidding started. No amount of server-side delivery improves a conversion definition that never described a customer. If your reported conversions massively exceed the real outcomes in your CRM, this is your problem and it is free to fix.
• Does your reported volume roughly track your real volume? Compare a month of Microsoft-reported conversions against orders or qualified leads your systems actually recorded from that channel. If the ratio is stable and sensible, your browser tracking is doing its job and the API will be an incremental improvement rather than a rescue.
• How much of your business closes away from the website? This is the question that decides whether the API is worth real effort. If everything converts on-site in one session, a browser tag already sees nearly all of it. If a meaningful share of revenue closes on a call, a quote or an invoice weeks later, that revenue is invisible today and no amount of tag tuning will change that.

Accounts that answer "a lot" to the third question should pursue pilot access energetically. Accounts where everything converts on-site in a single session should treat this as a nice improvement to adopt when it becomes generally available, and spend the intervening effort on the conversion definition instead.

Where this sits in a bigger pattern

Microsoft is not an isolated case. Meta has had a Conversions API long enough that people forget it was ever new. Google has enhanced conversions and offline conversion imports. LinkedIn has one. OpenAI shipped a measurement pixel and a Conversions API alongside ChatGPT Ads. Server-side conversion tracking has stopped being a Meta speciality and become the default expectation across the industry.

The consequence for anyone running multiple channels is not obvious until you count it. A multi-platform advertiser now maintains something like five pixels and four or five server-side connections, each with its own identifiers, its own deduplication rules, its own access tokens, and its own way of failing.

And each one fails silently. There is no error state for a token that expired, an event a developer renamed, a consent tool that updated, or a dataset a platform disabled over a policy flag. Campaigns keep running. Dashboards keep rendering numbers. The numbers keep looking plausible.

The symptom is identical no matter which integration broke: performance degrades over two or three weeks and the team responds by testing creative, because that is what you do when results slip and nothing else looks wrong. One silent integration was a manageable risk. Five is a different proposition, and very few teams have staffed for it.

A sensible position to take today

If you spend meaningfully on Microsoft, ask your representative about pilot access, because it is provisioned per account and asking is the only route in. Do the four preparation steps above regardless, since they improve your measurement immediately whether or not the API arrives.

When access does come, plan the reconciliation before you plan the integration. Decide in advance which number you will check the API against, how often you will check it, and what you will do when the two disagree. That sounds like overhead for a small platform, and it is the difference between adding a measurement channel and adding a second thing that can be quietly wrong.

The advertisers who get the most from server-side tracking are not the ones who implement it fastest. They are the ones who can still prove, six months later, that it is working.