Pubblicità programmatic in-app: come le DSP acquistano l’inventory delle app mobile

La maggior parte dei media buyer inizia dall’open web. Il modello mentale che ne deriva — un URL di pagina, un cookie, un referrer, un dominio da inserire in una whitelist — lì funziona abbastanza bene. Poi lo stesso buyer attiva l’inventory delle app mobile, e metà di quei segnali sparisce senza far rumore. Non c’è un URL. Non c’è un cookie di terze parti. Il campo del dominio è vuoto, e al suo posto arriva un bundle ID che sembra una sequenza di parole al contrario.

Non si tratta di una versione in scala ridotta del buying sul web. L’inventory in-app viaggia attraverso una supply chain diversa, porta con sé un insieme diverso di identificatori, usa formati pubblicitari che il web non ha mai avuto e viene verificata con un file diverso. Una DSP che tratta un’impression in-app come un’impression web comprerà le cose sbagliate, interpreterà male i propri report e spenderà budget su placement che non può vedere.

Questa guida spiega come funziona davvero l’advertising programmatic in-app: cosa contiene una bid request da app, come il livello di SDK e mediation si colloca tra un publisher e la tua piattaforma, quali formati una DSP deve supportare, come sono cambiati identità e misurazione dopo che le piattaforme mobile hanno stretto le maglie sulla privacy, e cosa dovrebbe configurare chi possiede la piattaforma prima di comprare traffico da app su larga scala.

Cos’è l’advertising programmatic in-app?

L’advertising programmatic in-app è l’acquisto automatizzato di placement pubblicitari all’interno delle applicazioni mobile — giochi, app di news, utility, app di streaming — tramite aste in tempo reale anziché con ordini di inserzione diretti. I meccanismi sono gli stessi dell’asta usata ovunque nel programmatic: un placement diventa disponibile, una bid request lo descrive, i buyer collegati rispondono con un prezzo e l’offerta idonea più alta si aggiudica l’impression.

Quello che cambia è l’ambiente. Un’app mobile non è un browser. Non ha un cookie jar condiviso, né una barra degli indirizzi, né un document object model che un annuncio possa ispezionare. Tutto ciò di cui l’annuncio ha bisogno — rendering, misurazione, gestione dei click — deve essere fornito dal codice che il publisher ha compilato all’interno dell’app stessa, ed è per questo che il software development kit (SDK) è l’elemento che definisce questo canale.

L’asta sottostante segue comunque la stessa sequenza descritta nella nostra guida su come funziona il real-time bidding. Se conosci un’asta OpenRTB sul web, conosci già il novanta percento di quella in-app. Il resto è l’argomento di questo articolo.

In cosa una bid request in-app è diversa da una web

In OpenRTB, una bid request descrive la propria inventory usando un oggetto site oppure un oggetto app. Non dovrebbe mai contenerli entrambi. È proprio questa biforcazione a dire al tuo bidder in quale mondo sta comprando, e quasi tutte le differenze pratiche derivano da lì.

L’oggetto app identifica l’applicazione tramite il bundle ID — il package name su Android o l’ID numerico dell’App Store su iOS — insieme a uno store URL, al nome dell’app e a un blocco publisher. Al posto di un URL di pagina e di un referrer, la tua logica di targeting e di blocco deve basarsi sul bundle. Al posto di un cookie, il dispositivo viene identificato da un advertising ID azzerabile passato nell’oggetto device, quando l’utente lo ha consentito.

Lato buy side, due campi meritano un’attenzione particolare. Il primo è device.lmt, il flag limit-ad-tracking: quando è attivo, l’utente ha scelto di non ricevere pubblicità personalizzata e qualsiasi segmento di audience legato a quel dispositivo va ignorato, non riutilizzato di nascosto. Il secondo è app.bundle, perché un bundle malformato o non coerente è in assoluto il segnale più comune di traffico da app falsificato.

La supply chain in-app: SDK, mediation ed exchange

Sul web, un publisher può aggiungere un demand partner incollando un tag. In un’app, aggiungere domanda ha storicamente significato integrare un altro SDK e pubblicare una nuova versione dell’app passando per la revisione dello store. Questo attrito ha plasmato l’intero canale, ed è il motivo per cui un livello intermedio — la mediation — è diventato lo standard.

