Accurately measuring digital advertising performance requires tracking user interactions from the initial ad click to the final purchase. However, browser restrictions, ad blockers, and privacy-focused technologies can limit the amount of data collected through traditional browser-based tracking.
Microsoft Advertising uses Universal Event Tracking (UET) to measure conversions and user interactions. While traditional UET implementations operate in the browser, Microsoft Conversion API (CAPI) enables businesses to send event data directly from their servers to Microsoft Advertising.
But what is the difference between Microsoft UET and Conversion API? How does the server-side tracking architecture work, and what should businesses consider when implementing it?
In this guide, we explore Microsoft UET and CAPI architecture, event structures, deduplication, ID Sync requirements, and msclkid management.
What Are Microsoft UET and Conversion API (CAPI)?
Microsoft Universal Event Tracking (UET) is a tracking technology that uses a JavaScript tag installed on a website to collect information about user interactions.
When someone clicks a Microsoft Advertising ad and visits a website, the UET tag can track page views and predefined conversion events.
In a traditional UET implementation, the tracking process works as follows:
User clicks an ad → Microsoft adds msclkid to the landing page URL → Browser loads the UET tag → User interactions are sent to Microsoft Advertising.
This approach is known as client-side tracking because data collection happens directly in the user's browser.
Microsoft Conversion API, on the other hand, allows businesses to send events from their servers to Microsoft Advertising.
For example, when a customer completes a purchase, the conversion event can be sent through both the browser-based UET tag and the server-side CAPI integration.
When configured correctly, this approach can help reduce browser-related data loss and improve conversion measurement quality.
However, sending only purchase events through CAPI is not enough. A complete Microsoft Advertising measurement architecture requires the correct event structure to support conversion tracking and remarketing.
Microsoft CAPI Event Structure: Page Load and Custom Events
Microsoft Conversion API processes website interactions through two primary event types: Page Load and Custom Event.
These event types serve different purposes and should be considered together when implementing server-side tracking.
1. Page Load Events
Page Load events represent visits to individual pages on a website.
Each page view sent through Microsoft CAPI should generate a separate pageLoad event. Page transitions within Single Page Applications (SPAs) should also be considered when implementing this tracking structure.
The main parameters used in Page Load events include:
| Parameter | Description |
|---|---|
eventType | Event type: pageLoad |
pageLoadId | Unique page view identifier; UUID v4 can be used |
eventSourceUrl | URL of the visited page |
pageTitle | Title of the visited page |
eventTime | Timestamp of the event |
Page Load events are important not only for tracking website visits but also for supporting URL-based conversion goals and remarketing audiences based on page visits.
2. Custom Events
Custom Events represent specific actions users perform on a website.
For example, an e-commerce business may track the following actions as Custom Events:
- Product views
- Add-to-cart actions
- Checkout initiation
- Purchases
- Form submissions
Custom Events use parameters such as eventName, eventId, and eventTime. Additional commercial information, such as purchase value and currency, can be included in customData.
There is one particularly important consideration when implementing Microsoft Conversion API:
Sending only purchase events through CAPI does not create a complete Microsoft Advertising measurement architecture.
If Page Load events are missing, URL-based conversion goals and remarketing audiences based on page visits may not function as expected.
Therefore, Microsoft CAPI implementations should cover both relevant page views and custom conversion events rather than focusing exclusively on purchase tracking.
Microsoft CAPI Deduplication: How to Prevent Duplicate Conversions
When Microsoft UET and Conversion API operate together, the same conversion event may be sent to Microsoft Advertising through two different channels.
For example, when a customer completes a purchase:
- The browser-based UET tag sends a purchase event.
- The server-side CAPI integration sends the same purchase event.
Without proper deduplication, the same transaction could potentially be counted twice.
Deduplication is the process of identifying duplicate events and ensuring that a single conversion is counted only once.
For deduplication to work correctly, three important fields must remain consistent.
| Parameter | Description | Requirement |
|---|---|---|
eventId | Unique identifier of the conversion event | Must be identical across UET and CAPI for the same conversion |
eventName | Name of the conversion event, such as purchase or lead | Must be consistent across both channels |
| UET Tag ID | Identifier of the UET tag associated with the events | The same UET Tag ID should be used for the same conversion |
For example, suppose a purchase event is assigned the following identifier:
eventId: order_12345
When the same purchase is sent through the browser and server, both implementations must preserve this value.
Microsoft Advertising can then identify the matching signals as belonging to the same conversion and prevent duplicate counting.
However, using the same eventId for different transactions can also cause measurement errors.
Each conversion should therefore receive a unique identifier, and that identifier should remain unchanged when the event is transmitted through multiple tracking channels.
What Is Microsoft ID Sync and Why Is It Important?
Microsoft Conversion API enables businesses to send conversion events directly from their servers. However, moving event transmission to the server does not eliminate the need for browser-based identity matching.
Microsoft uses an ID Sync mechanism to associate website visitor identifiers with identities within its advertising ecosystem.
ID Sync is particularly important for remarketing and dynamic remarketing use cases.
According to Microsoft's documentation, client-side ID Sync is required for dynamic remarketing and is also recommended to improve conversion matching quality.
How Does Microsoft ID Sync Work?
ID Sync operates through a pixel executed in the user's browser.
This pixel helps Microsoft recognize and match website visitors with identifiers used within its advertising platform.
The implementation uses three main parameters:
| Parameter | Requirement | Description |
|---|---|---|
Red3 | Required | Microsoft customer identifier in the format BACID_<CID> |
VID | Required | Anonymous visitor identifier, preferably a UUID |
UID | Optional | Anonymized identifier associated with a logged-in user |
There are two important details to consider.
First, the CID used in the Red3 parameter is not the UET Tag ID. It refers to the Microsoft Advertising customer account identifier.
Second, the VID value used by the ID Sync pixel must match the anonymousId sent in CAPI events.
For authenticated users, the optional UID can also correspond to the externalId used in CAPI.
Can Microsoft ID Sync Run Server-Side?
According to Microsoft's integration requirements, the ID Sync pixel must run in the browser.
This is because identity matching requires access to the user's browser context.
Therefore, even when conversion events are delivered through CAPI, the ID Sync mechanism cannot be moved entirely to a server-side environment.
Microsoft recommends executing the ID Sync pixel on as many pages as possible, ideally on the first page view and at least once per session.
What Is MSCLKID and How Should It Be Managed in CAPI?
MSCLKID (Microsoft Click ID) is a unique tracking parameter used by Microsoft Advertising to identify advertising clicks.
When auto-tagging is enabled in Microsoft Advertising, the platform adds the msclkid parameter to the landing page URL after a user clicks an ad.
For example:
https://example.com/products?msclkid=abc123
This identifier helps Microsoft connect advertising clicks with subsequent website conversions.
In a traditional UET JavaScript implementation, the tag can automatically process this parameter.
However, in a CAPI-only tracking architecture, capturing and storing msclkid becomes the responsibility of the implementation.
How to Capture and Store MSCLKID
A properly configured Microsoft CAPI implementation should manage msclkid through five key steps.
1. Capture
When a user first arrives on the website, the msclkid parameter should be extracted from the landing page URL.
2. Storage
The captured identifier can be stored using first-party cookies, localStorage, or an appropriate server-side storage solution.
3. Retention Period
Microsoft recommends retaining msclkid for approximately 90 days. The retention policy should also comply with applicable privacy and consent requirements.
4. Overwriting Existing Values
When the same user clicks another Microsoft advertisement, a new msclkid value may be generated.
In this case, the previously stored identifier should be updated with the latest captured value.
5. Event Transmission
The stored msclkid should be included in subsequent Page Load and Custom Events associated with the user whenever available.
This structure helps Microsoft Advertising establish a more reliable connection between advertising clicks and website conversions.
Safari Link Tracking Protection: How to Handle MSCLKID Loss
Server-side tracking can reduce certain types of data loss associated with browser-based tracking. However, it cannot completely bypass browser privacy restrictions.
Safari's Link Tracking Protection can remove certain tracking parameters from URLs in specific browsing contexts.
This behavior may affect the availability of advertising identifiers such as msclkid.
For example, if a user clicks a Microsoft advertisement and the browser removes the tracking parameter before the website can access it, the integration may be unable to capture that identifier.
This leads to an important limitation:
Server-side Google Tag Manager (sGTM) or Microsoft CAPI cannot recover a URL parameter that never reached the website.
Therefore, the correct approach is not simply to move tracking to the server but to capture available attribution signals as early as possible.
How Can Businesses Reduce MSCLKID Data Loss?
First, when msclkid is available, it should be captured as early as possible during the landing page visit and stored in an appropriate first-party storage solution.
Second, businesses can use additional identity matching signals when msclkid is unavailable.
Microsoft CAPI supports identifiers such as:
- Hashed email addresses
- Hashed phone numbers
- Anonymous visitor identifiers
When processed in compliance with applicable privacy laws and user consent requirements, these signals may improve conversion matching quality.
However, hashed customer information does not directly replace a missing msclkid or guarantee the same attribution results.
Microsoft CAPI Implementation Checklist
A successful Microsoft UET and Conversion API integration requires more than simply sending events to Microsoft's servers.
The quality of conversion measurement depends on how consistently event structures, visitor identifiers, and advertising click information are managed.
After implementation, businesses should verify the following areas:
- Event Coverage: Are Page Load and Custom Events being transmitted correctly?
- Deduplication: Do browser-side and server-side events use matching
eventIdvalues for the same conversion? - ID Sync: Is the browser-based ID Sync pixel working correctly, and does
VIDmatch the CAPIanonymousId? - MSCLKID: Is the click identifier captured, stored, and included in subsequent events?
- Conversion Goals: Are Microsoft Advertising conversion goals correctly associated with the transmitted events?
- Privacy and Consent: Are visitor identifiers and conversion data processed in accordance with applicable privacy and consent requirements?
These checks help businesses evaluate not only whether their tracking setup is operational but also whether the collected data is reliable enough to support advertising optimization.
How Should Microsoft UET and CAPI Work Together?
Microsoft Conversion API provides a server-side alternative to relying exclusively on browser-based advertising conversion measurement.
However, building an effective server-side tracking architecture involves more than removing the existing UET JavaScript tag and moving all events to a server.
A reliable implementation requires correctly structured Page Load and Custom Events, consistent deduplication identifiers, a functioning ID Sync mechanism, and effective msclkid management.
When implemented correctly, Microsoft UET and CAPI can work together to support more reliable conversion measurement, stronger attribution signals, and remarketing capabilities.
Ultimately, the goal of server-side tracking is not simply to send more data. It is to ensure that the data delivered to Microsoft Advertising is accurate, consistent, privacy-conscious, and useful for campaign optimization.