Политика push-уведомлений, чтобы пользователи не отключали их

Почему пользователи отключают уведомления

Люди не отключают уведомления потому, что они их ненавидят. Они отключают их потому, что приложение приучило их ожидать прерываний, которые не стоят их внимания.

Когда это происходит, каждое новое уведомление начинает с недостатка доверия. Пользователи перестают сразу проверять, смахивают сообщения, не читая, или отключают оповещения навсегда.

Большая часть проблемы — однообразие. Если обновление доставки, уикенд-акция и слабое напоминание звучат одинаково срочно, то ни одно из них не кажется срочным. Телефон вибрирует, пользователь смотрит — и это снова сообщение, которое могло подождать. После нескольких таких случаев доверие падает.

Время только усугубляет ситуацию. Полезное уведомление в 14:00 может показаться грубым в 23:30. Сообщение во время работы, забора ребенка из школы или ужина просит внимание в неподходящий момент. Люди редко отделяют сообщение от приложения — они запоминают прерывание.

Объем создает вторую проблему. Когда команды отправляют слишком часто, они закапывают важные оповещения. Человек, получивший пять незначительных push-ов за день, может пропустить сообщение о неудачном платеже или о том, что курьер уже на месте. Больше отправок не создаёт больше вовлечения — они приучают людей игнорировать весь канал.

Обычно это начинается с благих намерений. Маркетинг хочет вернуть пользователей. Продукт хочет больше использования. Поддержка хочет меньше пропущенных действий. Каждая команда добавляет ещё одно уведомление, и никто не задаёт простого вопроса: нужно ли это пользователю прямо сейчас?

Именно здесь помогает политика push-уведомлений. Она устанавливает более жёсткий стандарт. Отправляйте уведомления, когда что-то изменилось, когда пользователь просил обновлений, или когда ожидание создаст реальную проблему.

Пользователи сначала снисходительны. Большинство дадут приложению несколько шансов. Если эти шансы превращаются в шум, вернуть доверие куда сложнее, чем его сохранить.

Что должно запускать уведомление

Оповещение на телефоне должно приходить потому, что у пользователя есть причина волноваться прямо сейчас. Если ничего не изменилось, приложение должно молчать.

Самый безопасный триггер — действие пользователя или явный запрос на обновления. Кто-то сделал заказ, начал доставку, подписался на уведомления о доступности товара, встал в лист ожидания или отправил сообщение и ждёт ответ. В каждом из этих случаев уведомление отвечает на реальный вопрос, который уже есть у пользователя.

Хорошие триггеры обычно появляются в моменты с ясной ценностью. Статус заказа изменился. Курьер приближается. Платёж не прошёл и требует внимания. Кому-то ответили на комментарий. Вход выполнен с нового устройства. Такие уведомления экономят время или помогают предотвратить проблему.

Слабые триггеры делают обратное. Они дублируют то, что пользователь увидит при следующем открытии приложения. «Новые предложения ждут вас» часто — это просто контент главного экрана, выведенный на экран блокировки. Если приложение уже показывает такое обновление на видимом месте и ничего не требует действий, уведомление, скорее всего, — шум.

Быстрая проверка перед запуском новой отправки помогает:

• Сделал ли пользователь что-то, что запустило это?
• Попросил ли пользователь получать такие уведомления?
• Что-то действительно изменилось с момента последнего оповещения?
• Может ли пользователь сделать что-то полезное после открытия?

Командам также стоит прописывать причину для каждого уведомления в одном простом предложении. Держите его скучным и конкретным. «Отправлять, когда заказ клиента переходит из состояния «упаковано» в «выдано для доставки», чтобы он знал, когда быть доступным» — ясно. «Увеличить вовлечение с помощью обновлений о доставке» — нет.

Это одно предложение быстро выявляет плохие идеи. Если причина звучит расплывчато, корыстно или её легко проигнорировать, триггер, вероятно, неверен. Если в нём названы реальный момент, реальное изменение и реальная польза для пользователя, уведомление заслужило своё место.

Как «тихие часы» делают уведомления приятнее

«Тихие часы» защищают ту часть дня, когда телефон кажется особенно личным. Рутинное уведомление в 6:15 утра или в 23:40 не кажется полезным, даже если сообщение важно. Оно кажется грубым — и пользователи это запоминают.

Хорошая политика начинается с локального времени пользователя, а не времени офиса вашей команды. Если ваша компания работает в Нью-Йорке, а клиент живёт в Берлине, «утренняя отправка» — это два разных понятия. Сохраняйте часовой пояс пользователя и планируйте доставку по нему.

Для большинства продуктов ночные и ранние утренние часы стоит держать закрытыми по умолчанию. Простой диапазон вроде 21:00–08:00 подходит многим приложениям, и его можно корректировать после наблюдений за поведением. Обновления заказов, еженедельные сводки, предложения и мягкие напоминания могут подождать. Очень немногие рутинные сообщения стоят того, чтобы будить пользователя.