Una piattaforma di mediation risiede nell’app come un unico SDK e gestisce dietro di sé tutte le fonti di domanda collegate. Le prime soluzioni di mediation funzionavano con un waterfall a classifica, chiamando i network uno alla volta in base al prezzo medio storico. Le configurazioni moderne usano invece l’in-app bidding, che chiede a tutte le fonti collegate di fare un’offerta sulla stessa impression contemporaneamente — lo stesso cambiamento strutturale descritto nel nostro confronto header bidding vs waterfall.

Dal punto di vista della tua DSP, la conseguenza pratica è la distanza. Tra l’app e il tuo bidder possono esserci una piattaforma di mediation, una supply-side platform e uno o più reseller, ognuno dei quali trattiene una percentuale e ognuno in grado di aggiungere o perdere segnali lungo il percorso. Accorciare e verificare questa catena è proprio lo scopo della supply path optimization, e conta più in-app che sul web perché la catena di solito è più lunga.

La supply chain determina anche ciò che puoi far rispettare. Una connessione diretta con un SSP ti permette di negoziare un feed pulito a livello di bundle e di avere qualcuno che ne risponda. Un feed di un reseller al quarto passaggio raramente ti dà l’una o l’altra cosa. La nostra checklist su come collegare gli SSP alla tua DSP vale qui per intero, con un’aggiunta: chiedi esplicitamente se il feed è supply diretta da app o aggregata.

I formati in-app che una DSP deve supportare

L’inventory delle app è guidata dai formati in un modo che il display web non conosce. I giochi in particolare monetizzano tramite placement a schermo intero e basati su ricompense, e una piattaforma che serve solo banner verrà esclusa dalla maggior parte della supply di valore ancora prima che inizi l’asta.

• Banner. Piccoli placement fissi ancorati alla parte superiore o inferiore dello schermo. Costo basso, volumi alti, e rendering tramite il container MRAID anziché un semplice iframe.
• Interstitial. Un’unità a schermo intero mostrata in una pausa naturale, ad esempio tra un livello e l’altro di un gioco o dopo un articolo. Più attenzione, prezzo più alto e requisiti creativi più rigidi.
• Rewarded video. L’utente sceglie di guardare un video in cambio di valuta in-app o di una vita extra. I tassi di completamento sono alti perché lo scambio è esplicito, e il formato è dominato dalla supply gaming.
• Native. Un annuncio visualizzato con il layout e lo stile propri dell’app, composto da asset separati per titolo, immagine e call-to-action anziché da un’unica creatività fissa.
• Playable. Una breve demo interattiva, usata soprattutto per le campagne di app install, distribuita come creatività interattiva autonoma.

Due standard tecnici reggono la maggior parte di tutto questo. MRAID definisce come una creatività rich media comunica con l’SDK ospitante — come si espande, si chiude o apre un click-through. VAST definisce come vengono descritti una creatività video e i suoi eventi di tracciamento. Una DSP che compra inventory da app ha bisogno di entrambi, oltre alla struttura degli asset native, altrimenti buona parte delle risposte verrà semplicemente scartata come incompatibile.

Il supporto dei formati cambia anche il modo in cui leggi le performance. Il completamento di un rewarded video non è paragonabile alla visualizzazione di un banner, e fare la media in un unico numero aggregato nasconde quale formato stia davvero funzionando. Suddividere win rate, CPM e report sulle conversioni per formato è il livello minimo di reporting utile per le campagne in-app.

Identità e misurazione all’interno delle app

Le app non hanno mai usato i cookie di terze parti. Usavano un identificatore pubblicitario fornito dalla piattaforma: l’IDFA su iOS e il Google Advertising ID su Android. Entrambi sono azzerabili dall’utente ed entrambi sono legati al dispositivo anziché al browser, il che storicamente ha reso il targeting in-app più stabile, non meno, di quello web.

