Bing server-side tracking: Microsoft Ads through your sGTM

Bing server-side tracking isn’t a separate project. If you already run a server container for Google and Meta, the setup is the same one: same sGTM, same hosting, one more tag that sends your conversions to Microsoft Advertising through its Conversions API. Two things do work differently from Google, and they’re what this article is about. Microsoft only switches the API on account by account so far, and without clean deduplication every conversion gets counted twice.

1. Bing server-side tracking: the same logic as Google and Meta

How server-side tracking works in general, why adblockers and Safari’s ITP punch holes in your data, and the budget at which a tagging server pays off: I’ve covered all of that in server-side tracking with GTM. The short version: the browser sends its events to a server of your own on your subdomain, and a second GTM container, the server container, passes the data on to the ad platforms.

For Microsoft Advertising nothing about that principle changes. Only the destination at the end of the pipe is new. Meta calls its server-side interface the Conversions API, and Microsoft gave its equivalent the same name: the Conversions API, or CAPI. Your server sends conversion events straight to Microsoft, built on the same event model as the UET tag in the browser.

UET stays, CAPI comes on top

One misunderstanding to clear up first: the Conversions API doesn’t replace your UET tag. Microsoft’s own documentation recommends using CAPI together with UET wherever possible. The UET tag captures what happens in the browser, and CAPI adds the events the browser loses or never sees at all.

What that means for you:

• Your existing browser setup stays put. How to build the UET tag in GTM is in Bing conversion tracking: the UET tag, step by step. That guide is still the foundation.
• The server tag is a second line for the same conversions, not a new measurement.
• Because the same conversion can now arrive by two routes, you need a shared event ID. More on that in section two.

What the Conversions API sends to Microsoft

For Microsoft to match a server event to an ad click, every event needs at least one identifier. The ones that matter most:

• msclkid: the click ID Microsoft appends to your landing page URL when auto-tagging is on. It’s the strongest identifier for tying a conversion to a click.
• anonymousId: the visitor ID the UET tag stores in a cookie.
• Hashed email and phone number: SHA-256, never in plain text.
• Plus, where permitted, the visitor’s IP address and user agent.

If that looks familiar, it should. With Meta it’s the fbclid and hashed user data, with Google the gclid and enhanced conversions. The logic is the same everywhere.

What Bing server-side tracking isn’t

The usual rule for server-side tracking applies here too: it’s no way around consent. And Microsoft has one trap you should know about. According to its documentation, the Conversions API processes every event as if consent had been granted by default. Only when you send the adStorageConsent parameter with the value D does Microsoft keep the event out of advertising use. For sites in Germany and the rest of the EU that means the server tag fires only after marketing consent, exactly like your UET tag in the browser. You know the trigger mechanics from Consent Mode v2 setup.

2. The setup: same server container, one more Microsoft tag

This is the part that saves you the most work. You don’t need a new server, a second container or a different provider. Whether your sGTM runs on Stape, on Taggrs or on your own VPS makes no difference. The Microsoft tag is a template from the server container’s template gallery, so you install it in the container itself, not with the host.

Step 1: check whether your account has the Conversions API

Before you build anything in GTM, check in Microsoft Advertising whether the API is available for your account at all. Microsoft’s documentation describes getting the token like this:

1. Open the UET section of the account and edit your existing UET tag via the pencil icon.
2. In “Edit UET tag”, click Save and next.
3. Under “Set up tagging”, select Use Conversions API.
4. In the “Conversions API” section, click Copy Token and store the token somewhere safe.

And here’s the honest catch in “the setup is the same”: that option is missing in a lot of accounts. As of September 2026, ppc.land reported that Microsoft treats the Conversions API as a pilot it provisions per account. You can’t switch it on yourself. You have to ask your Microsoft account manager or Microsoft Advertising support to enrol your customer ID. Make that the first step, not the last. Otherwise you end up with a fully configured container and nowhere it’s allowed to send.

Step 2: add the Microsoft tag to the server container

In the server container it then goes the way you know from the Meta Conversions API:

1. Tags → New → Tag configuration → search the template gallery for Microsoft Ads UET Conversion API by Stape and add it to the workspace.
2. Create a new tag with that template.
3. Enter the UET Tag ID. It’s the same ID that’s already in your browser tag.
4. Enter the token from step one. It belongs to exactly this UET tag; a token from another tag won’t work.
5. Pass at least one user data parameter, for example the hashed email from your form event.
6. Trigger: the same event that already fires your Google Ads or Meta tag in the server container.

