Только представьте: вы запустили push-кампанию, нацеленную на ваших пользователей Android. В дашборде стоит статус «отправлено». Но количество открытий вдвое меньше, чем вы ожидали, и вы не можете понять, в чем проблема: в плохом креативе или в сбоях доставки.
На Android ответ часто — ни в том, ни в другом. Каналы уведомлений, настройки приоритета и агрессивная политика энергосбережения OEM-производителей могут незаметно «убивать» ваши сообщения до того, как пользователи их увидят. Дашборд не покажет ошибку. Ваша аналитика не объяснит причину. Сообщения просто исчезают.
Это руководство по диагностике: где на самом деле ломается воронка доставки на Android и что вы можете с этим сделать — без недель расследований со стороны разработчиков.
Где на самом деле теряются ваши push-уведомления?
Большинство команд мобильных приложений отслеживают 2 показателя: отправлено и открыто. Но на Android есть 4 этапа, и самые большие потери происходят посередине, где никто не ищет.
У каждого перехода есть свой режим сбоя:
Отправлено → Доставлено. Сообщение покинуло ваш сервер, но так и не достигло устройства. Частые причины: истек срок действия FCM-токенов, устройство долгое время было офлайн, приложение удалено, но устаревшие токены все еще в вашей базе данных.
Доставлено → Отображено. Сообщение достигло устройства, но так и не было показано пользователю. Именно здесь кроются специфичные для Android проблемы: оптимизация батареи от OEM-производителя «убивает» уведомление, канал уведомлений отключен или беззвучен, настройки приоритета приводят к тихой доставке.
Отображено → Открыто. Пользователь увидел уведомление, но не нажал на него. Вот где креатив, время и релевантность действительно имеют значение, но только после того, как вы убедились, что первые 2 этапа работают.
Ключевая мысль: если у вас низкий коэффициент перехода от доставки к отображению, никакое A/B-тестирование текста не поможет. Вы оптимизируете сообщение, которое никто не видит. Вот как найти и исправить настоящую проблему в 3 шага.
Топ-3 «тихих убийцы» доставки push-уведомлений на Android
Каналы уведомлений: 1 канал по умолчанию ≠ стратегия
Начиная с Android 8.0, каждое уведомление должно быть привязано к каналу. Пользователи могут управлять каждым каналом независимо — отключать звук, изменять его поведение или полностью деактивировать.
Проблема: когда все сообщения — рекламные, транзакционные, напоминания — идут через 1 канал по умолчанию, один раздраженный пользователь отключает всё. Он хотел получать меньше рекламы, а в итоге потерял подтверждения заказов, квитанции об оплате и оповещения безопасности.
Что делать: Структурируйте каналы по сценариям использования. Как минимум, разделите транзакционные сообщения (статус заказа, подтверждение оплаты) и рекламные (предложения, реактивация). Каждому каналу присваивается свой уровень важности.
Диагностический сигнал: если показатели оттока одинаковы для всех типов сообщений — и рекламных, и транзакционных — скорее всего, проблема в структуре ваших каналов. Пользователи отключают единственный канал, через который идет всё.
Приоритет и важность: почему ваше сообщение доставляется беззвучно
Есть 2 уровня, которые контролируют поведение уведомления, и их путаница — одна из самых распространенных ошибок.
Приоритет FCM определяет, насколько срочно система доставляет сообщение на устройство. ВЫСОКИЙ приоритет немедленно «будит» устройство; ОБЫЧНЫЙ может быть сгруппирован и доставлен с задержкой.
Важность канала определяет, как уведомление отображается пользователю, когда оно уже на устройстве. ВЫСОКАЯ важность вызывает всплывающий баннер и звук. ПО УМОЛЧАНИЮ — уведомление тихо появляется в шторке.
Ловушка: ВЫСОКИЙ приоритет FCM + важность канала ПО УМОЛЧАНИЮ = сообщение немедленно достигает устройства, а затем незаметно лежит в трее уведомлений. Аналитика говорит «доставлено». Пользователь ничего не заметил.
Политика энергосбережения OEM-производителей
«Чистый» Android — это только часть истории. Samsung, Xiaomi, Huawei, Oppo и Vivo применяют свою собственную агрессивную оптимизацию батареи поверх стандартных настроек Android. Эти политики могут полностью блокировать получение push-уведомлений вашим приложением, даже если FCM-токен действителен и доставка «успешна».
Вот как это выглядит у разных производителей:
- Xiaomi (MIUI): Автозапуск по умолчанию отключен. После перезагрузки устройства ваше приложение не может получать push-уведомления, пока пользователь не откроет его вручную — если только он не предоставил разрешение на автозапуск.
- Huawei (EMUI/HarmonyOS): Агрессивное завершение приложений убивает фоновые процессы. Push-уведомления перестают приходить после периода неактивности, даже если приложение недавно использовалось.
- Samsung (One UI): Списки «Спящие приложения» и «Глубоко спящие приложения» задерживают или блокируют уведомления для приложений, которые пользователь давно не открывал.
- Oppo/Vivo (ColorOS/Funtouch): Ограничения фоновой активности незаметно подавляют уведомления. Приложение кажется работающим нормально, когда открыто, но фоновая доставка не удается.
Общая черта: у всех этих OEM-производителей пользователь должен явно разрешить вашему приложению работать в фоновом режиме. Без этого разрешения доставка на бумаге «успешна», но уведомление так и не появляется.
Диагностический сигнал: если показатели доставки или открытий сильно различаются в зависимости от производителя устройства в рамках одной и той же кампании, почти наверняка причина в ограничениях OEM.
Найдите, где сбой, и исправьте это
Вы понимаете, что может пойти не так. Вот как найти вашу конкретную проблему и решить ее.
1. Настройте свои диагностические инструменты
Сегментируйте по устройствам. Создайте сегменты для Android по версии ОС и производителю устройства. Это ваш самый важный диагностический инструмент. Он позволяет увидеть, являются ли проблемы с доставкой универсальными или изолированными для конкретного OEM.
Отслеживайте всю воронку. Убедитесь, что ваш SDK настроен на передачу не только статуса «отправлено», но и «доставлено» и «открыто» как отдельных событий. Без этого вы слепы к середине воронки.
Структурируйте каналы уведомлений по сценариям использования. Как минимум, разделите транзакционные (статус заказа, оповещения безопасности) и рекламные (предложения, реактивация). У каждого канала должен быть свой уровень важности.
Задачи для разработчиков (однократная настройка):
- Передавать производителя устройства, версию ОС и модель как атрибуты пользователя для сегментации
- Убедиться, что отслеживание доставки правильно настроено в SDK
- Определить каналы уведомлений в коде с соответствующими уровнями важности
2. Запустите диагностический сценарий
Отправьте одну и ту же кампанию вашим сегментам Android (разделенным по производителям) и вашей аудитории iOS. Сравните отток и открытия на каждом шаге сценария.
Для этой цели мы рекомендуем использовать удобный для маркетологов конструктор путей клиента Pushwoosh (вы можете зарегистрироваться бесплатно и протестировать его):
- ⚠️ Сегменты Android отваливаются на этапе доставки, а iOS держится → проблема в инфраструктуре: ограничения OEM, проблемы с токенами или неверная конфигурация каналов.
- ⚠️ Обе платформы одинаково отваливаются на этапе открытия → проблема в вашем сообщении: креатив, время или релевантность.
- ⚠️ Один производитель отваливается непропорционально сильно → вы нашли проблему, специфичную для OEM.
- ⚠️ Доставка в порядке, но открытия низкие на всех устройствах → проверьте настройки приоритета/важности. Возможно, вы отправляете сообщения с ВЫСОКИМ приоритетом по каналу с важностью ПО УМОЛЧАНИЮ, что означает, что они приходят быстро, но появляются беззвучно.
3. Предотвратите будущие потери
Сопоставьте приоритет с важностью. Срочные сообщения (быстрые распродажи, оповещения безопасности) → ВЫСОКИЙ приоритет, ВЫСОКАЯ важность. Несрочный контент (дайджесты, советы) → ОБЫЧНЫЙ/ПО УМОЛЧАНИЮ.
Не устанавливайте все на ВЫСОКИЙ — это кратчайший путь к тому, чтобы пользователи отключили ваши каналы.
Применяйте ограничение частоты и часы тишины. Чрезмерное количество сообщений — самый быстрый путь к отключению канала. Установите ограничения частоты для каждого канала и уважайте местные часовые пояса с помощью часов тишины. Это не исправляет доставку — это ее защищает.
Используйте тихие push-уведомления с умом. Тихие push-уведомления позволяют обновлять контент приложения и синхронизировать данные в фоновом режиме без видимых для пользователя оповещений. Это мощный инструмент для поддержания актуальности вашего приложения, но у него также есть свои ограничения по доставке на устройствах с оптимизацией батареи.
Создайте резервный сценарий. Это ваша страховка. Если push-уведомление не открыто в течение N часов, запустите повторное сообщение через другой канал — in-app, email или SMS. Это защитит вас от сбоев доставки OEM, отключенных каналов и сегментов с низкой вовлеченностью.
Наладьте доставку push-уведомлений на Android с Pushwoosh
Цель — повторяемый цикл: сегментировать → измерять → определять точку сбоя → исправлять нужный уровень. Не креатив, когда проблема в доставке. Не доставка, когда проблема в креативе.
Готовы начать? Создайте свой первый сегмент в Pushwoosh, чтобы проверить, где на самом деле ломается ваша воронка.