Le cose sono cambiate con App Tracking Transparency. Da iOS 14.5, un’app deve chiedere il permesso all’utente prima di accedere all’IDFA per il tracciamento cross-app, e senza quel permesso l’identificatore non è disponibile. Android si è mosso in una direzione simile con il proprio opt-out e con il lavoro sulla Privacy Sandbox. Il risultato è un grande volume di traffico da app realmente anonimo a livello di dispositivo.

La misurazione si è adattata tramite framework di attribuzione gestiti dalle piattaforme — SKAdNetwork di Apple e il suo successore AdAttributionKit — che riportano le conversioni di installazione in forma aggregata e ritardata, invece di esporre un percorso click-installazione a livello di singolo utente. Per un buyer, questo significa che i dati di performance sulle installazioni arrivano più tardi e meno dettagliati rispetto ai dati di conversione web, e il pacing delle campagne deve tollerare questo ritardo.

La risposta pratica non è inseguire l’identificatore mancante. È puntare sui segnali che restano: il bundle, il placement, il formato, l’area geografica, l’orario e i tuoi dati di conversione first-party. Oggi l’ottimizzazione contestuale e a livello di inventory fa la maggior parte del lavoro in-app, ed è uno dei motivi per cui possedere la logica di bidding è importante — puoi pesare quei segnali tu stesso invece di accettare il modello fisso di un vendor.

Verificare la supply da app: app-ads.txt e pulizia dei bundle

L’inventory da app ha un tipo di frode specifico: la falsificazione del bundle ID. Un’app di scarso valore o inesistente si spaccia per un’app popolare, e un buyer che punta a quell’app popolare paga un premium per un’impression che non è mai avvenuta dove dichiarava. Dato che il buyer non può aprire un URL e guardare la pagina, l’inganno è più difficile da individuare manualmente rispetto al web.

La risposta del settore è app-ads.txt. Lo sviluppatore pubblica un file dei seller autorizzati sul dominio indicato nella scheda dello store dell’app, e qualsiasi buyer può recuperarlo e verificare che il seller che offre l’impression sia effettivamente autorizzato a venderla. Il funzionamento, insieme al file sellers.json che completa la catena nella direzione opposta, è trattato nel nostro articolo su ads.txt, app-ads.txt e sellers.json.

Oltre al file, alcuni controlli intercettano quasi tutto il resto. Verifica che il bundle esista davvero nello store di riferimento. Confronta il nome dichiarato dell’app con il bundle. Fai attenzione a un singolo bundle che compare presso un numero poco plausibile di seller non correlati tra loro. E considera le richieste con bundle mancante o malformato come non acquistabili, anziché come generico traffico mobile.

Cosa configurare prima di comprare traffico da app su larga scala

Attivare la supply da app è un lavoro di configurazione, non un interruttore. L’elenco qui sotto segue l’ordine che di solito riserva meno sorprese.

1. Separa le campagne app da quelle web. Formati diversi, identificatori diversi, benchmark diversi. Mescolarle le rende entrambe illeggibili.
2. Abilita i formati che puoi davvero servire. Verifica il supporto end to end di MRAID, VAST e degli asset native prima di fare offerte su quei placement, non dopo.
3. Attiva la verifica app-ads.txt. Rendila una condizione di bidding, non un report post-campagna.
4. Parti da una allowlist di bundle. Compra prima un insieme noto di app, impara cosa funziona, poi allarga. Il targeting aperto su tutta la supply da app è il modo più costoso per scoprire una blocklist.
5. Imposta i frequency cap per dispositivo, non per cookie. La logica di frequenza in-app si basa sull’advertising ID e deve degradare in modo controllato quando quell’ID è assente.
6. Dai alle campagne di installazione una finestra di misurazione più lunga. L’attribuzione aggregata arriva in ritardo; giudicare il primo giorno sui dati dello stesso giorno ti porterà fuori strada.
7. Fai reporting per bundle e per supply path. Il bundle ti dice cosa hai comprato; il path ti dice quanto hai pagato per ottenerlo.

Ogni punto di questo elenco è più semplice quando la piattaforma è tua. Su un seat in affitto, supporto dei formati, regole di verifica e logica di bidding sono quello che il vendor ha deciso di rendere disponibile. Su una piattaforma di proprietà sono impostazioni che controlli tu — e il buying in-app è proprio il canale in cui questi controlli decidono se la spesa funziona.