Безопасностные и экстренные уведомления требуют отдельных правил. Вход с нового устройства, код, который пользователь только что запросил, или предупреждение о мошенничестве могут требовать немедленной доставки. Маркетинг, продуктовые подсказки и обычные обновления — нет. Если каждое уведомление заявляет о срочности, пользователи перестают доверять всем уведомлениям.

Когда продукт позволяет, дайте пользователям возможность самому настраивать «тихие часы». Кому‑то удобно работать ночью. Кому‑то хочется приостанавливать не срочные уведомления на выходных. Небольшая настройка может предотвратить отключение уведомлений или даже удаление приложения.

Полезные настройки обычно простые: время начала и окончания для не срочных уведомлений, отдельный переключатель для безопасности и пауза на выходные для рутинных сообщений.

Пример с продуктовым приложением наглядно показывает разницу. Если покупатель обычно заказывает после работы, скидка, отправленная в 02:00, бесполезна. Отправьте её в 17:30 по местному времени. Но если магазин должен сообщить о проблеме с оплатой по активному заказу, такое уведомление может обойти «тихие часы», потому что покупателю нужно знать об этом немедленно.

«Тихие часы» — это, по сути, проявление уважения. Когда оповещения приходят в приличное время, пользователи читают их чаще, реже отключают и сохраняют включённые уведомления.

Как лимиты частоты останавливают усталость от сообщений

Большинство команд не хотят раздражать людей. Проблема в том, что каждое отдельное уведомление выглядит нормально, а пользователь чувствует общий объём. Без лимитов частоты даже полезные сообщения начинают казаться спамом.

Разумная политика устанавливает пределы по типам сообщений. Обновления заказа, уведомления о безопасности, напоминания и промо-рассылки не должны делить один и тот же лимит. Промо может заслуживать одной отправки в день. Обновление о доставке может допускать больше частых сообщений, потому что пользователь в ожидании.

Дневной лимит — первый уровень защиты. Он останавливает медленную капельную отправку, превращающуюся в постоянный шум к вечеру. Он также даёт команде простое правило, которое можно объяснить пользователю в случае вопроса.

Короткий лимит в маленьком окне важен не меньше. Дневные ограничения не помогут, если четыре уведомления прилетели за десять минут из‑за повторов, пересекающихся кампаний или шумного триггера. Установите меньший предел для всплесков, например: одна промо каждые шесть часов или не более двух напоминаний в 12 часов.

Многие приложения могут начать с таких правил:

• Промо: 1 в день
• Напоминания: 2 в день, с интервалом
• Обновления статуса: только когда статус реально изменился
• Уведомления безопасности: отправлять при реальной угрозе аккаунту

Повторные напоминания должны считаться в рамках одного и того же лимита. Пользователю всё равно, называет ли система сообщение «повторным» или «напоминанием». Если он видит его снова — это ещё одно прерывание. Команды часто этого не замечают и обходят собственные лимиты, выпуская три варианта одного и того же напоминания.

Правила сброса лимитов должны быть простыми. Полночь по локальному времени пользователя — предсказуемо и понятно. Скользящее окно в 24 часа строже, но его сложнее отлаживать и сложнее объяснить службе поддержки. Выберите одно правило, задокументируйте и применяйте везде.

Когда пользователь видит, что ваше приложение умеет вовремя остановиться, он остаётся восприимчивым к тем оповещениям, которые действительно важны. Это один из простых способов снизить количество отказов от уведомлений.

Постройте политику шаг за шагом

Хорошая политика push-уведомлений начинается с полного учёта, а не с догадок. Большинство команд помнит крупные уведомления и забывает мелкие: промо‑рассылки, напоминалки, предупреждения о неудачном платеже, сообщения про брошенную корзину и системные уведомления, которые включили месяцы назад.

Соберите все уведомления в одну таблицу. Укажите, что запускает каждый из них, кто его получает, когда он отправляется и почему пользователь должен об этом волноваться именно в этот момент.

Начните с простого аудита

Когда у вас есть полный список, разложите уведомления по трём корзинам: срочные, полезные и опциональные.

Если сообщение предупреждает о мошенничестве, о доставке, которая вот‑вот приедет, или о входе в систему — оно срочное. Если оно помогает кому‑то закончить задачу, которую он уже начал — полезное. Если в основном оно продвигает продукт или распродажу — опциональное.

Этот шаг позволяет быстро убрать много шума. Если вы не можете указать на конкретное действие пользователя или реальную необходимость — удаляйте сообщение или переносите в email.

Короткий аудит обычно включает пять пунктов:

• перечислить все живые уведомления
• отметить триггер и аудиторию
• классифицировать срочность
• удалить слабые или устаревшие отправки
• решить, какой канал подходит лучше

