Il y a un coût caché à chaque SDK publicitaire que vous intégrez. Chacun augmente la taille de votre binaire, allonge le temps de démarrage à froid, introduit des conflits de compatibilité potentiels et crée une dépendance supplémentaire. Pour les éditeurs avec cinq, huit ou douze SDK, l'impact cumulé peut être significatif.
Le vrai coût du bloat SDK
Chaque mégaoctet ajouté compte. Les recherches montrent que les taux de conversion d'installation diminuent avec chaque mégaoctet supplémentaire. Dans les marchés émergents avec un stockage limité et des connexions lentes, l'impact est encore plus prononcé.
Au-delà de la taille, les SDK consomment des ressources à l'exécution. Les utilisateurs qui attendent plus de trois secondes au chargement sont significativement plus susceptibles d'abandonner.
L'audit SDK
Pour chaque SDK, mesurez trois choses : la taille binaire ajoutée, le revenu généré et le taux de remplissage. Vous constaterez presque certainement qu'un ou deux SDK sont responsables de la majorité de votre revenu.
La règle 80/20 s'applique
Dans la plupart des apps, deux à trois SDK génèrent 80 pour cent ou plus du revenu total. L'objectif est de trouver le minimum qui capture le maximum.
Solutions côté serveur
L'Open Bidding de Google permet à plusieurs partenaires de concourir sans nécessiter leurs SDK individuels dans votre app.
L'approche partenaire géré
Un partenaire géré agrège la demande de dizaines de sources côté serveur. Votre app ne voit qu'une seule source — plus de diversité avec moins de surcharge.
Les éditeurs les plus intelligents ne demandent pas « combien de SDK puis-je ajouter ? » Ils demandent « quel est le nombre minimum de SDK pour capturer le maximum de revenus ? » La réponse est presque toujours moins que ce qu'ils ont actuellement.