These cookies are essential for the website to function properly. They enable core functionality such as security, shopping cart, and account access. You cannot disable these cookies.
These cookies enable enhanced functionality and personalization, such as remembering your language preference or region. If you do not allow these cookies, some features may not work properly.
These cookies help us understand how visitors interact with the website by collecting and reporting information anonymously. This helps us improve our website.
These cookies are used to deliver advertisements that are relevant to you based on your interests. They also help measure the effectiveness of advertising campaigns.
Bing UET Tag reports your PrestaShop shopping journey to Microsoft Advertising, from page views to purchases. One UET Tag ID starts browser tracking; a separate Microsoft access key adds direct server delivery.
Microsoft Advertising runs campaigns across Microsoft search and partner properties. The account is free, while advertising charges follow clicks within your budget. Store signals support conversion goals, remarketing audiences and automated bidding.
You switch standard actions individually, add custom actions and control marketing consent. Employees are excluded from tracking, and each shop keeps its own settings. Browser and server purchase reports share an order identifier, value, currency and products; interrupted server deliveries enter a retry queue.
A second delivery route preserves purchase reporting when the browser route is interrupted, with delivery results visible in PrestaShop.
Bing UET Tag connects a PrestaShop store to Microsoft Advertising, reports standard and store-specific actions, and gives every completed order both a browser route and a queued server route.
The order-confirmation page reports the purchase through the visitor's browser. At the same time, the shop places a second report in its own server queue. Both carry one identifier derived from the order, so Microsoft receives two accounts of the same sale rather than two unrelated conversions.
The purchase includes its transaction reference, revenue, currency, item count and products. The Microsoft click identifier is retained for the permitted period, while email, telephone and customer identifiers are protected before server delivery. This gives the advertising account stronger material for connecting an order with the campaign that brought it, even when the browser route is interrupted.
Delivery status stays in the PrestaShop panel, while conversion attribution and campaign results appear in Microsoft Advertising. The boundary is clear, the module delivers the store evidence and Microsoft processes it in the advertising account.
The standard set covers page views, product views, successful cart and wishlist additions, checkout starts, searches with the submitted phrase, registrations and purchases. Product and order events include the commercial context Microsoft needs for conversion goals and remarketing audiences.
Every standard event has a separate switch. A shop focused on leads keeps page, product and custom actions, while a retail shop sends the complete path to purchase. In a multistore installation, every shop holds its own UET Tag ID, event policy and server credential.
Custom rules extend the standard set to interactions unique to the storefront. A click, selected page address, selected shop area or named storefront event becomes a Microsoft Advertising signal, with fixed details and information taken from the element used by the visitor. The readiness test also confirms that each configured trigger works on the actual shop.
A completed purchase first enters a queue that refuses a duplicate row for the same order event. The module tries the first waiting records immediately, then processes the remaining work every five minutes. An unsuccessful delivery receives up to six attempts with growing intervals, and a stalled send returns to processing automatically.
The settings page separates waiting, sending, accepted and failed records. Recent entries show the number of attempts, Microsoft's response and the last error, so an agency or merchant knows whether a problem concerns the access key, rejected data or a temporary connection failure.
After the cause is corrected, the retry control returns a terminal failure to delivery with a renewed attempt budget. Valid records in the same delivery group continue even when Microsoft rejects another record, so one malformed event does not hold back the rest.
Marketing consent governs the Microsoft click identifier, browser events and server purchase delivery. A same-page grant starts tracking, withdrawal stops later sends and removes the module's marketing identifier. No marketing decision means no quiet event in the background.
Employees signed in to the shop panel remain outside storefront tracking, so product checks and test orders do not inflate conversion rates. If another installed tracking module already owns the same Microsoft tag, Bing UET Tag suppresses duplicate output and names the owner in the settings.
Each shop in a multistore installation has its own tag, event switches, access key and queue view. This keeps separate brands, countries or advertising accounts from mixing their conversion evidence while leaving the initial setup short.
The readiness table covers the tag identifier, browser delivery, consent handling, custom rules and the server route. A real test event checks whether Microsoft accepts the server connection, while the queue history shows what was accepted, what is still waiting and why a delivery failed.
The built-in storefront test goes further. It opens the selected shop page, confirms the expected tag identifier and Microsoft program, detects a duplicate tag, shows the current consent state and records the browser events that actually leave the page. On the order-confirmation preview it displays the purchase value, currency, products and shared event identifier before any live order is used as proof.
The merchant therefore sees configuration, storefront behavior and Microsoft acceptance in one working path. Campaign reports begin as a decision tool only after the underlying shop evidence has been observed.
Be the first to share your experience with this product.
Bing UET Tag + Conversions API adds Microsoft Advertising tracking to your PrestaShop store, including browser UET events and optional server-side purchase conversions. It helps you measure Microsoft Ads traffic, ecommerce actions, checkout starts and completed orders without editing your theme.
No. The browser tag is only injected by the PrestaShop header hook when tracking is active, meaning a numeric TAG_ID is saved and ENABLED is 1. When it runs, the Microsoft library is added with script.async = true from https://bat.bing.com/bat.js, so it loads without blocking page rendering.
On load the module pushes a single pageLoad to window.uetq, then sends only the events you enabled, such as product view, add-to-cart or purchase, through uetq.push('event', ...). When a supported client consent module is present, the pixel is loaded only after marketing consent is confirmed in the browser, so declined visitors trigger no request to Microsoft.
Server-side Conversions API sending runs on a scheduled cron task, not inside the shopper's request, and logged-in employees are excluded by default through EXCLUDE_EMPLOYEES.
When the Conversions API is enabled and a Microsoft bearer token is saved, purchase events are queued at order validation and sent server-side by a scheduled cron task, send_bing_uet_conversions, that runs every 300 seconds. Each run processes the queue up to the configured batch limit (CAPI_BATCH_LIMIT, default 20, allowed 1–100 and capped at 100 rows per run), so failed or pending events are retried on the next cycle rather than lost.
The server-side user data can include the stored Microsoft click id (msclkid), hashed email and phone, client IP and user agent. Processed and stale queue entries are cleaned automatically, keeping recent history and removing old rows over time.
If the bearer token is missing or empty, the admin readiness block shows a warning and no server-side events are sent until you add it. Browser UET can stay enabled independently for page views and remarketing while you configure the Conversions API.
Yes, it supports Microsoft Conversions API for server-side purchase events, but only when the required settings are complete. The module needs tracking enabled, a numeric TAG_ID, CAPI_ENABLED turned on, a saved CAPI_ACCESS_TOKEN, and purchase tracking enabled.
actionValidateOrder, the module checks canTrack(), TRACK_PURCHASE and CAPI readiness before queueing anything.microsoft_uet, tied to the order id, then the module immediately processes a small batch of 3 events. The cron task processes the normal configured batch later.The browser UET tag can still handle page, cart, search and remarketing events; the CAPI path in this module is specifically the server-side purchase path.
For setup, the important CAPI fields are:
CAPI_ENABLED=1 CAPI_ACCESS_TOKEN=your_microsoft_token CAPI_BATCH_LIMIT=20 TRACK_PURCHASE=1The API client sends events to Microsoft UET CAPI using the numeric tag ID in the endpoint and a bearer token. The payload normalizes event name/id/time/source URL, ad-storage consent, user data and custom purchase data. User matching can include IP address, user agent, stored msclkid, hashed customer details and anonymous cart/guest identifiers where available.
This is not a server-side replacement for every browser event in the module. Page view, product view, search, add-to-cart, wishlist and custom click/URL/controller events remain browser-side in the inspected source; CAPI is the server purchase supplement.
The module groups Microsoft Ads UET events around storefront commerce, account, search and custom-trigger activity. The main events are individually configurable in the module settings.
pageView, productView, addToCart, addToWishlist, initiateCheckout and purchase. Product, cart and purchase events include commerce parameters such as product IDs, order values, currency and quantities where available.search fires on search-result pages with the query context.signUp is triggered after customer registration through the module's registration hook flow.The purchase event is sent on the order-confirmation page, while add-to-cart and wishlist events are captured by front-office JavaScript listeners.
Most of those toggles default to enabled at install, including TRACK_PAGE_VIEW, TRACK_PRODUCT_VIEW, TRACK_ADD_CART, TRACK_ADD_WISHLIST, TRACK_INITIATE_CHECKOUT, TRACK_SEARCH, TRACK_PURCHASE and TRACK_SIGNUP. TRACK_CUSTOM_EVENTS defaults to off until you define custom event rules.
Custom rules are intentionally bounded: the config normalizer accepts up to 15 distinct event names, strips reserved event_id parameters, and supports click selectors, URL contains matches, controller names, or custom DOM events. Front-office JavaScript de-duplicates add-to-cart and wishlist button events for about one second so the same action is less likely to be counted twice.
Add your numeric Microsoft UET Tag ID and enable browser tracking in the module. The PrestaShop header hook loads the UET script, pushes the page load event, and then sends configured browser events when tracking is active and consent rules allow it.
In a new install, tracking is not live until those settings are complete: ENABLED defaults to 0, TAG_ID is empty, and the module only treats itself as active when the tag ID is numeric. In the admin form, save the Microsoft Ads UET tag ID without letters or spaces, keep RESPECT_CONSENT enabled if you use a supported cookie module, and decide which event toggles should stay on.
TAG_ID=123456789 ENABLED=1 RESPECT_CONSENT=1 TRACK_PAGE_VIEW=1 TRACK_PRODUCT_VIEW=1 TRACK_PURCHASE=1When the header hook runs, it can also capture msclkid from the landing URL for later conversion matching. Employee exclusion is enabled by default through EXCLUDE_EMPLOYEES, so logged-in back-office testing may not fire events unless you account for that setting.
Yes. With RESPECT_CONSENT enabled, the module checks marketing consent before it treats Microsoft UET tracking as active. It checks mprcookiesrevolution first by reading the mprcr_consent cookie and looking for marketing:1. If that cookie is absent, it falls back to that module's DEFAULT_CONSENT value. If Cookies Revolution is not active, it checks mprcookiebanner through mprcookie_consent=granted, again falling back to that module's default consent setting when the cookie is absent.
If no supported MPR consent module is active, the consent function returns allowed, so tracking is not blocked by consent alone. For strict GDPR gating, keep RESPECT_CONSENT enabled and install/configure one of the supported consent modules.
The msclkid flow runs in the header hook. The module reads msclkid from the landing URL, accepts only A-Za-z0-9._:- characters up to 500 characters, mirrors it into $_COOKIE['mprbuet_msclkid'], then writes an HTTP-only cookie named mprbuet_msclkid for 7776000 seconds. Later server-side conversion user data can include that stored Microsoft click ID when present.
https://shop.example/?msclkid=abc123 stores abc123 in the module cookie.The server-side consent check and the front-office JavaScript gate work together but are not identical. The PHP canTrack() guard blocks event building for employees, disabled modules, and failed marketing consent; the header template also checks browser cookies before loading bat.js when a supported client consent module is present.
If RESPECT_CONSENT is set to 0, the consent check is bypassed. If no supported MPR consent module is installed, the PHP function allows tracking by consent alone, so strict stores should not rely on the UET module by itself as their only consent layer.
The msclkid cookie is written before the later purchase, which matters because a shopper may arrive from Microsoft Ads, browse, and order in a later request. The value is accepted only if it matches the module's character whitelist; invalid or overlong values are ignored instead of being sent to Microsoft.
Modules our team genuinely pairs with this one, and exactly why each belongs in the same setup.
Bing UET Tag connects your store to Microsoft Advertising with browser events and an optional Conversions API path, so you can tie Microsoft Ads spend to real shopper actions and revenue. Knowing campaigns convert, though, tells you little about why visitors hesitate or struggle on the pages those ads send them to.
Microsoft Clarity covers that behavioural side, adding heatmaps, session recordings and custom events tagged around product views, cart actions, searches and checkout starts. It complements the UET tag: one measures conversion and ad attribution, the other shows on-page behaviour, each set up separately.
Together you get both the numbers and the narrative. The UET tag tells you which Microsoft campaigns drive revenue while Clarity helps you see where shoppers get stuck on the way there, so you can act on conversion data and behavioural insight at once, with each tool handling a different question about the same traffic.
Bing UET Tag handles Microsoft Advertising tracking specifically, sending its own browser events and optional Conversions API data for purchases. Many stores also run other marketing and analytics tags, and managing each as a separate snippet across the theme becomes harder to maintain as the stack grows.
Google Tag Manager helps with that broader organisation, adding your GTM container and sending it ecommerce shopping events from real behaviour so your tags work with product views, cart changes and purchases. It does not run or control the Bing UET tag from its container; the two operate independently, with GTM organising its own tag ecosystem alongside the dedicated UET module.
Used together, your Microsoft tracking stays in its purpose-built module while GTM manages the rest of your tag stack with shared ecommerce events. You get focused, reliable Microsoft Ads measurement and a tidier home for other tags, each tool doing its own job rather than one trying to absorb the other.
Bing UET Tag fires browser events and can send purchase data to Microsoft Advertising, which means it is processing visitor activity that, in many regions, requires a clear consent basis. A tracking tag without a consent layer leaves a compliance gap.
Cookies Revolution covers consent, collecting and enforcing shopper choices for necessary, functional, analytics and marketing cookies. It blocks matching external and inline scripts before consent, reactivates allowed ones once it is granted, and records each decision. It complements the UET tag by managing the consent framework around tracking rather than the tracking itself.
Together you can run Microsoft Ads measurement on a clearer consent footing. The UET tag handles attribution while Cookies Revolution records and enforces shopper choices, holding matching scripts until consent is given and reactivating them afterwards, so your tracking operates within a managed consent setup, with each tool owning its own responsibility.
Bing UET Tag gives your store Microsoft Advertising tracking, but if you also run Google Shopping or other paid channels, the wider question is whether your whole feed and measurement stack is sound, not just one tag in isolation.
Feed & Tracking Audit reviews exactly that, checking Merchant feed quality, GA4/Ads conversion tracking, pixels and Product/Offer schema and finding GTIN gaps, price mismatches, broken tags and double-counted conversions before your next campaign. It complements the module by assessing the stack rather than adding to it.
The payoff is trustworthy measurement before you spend. The UET tag keeps doing its Microsoft tracking job while the audit checks that your tags, including the broader pixel and feed setup, are firing correctly and not double-counting, so campaign decisions across channels rest on data you can rely on rather than tags that look installed but misreport.
30 days return right
Plug & Play Modules
Dedicated Support First
Built and maintained by David Miller and mypresta.rocks. David Miller has worked with PrestaShop since 2013, and the company behind this shop has been registered since 3 December 2018. Every module in this catalogue is our own work, so your questions to support reach the people who wrote the code. The changelog on this page lists every update with its date.
