Microsoft smette di comprare media e punta tutto sul sell-side

L’adapter AppNexus sarà rimosso da Prebid.js nel 2027, ma secondo l’Header Bidding Index è usato dal 44,8% dei publisher

Nel wrapper di molti publisher c’è una riga di codice che nessuno guarda più da anni: l’adapter AppNexus in Prebid.js, la libreria open source più usata per gestire l’header bidding, cioè l’asta in cui più fonti di domanda fanno offerte sull’inventario prima che la richiesta arrivi all’ad server. Quella riga ha una data di scadenza. Secondo l’ultimo aggiornamento di prodotto di Microsoft Monetize, nel primo trimestre 2027 l’adapter AppNexus verrà dismesso. Sarà rimosso da Prebid.js e l’endpoint legacy sarà deprecato. È il genere di modifica tecnica che passa inosservata finché un giorno, in fondo a un report, la domanda non comincia a calare senza una spiegazione evidente.

Un adapter su due che sta per sparire

Per capire quanto pesi questa scadenza bastano due numeri. Secondo l’Header Bidding Index di AdExchanger e ServerBid, il 44,8% dei publisher che fanno header bidding usa AppNexus come fonte di domanda. Index Exchange si ferma al 41,3%. Non si tratta quindi di un’integrazione di nicchia rimasta attiva per inerzia: per diffusione supera uno dei nomi più noti del sell-side.

Resta da capire perché Microsoft scelga di intervenire su un’integrazione così diffusa. La risposta non è nella nota tecnica sul 2027. Va cercata in una serie di decisioni strategiche prese prima.

Meno buy-side, più sell-side: la strategia dietro la dismissione

La direzione era stata indicata già nel maggio 2025. In un post del blog di Microsoft Advertising l’azienda annunciava che dal 2026 avrebbe concentrato gli investimenti nella tecnologia pubblicitaria buy-side esclusivamente sulla Microsoft Advertising Platform. Annunciava anche che dal 28 febbraio 2026 non avrebbe più supportato l’acquisto di media tramite il proprio DSP (demand-side platform, la piattaforma usata da inserzionisti e agenzie per comprare inventario), Microsoft Invest. Quella data è passata da mesi: sul lato acquisti la ristrutturazione è un fatto compiuto.

A prima vista sembra un paradosso. Microsoft riduce la presenza sul fronte della domanda e nello stesso periodo arricchisce il lato vendita. Monetize, la piattaforma per i publisher, ha rilasciato in questo trimestre sette aggiornamenti ai segnali OpenRTB, il protocollo standard con cui SSP e DSP si scambiano le richieste d’asta. L’obiettivo è dare ai DSP informazioni più ricche e standardizzate su contenuto, identità, dispositivi, posizionamento video e contesto della transazione. In pratica, ogni impression arriva al compratore con più contesto, e un compratore con più contesto tende a valutarla meglio.

Lo stesso vale per il video. Dal 2024 Monetize supporta la ricezione dai publisher delle richieste di dynamic ad pod in OpenRTB 2.6, cioè i blocchi di più annunci in sequenza tipici della CTV e dello streaming. Lo scorso agosto Microsoft ha completato l’altra metà del percorso: ha aggiornato le integrazioni con i DSP per trasmettere anche a loro i segnali dei pod OpenRTB 2.6, a partire da The Trade Desk. C’è poi la domanda di Amazon. Monetize applica ora localmente le raccomandazioni di traffic shaping del Dynamic Traffic Engine di Amazon e indirizza così la capacità di Amazon DSP verso l’inventario dei publisher Monetize. Se si mettono insieme questi pezzi, il quadro è coerente: meno tecnologia legacy da mantenere, come l’endpoint AppNexus, e più investimento nella qualità dei segnali e nell’accesso alla domanda esterna.

Una tecnologia più ricca di segnali, però, ha anche un costo operativo. Più parametri significano più cose da configurare, da monitorare e da diagnosticare quando un deal non consegna. Per questo la partita si sposta sugli strumenti di intelligenza artificiale, e lì il concorrente diretto è Google.

Copilot contro Ask Ad Manager, e cosa fare prima del 2027

Copilot è presente nelle piattaforme Microsoft fin dall’aprile 2025. All’inizio aveva un ruolo da guida: aiutava a navigare l’interfaccia, a capire i concetti chiave e a trovare la documentazione giusta. Il salto arriva con le nuove funzionalità basate su MCP (Model Context Protocol, uno standard che permette a un modello AI di collegarsi a fonti di dati esterne), ora in open beta sia su Monetize sia su Curate. Copilot non risponde più solo con la documentazione generica: basa le risposte sui dati dell’account Monetize del publisher.

Google si muove nella stessa direzione con Ask Ad Manager, un agente AI pensato per risolvere problemi, generare report personalizzati sulle performance e muoversi più rapidamente nella piattaforma. Anche in questo caso il punto di forza dichiarato è l’uso dei dati specifici dell’utente per fornire insight e raccomandazioni su misura. I due assistenti condividono quindi la stessa promessa: lasciare la risposta generica e ragionare sul proprio inventario. La differenza la faranno la profondità dell’accesso ai dati e l’affidabilità delle risposte, due aspetti che con funzionalità ancora in beta conviene verificare sul campo prima di prenderli per buoni.

Per chi gestisce un wrapper Prebid il primo trimestre 2027 è vicino. Le verifiche da fare sono concrete:

Adapter e wrapper. Controllare se l’adapter AppNexus è ancora presente nel proprio setup Prebid.js, anche in configurazioni secondarie o in siti meno curati del network. Conviene poi pianificare la migrazione prima che l’endpoint legacy venga deprecato, così da avere il tempo di confrontare i volumi di domanda prima e dopo il passaggio.

Segnali e video. Verificare che i segnali OpenRTB trasmessi siano completi e coerenti, e che la configurazione dei pod video in OpenRTB 2.6 sia pronta per i DSP che li leggono, a cominciare da The Trade Desk.

Assistenti AI. Scegliere tra Copilot e Ask Ad Manager in base ai dati su cui sanno davvero ragionare, non in base al marchio. Tenere presente che uno strumento in beta va affiancato a controlli manuali, non usato al loro posto.