Main partner:

Jobs

Appodeal rilascia il kit di sviluppo per le app Apple TV

Appodeal, la soluzione di monetizzazione per applicazioni mobili, è adesso in grado di supportare annunci sulle applicazioni di Apple TV. La nuova soluzione SDK permette agli sviluppatori di incorporare pubblicità all’interno delle app del servizio OTT di Cupertino, oltre che ottimizzare le campagne e condurre attività promozionali per le applicazioni iOS e tvOS.

Grazie alle soluzioni rilasciate dall’azienda guidata da Pavel Golubev, gli editori possono includere inserzioni nelle loro app tvOS in formato video saltabile e non saltabile, della lunghezza massima di trenta secondi, e in formato rewarded video, ossia annunci video in-app che conferiscono agli utenti un premio per guardare il contenuto, come ad esempio denaro, prodotti o altri incentivi. Inoltre, gli sviluppatori possono creare campagne con inserzionisti diretti.

Il nuovo SDK offre agli editori opportunità per la promozione incrociata dei loro progetti: posizionando gli annunci delle loro app Apple TV all’interno delle proprie applicazioni per iPhone e iPad, gli editori possono attrarre verso la nuova piattaforma un’utenza più fedele.

Programmatic mobile: Appodeal sbarca in Europa

Appodeal sbarca in Europa.

La società fondata nel 2015 a San Francisco e specializzata in soluzioni di mediazione in programmatic per le app mobile ha infatti aperto una nuova sede a Barcellona, da dove gestirà le operazioni per i mercati del Vecchio Continente. Entro la fine dell’anno, la società conta di assumere una decina di dipendenti per coprire le aree di Risorse Umane, Vendite ed Eventi.

Attualmente, Appodeal conta 253 sviluppatori in Spagna che lavorano con la società per massimizzare le revenue delle delle loro applicazioni e conta di arrivare a 500 entro la fine dell’anno.

Il business sarà coordinato da Anna Bai, in qualità di director of Appodeal Europe.

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.

bidding-appodeal

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

mobile-appodeal

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.

Le più lette