Microsoft ha iniziato a mandare i pod ai compratori
Microsoft Monetize invia i segnali dei pod dinamici OpenRTB 2.6 ai DSP partner, a partire da The Trade Desk, completando il protocollo.
La piattaforma ora trasmette i dati dei pod anche in uscita grazie ai DSP partner.
Basta guardare una bid request per capire dove sta il cambiamento. Già dal 2024 Microsoft Monetize sapeva ricevere dai publisher le richieste di pod pubblicitari dinamici in formato OpenRTB 2.6. Quei segnali però si fermavano lì e non arrivavano ai compratori. Solo lo scorso agosto, come racconta l’aggiornamento di Microsoft pubblicato la scorsa settimana, la piattaforma ha cambiato le integrazioni con i DSP partner per trasmettere i segnali dei pod 2.6, a partire da The Trade Desk. Per due anni il protocollo è stato implementato solo in ingresso. Adesso c’è anche l’uscita, ed è da qui che conviene partire per capire cosa cambia davvero nello stack, al di là di Copilot e degli agenti IA.
Metà protocollo, ora completo: i pod dinamici arrivano ai DSP
Un pod è un blocco di spot dentro un’interruzione pubblicitaria, tipico di CTV e video lungo. Le specifiche OpenRTB 2.6 permettono di descriverlo in modo dinamico: la durata complessiva dell’interruzione e il numero di slot non sono fissati a priori. Se una SSP riceve queste informazioni ma non le inoltra, il DSP fa offerte per un singolo spot senza sapere com’è fatto il break in cui finirà. Con l’aggiornamento di agosto quella perdita di informazione si chiude, almeno per il primo partner.
I pod non sono l’unica novità. Nel trimestre Monetize ha rilasciato sette aggiornamenti ai segnali OpenRTB. Servono a dare ai DSP informazioni più ricche e più standardizzate su contenuto, identità, dispositivi, posizionamento video e contesto transazionale. È un lavoro poco visibile, fatto di campi del protocollo popolati in modo coerente. Ma è quello che permette a un algoritmo di bidding di distinguere un’impression da un’altra. Resta da capire chi decide dove indirizzare il traffico e su quale codice gira tutto questo.
Sotto il cofano: traffic shaping locale, AppNexus in pensione e Copilot che legge l’account
La prima risposta riguarda il routing. Monetize ora applica localmente le raccomandazioni di traffic shaping del Dynamic Traffic Engine di Amazon e usa le indicazioni di Amazon per indirizzare la capacità di Amazon DSP verso l’inventario dei publisher Monetize. Si può pensare a un gestore di rete che riceve dal vicino una mappa della congestione e la usa sui propri router, senza dover passare ogni pacchetto da un nodo esterno. La logica di filtraggio sta dal lato della SSP. Le richieste che il DSP non vuole vedere non partono, e la capacità disponibile si concentra dove ha più probabilità di trasformarsi in offerte.
La seconda risposta riguarda il codice. Nel primo trimestre del 2027 l’adattatore AppNexus verrà dismesso: sarà rimosso da Prebid.js e l’endpoint legacy sarà deprecato. È la fine di uno degli adattatori più vecchi del mondo header bidding. Chi lo usa ancora nel proprio wrapper dovrà migrare. Va letta insieme a un altro cambiamento: secondo quanto riportato da Digiday, da febbraio gli inserzionisti potranno usare Xandr Monetize, cioè l’ex AppNexus, insieme alla piattaforma di curation di Microsoft per gestire le proprie proprietà owned and operated. Il marchio storico perde il suo vecchio endpoint e il suo motore trova un nuovo uso.
Solo a questo punto entra l’IA conversazionale. Come spiega il roundup di Microsoft dedicato ai publisher, Copilot ha nuove capacità basate su MCP, il Model Context Protocol, oggi in open beta sia su Monetize sia su Curate. Le risposte sono ancorate ai dati dell’account Monetize del publisher. L’esempio scelto da Microsoft è una richiesta come “Tell me why this deal isn’t spending”, cioè “dimmi perché questo deal non sta spendendo”. Per farlo l’agente non deve inventare nulla. Deve interrogare la configurazione del deal, i segnali e i log, attraverso un protocollo standard che espone quei dati al modello. Un assistente così però è utile solo se i dati sotto sono puliti, e qui torna il lavoro sui segnali. Resta da vedere se questo vantaggio sia esclusivo.
Tutti vogliono l’assistente, pochi hanno lo stack
La risposta breve è no, almeno per l’interfaccia. Già a febbraio 2026 PubMatic aveva lanciato analytics in linguaggio naturale per i publisher. Più di recente ha presentato AI Insights, disponibile tramite il PubMatic Assistant integrato nella piattaforma. Dà ai publisher visibilità in tempo reale su inventario, prezzi e domanda, confrontati con un gruppo di concorrenti comparabili. Magnite ha seguito la stessa strada: ad aprile 2026 ha rilasciato strumenti di monetizzazione basati sull’IA per i media owner, tra cui il rilevamento di anomalie nelle performance delle aste. Ha anche potenziato la mediazione pubblicitaria in SpringServe con rilevamento anomalie, ottimizzazione dei percorsi di domanda e strumenti di pricing dinamico che si adattano alle condizioni di mercato.
Se ogni SSP ha un assistente che risponde in linguaggio naturale, la chat da sola non distingue più nessuno. Contano la qualità e la standardizzazione dei dati che l’assistente legge, e quelle dei segnali che arrivano al DSP. La domanda per i prossimi trimestri è quale livello dello stack deciderà la competizione: l’interfaccia IA, che tutti stanno costruendo, o la completezza dell’implementazione OpenRTB, che è più lenta e meno visibile ma più difficile da copiare.
Per chi costruisce, le indicazioni sono pratiche. Chi usa ancora l’adattatore AppNexus in Prebid.js deve migrare entro il primo trimestre del 2027. Chi lavora su CTV e video deve verificare che i propri sistemi sappiano leggere e usare i segnali dei pod OpenRTB 2.6, che ora arrivano anche dal lato della domanda. L’agente che spiega perché un deal non spende è la parte che si vede. Il lavoro vero sta nei segnali che lo alimentano.