How to Set Up Microsoft Ads (Bing UET) Server-Side Tracking on Magento 2

TL;DR

Most guides to this integration start in the Magento admin, which is the wrong end of the wire. The Magento side is seven settings. What decides whether your events become counted conversions is the tag and goal structure in your Microsoft Advertising account, plus three platform rules on timing, identity and product IDs that no extension setting overrides. This guide runs the Microsoft side first, then the nine events and the fields, then the two places merchants usually lose data: a second endpoint that carries less than they expect, and a build old enough that one of the nine events never fired.

Key Takeaways

• Microsoft's position is that one UET tag covers all of your conversion goals and remarketing lists [1]. A second tag multiplies the Magento side too.
• UET records the action; a conversion goal turns it into a counted conversion [1]. An enabled event with no matching goal sends data nobody reports on.
• The configuration ships nine server-side events: Purchase, Add to Cart, Product View, Add to Wishlist, Begin Checkout, Add Payment Info, View Category, Search and Signup [3].
• CAPI rejects a stale event. Microsoft requires eventTime within the last 7 days [2], which matters when orders reach tracking on a status change.
• Every event needs at least one identifier in userData, and Microsoft marks msclkid as strongly preferred, with a recommended retention of 90 days [2].
• Sending the same events from the browser as well "may (in some cases) enrich your data" [3]. That hedge is the product's own, so verify the effect in your account.
• On builds older than v1.17.5, released September 16, 2026, the server-side add to wishlist event never fired because of a broken guard in the wishlist plugin [4].

Start in Microsoft Advertising, not in the Magento admin

Universal Event Tracking is the prerequisite for conversion tracking and remarketing in paid search [1]. The tag is the collector, the conversion goal is the accountant, and a store can run a healthy tag while reporting zero conversions because nothing counts what the tag observed.

Microsoft's guidance on how many tags to run is direct: "You can use one UET tag with all of your conversion goals and remarketing lists. Before you create multiple UET tags, see Reasons for creating more than one UET tag" [1]. Settle that before you go looking for the multi-endpoint setting further down, because every extra tag becomes another row you maintain on the Magento side.

One account fact catches agencies out, and Microsoft's rule is blunt: "A UET Tag can only be shared at the customer level, also known as the manager account level. You cannot share a UET Tag with any specific advertiser account" [1]. That limit arrives before any Magento configuration does.

Microsoft's recommendation for the server route is to run both layers: "Microsoft recommends using CAPI with Universal Event Tracking (UET) whenever possible" [2].

Which of the nine server-side events should you enable?

Write down your conversion goals, then enable the events that feed them.

The Track Events multiselect is the authoritative list of what the server can send: Purchase, Add to Cart, Product View, Add to Wishlist, Begin Checkout, Add Payment Info, View Category, Search and Signup [3]. The addon's feature summary lists fewer and relabels two of them; the configuration section is what ships.

Track Only Specific Customer Groups restricts server-side Bing events to the groups you select [3], which is how B2B stores keep wholesale orders out of a retail advertising account.

The client-side pixel that GA4 PRO ships separately carries nine events with the same labels [6]. They are two separately configured lists that happen to agree, so enabling an event in one place does not enable it in the other. The setup guide for Magento 2 GA4 server-side tracking covers the client-side layer and the container flow underneath all of this.

Getting the tag ID and the token into Magento

The addon requires the Google Analytics 4 PRO extension [3], and its prerequisite is stricter than most people expect: a client-side Microsoft Ads (Bing UET) pixel integration has to exist first, "in order to gain access to your Microsoft Ads (Bing UET) Pixel Tracking Base Code" [3]. Enabling the server side means "the server-side Microsoft Ads (Bing UET) functionality will use the Microsoft Ads (Bing UET) Javascript Tracking code configured in the client-side configuration section" [3]. Treat the base code as part of the install.

Install is Composer only, and has been since v1.16.0, released January 7, 2026, when Composer became the official and singular installation method for WeltPixel products [4].

composer require weltpixel/module-ga4-bingss

Documented compatibility: Magento 2.3.x to 2.4.9 with the security patches, all editions, multiple store views [3].

