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