The UET tag is installed. Debug mode confirms it is firing. The tag status in Microsoft Advertising shows “Active.” You have waited the standard 24-48 hours. And the conversion counter stays at zero.

This exact scenario has become the most common complaint on the Microsoft Advertising support forums since early 2024. The tag appears to work by every surface-level diagnostic, yet conversion data never arrives. Accounts running on this configuration are bidding without any learning signal, their automated strategies are operating blind, and the problem is entirely silent - no errors, no alerts, just missing data.

Understanding why this happens requires going one layer deeper than the UET debug tool shows you.

How UET Conversion Tracking Is Supposed to Work

Before diagnosing the failure, the working model is worth stating explicitly.

Microsoft’s Universal Event Tracking works in two parts:

Part 1: The UET base tag. This fires on every page of your site and tells Microsoft that the user visited. It establishes the session context and stores click data that enables attribution. The base tag firing is what causes the tag to show as “Active” in the Microsoft Advertising interface.

Part 2: The conversion event. This is a separate signal - either a custom event sent via the window.uetq data layer, or a Goal defined in Microsoft Advertising that triggers when a specific URL is loaded (a thank-you page, a confirmation page). The conversion is only recorded when this second signal fires and is successfully received.

The status indicator in Microsoft Advertising - the “Active” label - reflects Part 1 only. It confirms the base tag is receiving traffic. It says nothing about whether conversion events are firing or being recorded.

This is the core of the diagnostic confusion. Active means the base tag is working. It does not mean conversions are working.

The Most Common Causes Since Early 2024

The spike in reports from early 2024 onward is not coincidental. Several changes converged around that period that introduced new failure modes into UET conversion tracking.

Microsoft Advertising introduced its own consent mode framework, aligned with Google’s Consent Mode v2 rollout, requiring advertisers serving users in the EEA and UK to pass consent signals alongside UET events.

When consent is not granted - either because the user declined, or more commonly because the consent default state is denied and the user never interacted with the cookie banner - the UET base tag fires in a limited mode. It registers the session, which is why the tag shows “Active.” But the conversion event payload is held or discarded if ad_storage consent has not been granted.

This produces exactly the symptom: tag active, conversions zero.

The base tag ping is lightweight and designed to work in limited consent contexts. The conversion signal requires full consent to be transmitted and attributed. If your site’s consent setup defaults to denied and a large proportion of visitors never interact with the cookie banner, those visitors generate “Active” base tag pings but no conversion events.

The debug tool does not simulate a non-consented user. When you open the UET Tag Helper or debug mode, you are a consented user (or the tool bypasses consent checks). It shows the conversion firing. The real visitor population, most of whom never clicked “Accept” on your banner, shows nothing.

Many accounts that correctly implemented Google Consent Mode v2 did not implement the equivalent for Microsoft Advertising. The two platforms have different consent signal implementations.

Google uses the gtag('consent', 'update', {...}) mechanism. Microsoft Advertising requires that UET receive consent signals via the window.uetq interface or through a CMP that has native Microsoft consent integration.

If your consent management platform (CMP) only handles Google Consent Mode and does not pass signals to UET, Microsoft’s tags are operating without consent context. Depending on your account’s consent mode settings in Microsoft Advertising, this can mean all conversion events from EEA users are silently dropped.

3. Goal Configuration Set to the Wrong URL

URL-based Goals are the most common conversion setup for Microsoft Advertising - a Goal fires when a user reaches a specific URL (e.g., /thank-you or /order-confirmation).

This setup breaks silently in two scenarios:

The URL changed. A site update, migration, or A/B test changed the confirmation page URL. The Goal still points to the old URL. Real conversions fire on the new URL, which no Goal is monitoring. The UET base tag still fires (hence “Active”), but no Goal condition is ever met.

The URL uses dynamic parameters. A confirmation page with a dynamic order ID in the URL (e.g., /order/12345/confirmation) will not match a Goal configured to trigger on /order-confirmation. Unless the Goal uses a “contains” or regex match type rather than “equals,” it never fires.

This is straightforward to miss because the conversion setup worked before the URL changed, and the UET tag being active provides false confidence that tracking is intact.

4. Custom Event Firing With the Wrong Event Name

If your conversion is tracked as a custom event (not a URL-based Goal), the conversion Goal in Microsoft Advertising must be configured with an event category, action, label, or value that exactly matches what your tag sends via window.uetq.

A mismatch - a trailing space, a capitalization difference, a renamed event - means the event fires in UET but no Goal condition is met. The event data arrives at Microsoft but does not trigger a conversion record.

This is common when:

5. UET Tag Firing But on the Wrong Domain

Microsoft Advertising conversion attribution requires that the UET base tag fire on the same domain as where the click lands, and that the conversion event fire within the same user session (or within the conversion window).

