Supporto delle aste multi-venditore con la mediazione Protected Audience

Le piattaforme pubblicitarie lato vendite in genere diversificano le origini della domanda pubblicitaria per ottimizzare le entrate pubblicitarie. Con la mediazione degli annunci, una rete pubblicitaria o un servizio richiama più reti pubblicitarie per determinare l'annuncio migliore per una determinata area annuncio. Questa proposta introduce come l'API Protected Audience su Android può essere estesa per implementare la funzionalità di mediazione a cascata in modo da tutelare la privacy. Oggi, le reti pubblicitarie offrono agli sviluppatori di app vari modi per mediare le aste degli annunci di più venditori di annunci:

1. Mediazione 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 dell'app utilizza questo elenco per chiamare le reti pubblicitarie nell'ordine in cui sono elencate per determinare le origini della domanda di annunci pertinenti.
2. Mediazione programmatica: più reti pubblicitarie vengono configurate dallo sviluppatore dell'app per partecipare alle offerte per le opportunità pubblicitarie. Queste emittenti possono fare offerte in tempo reale in base al valore che attribuiscono all'opportunità.
3. Mediazione ibrida: una combinazione di tecniche di mediazione a cascata e programmatica.

Mediazione a cascata

Nella mediazione a cascata, quando si presenta un'opportunità pubblicitaria, un SDK annuncio invia una richiesta al server di backend. Anziché rispondere alla richiesta con una creatività 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 lato server, 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 nella catena. Questo processo viene ripetuto finché la richiesta non viene soddisfatta o la catena non viene esaurita.

La mediazione con struttura a cascata viene spesso ottimizzata riordinando regolarmente la catena di mediazione in base alla rivalutazione dell'eCPM delle origini della domanda di annunci proprietarie.

Mediazione programmatica

La mediazione programmatica (nota anche come "asta header") è 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, i fornitori utilizzano invece 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 struttura a cascata e asta per fornire un maggiore controllo sull'annuncio e ottenere il vantaggio di utilizzare eCPM in tempo reale per massimizzare le entrate delle reti pubblicitarie partecipanti.

Nei modelli di mediazione ibrida, le reti pubblicitarie e i fornitori di mediazione possono offrire maggiore flessibilità agli sviluppatori di app combinando elementi di aste a cascata e 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 le offerte in tempo reale con le reti partecipanti per soddisfare le opportunità pubblicitarie.

Mediazione con struttura a cascata Protected Audience

L'API Protected Audience su Android supporta la mediazione a cascata con più aste, ognuna per un singolo nodo nel grafico di mediazione. Se non viene selezionato un vincitore da un'asta, viene chiamato il nodo dell'asta di rete successivo finché la catena non è esaurita. La procedura di mediazione a cascata è la seguente:

1. L'SDK di mediazione recupera la catena di mediazione dall'endpoint dell'ad server contestuale, che può restituire annunci contestuali o catene di mediazione.
2. Se l'endpoint dell'ad server restituisce una catena di mediazione, l'SDK di mediazione itera ogni elemento della catena in ordine, 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 pubblicazione dell'annuncio.
3. Se nessuno degli elementi pubblicitari nella catena sceglie un annuncio vincente, l'SDK di mediazione potrebbe scegliere di mostrare un annuncio della propria rete pubblicitaria eseguendo una selezione di annunci Protected Audience 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 la possibilità per la rete pubblicitaria proprietaria di eseguire l'ottimizzazione. L'API Protected Audience supporta l'ottimizzazione delle reti pubblicitarie proprietarie consentendo il concatenamento dei flussi di lavoro di selezione degli annunci e la generazione di report sulle impressioni vincenti.

AdSelection outcome

Il tipo restituito di 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'elemento pubblicitario vincente.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

AdSelectionId funge da puntatore a AdSelectionOutcome. Oggi, AdSelectionId viene passato al metodo reportResult() come parametro ReportImpressionInput per identificare gli annunci corretti su cui vengono richiamati i metodi reportWin() e reportResult().

Proposta di selezione di annunci a 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 il prezzo minimo dell'offerta della rete successiva in linea.

Esempio 1:

Esempio 2:

Report sulle impressioni vincenti

Se c'è un vincitore da selectAds(AdSelectionFromOutcomes), l'annuncio vince la mediazione. Viene quindi chiamato reportImpression con l'ID selezione annuncio dell'annuncio vincente di selectAds(AdSelectionFromOutcomes) e il AdSelectionConfig corrispondente.

Se il vincitore viene restituito da un selectAds(AdSelectionConfig) per una delle reti, viene chiamato reportImpression con l'ID selezione annuncio e la configurazione di quella chiamata.

Esegui la mediazione a cascata

Ecco l'ordine delle operazioni per eseguire la procedura di mediazione a cascata.

1. Esegui la selezione degli annunci proprietari.
2. Itera la catena di mediazione. Per ogni rete di terze parti, procedi nel seguente modo:
   1. Crea AdSelectionFromOutcomeConfig, incluso il prezzo minimo di offerta dell'SDK proprietario outcomeId e di terze parti
   2. Chiama selectAds() con config del passaggio precedente.
   3. Se il risultato non è vuoto, restituisci l'annuncio.
   4. Chiama il metodo selectAds() dell'adattatore di rete SDK corrente. Se il risultato non è vuoto, restituisci l'annuncio.
3. Se non viene trovato alcun vincitore 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. Il troncamento è un processo spesso utilizzato per attivare l'ottimizzazione proprietaria perfezionando l'elenco dei segmenti 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 l'attivazione dell'ottimizzazione proprietaria lato server. Per ridurre i problemi relativi all'ottimizzazione proprietaria, esegui prima l'asta contestuale e poi esegui l'ottimizzazione proprietaria in base al risultato dell'annuncio vincente, come descritto in precedenza in questa pagina.

Mantieni le catene di mediazione on-device di piccole dimensioni

Per un rendimento ottimale, le catene di mediazione on-device devono essere mantenute di dimensioni ridotte. 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 numero maggiore di nodi comporta un maggior numero di cicli di calcolo richiesti e una maggiore latenza. Considera l'impatto della latenza sulle entrate quando trasmetti i nodi alla valutazione della mediazione on-device.

Considerazioni aggiuntive

L'API Protected Audience non offre una soluzione completa per la mediazione di più spazi pubblicitari. Ogni spazio pubblicitario deve essere elaborato in modo indipendente.

L'API Protected Audience Mediation supporta la mediazione a cascata e la mediazione programmatica limitata. In futuro verranno condivisi maggiori dettagli sul supporto di casi d'uso aggiuntivi per la mediazione programmatica.

Poiché la selezione degli annunci Protected Audience viene eseguita dopo il recupero degli annunci contestuali, l'invocazione dell'API Protected Audience può influire sulla latenza end-to-end delle richieste di annunci.