Any Prebid setup that still calls the appnexus bidder will stop getting Microsoft Monetize bids once Microsoft removes that adapter from Prebid.js and retires its endpoint, which it has scheduled for early 2027. The fix is the msft adapter on Prebid.js 11.36.0 or later. The part that quietly costs money is in Ad Manager: line items keyed to hb_pb_appnexus.
The code change is small. Finding every place your stack still says appnexus, and keeping the Ad Manager side in step, takes longer, which is why it is worth starting this month rather than in January.
What Microsoft announced and when
Microsoft has been moving publishers off the old adapter for a year. The dates, from Microsoft and the Prebid.js repository:
| Date | What happened |
|---|---|
| 14 October 2025 | The msft adapter is merged into Prebid.js, marked "for closed testing" |
| 19 November 2025 | Microsoft's Q4 roundup says the new adapter "replaces the longstanding AppNexus adapter" and moves to an OpenRTB-based model |
| 24 September 2026 | A fix for how msft passes addtl_consent is merged |
| 28 September 2026 | Prebid.js 11.36.0 ships with that fix |
| 21 October 2026 | Microsoft: the AppNexus adapter shuts down in early 2027, removed from Prebid.js, legacy endpoint deprecated; publishers should move to msft and confirm they run 11.36.0 |
| Early 2027 | Removal, no exact day given |
The 21 October post gives the reason for the version floor in one line: 11.36.0 "supports important consent passthrough" so that spend from DSPs, DV360 in particular, is not affected. It does not name the signal.
Why the post asks for Prebid.js 11.36.0
The 11.36.0 changelog has one line for this adapter: "msft Bid Adapter - fix support for addtl_consent". The pull request behind it says the adapter now writes the value to user.ext.addtl_consent and formats it the way the AppNexus adapter did.
addtl_consent carries Google's Additional Consent string. It sits next to the IAB TCF string and lists Google ad tech providers that are not on the IAB Global Vendor List. Google's spec says it only works alongside a TC string, and that Google discards it when no TC string comes with the request.
Putting those together is our reading, not something Microsoft wrote: the "consent passthrough" in the announcement is most likely this AC string fix, and a msft build older than 11.36.0 can send EEA requests without a usable AC string. If most of your Microsoft revenue comes from outside Europe, the version floor matters less for demand, but you still need a build that has the adapter at all. Microsoft's PSP page notes that on Prebid.js 10.12 or lower you must stay on appnexus.
Find every place your setup still calls appnexus
Do this on a production page with the console open. A single site often has more than one wrapper (the main template, AMP, a video player, a second domain), so repeat it on each.
- Check the version:
pbjs.version. Anything belowv11.36.0needs an upgrade before the bidder swap. If it starts with 9 or 10, the jump to 11 has its own breaking changes, such as stricter media type checks and strict storage control by default. Read the Prebid.js 11 notes first. - List the bidders that were actually requested:
[...new Set(pbjs.getEvents().filter(e => e.eventType === 'bidRequested').map(e => e.args.bidderCode))]. This catches ad units passed straight torequestBids, whichpbjs.adUnitscan miss. - List the aliases:
pbjs.aliasRegistry. Any entry whose value isappnexusis a partner riding on the old adapter. If your build set the registry to private, you will get nothing back, and you have to read the wrapper config instead. - Check server-side calls:
pbjs.getConfig('s2sConfig'). Look forappnexusinbiddersand for Microsoft endpoints. Microsoft's deprecation covers the legacy endpoint, so a Prebid Server or PSP setup that still names the old bidder belongs on the same list. - Search the wrapper repository for
appnexus,placementId, andappnexusAuctionKeywords. Those strings show you where the param changes below will land.
What changes in the bid params
The msft page keeps most params and renames a few. Some values the AppNexus adapter took as params now come from standard Prebid locations.
| AppNexus adapter | msft adapter |
|---|---|
placementId |
placement_id, integers only |
frameworks |
banner_frameworks |
pub_click |
pubclick |
external_imp_id |
ext_imp_id |
publisher_id |
ortb2.publisher.id |
user, app |
ortb2.user, ortb2.app |
supply_type |
ortb2.site or ortb2.app |
video, video.frameworks |
mediaTypes.video, mediaTypes.video.api |
position |
mediaTypes.banner.pos |
reserve |
the floors module |
appnexusAuctionKeywords (setConfig) |
First Party Data, for example ortb2.site.keywords |
Three details catch people out. Keywords change format: each value repeats its key, as in genre=news,genre=sport, instead of grouping values under one key. Native ad units must use ORTB Native 1.2 with eventtrackers for event type 1 (impression) and event type 2 (viewable MRC); the legacy Prebid native setup is not supported, and the docs warn that missing trackers can reduce demand. And a single requestBids call can only carry placements from one parent publisher, so a shared wrapper that bids for several publishers gets no demand for the mixed placements.
A placementId written as a string, "12345678", is the first thing I would grep for. The new param takes integers only.
The Ad Manager side: line items keyed to appnexus
This is where revenue goes missing without an error. With Send All Bids, Prebid sets bidder-specific keys. After the swap, Microsoft's bid arrives as hb_pb_msft, hb_bidder_msft and so on, and a line item that targets hb_pb_appnexus=5.00 or hb_bidder=appnexus no longer matches anything. The bid comes back and has nothing in Ad Manager to win against.
What to check, per setup:
- Send All Bids: add
hb_pb_msftand the othermsftkeys as key-values, then either create Microsoft line items or retarget the existing ones. The docs list eleven keys, and Ad Manager truncates key names to 20 characters. - Send Top Bid only: the generic
hb_pbline items still work. Any targeting or report filter onhb_bidder=appnexusneedsmsftadded. - Aliased partners: their keys follow the alias name, so they do not change unless the partner changes its bidder code.
- Reports and alerts: any saved report, dashboard or alert filtered on the
appnexusvalue will show a drop on swap day that is only a rename. Addmsftto the filter before you ship.
Roll it out on a slice and measure
Swap the bidder on a share of traffic first, through the wrapper or a test ad unit. Compare appnexus and msft over the same days on the same ad units, so weekday mix does not muddy it:
| Number | Where to read it | What a problem looks like |
|---|---|---|
| Bid rate | Prebid analytics, bids per bid request | msft well below appnexus on the same units: check params and placement IDs |
| Timeouts | Prebid analytics | A rise after the swap: compare response times before blaming the new endpoint |
| Win rate in Ad Manager | Ad Manager report with hb_bidder as a key-value dimension |
Bids arrive but rarely win: line items or price buckets are missing for msft |
| Revenue per 1,000 requests | Ad Manager plus Prebid analytics | Flat bids but lower revenue: check native trackers and EEA traffic separately |
Splitting by country matters for the consent question. If msft holds steady outside Europe and falls inside it, check the version and the AC string before anything else.
Optimon reads your own Ad Manager and Prebid data and shows what moved after a change like this one, by bidder and ad unit, with the numbers next to it.
What to do tomorrow morning
- Run the five console checks on every wrapper and write down each
appnexuscall and alias. - If
pbjs.versionis below 11.36.0, put the upgrade on the plan first. - List the Ad Manager line items, reports and alerts that name
appnexus. - Swap one slice, compare the four numbers for a full week, then roll out.
- Ask each partner that aliases
appnexuswhich bidder code they will use in 2027.
FAQ
Do I lose Microsoft demand today if I stay on the appnexus adapter?
Not from the announcement alone. Microsoft gives "early 2027" for removing the adapter and retiring the legacy endpoint, with no exact day. Its 21 October post does tie Prebid.js 11.36.0 to consent passthrough that DSPs such as DV360 need, so an old build may already carry less demand than it could. Measure it on a slice before you assume either way.
Can I keep an old Prebid.js version and only swap the bidder code?
Only if the build is new enough to contain msft. Microsoft's PSP page says that on Prebid.js 10.12 or lower you must use the legacy appnexus adapter, and Microsoft asks for 11.36.0 or later. A build older than 11 is a major version jump, so read the Prebid.js 11 notes before you schedule it.
What happens to adapters that alias appnexus?
Each one needs checking on its own. The msft page allows aliases of the new adapter, and Prebid.js has already moved some aliases across, such as Project Agora. Run pbjs.aliasRegistry in the console, list every alias that resolves to appnexus, and ask that partner which bidder code they want after the switch.
Sources
- Work smarter this holiday season, what's new in Microsoft Monetize (Microsoft Advertising, 21 October 2026)
- Publisher release roundup, Q4 2025 edition (Microsoft Advertising)
- Microsoft (msft) bidder documentation (Prebid.org)
- AppNexus bidder documentation (Prebid.org)
- Prebid 11.36.0 release notes (Prebid.js on GitHub)
- msft Bid Adapter, fix support for addtl_consent (Prebid.js pull request 15644)
- Msft Bid adapter, initial release for closed testing (Prebid.js pull request 13952)
- Integrate web and mobile web with PSP (Microsoft Learn)
- Additional Consent mode technical specification (Google Ad Manager Help)
- pbjs.aliasRegistry (Prebid.org)
- pbjs.getEvents (Prebid.org)
- Prebid.js 11 release notes (Prebid.org)