If your site uses a subdomain for checkout (e.g., checkout.yoursite.com) and the UET base tag only fires on yoursite.com, the conversion event that fires on the checkout subdomain fires without an associated base tag session from the same domain. Microsoft cannot connect the click to the conversion.

The tag shows Active (because it fires on yoursite.com and Microsoft receives those pings). Conversions are zero (because they fire on checkout.yoursite.com where there is no base tag or session context).

6. Tag Fires in Debug Mode Only (Conditional Firing)

Some GTM implementations include triggers that accidentally restrict the conversion tag to firing only when the GTM preview/debug mode is active. This can happen when:

The UET Tag Helper runs in debug mode. Every test confirms the tag fires. In production, without debug mode, the trigger condition is never met and the tag never fires.

7. Single-Page Application (SPA) Navigation Not Triggering the Tag

On single-page applications (React, Vue, Angular, Next.js), page navigation does not reload the page. The URL changes but no new page load event fires.

If the conversion tag is set to fire on a “Page View” trigger in GTM, it will not fire when the user navigates to the confirmation page in an SPA - because no page view event occurs. The tag fires on the initial page load and then goes dormant.

The debug tool typically tests against a full page load, which works fine. Real SPA navigation, which never reloads the page, does not trigger the conversion.

Diagnosing Your Specific Case

Work through these checks in order. Most accounts fail on one of the first three.

Open your CMP analytics (Cookiebot, OneTrust, Usercentrics, or equivalent) and find the consent interaction report.

Look at:

If 60%+ of users are in the “never interacted” category, and your consent default is denied, those users are your missing conversions.

Then check whether your CMP has a Microsoft Advertising / UET consent integration enabled. This is often a separate toggle from the Google Consent Mode integration. In most CMPs it is found in a “tag vendor” or “consent categories” section.

If no UET consent integration exists, your consent signals are reaching Google but not Microsoft.

Check 2: Test the Goal URL With a Real Conversion

Do not use debug mode for this test. Complete an actual conversion on your site - submit the form, complete the purchase - and check the URL you land on after completion.

Copy that exact URL (including any query parameters if relevant) and compare it to the Goal configuration in Microsoft Advertising.

Go to Microsoft Advertising → Tools → Conversion Goals and open the Goal you are using. Check:

Even a minor discrepancy - a trailing slash, a case difference, a missing subdirectory - will prevent the Goal from firing.

Check 3: Verify the UET Tag Is on the Conversion Page

In your browser, navigate to the actual conversion confirmation page (the thank-you page, order confirmation, etc.) by completing a real conversion. Then open DevTools → Network tab and filter by bat.bing.com.

You should see network requests to bat.bing.com when the page loads. If you see requests on the homepage but not on the confirmation page, the UET base tag is missing from that page - either a GTM container is not loading, or the tag has a trigger restriction.

Also look for a request to bat.bing.com/action/0 or similar - this is the conversion event specifically. A base tag request alone is not enough.

Check 4: Check for Custom Event Name Mismatch

If your conversion uses a custom event rather than a URL goal, open the browser console on your conversion page and type:

window.uetq

This returns the UET queue. After your conversion event fires, call:

window.uetq.push('event', 'test', {})

This manually pushes a test event. Then check what your actual conversion tag pushes - the event name, category, action, label values - and compare them character-for-character to the Goal configuration in Microsoft Advertising.

In the UET Tag Helper, switch to the “Events” tab and look at what event data is being sent. Match it exactly to what the Goal expects.

Check 5: Test Without GTM (Direct UET Code)

If you are deploying UET through GTM, test whether the issue is GTM-specific by temporarily adding the UET conversion snippet directly to your confirmation page HTML (outside of GTM):

<script>
  window.uetq = window.uetq || [];
  window.uetq.push('event', 'purchase', {
    'revenue_value': 1,
    'currency': 'USD'
  });
</script>

If this records a conversion in Microsoft Advertising and your GTM-deployed version does not, the problem is in your GTM configuration - trigger, tag settings, or event data.

Check 6: Check for SPA Behavior

Navigate to your site’s conversion page by clicking through the normal user journey (do not load the URL directly). Watch the browser URL bar.

If the URL changes from /checkout to /confirmation without the page visually reloading (no white flash, no full page load indicator), you are on a single-page application. Your page view-based triggers will not fire on this navigation.

In GTM, you need a History Change trigger (or a custom event pushed by your application framework) to detect SPA navigation and fire the conversion tag.

Fixes by Cause

Option A: Implement Microsoft’s consent signal via your CMP.

Most major CMPs have a Microsoft Advertising consent integration. In Cookiebot, this is found under the Cookiebot tag manager integration settings. In OneTrust, it is in the Google Tag Manager consent mode configuration. Enable the Microsoft / UET consent category and confirm that ad_storage signals are being passed to the UET tag.

Option B: Implement the consent signal manually in GTM.

