Microsoft UET Has a Server Side. Most WooCommerce Stores Don’t Use It.

May 6, 2026
by Cherry Rose

Microsoft UET Conversion API moved to general availability in late 2025. Tealium published its connector documentation on December 3 2025; Stape released a GTM Server template the same quarter. What this means for a WooCommerce store: the browser-side UET tag you installed years ago is now half of Microsoft’s recommended setup. The other half is a server-to-server endpoint, sending conversions directly from your server to Microsoft Ads — and most WooCommerce stores have not wired it.

UET Conversion API Just Went GA — Here’s How to Wire It to WooCommerce

The case for sending it is direct. 31.5% of internet users globally run ad blockers that prevent browser-side UET tags from firing entirely (Statista, 2024). On Microsoft Advertising’s professional-skewing 724 million monthly searcher audience (Microsoft Advertising, 2025), that share is typically higher — corporate networks, B2B users on privacy tools, anyone running uBlock Origin on a work laptop. Every one of those clicks reaches Bing through a paid channel and converts on your store invisibly.

The browser tag does not see them. The CAPI does.

What UET Conversion API Actually Is

Microsoft UET Conversion API is a server-to-server endpoint for sending Microsoft Advertising web and offline conversion events directly from the merchant’s server. It is positioned as a resilience layer alongside the browser-side UET tag, not as a replacement. Microsoft’s official guidance is that both surfaces should fire — the tag from the browser, the CAPI from your server — sharing the same event_id for deduplication.

The dedupe rule is the part most implementations get wrong. Microsoft deduplicates on event_id within a 24-hour window. Generate one ID per order, fire it from both the browser UET tag and the server CAPI call, and Microsoft keeps whichever arrived first. Skip the shared ID and you double-count the conversions both surfaces saw. Smart Bidding then optimizes against an inflated signal.

The msclkid Persistence Rule

msclkid is the Microsoft Click ID appended to the landing-page URL when auto-tagging is enabled in Microsoft Ads. It is the single highest-quality match signal Microsoft accepts (Microsoft UET CAPI implementation guidance via Tealium, 2025). Without msclkid in the CAPI payload, Microsoft falls back to lower-quality identifiers and match rates drop sharply.

The persistence problem on WooCommerce is structural. msclkid arrives on the landing page. The order completes minutes or days later, on a different page, possibly after a session timeout. If you do not capture and persist msclkid through to the order, the CAPI call cannot include it, and the conversion lands in Microsoft’s lower match-quality bucket.

You may be interested in: Microsoft UET Tag for WooCommerce (client-side setup)

Why WooCommerce Stores Get Hit Hardest by the Client-Side-Only Setup

WordPress runs roughly 43.5% of websites worldwide. WooCommerce runs on a large slice of those. The default Bing setup for a WooCommerce store is the client-side UET tag — installed via the Microsoft Advertising plugin, a generic GTM container, or a hardcoded snippet in the theme’s footer. All three approaches share one weakness: the tag fires in the browser, where it can be blocked, broken, or skipped entirely.

The blocking surface keeps expanding. uBlock Origin, AdBlock, AdGuard, and Brave’s built-in shields all strip the UET tag’s network request before it reaches Microsoft. Safari’s Intelligent Tracking Prevention adds a 7-day cookie cap on top. Privacy-focused browsers like LibreWolf and Arc default to stripping ad-tech requests. Bing Ads typically have 20-35% lower CPCs than Google Ads for equivalent keywords (Industry consensus / Seresa Bing UET coverage, 2024) — savings that compound when CAPI gives Smart Bidding clean signal, and disappear when the bidder is making decisions on the 60-70% of conversions that survived the tag.

The Three Implementation Paths

Microsoft does not ship an official WooCommerce plugin for UET CAPI. The three real-world implementation paths each have different cost and complexity profiles.

Path 1: Tealium (Enterprise)

Tealium added a Microsoft UET Conversion API server-side connector with documentation updated December 3 2025. This is the cleanest official integration — Tealium handles the server-side request formatting, event_id management, and msclkid passthrough. The cost is a Tealium iQ Tag Management contract, which is in the enterprise CDP price band most WooCommerce stores cannot justify.

Path 2: Stape GTM Server (Mid-Market)

Stape released a UET CAPI tag template for GTM Server-Side late 2025. This requires running a GTM Server container — typically on Stape’s hosted infrastructure — and configuring the template against your Microsoft Ads UET tag ID and CAPI token. Working setup, but it adds a GTM Server bill on top of an already-busy tracking stack, and the GTM Server learning curve is steep.

Path 3: WooCommerce Hooks (Server-Native)

The path Microsoft does not document, and most stores do not realize is the cleanest: fire the UET CAPI call directly from the WooCommerce woocommerce_order_status_completed hook. No GTM Server. No CDP contract. The hook fires on your server at the moment an order transitions to completed, with full access to order data, msclkid (if persisted), and a server-generated event_id that the browser UET tag can also read.

