Push даёт приложению возможность напомнить о себе без нового перехода из рекламы, поиска или письма: для повторного касания человеку не нужно снова вас искать.
И это же способ приложение обесценить. Одно движение пальцем — и канал закрыт. После отключения вернуть его сложнее: пользователю придётся снова изменить разрешение, а попросить его об этом через сами уведомления уже нельзя.
Push-уведомления для бизнеса устроены не так, как рассылка, хотя выглядят похоже, — и ломаются они по-другому. Ниже: как работает разрешение, чем сервисное сообщение отличается от маркетингового, что отправлять не стоит и как проверить свой сценарий до того, как он уйдёт живым людям.
Разрешение: без него канала не существует
Первое, что стоит понять: push — это не свойство телефона, которое включается само. Разрешение даёт человек, и он вправе отказать.
Отсюда практический вопрос, который решается при проектировании: в какой момент спрашивать.
Спросить сразу при первом запуске — быстро и просто. Человек в этот момент ещё ничего не получил от приложения и не понимает, о чём его будут уведомлять.
Спросить в момент, когда уведомление становится осмысленным — сложнее в реализации, но вопрос звучит понятно: «сообщить, когда заказ будет готов?», «напомнить за час до занятия?». Здесь человек соглашается не абстрактно, а на конкретную пользу.
Поэтому момент запроса — часть сценария приложения: сначала человеку нужно понять, какую пользу даст уведомление.
Три типа сообщений — и у каждого своя задача
Проблемы начинаются, когда все три типа используются одинаково.
Транзакционные. Заказ принят, оплата прошла, курьер выехал, код подтверждения. Их содержание напрямую связано с уже совершённым действием человека: заказом, оплатой, подтверждением.
Сервисные. Запись завтра в 15:00, абонемент заканчивается через три занятия, документ готов к получению. Привязаны к состоянию конкретного человека, а не к календарю компании. Здесь ценность зависит от точности: напоминание о записи, которой нет, быстро подрывает доверие к каналу.
Маркетинговые. Акция, новинка, скидка выходного дня. Отправляются не потому, что что-то произошло у клиента, а потому, что что-то происходит у вас.
Разница между третьим типом и первыми двумя принципиальная. Первые два человек получает о себе. Третий — о вас. Маркетинговые сообщения поэтому требуют особенно осторожного обращения: их причина находится на стороне бизнеса, а не в уже совершённом действии клиента.
Что делает push-уведомление для бизнеса раздражающим
Четыре признака, и ни один не про текст сообщения.
Оно не про этого человека. Одинаковое сообщение всем, кто установил приложение, — это рассылка, у которой просто другой транспорт. Сильная сторона push раскрывается, когда сообщение привязано к конкретному состоянию: заказу, записи, балансу, окончанию абонемента.
Оно приходит не вовремя. Напоминание должно приходить тогда, когда человек ещё может им воспользоваться, — и для конкретного сценария это время определяется отдельно. Время отправки часть сценария, а не настройка «по умолчанию».
Оно требует действия, которого человек не планировал. «Загляните в приложение» — это просьба, а не сообщение. Полезное уведомление либо само содержит нужную информацию, либо ведёт ровно на тот экран, где действие завершается.
Их слишком много. Здесь нет правильного числа: для доставки еды и для стоматологии оно разное. Но есть проверяемый признак — если вы не можете назвать событие, по которому отправляется каждое сообщение, значит часть из них отправляется просто так.
Что происходит после отключения
Про это думают в последнюю очередь, а последствие тут дорогое.
Отключение канала — действие тихое: человек не пишет вам и не жалуется, он просто перестаёт получать сообщения.
Если пользователь отключил уведомления приложения, этот канал больше нельзя считать способом доставки — ни маркетинговых сообщений, ни сервисных. Поэтому важные события вроде изменения заказа или переноса записи не стоит проектировать так, будто push гарантированно дойдёт до каждого: для них нужен запасной путь.
Отсюда практическое правило, которое стоит держать в голове при каждом обсуждении рассылки: маркетинговые push конкурируют за то же разрешение, которое требуется сервисным уведомлениям. Пользоваться этим каналом стоит сдержанно.
Что не стоит отправлять
Короткий список, который экономит больше, чем любые тексты.
Сообщения без события. Если единственный повод — «давно не писали», это уже не сервисное сообщение, а маркетинговая коммуникация.
Персональные данные в тексте уведомления. Содержимое push может отображаться на заблокированном экране — это зависит от настроек устройства. Поэтому чувствительные данные лучше не выносить в текст без необходимости: диагноз, сумма долга, содержание заказа в некоторых нишах.
Срочность, которой нет. Если одинаковое «осталось 2 часа» появляется регулярно, само сообщение перестаёт соответствовать реальной ситуации.
Дубли без причины. Если одно событие уже уходит по нескольким каналам, заранее решите, зачем нужен каждый дубль: иначе легко получить три сообщения там, где человеку достаточно одного.
Как проверить сценарий до запуска
Простое упражнение, для которого не нужны разработчики.
Выпишите все уведомления, которые планируете отправлять, и напротив каждого — три вещи:
- Событие. Что именно произошло. Не «понедельник», а «статус заказа изменился», «до записи остался час», «на счету осталось одно занятие».
- Почему сообщение отправляется именно этому человеку. Потому что что-то произошло с его заказом, записью или счётом — или потому что бизнесу есть что рассказать о себе?
- Что человек сделает после. Конкретное действие или «ничего, просто будет знать». Второе тоже нормально — для транзакционных.
Если события пользователя нет, перед вами уже не сервисное уведомление. Такую строку стоит вынести в отдельную группу и решить, действительно ли для неё нужен push — зная, что она расходует то же разрешение, что и сервисные сообщения.
Это же упражнение помогает с оценкой. Для сметы важно не только число текстов: отдельный объём создают сами события, источники данных и логика, по которой определяется получатель и момент отправки.
Что для этого нужно со стороны системы
Коротко, потому что подробности — в разборе интеграций.
Уведомление привязано к событию, а событие происходит не в приложении, а в вашей системе: заказ сменил статус в CRM, до записи остался час по расписанию. Значит, приложение должно об этом узнать — и здесь появляется та самая связь между системами, про которую я писал отдельно.
Практический вывод для сметы: «настроить push» — это не одна строка. При оценке нужно перечислять не только сообщения, но и события, которые их запускают, и системы-источники этих событий.
Что входит в разработку приложения вместе с уведомлениями и что оценивается отдельно — на странице мобильных приложений.
Чего push не сделает
Три вещи, чтобы не переоценить канал.
Он не создаст повод вернуться. Если человеку не нужен ваш товар прямо сейчас, уведомление об этом не напомнит — оно напомнит о вас. Разница между этими двумя вещами и есть весь разговор про удержание.
Он не работает без установки. Push существует только для тех, кто скачал приложение и разрешил уведомления. Это подмножество ваших клиентов, а не все они.
Он не заменяет остальные каналы. Почта и мессенджеры остаются — хотя бы потому, что часть людей приложение не установит.
Что сделать на этой неделе
Пройдите упражнение с тремя колонками по своим планируемым уведомлениям. После него в списке остаётся то, у чего есть событие, — а это и есть способ не оказаться в «отключить уведомления».
А чтобы понять, окупается ли вся конструкция целиком, я собрал модель на повторных покупках: четыре шага по вашим числам, и она покажет, сколько дополнительных повторных покупок нужно, чтобы покрыть стоимость приложения. Оставьте задачу в форме ниже — пришлю вместе с разбором. Или напишите слово «модель» в Telegram или Max, контакты в подвале сайта.