C'è un costo nascosto per ogni ad SDK che integri nella tua app. Ognuno aumenta la dimensione del binary, allunga il tempo di cold start, introduce potenziali conflitti di compatibilità e crea un'altra dipendenza che necessita di aggiornamento quando escono nuove versioni del sistema operativo. Per i publisher che utilizzano cinque, otto o persino dodici SDK, l'impatto cumulativo sulle prestazioni dell'app e sull'esperienza utente può essere significativo — ed è spesso invisibile perché avviene gradualmente.
Il vero costo del bloat degli SDK
Ogni megabyte aggiunto al binary della tua app conta. Le ricerche mostrano costantemente che i tassi di conversione delle installazioni diminuiscono in modo misurabile con ogni megabyte aggiuntivo. Nei mercati emergenti dove gli utenti hanno spazio di archiviazione limitato e connessioni più lente, l'impatto è ancora più pronunciato. Un publisher che aggiunge tre ad SDK per un totale di 15 megabyte potrebbe perdere più ricavi dalla riduzione delle installazioni di quanto guadagni dalla domanda incrementale fornita da quegli SDK.
Oltre alla dimensione del download, gli SDK consumano risorse a runtime. Ogni SDK che si inizializza all'avvio dell'app aggiunge al tempo di startup. Gli utenti che aspettano più di tre secondi per il caricamento di un'app hanno una probabilità significativamente maggiore di abbandonarla. E ogni SDK in esecuzione in background consuma memoria e batteria — risorse che gli utenti notano e per le quali gli app store penalizzano sempre di più.
L'audit degli SDK
Inizia con un audit del tuo stack SDK attuale. Per ogni ad SDK nella tua app, misura tre cose: la dimensione binary che aggiunge, il revenue che genera e il suo fill rate. Quasi certamente scoprirai che uno o due SDK sono responsabili della maggior parte dei tuoi ricavi, mentre diversi altri contribuiscono marginalmente ma aggiungono un overhead significativo.
La regola dell'80/20 si applica
Nella maggior parte delle app dei publisher, due o tre ad SDK generano l'80 per cento o più del revenue pubblicitario totale. Gli SDK rimanenti colmano lacune ma spesso a un costo che supera il loro contributo quando si tiene conto dell'impatto sulle prestazioni. L'obiettivo non è eliminare tutti gli SDK — è trovare il set minimo che cattura il revenue massimo.
Soluzioni lato server
Il modo più efficace per ridurre il numero di SDK senza perdere la diversità della domanda è spostare l'aggregazione della domanda dal lato client al lato server. L'Open Bidding di Google, ad esempio, consente a più demand partner di competere per il tuo inventario senza richiedere i loro SDK individuali nella tua app. Ottieni la pressione competitiva di più offerenti con la semplicità di una singola integrazione SDK.
L'approccio della domanda gestita
Un demand partner gestito porta questo concetto ancora oltre. Invece di integrare più SDK tu stesso, integri un unico punto di connessione — tramite la tua piattaforma di mediation esistente o tramite un'integrazione leggera lato server. Il partner gestito aggrega la domanda da decine di fonti sulla propria infrastruttura, e la tua app vede solo una singola fonte di domanda. Il risultato è maggiore diversità di domanda con meno overhead SDK.
I publisher più intelligenti non chiedono "quanti SDK posso aggiungere?" Chiedono "qual è il numero minimo di SDK di cui ho bisogno per catturare il massimo revenue?" La risposta è quasi sempre inferiore a quello che hanno attualmente.
Passi pratici per ridurre il bloat degli SDK
1. Rimuovi gli SDK sottoperformanti
Se un SDK genera meno del 5 per cento del tuo revenue pubblicitario totale, considera seriamente di rimuoverlo. Il costo in termini di prestazioni probabilmente supera il contributo in termini di ricavi.
2. Consolida attraverso la mediation
Utilizza gli adapter integrati della tua piattaforma di mediation piuttosto che integrazioni SDK autonome dove possibile. Gli adapter di mediation sono tipicamente più leggeri delle integrazioni SDK complete.
3. Sfrutta il bidding lato server
Sposta i demand partner che supportano il bidding lato server su quel modello. Questo rimuove il loro SDK dalla tua app mantenendo la loro domanda nel tuo waterfall.
4. Usa un partner gestito per la domanda long-tail
Invece di integrare cinque SDK di nicchia per la domanda regionale o specializzata, usa un singolo partner gestito che aggrega quella domanda lato server.
Misurare l'impatto
Dopo aver ridotto il numero di SDK, monitora tre metriche: la riduzione della dimensione dell'app, il miglioramento del tempo di avvio e il revenue pubblicitario totale. Una riduzione degli SDK ben eseguita dovrebbe mostrare miglioramenti misurabili nelle prime due senza cambiamenti significativi — o addirittura un miglioramento — nella terza, poiché una dimensione dell'app ridotta porta a tassi di installazione più alti e una migliore retention degli utenti.