In genere, le piattaforme pubblicitarie lato vendita diversificano le origini della domanda di annunci per ottimizzare le entrate pubblicitarie. Con la mediazione degli annunci, un servizio o una rete pubblicitaria richiama più reti pubblicitarie per determinare l'annuncio migliore per una determinata area annuncio. Questa proposta illustra come l'API Protected Audience su Android può essere estesa per implementare la funzionalità di mediazione a cascata nel rispetto della privacy. Oggi, le reti pubblicitarie offrono agli sviluppatori di app vari modi per mediare le aste di annunci di diversi venditori di annunci:
- Mediazione con struttura a cascata: gli sviluppatori di app definiscono un elenco ordinato di reti pubblicitarie, spesso classificate in base agli eCPMs storici per la rete in questione. Questo elenco è noto come catena di mediazione. La piattaforma di mediazione dello sviluppatore di app utilizza questo elenco per chiamare le reti pubblicitarie nell'ordine in cui sono elencate per determinare le origini della domanda di annunci pertinenti.
- Mediazione programmatica: lo sviluppatore dell'app configura più reti pubblicitarie per partecipare alle offerte per le opportunità pubblicitarie. Queste reti possono fare offerte in tempo reale in base alla valutazione dell'opportunità.
- Mediazione ibrida: una combinazione di tecniche di mediazione waterfall e programmatica.
Mediazione a cascata
Nella mediazione a cascata, quando si presenta un'opportunità pubblicitaria, un SDK annuncio invia una richiesta al proprio server di backend. Invece di rispondere alla richiesta con una creatività dell'annuncio vincente, il server risponde con una catena di mediazione che contiene un elenco di reti pubblicitarie ordinate in base all'eCPM storico.
Figura 1. Il modello di mediazione a cascata.
Nel modello a cascata tradizionale, un SDK per gli annunci chiama ogni rete pubblicitaria (o il proprio SDK per l'asta) nell'ordine specificato dalla catena di mediazione. Se una rete pubblicitaria può soddisfare la richiesta di annuncio, la rete pubblicitaria esegue il rendering dell'annuncio. In caso contrario, la richiesta viene inviata alla rete successiva della catena. Questo processo viene ripetuto finché la richiesta non viene soddisfatta o la catena non è esaurita.
La mediazione con struttura a cascata viene spesso ottimizzata riordinando regolarmente la catena di mediazione in base alla rivalutazione dell'eCPM dalle sorgenti della domanda di annunci proprietari.
Mediazione programmatica
La mediazione programmatica (nota anche come "asta di intestazione") è un'alternativa all'utilizzo dell'eCPM storico per determinare quale rete pubblicitaria ha la possibilità di pubblicare una richiesta di annuncio. Con la mediazione programmatica, invece, i fornitori utilizzano i valori delle offerte in tempo reale per trovare l'annuncio vincente.
Figura 2: il modello di mediazione programmatica
Mediazione ibrida
Alcune soluzioni di mediazione programmatica combinano le reti pubblicitarie in una modalità ibrida di asta e struttura a cascata per offrire un maggiore controllo sull'annuncio, sfruttando al contempo il vantaggio dell'utilizzo di eCPM in tempo reale per massimizzare le entrate provenienti dalle reti pubblicitarie partecipanti.
Nei modelli di mediazione ibrida, le reti pubblicitarie e i fornitori di servizi di mediazione possono offrire una maggiore flessibilità agli sviluppatori di app combinando elementi dell'asta con struttura a cascata e dell'asta in tempo reale. I modelli ibridi consentono agli sviluppatori di app di configurare le reti pubblicitarie in base agli eCPM storici, offrendo loro l'opportunità di mostrare un annuncio prima di eseguire l'asta in tempo reale con le reti partecipanti per soddisfare le opportunità di annunci.
Mediazione con struttura a cascata Protected Audience
L'API Protected Audience su Android supporta la mediazione a cascata grazie a più aste, ciascuna per un singolo nodo nel grafico di mediazione. Se non viene scelto un vincitore per un'asta, viene chiamato il successivo nodo dell'asta di rete finché la catena non è esaurita. La procedura di mediazione a cascata è la seguente:
- L'SDK di mediazione recupera la catena di mediazione dall'endpoint dell'ad server contestuale, che può restituire annunci contestuali o catene di mediazione.
- Se l'endpoint dell'ad server restituisce una catena di mediazione, l'SDK di mediazione esamina in sequenza ogni elemento della catena, richiamando l'SDK della rete pubblicitaria partecipante per eseguire una selezione di annunci contestuali e di remarketing. Ogni elemento della catena rappresenta la richiesta di una rete pubblicitaria di acquistare spazio pubblicitario a un prezzo specifico per una quantità specifica di impressioni, clic o tempo di visualizzazione dell'annuncio.
- Se nessuno degli elementi pubblicitari della catena sceglie un annuncio vincente, l'SDK di mediazione può scegliere di mostrare un annuncio della propria rete pubblicitaria pubblicando una selezione di annunci per pubblico protetto che prende in considerazione sia gli annunci di remarketing sia quelli contestuali.
Figura 3. Mediazione a cascata con l'API Protected Audience.
Il diagramma precedente rappresenta un esempio di algoritmo di mediazione a cascata che un SDK di mediazione può implementare, ma senza che la rete pubblicitaria di proprietà possa ottimizzare. L'API Protected Audience supporta l'ottimizzazione della rete pubblicitaria proprietaria consentendo l'accodamento dei flussi di lavoro di selezione degli annunci e la generazione di report sulle impressioni vincenti.
Risultato di selezione annunci
Il tipo restituito da selectAds() è un oggetto AdSelectionOutcome.
AdSelectionOutcome contiene l'URI di rendering dell'annuncio vincente e un
AdSelectionId, ovvero un numero intero opaco che identifica la creatività dell'annuncio dell'elemento pubblicitario vincente.
AdSelectionOutcome {
Uri renderUri;
Long AdSelectionId;
}
AdSelectionId agisce come un puntatore a AdSelectionOutcome. Attualmente,
AdSelectionId viene passato al metodo reportResult() come
ReportImpressionInput parametro per identificare gli annunci corretti su cui vengono invocati i metodi
reportWin() e reportResult().
Proposta di selezione di annunci in catena
Proponiamo di sovraccaricare selectAds() con AdSelectionFromOutcomesConfig.
val config = AdSelectionFromOutcomesConfig.Builder()
.setSeller(seller)
.setAdSelectionIds(listOf(outcome1pAdSelectionId))
.setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
.setSelectionLogicUri(selectionLogicUri)
.build()
adSelectionClient.selectAds(config)
In questo modo, l'SDK di mediazione può confrontare l'offerta dell'annuncio vincente con la base di offerta della rete successiva in linea.
Esempio 1:
Esempio 2:
Segnalare le impressioni vincenti
Se esiste un annuncio vincente tra quelli di selectAds(AdSelectionFromOutcomes), questo vince la mediazione. Quindi, reportImpression viene chiamato con l'ID selezione dell'annuncio vincente di selectAds(AdSelectionFromOutcomes) e il corrispondente AdSelectionConfig.
Se il vincitore viene restituito da un selectAds(AdSelectionConfig) per una delle reti, reportImpression viene chiamato con l'ID selezione dell'annuncio e la relativa configurazione da quella chiamata.
Eseguire la mediazione a cascata
Di seguito è riportato l'ordine delle operazioni per eseguire la procedura di mediazione con struttura a cascata.
- Esegui la selezione degli annunci proprietari.
- Esegui l'iterazione della catena di mediazione. Per ogni emittente di terze parti, svolgi quanto segue:
- Crea
AdSelectionFromOutcomeConfig, inclusioutcomeIddi proprietà e la soglia di offerta dell'SDK di terze parti - Chiama
selectAds()con ilconfigdel passaggio precedente. - Se il risultato non è vuoto, restituisce l'annuncio.
- Chiama il metodo
selectAds()dell'adattatore di rete dell'SDK corrente. Se il risultato non è vuoto, restituisce l'annuncio.
- Crea
- Se non viene trovato alcun annuncio vincente nella catena, restituisci l'annuncio proprietario.
Best practice
Esegui aste contestuali prima dell'ottimizzazione proprietaria
La domanda di remarketing può generare offerte elevate che possono produrre risultati vincenti in una catena di mediazione. La troncatura è un processo spesso utilizzato per attivare l'ottimizzazione proprietaria perfezionando l'elenco del segmento di pubblico per il remarketing.
La domanda di remarketing dell'API Protected Audience è disponibile solo lato client con le aste Protected Audience. Ciò può rendere difficile attivare l'ottimizzazione proprietaria lato server. Per ridurre i problemi relativi all'ottimizzazione proprietaria, esegui prima l'asta contestuale e poi l'ottimizzazione proprietaria in base al risultato dell'annuncio vincente, come descritto in precedenza in questa pagina.
Mantieni piccole le catene di mediazione on-device
Per un rendimento ottimale, le catene di mediazione on-device devono essere ridotte al minimo. Il costo di calcolo per l'esecuzione sul dispositivo può essere lineare in base al numero di aste valutate nell'ambito della catena di mediazione. In altre parole, un maggior numero di nodi comporta un aumento dei requisiti dei cicli di calcolo e della latenza. Prendi in considerazione l'impatto della latenza sulle entrate quando passi i nodi alla valutazione della mediazione on-device.
Considerazioni aggiuntive
L'API Protected Audience non offre una soluzione completa per la mediazione di più aree annuncio. Ogni area annuncio deve essere elaborata in modo indipendente.
L'API Protected Audience Mediation supporta la mediazione a cascata e la mediazione programmatica limitata. In futuro verranno condivisi ulteriori dettagli sul supporto di altri casi d'uso della mediazione programmatica.
Poiché la selezione degli annunci Protected Audience viene eseguita dopo il recupero degli annunci contestuali, invocare l'API Protected Audience potrebbe influire sulla latenza end-to-end delle richieste di annunci.