Pronto a comprare inventory da app sulla tua DSP?

AdTech Europe fornisce la tecnologia demand-side platform alla base di agenzie, ad network e team di media buying che preferiscono possedere la propria infrastruttura anziché affittare l’accesso a quella di qualcun altro. Ogni piano include scalabilità QPS illimitata, branding white-label e accesso a oltre 1.000 integrazioni SSP che coprono web, app e canali emergenti, così la supply da app fa parte della piattaforma invece di essere un componente aggiuntivo da negoziare a parte.

A settembre 2026, la White Label DSP costa $500 al mese, senza costi di setup e con contratto mensile, ed è operativa entro 24 ore. Una DSP License costa $25,000 una tantum e una DSP Acquisition con piena proprietà del codice sorgente costa $50,000 una tantum, entrambe disponibili in cinque rate mensili ed entrambe operative in cinque-sette giorni lavorativi. I dettagli aggiornati sono sempre disponibili nella pagina dei prezzi.

Se stai pensando di aggiungere inventory da app al tuo media mix e vuoi analizzare formati, verifica della supply e configurazione del bidder sulle tue campagne, puoi prenotare una call sulla strategia programmatic con il team.

FAQ

Cos’è l’advertising programmatic in-app?

L’advertising programmatic in-app è l’acquisto automatizzato di placement pubblicitari all’interno delle applicazioni mobile tramite aste in tempo reale. I meccanismi d’asta sono gli stessi del resto del programmatic, ma l’inventory è descritta da un bundle ID dell’app anziché da un URL di pagina, e l’annuncio viene visualizzato da un SDK all’interno dell’app anziché da un browser.

In cosa una bid request in-app è diversa da una bid request web?

Una richiesta in-app contiene un oggetto app di OpenRTB anziché un oggetto site. Questo significa un bundle ID e uno store URL al posto di dominio e URL di pagina, un advertising ID del dispositivo al posto di un cookie, e segnali di formato per unità interstitial, rewarded o playable che l’open web non usa.

Cos’è app-ads.txt e perché è importante per il buying in-app?

App-ads.txt è un file pubblicato sul sito web dello sviluppatore dell’app che elenca i seller autorizzati a vendere l’inventory di quell’app. I buyer lo usano per verificare che chi offre un’impression in-app abbia effettivamente il diritto di venderla, ed è la principale difesa contro la falsificazione del bundle ID.

Si può ancora fare audience targeting nelle app dopo App Tracking Transparency?

L’audience targeting a livello di dispositivo funziona solo quando l’utente ha concesso il permesso e l’advertising ID è presente nella richiesta. Per il resto del traffico da app, il targeting si basa su segnali contestuali e a livello di inventory come il bundle, il placement, il formato, l’area geografica e l’orario, oltre ai tuoi dati di conversione first-party.

Perché una DSP ha bisogno del supporto MRAID e VAST per l’inventory da app?

MRAID definisce come una creatività rich media interagisce con l’SDK del publisher, e VAST definisce come vengono descritte le creatività video e i relativi eventi di tracciamento. Senza entrambi, buona parte dei placement in-app rifiuterà o scarterà la tua creatività, e quelle bid response non si trasformeranno mai in impression erogate.

Cos’è la mediation nell’advertising per app mobile?

La mediation è un livello all’interno dell’app che gestisce più fonti di domanda tramite un unico SDK, evitando al publisher di integrare ogni partner separatamente. La mediation tradizionale funzionava con un waterfall a classifica; l’in-app bidding moderno chiede a tutte le fonti collegate di fare un’offerta sulla stessa impression contemporaneamente.

Serve una DSP di proprietà per comprare inventory in-app?

No, ma la proprietà cambia ciò che puoi controllare. Su una piattaforma di proprietà sei tu a impostare il supporto dei formati, le regole di verifica della supply, le allowlist di bundle e la logica di bidding, invece di lavorare entro i limiti della configurazione che un seat in affitto rende disponibile.