Každé reklamní SDK, které do své aplikace integrujete, má skrytý náklad. Každé přidává k binary size, prodlužuje dobu cold start, přináší potenciální konflikty kompatibility a vytváří další závislost, kterou je třeba aktualizovat s novými verzemi OS. Pro publishery provozující pět, osm nebo dokonce dvanáct SDK může být kumulativní dopad na výkon aplikace a uživatelský zážitek značný — a často je neviditelný, protože se hromadí postupně.
Skutečné náklady SDK bloatu
Každý megabajt přidaný k binary vaší aplikace se počítá. Výzkumy opakovaně ukazují, že konverzní poměry instalací měřitelně klesají s každým dalším megabajtem velikosti ke stažení. Na rozvíjejících se trzích, kde mají uživatelé omezené úložiště a pomalejší připojení, je dopad ještě výraznější. Publisher, který přidá tři reklamní SDK o celkové velikosti 15 megabajtů, může na snížených instalacích ztrácet více revenue, než kolik získá z přírůstkové poptávky, kterou tato SDK poskytují.
Kromě velikosti ke stažení spotřebovávají SDK runtime zdroje. Každé SDK, které se inicializuje při spuštění aplikace, přidává k době startu. Uživatelé, kteří čekají na načtení aplikace déle než tři sekundy, ji s výrazně vyšší pravděpodobností opustí. A každé SDK běžící na pozadí spotřebovává paměť a baterii — zdroje, kterých si uživatelé všímají a za které obchody s aplikacemi stále více penalizují.
Audit SDK
Začněte auditem svého současného SDK stacku. U každého reklamního SDK ve vaší aplikaci změřte tři věci: binary size, který přidává, revenue, které generuje, a jeho fill rate. Téměř jistě zjistíte, že jedno nebo dvě SDK jsou zodpovědná za většinu vašeho revenue, zatímco několik dalších přispívá marginálně, ale přidává značnou zátěž.
Pravidlo 80/20 platí
Ve většině publisherských aplikací generují dvě až tři reklamní SDK 80 procent nebo více celkového reklamního revenue. Zbývající SDK vyplňují mezery, ale často za cenu převyšující jejich přínos, pokud zohledníte dopad na výkon. Cílem není eliminovat všechna SDK — ale najít minimální sadu, která zachytí maximální revenue.
Řešení na straně serveru
Nejúčinnějším způsobem, jak snížit počet SDK bez ztráty diverzity poptávky, je přesunout agregaci poptávky ze strany klienta na stranu serveru. Open Bidding od Googlu například umožňuje více demand partnerům soutěžit o váš inventář bez nutnosti integrace jejich individuálních SDK do vaší aplikace. Získáte konkurenční tlak více bidderů s jednoduchostí jediné SDK integrace.
Přístup řízené poptávky
Řízený demand partner posouvá tento koncept ještě dál. Místo integrace více SDK sami integrujete jeden přípojný bod — buď prostřednictvím stávající mediation platformy, nebo přes lehkou serverovou integraci. Řízený partner agreguje poptávku z desítek zdrojů na své infrastruktuře a vaše aplikace vidí pouze jeden demand zdroj. Výsledkem je větší diverzita poptávky s menší zátěží SDK.
Nejchytřejší publisheři se neptají «kolik SDK mohu přidat?» Ptají se: «jaký je minimální počet SDK, který potřebuji k zachycení maximálního revenue?» Odpověď je téměř vždy méně, než aktuálně mají.
Praktické kroky ke snížení SDK bloatu
1. Odstraňte podvýkonná SDK
Pokud SDK generuje méně než 5 procent vašeho celkového reklamního revenue, vážně zvažte jeho odstranění. Náklady na výkon pravděpodobně převyšují jeho přínos k revenue.
2. Konsolidujte prostřednictvím mediation
Kde je to možné, používejte vestavěné adaptéry vaší mediation platformy místo samostatných SDK integrací. Mediation adaptéry jsou obvykle lehčí než plné SDK integrace.
3. Využijte server-side bidding
Přesuňte demand partnery podporující server-side bidding na tento model. Tím odstraníte jejich SDK z vaší aplikace a zároveň zachováte jejich poptávku ve vašem waterfall.
4. Využijte řízeného partnera pro long-tail poptávku
Místo integrace pěti niche SDK pro regionální nebo specializovanou poptávku využijte jediného řízeného partnera, který tuto poptávku agreguje na straně serveru.
Měření dopadu
Po snížení počtu SDK sledujte tři metriky: zmenšení velikosti aplikace, zlepšení doby startu a celkové reklamní revenue. Dobře provedené snížení SDK by mělo ukázat měřitelná zlepšení v prvních dvou bez výrazné změny — nebo dokonce se zlepšením — ve třetím, protože menší velikost aplikace vede k vyšším mírám instalace a lepší retenci uživatelů.