Send conversions from MediaScalers straight to Microsoft Advertising (formerly Bing Ads) server to server, with no browser tracking involved.
This integration sends your conversions straight from MediaScalers to Microsoft Advertising, server to server, using the Microsoft Conversions API. Nothing runs in the visitor's browser, so ad blockers and browser cookie limits do not get in the way and your attribution stays more accurate.
Some Microsoft integrations make you sign in and approve access. This one does not. You paste your tag ID and token, and that is the whole connection.
There are two places to do this, depending on who you are.
Once you have one saved, opening the tile shows your list of configurations. You can edit, delete, or add another from there.
The API token is never shown back to you, including to the Network. If you lose it, generate a new one in Microsoft Advertising and paste it in again.
The connection above only stores your credentials. The postback is what actually sends a conversion.
| Field | Sends as | What it is |
|---|---|---|
| Event Type | eventType | Either pageLoad or custom. Page load events suit destination goals and remarketing. Custom events are for a specific action, like a purchase. |
| Event ID | eventId | Free text, and macros work. |
| Event Source URL | eventSourceUrl | The page the event happened on. Free text, and macros work. Only required when Event Type is pageLoad, and the field asks for it only then. |
| Field | Sends as | What it is |
|---|---|---|
| Ad Storage Consent | adStorageConsent | Whether the visitor agreed to their data being used for advertising. See the section below, this one matters. |
| Event Time | eventTime | When the event happened. |
| Field | Sends as | What it is |
|---|---|---|
| Anonymous ID | anonymousId | Your own anonymous identifier. |
| External ID | externalId | A first-party ID of your own, like a customer ID. |
| em | verflow hashes this before sending. Microsoft never receives the plain address. | |
| Phone | ph | Everflow hashes this before sending too. |
| MSCLKID | msclkid | Microsoft's click ID, which Microsoft lists as its strongly preferred way to match a conversion to an ad click. Everflow cannot create it, so you carry it in on a sub parameter and map it here, for example {sub1}. See Populating The MSCLKID Field below. |
| Client User Agent | clientUserAgent | The visitor's browser user agent. |
| IP Address | clientIpAddress | IPv4 or IPv6. |
| iOS Advertising Identifier | idfa | Apple's advertising ID. |
| Android Google Advertising ID | gaid | Google's advertising ID on Android. |
| XXXX | XXXX | XXXX |
| Field | Sends as | What it is |
|---|---|---|
| Event Category | eventCategory | Category for a custom goal |
| Event Label | eventLabel | Label for a custom goal. |
| Search Term | searchTerm | The search the visitor ran, if there was one. |
| Transaction ID | transactionId | A unique ID for a one-off event, such as a purchase. |
| Event Value | eventValue | A number. The value of a custom goal. |
| Value | value | A number. The revenue on the conversion. |
| Currency | currency | A three letter code, such as USD or EUR. |
Every field above takes a macro, so you can map values straight off the conversion instead of typing them. See Your Guide To Parameters & Macros.
MSCLKID is the field people ask about most, because you cannot type a value into it. Microsoft creates the click ID when someone clicks your ad, and with auto-tagging turned on it adds it to your landing page URL as msclkid. Everflow cannot generate it. Your job is to carry that value into the Everflow click, then point the postback at it.
Microsoft lists msclkid as strongly preferred, not required, and it has to be the real click ID. A placeholder word such as MSCLICKID, or the literal text {msclkid}, gives Microsoft nothing to match on.
Map Microsoft's click ID into one of your sub parameters, then set the MSCLKID field to that sub's macro. This shows up in Everflow reporting and needs no change to a standard click script. For how parameters are captured on the click and returned in a postback, see Your Guide To Parameters & Macros. The examples use sub1. Any sub you are not already using for something else works the same way.
Add this to your Final URL Suffix, ideally at the account level so every campaign inherits it. Do not start the suffix with ? or &, Microsoft adds the right one. If your suffix already holds other parameters, put & between them, for example src=bing&sub1={msclkid}.
sub1={msclkid}
If you already manage a tracking template instead, add the same pair to the end of it, after {lpurl} and your Everflow parameters. Either way, when someone clicks the ad, your landing page URL ends up looking like this, with Microsoft's real click ID in place of the placeholder:
https://www.example.com/landing/?oid=1&affid=2&sub1=MICROSOFT_CLICK_ID
If your Final URL already has a hard-coded placeholder like sub1=MSCLICKID, delete it from the Final URL and let the suffix or template add sub1={msclkid} instead, so Microsoft fills in the real value on every click and sub1 is not sent twice. Then work through the steps below.
| 1 |
Map The Click ID In Microsoft AdvertisingAdd sub1={msclkid} to your Final URL Suffix (or tracking template) as shown above. Make sure auto-tagging is on in your Microsoft Advertising account settings. Templates and suffixes set at a lower level, like campaign or ad, override the account level one. |
| 2 |
Check Your Click Script Reads That SubYour Everflow click script on the landing page has to pick the sub up from the URL. The standard script already reads sub1 to sub5, so most setups need no change. If yours is customised, confirm it includes sub1: EF.urlParameter('sub1') |
| 3 |
Set The MSCLKID Field On The PostbackOpen the postback in Partners → Postbacks with the Microsoft Advertising delivery method. Under User Data, click +, choose MSCLKID as the Data Field and enter {sub1} as the Value, or the macro for whichever sub you used. No hashing needed. Everflow hashes the fields that need it automatically. |
| 4 |
Test One ClickClick one of your ads, then find that click in Everflow reporting. Sub1 should hold a long ID, not the word MSCLICKID and not {msclkid}. If it is empty, check the suffix or template first, then the click script. |
One thing to check before you pick a sub, if the same page also runs Everflow organic tracking.
Organic tracking fills sub1 to sub5 with its own values, and sets sub1 to the ad platform it detects, such as Microsoft. If your landing page uses the organic script, talk to Support before choosing which sub carries the click ID.
Everflow picks up fbclid, gclid and ttclid from the URL automatically. It does not do that for msclkid yet, and that support is being worked on. Until then, the only way to capture msclkid under its own name is to add it to the parameters block of your click script, as below, and then set the MSCLKID field to {msclkid}.
parameters: {
'msclkid': EF.urlParameter('msclkid')
}
We do not recommend this today. It needs a click script change, and free-form parameters do not appear in standard Everflow reporting, so you cannot easily check that the click ID arrived. Use the sub parameter setup above unless you have a specific reason not to.
If a visitor declines on your cookie banner and you send their conversion to Microsoft anyway with no consent value, you are sharing their data for ad targeting when they said no. Under GDPR and the Digital Markets Act that is a real problem, not a technical detail. If any of your traffic comes from Europe, map Ad Storage Consent so the visitor's answer travels with the conversion. If your traffic is all outside Europe, leaving it blank generally will not break anything today.
The payload is kept deliberately lean, the same way the Meta integration is. Everflow does not send line items, item IDs, or hotel data. If you need those, this integration is not the way to get them across.
This integration covers the Conversions API only. Microsoft's other tools, like Ad Insight and Campaign Management, are not part of it.
Quick answers to the setup questions we hear most.