Supporto delle aste multi-venditore con la mediazione Protected Audience

Inviare feedback

In genere, le piattaforme pubblicitarie lato vendite diversificano le origini della domanda di annunci per ottimizzare le entrate pubblicitarie. Con la mediazione annunci, una rete pubblicitaria o un servizio richiama più reti pubblicitarie per determinare l'annuncio migliore per una determinata area annuncio. Questa proposta introduce il modo in cui l'API Protected Audience su Android può essere estesa per implementare la funzionalità di mediazione a cascata con un approccio incentrato sulla tutela della 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 della 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.
  2. Mediazione programmatica: lo sviluppatore di app ha configurato più reti pubblicitarie per partecipare alle offerte per le opportunità di annunci. Queste reti possono fare offerte in tempo reale in base al modo in cui valutano l'opportunità.
  3. Mediazione ibrida: una combinazione di tecniche a cascata e di mediazione programmatica.

Mediazione con struttura a cascata

Nella mediazione a cascata, quando si verifica un'opportunità di annuncio, un SDK per gli annunci invia una richiesta al proprio server di backend. Anziché rispondere alla richiesta con una creatività dell'annuncio vincente, il server risponde con una catena di mediazione contenente un elenco di reti pubblicitarie ordinate in base all'eCPM storico.

Diagramma del modello di mediazione con struttura a cascata
Figura 1. Il modello di mediazione con struttura a cascata.

Nel modello tradizionale con struttura a cascata, 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, l'annuncio viene visualizzato dalla rete pubblicitaria. In caso contrario, la richiesta viene inviata alla rete successiva nella catena. Questo processo viene ripetuto fino a quando la richiesta non viene soddisfatta o fino a esaurimento della catena.

La mediazione con struttura a cascata viene spesso ottimizzata riordinando regolarmente la catena di mediazione in base alla nuova valutazione dell'eCPM dalle origini della domanda degli annunci proprietari.

Mediazione programmatica

La mediazione programmatica (nota anche come "offerte su intestazioni") è 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 usano i valori dell'offerta in tempo reale per trovare l'annuncio vincente.

Diagramma del modello di mediazione programmatica
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 al contempo ottenere il vantaggio di utilizzare gli eCPM in tempo reale al fine di massimizzare le entrate provenienti dalle reti pubblicitarie partecipanti.

Nei modelli di mediazione ibridi, le reti pubblicitarie e i fornitori di mediazione possono offrire una maggiore flessibilità agli sviluppatori di app combinando elementi di struttura a cascata e offerte in tempo reale. I modelli ibridi consentono agli sviluppatori di app di configurare le reti pubblicitarie in base agli eCPM storici, dando loro l'opportunità di mostrare un annuncio prima di eseguire offerte in tempo reale con le reti partecipanti per riempire le opportunità di annunci.

Mediazione a cascata di Protected Audience

L'API Protected Audience su Android supporta la mediazione a cascata tramite più aste, ciascuna per un singolo nodo nel grafico di mediazione. Se un'asta non ha un vincitore, viene chiamato il successivo nodo dell'asta di rete fino a quando 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 esegue l'iterazione in ogni elemento della catena, richiamando l'SDK della rete pubblicitaria partecipante per eseguire una selezione di annunci contestuale e di remarketing. Ogni elemento della catena rappresenta la richiesta di una rete pubblicitaria di acquistare uno spazio pubblicitario a un prezzo specifico per una quantità specifica di impressioni, clic o durata dell'annuncio.
  3. Se nessuno degli elementi pubblicitari della catena sceglie un annuncio vincente, l'SDK di mediazione potrebbe scegliere di mostrare un annuncio dalla propria rete pubblicitaria eseguendo una selezione di annunci dei segmenti di pubblico protetti che considera sia gli annunci di remarketing sia quelli contestuali.

Diagramma del flusso di mediazione a cascata di Protected Audience
Figura 3. Mediazione con struttura a cascata con l'API Protected Audience.

Il diagramma precedente rappresenta un esempio di algoritmo di mediazione con struttura a cascata che un SDK di mediazione può implementare, ma senza la possibilità di ottimizzare la rete pubblicitaria proprietaria. L'API Protected Audience supporta l'ottimizzazione delle reti pubblicitarie proprietarie consentendo il concatenamento dei flussi di lavoro per la selezione degli annunci e la generazione di report sulle impressioni vincenti.

Risultato selezione annunci

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'annuncio 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 sono richiamati i metodi reportWin() e reportResult().

Proposta di selezione degli annunci della catena

Proponiamo di sovraccaricare con AdSelectionFromOutcomesConfig le selectAds().

val config = AdSelectionFromOutcomesConfig.Builder()
        .setSeller(seller)
        .setAdSelectionIds(listOf(outcome1pAdSelectionId))
        .setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
        .setSelectionLogicUri(selectionLogicUri)
        .build()
adSelectionClient.selectAds(config)

Ciò consente all'SDK di mediazione di confrontare l'offerta dell'annuncio vincitore con l'offerta minima della rete successiva in linea.

Esempio 1:

Esempio 2:

Segnala impressioni vincenti

Se esiste un vincitore tra selectAds(AdSelectionFromOutcomes), questo annuncio vince la mediazione. A questo punto, viene chiamato reportImpression con l'ID selezione degli annunci dell'annuncio vincitore di selectAds(AdSelectionFromOutcomes) e il corrispondente AdSelectionConfig.

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

Eseguire la mediazione a cascata

Ecco l'ordine delle operazioni per l'esecuzione del processo di mediazione a cascata.

  1. Esegui la selezione degli annunci proprietari.
  2. Ripeti il processo sulla catena di mediazione. Per ogni rete di terze parti:
    1. Creazione di AdSelectionFromOutcomeConfig, inclusi la proprietà outcomeId e l'offerta minima dell'SDK di terze parti
    2. Chiama selectAds() con il 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

Eseguire aste contestuali prima dell'ottimizzazione proprietaria

La domanda di remarketing può generare offerte elevate che possono generare risultati vincenti in una catena di mediazione. Il troncamento è un processo spesso utilizzato per consentire 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ò complicare l'abilitazione dell'ottimizzazione proprietaria lato server. Per mitigare i problemi con l'ottimizzazione proprietaria, esegui prima l'asta contestuale, quindi esegui l'ottimizzazione proprietaria in base al risultato dell'annuncio vincente come descritto in precedenza in questa pagina.

Riduci le dimensioni delle tue catene di mediazione sul dispositivo

Per un rendimento ottimale, le catene di mediazione on-device devono essere ridotte. Il costo di calcolo per l'esecuzione on-device può essere lineare per il numero di aste valutate nell'ambito della catena di mediazione. In altre parole, un maggior numero di nodi richiede più cicli di calcolo e una maggiore latenza. Considera 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 condivideremo ulteriori dettagli sul supporto di ulteriori casi d'uso della mediazione programmatica.

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