If your CMP does not have a native Microsoft integration, add a GTM tag that fires when consent is granted and updates UET’s consent state:

<script>
  window.uetq = window.uetq || [];
  window.uetq.push('consent', 'update', {
    'ad_storage': 'granted'
  });
</script>

This tag should be triggered by your CMP’s consent-granted event (the same event you use to fire the Google consent update tag).

Option C: Review your Microsoft Advertising consent mode settings.

In Microsoft Advertising, go to Tools → Conversion Goals → Settings and check whether consent mode enforcement is enabled for your account. If it is, and you are not passing consent signals, conversions from non-consented users will be blocked. If it is not, conversions should record regardless of consent signals (though this may not be compliant for EEA traffic).

Fix for Wrong Goal URL

Update the Goal configuration in Microsoft Advertising to match the exact URL of your current confirmation page.

Use “Begins with” as the match type if your confirmation URL includes dynamic parameters (e.g., order IDs). This matches /order/ regardless of what follows it.

Use “Contains” for more flexible matching when the URL structure is variable.

Avoid “Equals” unless your confirmation URL is completely static and will never change.

After updating the Goal, complete a test conversion to verify it fires.

Fix for Custom Event Name Mismatch

Open your conversion Goal in Microsoft Advertising and compare every field - event category, action, label, value - against what your UET tag actually sends.

Update whichever side has the error. If the Goal is wrong, update it in Microsoft Advertising. If the tag is wrong, update it in GTM. After making changes, test with a real conversion event, not the debug tool.

Fix for Missing UET Tag on Conversion Page

Ensure your GTM container fires on every page of your site, including the conversion confirmation page. Verify there are no trigger restrictions on the UET base tag - it should fire on All Pages without condition.

If the conversion page is on a different subdomain (e.g., checkout.yoursite.com), deploy a separate GTM container or the same container (with the appropriate settings) on that subdomain.

Fix for SPA Navigation

Replace your Page View conversion trigger with a History Change trigger in GTM:

  1. Create a new Trigger
  2. Trigger type: History Change
  3. Fire on: All History Changes (or filter by the new URL fragment that indicates a conversion)

This fires every time the URL changes in an SPA without a full page load. Add a condition to restrict it to the confirmation URL to avoid firing the conversion on every SPA navigation.

Alternatively, push a custom data layer event from your application code when the conversion is complete:

window.dataLayer.push({
  event: 'conversion_complete',
  transactionId: '12345',
  transactionValue: 99.00
});

Then trigger your UET conversion tag on this custom event rather than a page view.

Verifying the Fix

After making changes, do not rely on the UET Tag Helper alone. Run a full end-to-end test:

  1. Open Microsoft Advertising and navigate to Tools → Conversion Goals
  2. Note the current conversion count for your Goal
  3. Complete a real conversion on your site (submit the form, complete the purchase)
  4. Wait 15-30 minutes
  5. Refresh the Conversion Goals page and confirm the count incremented

If the count does not increment after a real conversion, the fix did not work and you need to continue diagnosing.

Also check the UET Tag Health section in Microsoft Advertising under Tools → UET Tags. This shows a more detailed breakdown of tag activity, including whether conversion events are being received - separate from whether the base tag is active.

Key Takeaway

“Active” in Microsoft Advertising means the UET base tag is receiving traffic. It does not mean conversions are working. These are two separate signals, and the Active status tells you nothing about the second one.

Since early 2024, the most common cause of the active-but-no-conversions problem is consent mode - specifically, accounts that implemented Google Consent Mode v2 but did not implement the equivalent for Microsoft Advertising. The base tag fires in limited mode (hence “Active”), but the conversion event payload is blocked because no ad_storage consent signal has been passed.

Check your consent setup first. Then verify the Goal URL matches your actual confirmation page URL. Then look for custom event name mismatches, missing tags on conversion pages, and SPA trigger issues.

The fix is almost always one of these five causes. The UET Tag Helper will not show you the problem because it tests in conditions that bypass the real failure. You need to test as a real non-consented user, on a real conversion page, with real conversion data flowing through.

Related Posts

Why Consent Mode Is Silently Killing Your Google Ads Conversions

13 min read

Consent ModeGoogle AdsGDPRConversion TrackingCookie BannerConsent Mode Series

How to Implement Consent Mode v2 with Google Tag Manager

14 min read

Consent ModeGoogle Tag ManagerPrivacyGDPRConversion TrackingConsent Mode Series

Enhanced Conversions for Shopify: The Practical Setup Guide

Google AdsEnhanced ConversionsShopifyConversion TrackingGoogle Ads Strategy Series
Adnan Agic

Adnan Agic

Google Ads Strategist & Technical Marketing Expert with 5+ years experience managing $10M+ in ad spend across 100+ accounts.

Need Help With Your Google Ads?

I help e-commerce brands scale profitably with data-driven PPC strategies.

Get In Touch
Back to Blog