Push-уведомление — это сообщение, которое приложение показывает на экране телефона, даже когда оно закрыто, и только тем, кто разрешил уведомления. Разрешение и есть первое ограничение, о котором забывают: на Android 13 и новее уведомления у нового приложения выключены по умолчанию, а на iOS их включает системный запрос. Дальше всё решают сегмент, повод и время отправки.
Коротко
Разрешение спрашивают в тот момент, когда польза уведомления очевидна, а не на первом экране. На Android правило записано прямо: если пользователь ставит приложение на устройство с Android 13 или новее, уведомления по умолчанию выключены, и отправлять их можно только после того, как он дал разрешение. На iOS уведомления тоже включает только явное разрешение: приложение показывает системный запрос, и ответ на него определяет всю дальнейшую работу с каналом.
Цена отказа на Android выше, чем кажется. В документации сказано: если приложение нацелено на Android 12L или ниже и человек хотя бы один раз нажал «Не разрешать», запрос больше не появится, пока приложение не переустановят или не обновят до версии, нацеленной на Android 13.
Поэтому первая метрика канала — не открытия, а доля разрешивших уведомления от числа установивших. Пока она низкая, работать над текстами бессмысленно: сообщения просто некому показать.
Пользователь отключает не приложение целиком, а отдельный тип уведомлений — если вы их разделили. Начиная с Android 8.0 каждое уведомление должно быть привязано к каналу; уведомление без канала в приложении, нацеленном на Android 8.0 и выше, просто не появится, а система запишет ошибку.
Практический вывод простой. Каналов должно быть столько, сколько у вас разных поводов писать: «Заказы», «Доставка», «Напоминания», «Акции». Тогда человек, которому надоели промо, отключит промо, а не статусы своего заказа.
Совет Никогда не кладите рекламу в тот же канал, что и статусы заказа. Один раз отключив канал со смешанным содержимым, человек перестанет получать и то, ради чего ставил приложение, — а вернуть его в уведомления вы уже не сможете: настройками каналов управляет пользователь, а не приложение.
Работают уведомления, привязанные к действию человека, а не к плану маркетинга. У каждого такого сценария есть событие-триггер, понятный повод и метрика, по которой видно, стоит ли его оставлять.
| Событие | Пример сообщения | Когда отправлять | Метрика сценария |
|---|---|---|---|
| Заказ оформлен | «Заказ № 1284 принят. Напишем, когда курьер выедет» | Сразу | Доставляемость и открытия |
| Статус доставки изменился | «Курьер выехал, будет в течение часа» | В момент события | Открытия |
| Корзина брошена | «В корзине остались две позиции. Сохранить до завтра?» | Через два-четыре часа | Переходы в корзину и заказы |
| Подписка заканчивается | «Подписка закончится 24 сентября. Продлить сейчас?» | За три дня и в день окончания | Продления |
| Ответ в поддержке | «Оператор ответил на ваше обращение» | Сразу | Открытия и время до ответа |
| Нет активности | «Неделю не заходили. Появились новые условия доставки» | По расписанию, не чаще раза в неделю | Возвраты и отписки |
Каждое уведомление должно открывать нужный экран, а не главный: заказ — карточку заказа, корзину — корзину. Как устроены такие ссылки внутрь приложения и как не потерять источник перехода, разобрано в статье про диплинки и атрибуцию переходов.
Главное ограничение касается рекламы. Правила проверки App Store в пункте 4.5.4 говорят: push-уведомления не должны быть обязательными для работы приложения и не должны использоваться для передачи личной или конфиденциальной информации; для промо и прямого маркетинга нужно явное согласие, полученное в интерфейсе приложения, и в приложении должен быть способ от таких сообщений отказаться.
Из этого следуют три вещи, которые проектируют заранее: отдельное согласие на промо помимо системного разрешения, отдельный переключатель для отказа и понимание, что в тексте уведомления нельзя показывать ничего чувствительного — оно видно на заблокированном экране.
Персонализация по дате рождения, истории покупок или городу — это обработка персональных данных, а значит, нужны согласие и понятная формулировка, зачем эти данные собираются. Что здесь идёт не так чаще всего, разобрано в статье про риски утечки персональных данных. Требования магазинов к описанию сбора данных разобраны отдельно — в статье про публикацию в App Store и Google Play.
У push своя воронка, и она короче продуктовой: разрешение, доставка, открытие, целевое действие. Отписки и удаления идут в ту же таблицу, потому что без них картина выглядит лучше, чем есть.
| Метрика | Формула | О чём говорит |
|---|---|---|
| Доля разрешивших | разрешили ÷ установили | Момент и формулировка запроса |
| Доставляемость | доставлено ÷ отправлено | Состояние базы токенов и живых устройств |
| Открытия | открытия ÷ доставленные | Попадание в повод, текст и время |
| Целевое действие | заказы ÷ открытия | Ценность сценария, а не самой рассылки |
| Отписки | отключили уведомления ÷ получили | Усталость аудитории от частоты |
| Удаления после рассылки | удалили приложение ÷ получили | Перегрев: сообщение оказалось лишним |
Доставляемость считают не сразу. Сообщение, которое не удалось доставить, сервис хранит и досылает, когда устройство снова выйдет на связь: по умолчанию срок хранения в Firebase Cloud Messaging — четыре недели, а при нулевом времени жизни недоставленное сообщение отбрасывается сразу. Поэтому для срочных сообщений время жизни ставят коротким: уведомление «курьер у подъезда», пришедшее назавтра, вредит больше, чем молчание.
Общие метрики продукта — активная аудитория за день и месяц, удержание по дням — считаются отдельно и не заменяют метрики push. Они показывают состояние продукта, а не работу канала.
Базу теряют не из-за одного неудачного текста, а из-за частоты. Правило простое: один повод — одно сообщение, и повод должен принадлежать человеку, а не отделу маркетинга.
Окно тишины пропускают чаще остальных пунктов, а стоит это дорого: ночное промо даёт всплеск отписок, который потом списывают на неудачный текст.
Ту же задачу закрывает Telegram-бот: рассылка по сегментам, напоминание о записи, статус заказа. Разрешение здесь выдаётся самим фактом запуска бота, а сегменты собираются по ответам и действиям человека в диалоге.
На выставке UzFranchise Expo так и работали коммуникации: письмо уходило нужной группе, а те, кто не пришёл в первый день, получили приглашение на второй. Аудитория делилась по интересам, поэтому рассылки шли отдельным сегментам, а не всем сразу.
Ограничение у канала одно, зато жёсткое: бот не может написать человеку первым — сначала пользователь запускает бота сам. Значит, база для рассылок собирается только из тех, кто уже начал диалог. Что ещё умеет и чего не умеет этот канал, разобрано в статье про Telegram-ботов для бизнеса.
Отдельной услуги «настройка push» у нас нет: уведомления проектируются вместе со сценарием продукта. На страницах услуг ближе всего три формата.
Бюджет выше стартового поднимают число сценариев, число языков интерфейса и требования к сегментации: сегмент по одному признаку настраивается быстро, сегмент по поведению требует событий, которых в продукте может ещё не быть. Состав работ описан на странице ботов и ИИ-ассистентов.
Syntra Systems начинает с карты поводов, а не с текстов. Разбираем, какие события в продукте вообще заслуживают сообщения, что человек должен сделать после него и в каком экране это действие живёт. После этого собираем сценарии, раскладываем их по каналам уведомлений и заранее договариваемся о частоте и окне тишины.
Дальше подключаем отправку, размечаем переходы, чтобы было видно, какое сообщение привело к действию, и настраиваем отчёт: разрешения, доставка, открытия, целевые действия, отписки. Если приложения пока нет, ту же логику собираем в Telegram-боте — с сегментами и теми же метриками.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Push бесплатен для отправителя, приходит мгновенно и открывает нужный экран приложения, но уходит только тем, кто дал разрешение и не удалил приложение. SMS доходит почти до всех и стоит денег, письмо даёт больше места для текста. Эти каналы не заменяют друг друга: критичные сообщения дублируют, промо оставляют в push.
Готовой нормы нет, её подбирают по своей базе: после каждой промо-рассылки смотрят отписки и удаления приложения и останавливаются на частоте, где они не растут. Ограничение ставят только на промо — статусы заказа и ответы поддержки в него не входят.
Оставить их в покое и работать другими каналами: письмом, сообщением в боте, баннером внутри приложения. Повторные системные запросы ситуацию не исправят, а на Android при устаревшем таргете запрос вообще не покажется. Иногда помогает переформулированный экран с пользой и переключатель в настройках.
Хватит одной таблицы: доля разрешивших от установивших, доставляемость, открытия, отписки и удаления после рассылки. Первая важнее остальных — пока разрешений мало, тексты ничего не меняют.
Причин три: человек отключил уведомления или канал, устройство было офлайн дольше срока хранения сообщения, токен устройства устарел после переустановки. Первое лечится сегментацией и частотой, второе — коротким временем жизни для срочных сообщений, третье — регулярной чисткой базы токенов.
Тот, кто отвечает за продукт, а не за рекламу. Уведомления — часть пользовательского сценария: они завязаны на события в системе, права доступа и тексты в интерфейсе. Маркетинг предлагает поводы, но решение о частоте и составе каналов остаётся за продуктом.
Проверьте две вещи. На Android 13 и новее уведомления нового приложения выключены, пока человек сам их не разрешит. А с Android 8.0 каждое уведомление должно быть привязано к каналу — отдельному типу сообщений вроде «Заказы» или «Акции», и без канала оно просто не появится на экране.