The template reads the click ID and visitor ID from the cookies the UET tag sets anyway (_uetmsclkid and _uetvid), or straight from the msclkid parameter in the URL. Check in Microsoft Advertising that auto-tagging is switched on. Without auto-tagging there’s no msclkid, and matching to the click gets a lot weaker.

Step 3: set up deduplication

This is where most setups go wrong. Your UET tag in the browser reports a conversion, and your server tag reports the same conversion again. Without a match, Microsoft counts both, and your smart bidding optimises on twice as many conversions as actually happened.

The fix is a shared event ID:

• In the web container, your UET event tag gets an event_id parameter with a unique ID per conversion.
• The same ID travels with the event to your server container, and the server tag sends it to Microsoft as eventId.
• Tag ID and event name have to be identical on both routes. According to Microsoft, that combination is what duplicates are recognised by.

If you’ve already deduplicated the Meta Conversions API, you know the pattern. How it looks for Meta is in Meta pixel setup. For Microsoft it’s exactly the same principle, just with different field names.

Step 4: test

Three checks, in this order:

1. Preview in the server container: does the Microsoft tag fire on the right event, and does Microsoft answer with status 200? A 401 almost always means the wrong token or the wrong tag ID, a 400 means a faulty field in the event.
2. Check the same test conversion in the web container: does the UET event carry the same event_id as the server event?
3. After a while, look at the conversion goal in Microsoft Advertising. If a single test raises the count by two instead of one, deduplication isn’t working.

3. When Bing server-side tracking pays off

The budget logic from the general article applies here too, with one difference. With Microsoft the question is rarely “server or no server”. It’s “is the server already running?”.

If you already run sGTM

Then the maths is simple. The server is running, the costs are there anyway, the events are already arriving. For Microsoft you add one tag, set up deduplication and test. That’s a manageable amount of work, and Microsoft’s automated bidding then gets the same better data as Google and Meta. If you run Microsoft Advertising on a conversion-based bidding strategy and your account gets access, I wouldn’t leave it lying around.

If you don’t have a server yet

Then Microsoft on its own is, in most cases, no reason to set one up. If Microsoft is the smaller channel next to Google and Meta for you, as it is in plenty of accounts, Bing doesn’t decide the server question. You make that call on your total ad budget, using the rule of thumb from the server-side tracking article: under roughly €1,000 a month, sort out basic tracking, ads and landing page first; above that, the server pays off. Microsoft then simply comes along.

Leads from the CRM: yes, but only seven days back

According to Microsoft, the Conversions API accepts CRM and offline events as well as website events. For lead generation that’s interesting, because you can report a qualified lead or a closed deal as the conversion instead of just the form. One detail decides the planning, though: the eventTime field has to fall within the last seven days. A deal that lands in the CRM three weeks after the click won’t fit through this route. How to feed long sales cycles back to Google properly is in offline conversion import for lead gen.

When not (yet)

• Your UET tag in the browser doesn’t measure cleanly, or your conversion goals count nothing. Fix the basics first, or the server just delivers the same wrong data more reliably. My tracking check shows you what actually fires on your site.
• Microsoft hasn’t enabled the Conversions API for your account. Then the UET tag stays your only route, and that’s no drama as long as it measures cleanly.
• Nobody looks after deduplication. A server tag without a shared event ID makes your data worse, not better.

FAQ

Do I need a separate tagging server for Bing?

No. The Microsoft tag runs in the same server container as your Google and Meta tags, whether Stape, Taggrs or your own server sits behind it. You add a tag, not a server.

Does the Conversions API replace the UET tag?

No. Microsoft recommends using both together. The UET tag stays in the browser, and the Conversions API sends from the server on top. Both carry the same event ID so nothing is counted twice.

Why can’t I find the “Use Conversions API” option in my UET tag?

Most likely the API hasn’t been enabled for your account yet. As of September 2026, trade press reported that Microsoft provisions the Conversions API per account. Ask Microsoft Advertising support or your account manager, and give them your customer ID.

The bottom line

Bing server-side tracking is the setup you already have for Google and Meta, plus one Microsoft tag. The difference isn’t in the technology. It’s in getting access and in being careful with deduplication.

The takeaways:

• Same server container, same host: Stape, Taggrs or your own VPS, the Microsoft tag simply joins in.
• The Conversions API complements the UET tag; it doesn’t replace it. Your browser setup stays the foundation.
• Sort out access first: if “Use Conversions API” is missing from your UET tag, ask Microsoft to enable your customer ID.
• A shared event ID in the web and server tags, or every conversion counts twice.
• The server tag fires only after consent. Microsoft treats events without a consent parameter as consented.
• Without an existing sGTM, Microsoft alone is rarely the reason for a server. With one, it’s a small extra step.