Всеки рекламен SDK, който интегрирате в приложението си, има скрита цена. Всеки от тях увеличава binary size, удължава времето за cold start, създава потенциални конфликти на съвместимост и добавя още една зависимост, която трябва да се актуализира при нови версии на ОС. За издатели, работещи с пет, осем или дори дванадесет SDK, кумулативното въздействие върху производителността на приложението и потребителското изживяване може да бъде значително — и често е невидимо, защото се натрупва постепенно.
Истинската цена на раздуването на SDK
Всеки мегабайт, добавен към binary-то на приложението ви, има значение. Проучванията последователно показват, че процентът на конверсия при инсталиране намалява осезаемо с всеки допълнителен мегабайт от размера за изтегляне. На развиващи се пазари, където потребителите имат ограничено място и по-бавни връзки, въздействието е още по-изразено. Издател, който добавя три рекламни SDK с общ размер 15 мегабайта, може да губи повече приходи от намалени инсталации, отколкото печели от допълнителното търсене, което тези пакети осигуряват.
Отвъд размера за изтегляне, SDK-тата консумират runtime ресурси. Всеки SDK, който се инициализира при стартиране на приложението, добавя към времето за зареждане. Потребители, които чакат повече от три секунди приложението да се зареди, са значително по-склонни да го изоставят. И всеки SDK, работещ на заден план, консумира памет и батерия — ресурси, които потребителите забелязват и за които магазините за приложения все по-често наказват.
Одитът на SDK
Започнете с одит на текущия ви SDK стек. За всеки рекламен SDK в приложението ви измерете три неща: binary size, който добавя, приходите, които генерира, и неговия fill rate. Почти сигурно ще установите, че един или два SDK са отговорни за по-голямата част от приходите ви, докато няколко други допринасят маргинално, но добавят значително натоварване.
Правилото 80/20 важи
В повечето приложения на издатели два до три рекламни SDK генерират 80 процента или повече от общите рекламни приходи. Останалите SDK запълват празнини, но често с цена, надхвърляща приноса им, когато вземете предвид влиянието върху производителността. Целта не е да елиминирате всички SDK — а да намерите минималния набор, който улавя максималните приходи.
Решения от страна на сървъра
Най-ефективният начин да намалите броя SDK, без да загубите разнообразие на търсенето, е да прехвърлите агрегацията на търсенето от клиентската страна към сървърната. Open Bidding на Google например позволява на множество demand партньори да се конкурират за инвентара ви, без да изискват интеграция на техните индивидуални SDK в приложението ви. Получавате конкурентния натиск на множество наддавачи с простотата на една единствена SDK интеграция.
Подходът с управляемо търсене
Управляем demand партньор развива тази концепция по-нататък. Вместо да интегрирате множество SDK сами, интегрирате една точка за свързване — или чрез съществуващата ви mediation платформа, или чрез лека сървърна интеграция. Управляемият партньор агрегира търсене от десетки източници на своята инфраструктура, а приложението ви вижда само един demand източник. Резултатът е повече разнообразие на търсенето с по-малко SDK натоварване.
Най-умните издатели не питат «колко SDK мога да добавя?» Те питат: «какъв е минималният брой SDK, от който се нуждая, за да уловя максимални приходи?» Отговорът почти винаги е по-малко, отколкото имат в момента.
Практически стъпки за намаляване на раздуването на SDK
1. Премахнете слабо представящите се SDK
Ако един SDK генерира по-малко от 5 процента от общите ви рекламни приходи, сериозно обмислете премахването му. Цената на производителността вероятно надхвърля приноса му към приходите.
2. Консолидирайте чрез mediation
Използвайте вградените адаптери на mediation платформата си вместо самостоятелни SDK интеграции, където е възможно. Адаптерите за mediation обикновено са по-леки от пълните SDK интеграции.
3. Възползвайте се от server-side bidding
Прехвърлете demand партньорите, които поддържат server-side bidding, към този модел. Това премахва техния SDK от приложението ви, като запазва търсенето им във вашия waterfall.
4. Използвайте управляем партньор за дългата опашка на търсенето
Вместо да интегрирате пет нишови SDK за регионално или специализирано търсене, използвайте един управляем партньор, който агрегира това търсене от сървърна страна.
Измерване на въздействието
След като намалите броя SDK, наблюдавайте три показателя: намаление на размера на приложението, подобрение на времето за стартиране и общи рекламни приходи. Добре изпълненото намаляване на SDK трябва да покаже измерими подобрения в първите два без значителна промяна — или дори подобрение — в третия, тъй като по-малкият размер на приложението води до по-висок процент на инсталиране и по-добро задържане на потребителите.