Then the fields, at Admin → WeltPixel → Google Analytics 4 Ecommerce PRO → Bing UET Tracking Settings [3]:

• Enable Microsoft Ads (Bing UET) Server Side Tracking, the master switch described above.
• Microsoft Ads (Bing UET) Tag ID. That is the exact label. The guide points you at Microsoft Ads Manager, UET Tag → View UET tag, or at the Javascript tracking code in the client-side section [3].
• Track Events, the nine above.
• Enable File Log, which writes bing-api.log to the var/log directory of the Magento root [3].

Have your CAPI token ready first. Microsoft hands it over in the UET section of the account: select the tag with the pencil icon, then Save and next → Set up tagging → Use Conversions API → Copy Token [2]. Microsoft's documentation is also the reference for the endpoint that token authorizes, POST /v1/{tagId}/events at capi.uet.microsoft.com with an Authorization: Bearer header [2].

Does sending the same events from the browser too help?

Sometimes, and the product says so in those terms.

Send enabled events via the frontend Microsoft Ads (Bing UET) Tag as well does what the label says, and the guide's own description sets the confidence level: "Microsoft Ads Manager should have built-in functionality to avoid data duplication, and this may (in some cases) enrich your data" [3]. Should, and may in some cases. Switch it on, compare a week of conversion counts in Microsoft Advertising against your Magento order count, and keep it only if the numbers improve.

Microsoft's dedup rule is what makes the combination work at all: when UET JavaScript and CAPI send the same conversion event, "pass the same stable deduplication value in eventId and keep eventName compatible across both systems", using the same tag ID, event ID and event name [2]. That requirement lands on whoever builds the payload, so test the combination rather than assume it.

When a second endpoint is right, and what it will not carry

Send eCommerce Event Data to multiple Bing UET endpoints lets you add extra property IDs, and you need the tag ID of each one [3]. The limitation sits right next to it: "Adding a new property here will only send the enabled eCommerce events in the Bing UET Server Side Tracking configuration. If you need to also send Page View events, in order to stitch data and ensure attribution, you'll also need to add additional Bing UET Tracking codes in the Bing UET Tag Javascript Code section above" [3].

Read that as a division of labor. The extra endpoint is an ecommerce feed. Attribution needs page views, and those come from client-side base code you load for that property yourself. A second tag receiving purchases with no page views behind them reports revenue with no sessions, which makes its conversion rate meaningless. So: add endpoints when you genuinely run separate advertiser accounts, and budget the client-side work for each.

Three Microsoft rules that decide whether a conversion counts

These are platform constraints, not extension behavior. Check each against your own account.

First, timing. eventTime "must be within the last 7 days" [2], and the API returns a matching error otherwise. If you exclude orders by status and let them reach tracking when the status changes, that window is your deadline. An order sitting in a review queue for nine days is outside it.

Second, identity. Every event needs at least one identifier in userData, from anonymousId, externalId, em, ph, msclkid, idfa or gaid, and msclkid is strongly preferred, with a recommended retention of 90 days [2]. Two dated fixes feed exactly this. Since v1.14.19, released April 8, 2025, the extension no longer sends the IP a CDN such as Cloudflare assigned instead of the visitor's own, and orders sent by cron carry a default user agent [4]. Since v1.16.1, released March 6, 2026, hashed customer data captured with the purchase event is persisted and sent alongside later events for returning customers [4].

Third, product IDs, if you run dynamic remarketing. Microsoft requires that "Product IDs must match either the id or item_group_id attribute in your product feed submitted through Microsoft Merchant Center (MMC)" [2]. On a store with configurable products that is a real decision, because the identifier you send and the identifier in your feed are configured in different places.

On consent, Microsoft's platform default is that all events are processed with the consent state set to granted, with an optional adStorageConsent value of granted or denied [2]. On the Magento side, since v1.17.4, released September 1, 2026, with Require Visitor Consent for Server-Side Events enabled in the GA4 configuration, server-side events are gated on the shopper's advertising consent and order events are judged on the consent stored with the order [4]. The same release added server-side bot filtering, using the same merchant-editable pattern list as the GA4 Measurement Protocol, so traffic from self-identifying crawlers is no longer sent to the Conversions API while order events are always sent [4]; keeping bot traffic out of GA4 and your CAPI reports covers the pattern list.