Затем добавьте правила для каждой корзины. Срочные оповещения могут прорываться чаще, но даже им нужны ограничения. Полезные уведомления должны уважать «тихие часы» и избегать ночных отправок, если пользователь прямо не просил. Опциональные — под самыми строгими лимитами, потому что их первыми отключают.

Пример для продуктового приложения прост: «Ваш заказ выехал» может отправляться в 20:10, потому что пользователь ждёт. «Попробуйте скидки на фрукты на этой неделе» может подождать до позднего утра и не должна приходить три раза за два дня.

Тестируйте перед полным развёртыванием

Не включайте новые правила для всех сразу. Начните с небольшой группы пользователей и следите за простыми сигналами: open-rate, отписки, деинсталлы и завершение задач, для которых уведомление предназначалось.

Если полезное уведомление игнорируют, чаще всего проблема в времени. Если после кампании растёт число отписок — лимит слишком свободный или сообщение слишком корыстное. Отрегулируйте правила, протестируйте снова и только после этого разверните политку на всю аудиторию.

Лучшие политики скучны на бумаге и уважительны на практике. Пользователи оставляют уведомления включёнными, когда каждое сообщение заслуживает своего места.

Простой пример на продукте для покупок продуктов

Продуктовое приложение хорошо показывает, как выглядит хорошая политика: цель пользователя очень понятна. Люди открывают приложение, чтобы их еда пришла без сюрпризов. Уведомления должны следовать за заказом, а не за календарём маркетинга.

Представьте, что покупатель открыл приложение в 18:15, набил корзину и оплатил. Приложение может отправить одно уведомление, когда магазин действительно начал сбор заказа. Это сообщение важно: оно подтверждает, что заказ живой и движется.

Дальше приложение должно молчать, если не происходит ничего, что требует внимания. Многие команды делают ошибку и рассылают: «заказ получен», затем «назначен сборщик», затем «упаковывают», затем «курьер готов», затем «курьер в пути». Большинство таких обновлений почти не добавляют ценности. Одно уведомление ближе ко времени прибытия часто полезнее, чем пять мелких статусов.

Более чистый поток выглядит так:

• «Мы начали собирать ваш заказ»
• «Один товар изменился, нажмите, чтобы проверить»
• «Ваш заказ приедет через 10 минут»

Изменения цены — хороший стресс‑тест. Если магазин меняет бренды и итоговая сумма меняется три раза за десять минут, приложение не должно отправлять три отдельных уведомления. Его стоит объединить в одно обновление, чтобы покупатель проверил ситуацию один раз, а не по нескольку раз подряд.

Время имеет значение. Промо после 21:00 по местному времени кажется грубым практически в любом ритейле, и продукты для продуктов не исключение. Если приложение хочет предложить «бесплатную доставку завтра», оно может подождать до утра. Обновления заказа при активной покупке могут идти в обход «тихих часов», но рекламные рассылки должны им подчиняться.

Это не сложно. В этом и смысл. Уведомления, основанные на действиях пользователя, плюс «тихие часы» и лимиты частоты делают приложение спокойным. Пользователи оставляют уведомления включёнными, когда сообщения помогают им закончить задачу, для которой они пришли.

Ошибки, которые заставляют людей отключать уведомления

Большинство людей не отключают уведомления после одного плохого сообщения. Они отключают их после образца поведения. Политика уведомлений проваливается, когда команда считает внимание неисчерпаемым ресурсом.

Одна распространённая ошибка — отправлять промо сразу после того, как пользователь отключил похожую кампанию. Это сигнализирует: система запомнила клик, но проигнорировала смысл. Если человек сказал «нет» рассылкам о распродажах, не пытайтесь снова через час с чуть другим названием.

Другой быстрый способ потерять доверие — использовать один и тот же звук, тон и срочность для любого сообщения. Скидка, обновление доставки и предупреждение безопасности не должны звучать как экстренныe. Когда всё кажется срочным, ничего не кажется таким. Сильные звуки и более резкая формулировка должны быть зарезервированы для сообщений, требующих быстрого действия.

Команды также усложняют жизнь, когда отправляют уведомления по своим, отдельным правилам. Маркетинг хочет кликов. Продукт — возвратов. Операции — обновлений по доставке. Поддержка — обратной связи. Пользователь видит одно — слишком много прерываний. Одно общее правило важнее отдельных целей команд.

Слабая настройка часто выглядит так:

• одна команда может отправлять промо, даже если другая команда зафиксировала отписку
• у всех уведомлений одинаковый звук и приоритет
• время отправки следует серверному времени, а не локальному времени пользователя
• текст почти ничего не говорит до открытия

