Come implementare l’Header Bidding in una mobile app?

Se siete degli sviluppatori, è normale che vogliate ottenere il massimo rendimento possibile dalla vostra inventory pubblicitaria. L’Header Bidding è sicuramente un buon modo, ma prima di poter vedere un effettivo aumento dei ricavi, bisogna capire come lavorare correttamente all’interno dell’app. E questo è esattamente quello che vedremo. Il problema Prima di addentrarci nell’implementazione dell’header bidding, è importante rivedere il vostro tradizionale setup a cascata, in cui ad ogni ad network viene assegnata una specifica priorità. Prendiamo questo esempio come riferimento:

1. Domanda Diretta
2. Domanda in Programmatic
3. Admob

A una prima occhiata, sembrerebbe tutto a posto. Ma guardate meglio. Riuscite a individuare il problema? Ecco una prima falla. Admob non può competere per una prima chiamata perché questa è sempre una vendita diretta all’inserzionista. Mettiamo da parte Domanda Diretta e Domanda in Programmatic per un momento e consideriamo questo esempio:

1. Applovin
2. Mopub
3. UnityAds
4. Adcolony

Meglio? Non del tutto. Adesso abbiamo un secondo problema. Adcolony è sempre alla fine della cascata e non può competere per il traffico premium. Aspettate! C’è dell’altro. Applovin è in cima. Questo vuol dire che non può competere per l’invenduto, dato che bisogna essere alla fine della cascata per poterlo fare. La soluzione Se tutti questi problemi vi stanno mettendo ansia, non vi preoccupate. E’ adesso che entra in campo l’Header Bidding. Con l’Header Bidding, potete mandare una richiesta preliminare ad ogni sorgente di domanda per verificare quanto ciascuna è disposta a pagare per quella impression, senza effettivamente servire nessuna impression. A questo punto aggiorniamo l’esempio di poco fa:

• Applovin: $10 eCPM
• MoPub: $5 eCPM
• UnityAds: $15 eCPM
• Adcolony: $12 eCPM*

Il vincitore? E’ UnityAds, con un eCPM di 15 dollari. Dal momento che non siamo lavorando in un sistema a cascata, UnityAds non ha una posizione fissata nel sistema; può competere alla prima chiamata e persino vincere. *nb: al momento, non state ancora servendo nessun annuncio. State semplicemente dando un’occhiata ai bid per determinare il vincitore. Dunque, per questa specifica impression, il nostro ordine avrà questo aspetto:

1. UnityAds
2. Adcolony
3. Applovin
4. Mopub

E se aveste usato un sistema a cascata? Indovinate un po’. Avreste servito quella impression ad Applovin per un eCPM di 10 dollari, perdendo l’opportunità di venderla a Unity a 15 dollari. Ahia. * Notare che i numeri mostrati qui non si riferiscono agli effettivi eCPM di ciascuno degli ad network. L’ecosistema mobile e l’Header Bidding L’Header Bidding esiste da un po’. E’ stato inventato da editori desktop come un modo per appiattire il sistema a cascata. Il suo obiettivo sottinteso era obbligare i partner a dichiarare preventivamente il valore assegnato a un’inventory. In quell’ecosistema, la falla dell’header bidding sta nel fatto che richiede un protocollo speciale lato offerta. Ma per fortuna, l’ambiente mobile è diverso. Come mai? E’ molto comune per le app mobile fare richiesta di un annuncio pubblicitario e non servirlo mai. La ragione principale è il pre-caching, che è utilizzato per evitare il ritardo tra la richiesta di visualizzazione di un annuncio e la sua effettiva erogazione. Esaminiamo il pre-caching in modo più dettagliato. In un pre-cache, lo sviluppatore avvia il SDK pubblicitario immediatamente al lancio dell’app e salva in cache l’annuncio. Il vantaggio è che si ha a disposizione in cache una pubblicità da mostrare immediatamente in qualsiasi momento e posizione. C’è però il rischio che l’utente abbandoni l’app prima l’annuncio venga mostrato. A causa del pre-caching, nel mondo delle app mobile è abbastanza comune un basso livello di resa. Il Setup dell’Header Bidding Ecco una buona notizia per l’implementazione dell’header bidding in un’app mobile. Non è richiesto un protocollo speciale come su desktop. Potete utilizzare il seguente setup:

• Create un elenco multiplo per ogni partner demand-side e assegnate a ogni voce un price floor diverso. Questo step si applica anche ad alcuni partner non in programmatic che supportano i price floor.

Ma mettiamo che volete provarci in un altro modo. Potete raggiungere lo stesso risultato impostando un frequency cap per ogni voce. Ecco un esempio che illustra entrambi gli approcci: Mopub Marketplace:

• Voce 1 (Price Floor $0.5)
• Voce 2 (Price Floor $1.0)
• Voce 3 (Price Floor $1.5)
• Voce N (Price Floor $N)

Admob:

• Ad unit 1 (Price Floor $0.5)
• Ad unit 2 (Price Floor $1.0)
• Ad unit 3 (Price Floor $1.5)
• Ad unit N (Price Floor $N)

Applovin:

• Ad Unit 1 (Frequency Cap 1, eCPM medio $6.43)
• Ad Unit 2 (Frequency Cap 5, eCPM medio $3.52)
• Ad Unit 3 (Frequency Cap aperto, eCPM medio $0.2)

E ora il risultato, che è la cosa che importa di più: Si finisce con un grande sistema a cascata che in sostanza implementa l’Header Bidding.

1. Applovin Ad Unit 1 (Frequency Cap 1, eCPM medio $6.43)
2. Applovin Ad Unit 2 (Frequency Cap 5, eCPM medio $3.52)
3. Mopub Line Item 3 (Price Floor $1.5)
4. Admob Ad Unit 3 (Price Floor $1.5)
5. Mopub Line Item 2 (Price Floor $1)
6. Admob Ad Unit 2 (Price Floor $1)
7. Mopub Line Item 1 (Price Floor $0.5)
8. Admob Ad Unit 1 (Price Floor $0.5)
9. Applovin Ad Unit 3 (Frequency Cap aperto, eCPM medio $0.2)

Resta ancora un passo da compiere. Adesso è il momento di attraversare la cascata nel momento del lancio dell’app. Fatelo prima che gli utenti richiedano che l’annuncio venga mostrato o prima che sia il momento di farne un refresh. Adesso siamo alla fine. Attraversando il sistema a cascata, avrete visto che il primo partner che soddisfa una richiesta essenzialmente valuta la vostra impression più di tutti gli altri. Il che, di conseguenza, dà una bella spinta al fondo della vostra cascata.