Where does the log tell you it worked?

Check your version first, because one of the nine events had a real bug. v1.17.5, released September 16, 2026, "fixed the server-side add-to-wishlist event never being sent because of a broken guard in the wishlist plugin" [4]. A store that enabled Add to Wishlist on an older build saw nothing in the log and could not tell a wrong setting from a missing event. The same release hardened the public server-side tracking endpoint so it only sends events for the current session's own order or cart [4].

Then read the log. With Enable File Log on, var/log/bing-api.log shows the pushed event data [3], and since v1.15.7 all data logged for one event sits on the same line [4], which makes it greppable by order increment ID. Shell access is optional: since v1.15.11, released November 25, 2025, the addon carries a Magento admin interface for exploring payloads and event logs [4]. Place one real order per enabled event rather than clicking around the storefront and hoping.

The wider verification chain for this stack, DebugView and the preview tools included, is in the guide to verifying GA4 events on Magento 2, and the same route-by-route reasoning for the Google side is in which route to send Google Ads conversions through.

If you set this up before 2026, the earlier walkthrough on integrating Magento 2 with the Microsoft Ads (Bing UET) API is probably the one you followed. Its install section describes the file-copy method Composer replaced in January 2026.

FAQ

Do I still need the client-side Bing pixel if I send events from the server?

Yes. The addon's stated requirement is a client-side Microsoft Ads (Bing UET) pixel integration, because that is where the tracking base code lives, and the server-side switch reuses that code [3].

How many server-side events can the addon send?

Nine, selected in Track Events: Purchase, Add to Cart, Product View, Add to Wishlist, Begin Checkout, Add Payment Info, View Category, Search and Signup [3].

Why would a conversion I can see in the log not appear in Microsoft Advertising?

Three reasons, cheapest first. No conversion goal in the account counts that action [1]. The event arrived outside Microsoft's 7 day eventTime window [2]. Or it carried no usable identifier in userData, where msclkid is the preferred one [2].

Should I add a second endpoint for a second storefront?

Only if it is a genuinely separate advertiser account. Extra endpoints receive the enabled ecommerce events only, so attribution for that property needs its own client-side tracking code loaded as well [3].

The nine server-side events described here come from the Microsoft Ads server-side addon, priced at 99 EUR for Magento Open Source, 299 EUR for Commerce and 499 EUR for Cloud as read on September 21, 2026 [5]. It runs on top of the Google Analytics 4 PRO extension, which is its documented requirement [3].

Check your version before you change any setting. On anything older than v1.17.5, released September 16, 2026, one of the nine events never left the server at all [4].

Sources

1. Microsoft Learn, "Universal Event Tracking", Microsoft Advertising API, accessed September 21, 2026, https://learn.microsoft.com/en-us/advertising/guides/universal-event-tracking
2. Microsoft Learn, "Conversions API (CAPI)", Microsoft Advertising API, accessed September 21, 2026, https://learn.microsoft.com/en-us/advertising/guides/uet-conversion-api-integration?view=bingads-13
3. WeltPixel, "Microsoft Ads (Bing UET) API Addon for Google Analytics 4 PRO User Guide", https://docs.weltpixel.com/BingUETAddon/User-Guide-WeltPixel-Bing-UET-Addon.html
4. WeltPixel, Microsoft Ads (Bing UET) API Addon change log, versions 1.14.19 (April 8, 2025) through 1.17.5 (September 16, 2026), https://docs.weltpixel.com/BingUETAddon/User-Guide-WeltPixel-Bing-UET-Addon.html
5. WeltPixel, Microsoft Ads server-side addon product page, prices read September 21, 2026, https://weltpixel.com/products/microsoft-ads-server-side-addon
6. WeltPixel Google Analytics 4 User Guide, section "Microsoft Ads (Bing UET) Tracking (PRO version only)", https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html