Часовые пояса ставят многих в тупик. Сообщение, отправленное в 9 утра вашего офиса, может прилететь пользователю в 3 утра. Путешественники, сменные работники и глобальные клиенты усложняют задачу. Хорошие системы используют локальное время, «тихие часы» и предпочтения пользователя, а не один общий график.

Расплывчатый текст тоже вреден. «У вас обновление» не даёт причин волноваться. Люди не любят загадочные уведомления. Скажите, что случилось и почему это важно сейчас. «Ваш заказ у дверей» работает. «Цена на сохранённый товар упала» работает. Пустая формулировка игнорируется.

Если пользователи продолжают отключать уведомления, сначала проверьте уважение. Соблюдали ли вы их выборы, их время и контекст? Это чаще объясняет проблему быстрее, чем любые дашборды.

Быстрые проверки перед запуском нового уведомления

Соблюдать политику проще, когда каждое новое уведомление проходит короткий одинаковый просмотр. Команды часто одобряют текст, потому что он звучит нормально, но пропускают главный вопрос: нужно ли это уведомление вообще?

Начните с практического теста. Если пользователь увидит сообщение и спросит: «Почему я это получил?», ответ должен быть очевиден из того, что он только что сделал. Возможно, он оформил заказ, изменил настройку или оставил товар в корзине. Если причина туманна, уведомление будет казаться случайным.

Следующий тест — время. Спросите, помогло бы сообщение, если бы оно пришло завтра утром. Если да — вероятно, не стоит прерывать человека сегодня вечером. Большинство уведомлений менее срочные, чем думают команды.

Короткий обзор может быть таким:

• пользователь может связать сообщение с недавним действием
• уведомление всё ещё имело бы смысл, если бы его отложили до нормальных часов бодрствования
• то же обновление не покрывается уже приложением, почтой или другим сообщением
• отправка укладывается в дневной лимит этого пользователя
• служба поддержки сможет объяснить правило одним простым предложением

Третий пункт экономит больше проблем, чем ожидают многие команды. Дублированные обновления — один из быстрейших способов приучить пользователей игнорировать вас. Если то же обновление уже видно на странице заказа и в email, push может добавить шума вместо помощи.

Лимиты частоты важны, но на уровне пользователя. Кампания может выглядеть маленькой на дашборде, в то время как один человек получает три уведомления в день, потому что он также сгенерировал продуктовые триггеры. Проверьте полный счёт перед отправкой.

Тест для службы поддержки особенно полезен: он быстро выявляет слабую логику. Если вашей команде нужен длинный внутренний документ, чтобы объяснить, когда пуш отправляется, правило слишком мудрено. Хорошие правила укладываются в простую фразу: «Отправляем это только после неудачного платежа и не чаще одного раза в день, пока проблема не решена».

Если сообщение проваливается хотя бы в одном из этих тестов — приостановите его. Перепишите, отложите, объедините с другим обновлением или вообще не отправляйте.

Что делать дальше

Начните с малого. Выберите часть продукта, где пользователи уже жалуются на шум уведомлений или где после новой кампании растут отписки. Это даст ясное место для теста улучшенной политики без радикальных изменений.

Продуктовое приложение — хороший пример. Обновления заказов обычно заслуживают уведомлений. Ежедневные промо в 7 утра — обычно нет. Если пользователи отключили один шумный тип уведомлений, это часто лучшее место для исправления.

Напишите политику простым языком до начала работ. Если продакт‑менеджер, дизайнер и руководитель поддержки могут её прочитать и согласиться, реализация чаще идёт быстрее и выходит лучше.

Держите первый черновик простым:

• отправлять уведомления только при реальных действиях пользователя или при срочных обновлениях
• приостанавливать не срочные сообщения в «тихие часы»
• ставить лимиты частоты, чтобы один пользователь не получал уведомления весь день
• назначить ответственного за утверждение новых типов уведомлений

Этот короткий набросок ловит много плохих идей на раннем этапе. Он также помогает команде заметить пограничные случаи: два сервиса отправляют одно и то же уведомление или промо идёт сразу после уведомления о неудачной доставке.

После запуска наблюдайте поведение несколько недель. Open-rate важен, но он не даёт полной картины. Если open-rate растёт, но количество обращений в поддержку с жалобами на спам также растёт — политика всё ещё требует правок.

Смотрите вместе три сигнала: меньше отписок от уведомлений, стабильный или улучшившийся open-rate и меньше жалоб в поддержку на шум или нерелевантные оповещения.

Если один из показателей идёт в неправильную сторону — корректируйте правила. Ужесточите триггеры, сузьте окно отправки или понизьте лимит. Малые правки часто решают больше проблем, чем полная переработка.

Некоторым командам сложно согласовать продуктовые правила и системы отправки. Если это ваша проблема, Oleg Sotnikov на oleg.is может просмотреть политику как часть услуг Fractional CTO и помочь превратить простые правила в систему, которой команда сможет управлять без постоянной чистки.