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