Microsoft Advertising
Microsoft Ads server-side tracking without the UET tag
Capture msclkid at click time and deliver Microsoft Ads conversions server-to-server through Microsoft Advertising’s APIs. UET conversion events, offline conversion uploads, and SHA-256 hashed enhanced conversions, all with 400-day attribution. The same path works for Bing Ads campaigns and the Microsoft Audience Network. No UET tag in the browser. No signal loss.
400 days
Click attribution
msclkid persisted in server-set first-party cookies
20-40%
More conversions
Recovered from ad blocker signal loss
0 KB
UET tag JavaScript
No browser UET tag, no client-side conversion script
<50ms
Delivery latency
Conversion data reaches Microsoft in real time
Why client-side UET tracking breaks
Microsoft Advertising relies on three things to attribute conversions correctly: an msclkid click identifier captured at landing, hashed customer data for enhanced conversions matching, and timely conversion reporting. Client-side UET tracking fails at all three.
Ad blockers hide your best customers
A large share of desktop visitors block tracking scripts, the UET tag included. These aren’t random users, they’re tech-savvy, high-intent buyers. Every blocked conversion is a missing signal that degrades automated bidding. Microsoft optimises on what it can see, and it can’t see your best customers.
msclkid expires before customers convert
Microsoft only exposes msclkid on the landing page, and Safari caps client-set cookies at 7 days. If a customer clicks a Bing ad, researches for 10 days, and then converts, the click ID is gone. The conversion can’t be matched to the click and your ROAS calculations are wrong.
Enhanced conversions need clean PII
Microsoft enhanced conversions require SHA-256 hashed email and phone in the em and ph parameters. Client-side implementations depend on the UET tag reading form fields correctly, which is fragile, privacy-risky, and often misconfigured.
What moves server-side
Microsoft Advertising does not have a single Meta-style Conversions API brand. Instead it offers three complementary server-side paths, and Datafly Signal handles all three from one pipeline.
UET Conversions API
Web conversion events that would otherwise fire from the browser UET tag are delivered server-to-server through the UET Conversions API. This is the server-side path for your existing UET conversion goals, not a separate measurement product. Access is provisioned per account by Microsoft.
Offline conversion uploads
CRM and backend conversions are imported and matched to the original msclkid. Microsoft requires the conversion time to fall within the last 90 days, so Signal forwards offline events as they happen rather than batching them weeks later.
Enhanced conversions
SHA-256 hashed email and phone are attached to conversions so Microsoft can match them to ad clicks even in cross-device and cookie-restricted scenarios. The hashing happens in the governance layer, so raw PII never leaves your infrastructure.
How Datafly Signal delivers conversions to Microsoft Ads
Capture msclkid at click time
With auto-tagging enabled, Microsoft appends msclkid to the landing page URL. Datafly.js extracts it on landing and the gateway stores it in a server-set first-party cookie with a 400-day expiry, fully ITP-exempt. The most recent msclkid is always kept for each user.
Collect conversion events server-side
When a purchase, lead form, or signup occurs, Datafly.js sends the event to your own first-party subdomain. The Ingestion Gateway enriches it with the stored msclkid and user identity.
Hash PII in the governance layer
The Org Data Layer SHA-256 hashes email and phone, normalising email (trimmed, lowercased) and phone (E.164) into the em and ph parameters before the event reaches the delivery pipeline. No raw PII ever leaves your infrastructure.
Deliver via Microsoft Advertising APIs
The Delivery Worker sends UET conversion events through the UET Conversions API and uploads offline conversions, each carrying msclkid, hashed identifiers, conversion value, currency, and the resolved consent signal. Guaranteed delivery with retry.
Microsoft matches and attributes
Microsoft receives a complete conversion signal, click ID plus hashed PII, and matches it to the original ad click. Enhanced conversions fill in gaps where msclkid alone is not sufficient, including cross-device journeys.
Pipeline configuration
Every conversion is shaped by a version-controlled pipeline config. The mapping below sends purchase events to Microsoft Advertising with msclkid attribution, hashed customer data for enhanced conversions, and a server-resolved consent signal.
# microsoft-ads-conversion.yaml
name: microsoft_ads_purchase
integration: microsoft-ads
trigger:
event: purchase
parameters:
uet_tag_id: "12345678"
# delivered via the UET Conversions API path
goal_name: "Purchase"
global:
msclkid:
source: context.click_ids.msclkid
mode: direct
events:
purchase:
destination_event: conversion
mappings:
conversion_name:
source: properties.goal_name
mode: direct
conversion_time:
source: timestamp
mode: direct
conversion_value:
source: properties.value
mode: direct
conversion_currency:
source: properties.currency
mode: direct
adjustment_type:
value: restate
mode: static
# enhanced conversions: hashed first-party data
pii:
em:
source: context.traits.email
mode: hash_sha256
ph:
source: context.traits.phone
mode: hash_sha256
# consent resolved server-side before delivery
consent:
ad_storage:
source: context.consent.ad_storage
mode: directBuilt for Microsoft Ads performance
Every feature is designed to maximise the conversion signal Microsoft receives.
Automatic msclkid capture
msclkid captured from the landing page URL and stored in 400-day server-set cookies. The most recent click ID is always kept per user, no browser UET tag needed.
Enhanced conversions
SHA-256 hashed email and phone sent in the em and ph parameters with every conversion. Maximises match rate without exposing raw PII to Microsoft.
Offline conversion uploads
Import CRM and backend conversions on the same pipeline, matched to msclkid. Forwarded within the 90-day window Microsoft requires.
400-day attribution
Server-set cookies persist msclkid for 400 days, far longer than Safari’s 7-day client-side limit. Full buying-cycle coverage for Bing Ads clicks.
Zero UET JavaScript
No browser UET tag and no client-side conversion script. Remove a category of ad blocker target while improving conversion signal quality.
Server-resolved consent
The ad-storage consent signal is resolved server-side before delivery, so Microsoft only counts conversions your policy permits, with no banner race in the browser.
Supported conversion types
Any event tracked by Datafly.js or sent via the server-side API can be mapped to a Microsoft Advertising conversion goal.
| Conversion Type | Source Event | Key Signals |
|---|---|---|
| Purchase | purchase | msclkid, value, currency, hashed em/ph |
| Lead | generate_lead | msclkid, lead value, hashed em/ph |
| Sign up | sign_up | msclkid, hashed em |
| Add to cart | add_to_cart | msclkid, value, currency, items |
| Begin checkout | begin_checkout | msclkid, value, currency |
| Page view | page_view | msclkid, page URL, page title |
| Offline / CRM | custom | msclkid or hashed em, conversion value, time |
Frequently asked questions
- How does Datafly Signal capture msclkid for Microsoft Ads attribution?
- When auto-tagging is enabled in Microsoft Advertising, the landing page URL carries an msclkid query parameter after a user clicks a Bing or Microsoft Audience Network ad. Datafly.js extracts msclkid on landing and the gateway persists it in a server-set first-party cookie with a 400-day expiry that is exempt from Safari ITP’s 7-day cap on JavaScript-set cookies. Microsoft only ever exposes msclkid on the landing page, so capturing it reliably at click time is the single most important step. Later conversions are matched to the original click for the full buying cycle.
- Is there a Microsoft Conversions API like Meta CAPI?
- Microsoft Advertising offers a Conversions API for Universal Event Tracking (the UET Conversions API), which sends web and offline conversion events server-to-server instead of relying on the browser UET tag. It is not a separate product brand the way Meta CAPI is; it is the server-side delivery path for the same UET conversion goals. Signal delivers UET conversion events through this API, uploads offline conversions keyed on msclkid, and attaches hashed customer data for enhanced conversions matching. Access to the UET Conversions API is provisioned per account by Microsoft, so the exact path depends on what your account is enabled for.
- What hash format does Microsoft enhanced conversions require?
- Microsoft enhanced conversions expect SHA-256 hashes of normalised email and phone, sent in the em and ph parameters as lowercase hexadecimal strings. Email is trimmed and lowercased before hashing, and phone is normalised to E.164. Datafly Signal applies these vendor-correct normalisation rules in the Org Data Layer before delivery, so raw email and phone never leave your infrastructure and match rates max out without each integration team needing to know the exact requirements.
- Can I upload offline conversions from CRM or backend systems?
- Yes. The same pipeline accepts events from Datafly.js, the iOS / Android SDKs, or direct server-to-server calls from your CRM. Offline conversions are matched to the original msclkid where it is known, or to hashed customer data for enhanced conversions. Microsoft requires the offline conversion time to fall within the last 90 days, so the pipeline timestamps and forwards events as they happen rather than batching them weeks later.
- Do I still need the UET tag on the page?
- No. The UET tag exists to set its identifier, capture msclkid from the URL, and fire conversion goals, all of which Datafly.js and the gateway handle server-side instead. Removing the UET tag eliminates a category of ad blocker target and gives you cleaner attribution because msclkid persists for 400 days instead of 7. You can run the UET tag and the server-side path in parallel during migration and deduplicate before fully removing the tag.
- How are consent signals handled for Microsoft Ads?
- Microsoft processes events as consent granted by default and accepts an explicit ad-storage consent signal (granted or denied) per event. Denied events are not used for ad purposes including conversion attribution and retargeting. Because Signal is deployed in your own cloud and the pipeline decides what is sent, your consent state is resolved server-side before delivery rather than racing a banner in the browser. Signal is a consent-enablement toolkit, not a compliance guarantee, so the policy you encode in the pipeline is the policy Microsoft sees.
Related
Google Ads
Equivalent server-side delivery for Google Ads Enhanced Conversions and gclid persistence.
Google Analytics
Server-side GA4 Measurement Protocol with the same first-party collector and 400-day cookies.
PII Handling
How email and phone fields are SHA-256 hashed in the right format for vendor-correct matching.
Safari ITP Recovery
400-day first-party cookies for msclkid persistence across the full buying cycle.
Recover every Microsoft Ads conversion
Request a technical walkthrough. We'll show you how much Bing Ads conversion signal your current UET setup is losing and how Datafly Signal recovers it server-side.