Когда сессия обрывается из-за сбоя, вы теряете не только доверие пользователя. Вы теряете все рекламные показы, которые могли состояться до конца сессии, все постбэки, которые должны были отправиться при её завершении, и заметную долю удержания следующего дня. Цифры неприятные.
Цепочка потерь
Средняя длительность сессии в стабильно работающем мобильном приложении — 6–9 минут. Среднее число рекламных показов за сессию с учётом ограничений частоты — 2,4. Если приложение падает на второй минуте, вы теряете в среднем около 1,6 показа — безвозвратно.
При частоте сбоев 1% и 5 млн DAU это уже 80 000 потерянных показов в день. При eCPM в $7 вы ежедневно недополучаете $560 дохода — из-за одного процентного пункта нестабильности.
Полная модель потери дохода
Формула короткая: потерянный доход за день = DAU × частота сбоев × (показы за сессию − показы до сбоя) × eCPM / 1000. Стоит подставить реальные числа — и масштаб потерь становится неприятно очевидным.
- 1 млн DAU × 1,5% сбоев × 1,6 потерянного показа × $6 eCPM ≈ $144 в день, $52 тыс. в год
- 5 млн DAU × 1,0% сбоев × 1,6 потерянного показа × $7 eCPM ≈ $560 в день, $204 тыс. в год
- 25 млн DAU × 0,6% сбоев × 1,6 потерянного показа × $8 eCPM ≈ $1 920 в день, $700 тыс. в год
- И это только потерянные показы — без учёта снижения удержания, которое обычно обходится ещё дороже
ANR: зависания, которые бьют по монетизации сильнее сбоев
ANR (Application Not Responding — «Приложение не отвечает») на Android — незаметный убийца дохода. Пользователь видит зависший интерфейс, принудительно закрывает приложение и удаляет его. Но отчёт о сбое не отправляется, и команда, которая следит за Crashlytics, ничего не замечает. Доля ANR выше 0,5% — обычное дело для приложений, которые инициализируют рекламный SDK в главном потоке.
Аналог на iOS — принудительное завершение приложения механизмом watchdog с кодом 0x8badf00d. Причина обычно та же: синхронные операции в главном потоке при запуске. Относитесь к обоим случаям так же, как к сбоям: настройте оповещения, рассчитывайте потери дохода по той же модели и проверяйте эти показатели перед выпуском каждого релиза.
Защитные паттерны для каждой платформы
Эти паттерны мы по умолчанию включаем в каждую интеграцию Apps Kit SDK. Никаких хитростей — но в большинстве кодовых баз, которые мы проверяем, их нет.
- Android: инициализируйте SDK в задаче WorkManager, а не в Application.onCreate
- Android: храните ссылки на рекламные представления в WeakReference и обнуляйте их в onDestroyView
- iOS: запускайте инициализацию SDK из didFinishLaunching в очереди с QoS уровня utility, не блокируя главный поток
- iOS: отключайте рекламные делегаты и разрывайте циклы сильных ссылок в viewWillDisappear, а не в deinit
- Обе платформы: разрешайте каждый рекламный запрос только через конечный автомат, который учитывает согласие пользователя, состояние сети и готовность SDK
Откуда берутся сбои
- Инициализация SDK в главном потоке — самая частая причина, которую мы встречаем
- Синхронная загрузка рекламы в onCreate / didFinishLaunching
- Нехватка памяти из-за удержания рекламных представлений дольше, чем они нужны
- Состояния гонки между обновлением статуса согласия пользователя и отправкой рекламного запроса
Оповещения о сбоях, которые влияют на доход
Оповещения о частоте сбоев обычно привязаны к фиксированному процентному порогу, и при срабатывании их игнорируют. Вместо этого привяжите их к влиянию на доход: отправляйте оповещение, когда расчётные суточные потери от сбоев с одной сигнатурой превышают $X. Ради такого сигнала дежурный инженер уже готов проснуться. Мы поставляем шаблон Cloud Function, который делает именно это на основе данных, экспортированных в BigQuery.
Базовый защитный паттерн
Инициализируйте SDK через фоновый диспетчер, пропускайте каждый рекламный запрос через конечный автомат согласия пользователя и освобождайте ссылки на рекламные представления сразу после закрытия рекламного блока. Ничего нового. Но в большинстве интеграций, которые мы проверяем, всего этого нет.
Считайте частоту сбоев рычагом роста дохода, а не метрикой технической гигиены — и обсуждение приоритетов работы над стабильностью станет намного короче.
Что сделать на этой неделе
Откройте дашборд сбоев, возьмите три самые частые сигнатуры, рассчитайте потери по модели выше и укажите рядом с каждой сумму в долларах. Релиз с исправлением самой дорогой ошибки окупится ещё до завершения следующего цикла проверки в App Store.