The reasoning for this path is simple: the browser tag is already firing client-side from the thank-you page. The CAPI call needs to fire at the same business event — order completion — but from the server. The order-completion hook is the canonical PHP-side event for that moment.

You may be interested in: Bing Ads UET Tag for WooCommerce: The Ad Channel You’re Probably Ignoring

The 90-Day Backfill Window

Microsoft supports backdated CAPI events up to 90 days old for offline conversions (Tealium / Microsoft UET CAPI documentation, 2025). This window matters more than it sounds for a new CAPI implementation. The first time a WooCommerce store wires the server-side path, it can replay the last three months of completed orders through the API and recover the conversions the client-side tag missed during that period.

That backfill does two things. It gives Microsoft a fuller training set for Smart Bidding immediately, instead of waiting for new conversion volume to accumulate. And it surfaces a delta: comparing the 90-day backfilled CAPI conversions against what the browser tag actually reported in the same period gives you a concrete number for the share of Bing conversions your store has been losing to ad blockers and tracking gaps.

Why a Server-Side First-Party Layer Is the Cleaner Foundation

UET CAPI is one destination among many. Meta CAPI, Google Ads enhanced conversions, GA4 Measurement Protocol, BigQuery — every major destination Smart Bidding optimizes against now has a server-to-server counterpart. Wiring each one as a separate WooCommerce plugin or hook handler creates a brittle stack. The order-completion hook ends up firing six or eight server-to-server requests in sequence, each with its own retry logic, secrets management, and rate-limiting concerns.

The cleaner pattern is a first-party event router. The order-completion hook fires once into a server-side pipeline, which then formats and routes the same event to UET CAPI, Meta CAPI, Google Ads, GA4, and BigQuery in parallel. The hook stays simple. The destination logic lives in one place.

How Seresa’s Stack Fits This

Transmute Engine™ is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures events from WooCommerce hooks — including woocommerce_order_status_completed — and sends them via API to your Transmute Engine server, which formats and routes them simultaneously to Microsoft UET Conversion API, Meta CAPI, Google Ads enhanced conversions, GA4, and BigQuery. Microsoft’s UET CAPI is a single outPIPE destination on the same architecture, with msclkid persistence and event_id deduplication handled at the engine layer rather than at the WordPress plugin layer.

Key Takeaways

  • Microsoft UET Conversion API is generally available. Tealium’s connector docs updated December 3 2025; Stape’s GTM Server template shipped the same quarter. Microsoft’s recommended setup is now UET tag + UET CAPI together with shared event_id.
  • The client-side UET tag is invisible to 31.5% of users. Bing’s professional-skewing audience pushes that share higher. CAPI is the resilience layer that recovers it.
  • msclkid persistence is mandatory. Capture msclkid on the landing page, persist it through to checkout, include it in the CAPI payload at order completion. Without it, match rates drop.
  • Three implementation paths exist. Tealium (enterprise CDP), Stape GTM Server (mid-market), or direct from the WooCommerce woocommerce_order_status_completed hook (server-native). The third needs no GTM Server.
  • The 90-day backfill window matters. First-time CAPI wiring can replay three months of completed WooCommerce orders, immediately giving Smart Bidding a fuller training set and exposing the conversion delta the client-side tag missed.

Frequently Asked Questions

Does Microsoft UET have a Conversions API like Meta CAPI?

Yes. Microsoft UET Conversion API moved to general availability in late 2025. It is a server-to-server endpoint for sending web and offline conversion events directly to Microsoft Advertising — used as a resilience layer alongside the browser-side UET tag, not as a replacement for it.

Can I run UET CAPI on WooCommerce without GTM Server?

Yes. The cleanest path is firing the UET CAPI call from the woocommerce_order_status_completed hook server-side. No GTM Server container required. Stape’s GTM Server template is one option for stores already running a server container, but it is not a prerequisite.

How does UET CAPI handle msclkid attribution?

msclkid (Microsoft Click ID) is appended to the landing-page URL when auto-tagging is on. Capture it on landing, persist it through to checkout, and include it in the CAPI payload at order completion. Without msclkid, Microsoft falls back to lower-quality identifiers and match rates drop.

Will UET CAPI cause double-counted conversions?

Not if you use a shared event_id between the browser UET tag and the CAPI call. Microsoft deduplicates on event_id within a 24-hour window. Generate one ID per order, fire it from both surfaces, and Microsoft keeps whichever arrived first.

How far back can I backfill UET CAPI conversions?

Microsoft accepts backdated CAPI events up to 90 days old. New implementations can recover roughly three months of historical WooCommerce orders that the client-side tag missed — useful for retraining Smart Bidding on a fuller signal set.

Wire the server-side half. Backfill the 90 days. Then read the delta. Start at seresa.io.

Share this post
Related posts