Проектируйте настройки уведомлений с переключателями по событиям, тихими часами, дайджестами и отслеживанием доставки, чтобы люди были в курсе, но не чувствовали себя заспамленными.
Большинство людей не ненавидят уведомления. Они ненавидят, когда их прерывают без уважительной причины. Когда оповещения приходят слишком часто, повторяются или появляются в неподходящий момент, пользователи перестают читать и начинают свайпать.
Основная проблема обычно не в объёме. Она — в несоответствии. То, что срочно для вашей системы, может быть неважно для человека. Продавцу может понадобиться немедленное уведомление о назначении лида, но не «еженедельный совет» в 21:07. Когда всё выглядит одинаково важным, ничто не кажется важным.
Люди отключают уведомления по предсказуемым причинам: они слишком частые, не соответствуют роли, приходят в неподходящее время (сон, встречи, дорога), непонятно, что делать дальше, или непонятно, откуда пришло сообщение.
Полезные оповещения снижают усилия. Шум добавляет усилий. Хорошее уведомление быстро отвечает на три вопроса: Что случилось? Важно ли это для меня? Что мне делать дальше?
Есть ещё скрытая цена, когда пользователи в гневе отключают всё: они пропускают единственное сообщение, которое действительно важно. Заблокированный аккаунт, ошибка оплаты или предупреждение о безопасности остаются без внимания, потому что пользователь отписался после недель низкокачественных пингов. Так «раздражает» превращается в «заявка в поддержку».
Хорошие настройки уведомлений выполняют одну задачу: дают людям контроль с понятными выбором и делают поведение предсказуемым. Если пользователь отключил один тип оповещений, он должен оставаться отключённым. Если он установил тихие часы, приложение должно уважать это каждый раз, во всех каналах.
Хорошие настройки уведомлений начинаются с одного вопроса: за чем пользователь пытается следить, а что может подождать.
Если кто-то включает оповещения для «новых заказов», обычно это означает «сообщайте быстро, чтобы я мог действовать». Если он хочет «еженедельные советы по продукту», это значит «я прочитаю это, когда буду иметь время». Стройте настройки вокруг такого намерения, а не вокруг вашего внутреннего списка событий.
Держите число событий небольшим и различимым. Если у вас пять вариантов «статус изменился», большинство людей либо отключит всё, либо оставит всё включённым и потом пожалеет. Объединяйте похожие события в одну понятную опцию и разделяйте только когда следующее действие действительно другое.
По умолчанию важнее, чем думают многие команды. Для всего не критичного начинайте с тишины по умолчанию, а затем позвольте людям подписываться. Новый пользователь должен иметь возможность ничего не менять и чувствовать уважение.
Используйте простой язык. Избегайте терминов вроде «workflow», «жизненный цикл тикета» или «webhook failure», если ваши пользователи на самом деле так не говорят. Пишите метки так, как кто-то объяснил бы их коллеге.
Когда кто-то нажимает переключатель, он должен понять три вещи:
Прежде чем создавать длинный список настроек уведомлений, решите, какие события вообще заслуживают настройки. Большинство экранов настроек раздражают, потому что предлагают выбор для шумных низкозначимых событий, а несколько действительно важных спрятаны.
Начните с группировки событий по назначению, чтобы люди могли предсказать, что они получат:
Внутри каждой группы разделяйте события на критичные, информационные и промо. Критичное — значит нужно действие или высокий риск. Информационное — «полезно знать». Промо — «приятно получить». Для каждого события определяйте срочность и допустимую задержку. Сбой оплаты может требовать немедленной доставки. Еженедельный отчёт может ждать дайджеста.
Будьте осторожны с событиями, которые вы «никогда не позволяете отключать». Если что-то должно оставаться включённым, держите этот список очень коротким и объясняйте почему (обычно безопасность и определённые оповещения о платеже). Всё остальное должно контролироваться пользователем.
Практическое правило: напишите одно предложение для каждого события, которое говорит, что произошло и почему это важно. Пример: «В аккаунт вошло новое устройство, чтобы вы могли заметить подозрительный доступ». Если вы не можете написать такое предложение, не звучащее расплывчато, событие, вероятно, не заслуживает собственного переключателя.
Переключатели по событию работают, когда они соответствуют моментам, которые действительно важны пользователям. Если событие может стоить денег, времени или доверия, оно заслуживает собственного переключателя. Если это в основном «для информации», рассмотрите объединение в дайджест вместо добавления ещё одного переключателя.
Называйте переключатели как реальные события, а не области функций. «Платёж отклонён» понятнее, чем «Обновления биллинга». Это разница между настройками, которые кажутся уважительными, и настройками-лабиринтами.
Под каждым переключателем показывайте однострочный пример того, как выглядит сообщение. Это задаёт ожидания и упрощает решение.
Категорийные переключатели полезны только когда категории очевидны и стабильны. «Security», «Billing» и «Account access» обычно ясны. «Обновления продукта» или «Активность» часто скрывают слишком многое.
Избегайте скрытых зависимостей. Если отключение «Комментарии» также отключает «Упоминания», скажите об этом прямо. Лучше разделить их. Сюрпризы заставляют людей не доверять всему экрану.
Добавьте глобальную паузу, которая не стирает выборы. «Приостановить все уведомления на 1 час / 1 день / до моего включения» — это предохранительный клапан для загруженных дней, при этом индивидуальные настройки остаются нетронутыми.
Тихие часы должны значить одно: никаких не срочных сообщений в те часы, когда пользователь заявил, что не хочет, чтобы его беспокоили.
Часовые пояса — вот что делает тихие часы либо «правильными», либо сломанными. Некоторые люди путешествуют и хотят, чтобы тихие часы следовали за их текущим местоположением. Другие хотят фиксированное «домашнее» расписание даже в поездках. Предлагайте оба варианта с простыми метками вроде «Использовать мой текущий часовой пояс» и «Использовать домашний часовой пояс».
Тихие часы также нуждаются в понятных исключениях. Пользователи принимают обходы, если они редки и понятны. Держите список обходов коротким и ориентированным на риск, а не на маркетинг:
Пограничные случаи важны. Переход на летнее/зимнее время может сместить расписание на час, поэтому показывайте в UI, когда в следующий раз «тихие часы начинаются» и «заканчиваются».
Для выходных избегайте заставлять пользователя строить два расписания с нуля. Предоставьте простой переключатель «Только будни» или позвольте выбрать дни одним нажатием.
Пресеты помогают людям закончить быстро: «Ночь (22:00–08:00)» плюс «Пользовательский». Делайте пресеты редактируемыми после выбора, чтобы они никогда не казались ловушкой.
Дайджест — это обещание: «Мы держим вас в курсе, просто не прерываем». Это лучше всего работает для шумных, низкосрочных обновлений вроде реакций, рутинной активности или ежедневной статистики. Это плохо работает для всего, что блокирует работу, требует быстрого ответа или имеет дедлайн.
Опция дайджеста должна начинаться с разделения событий на две корзины. Сохраните высокосрочные события в реальном времени (оповещения безопасности, платёжные ошибки, утверждения, аутейджи). Перенесите высокообъёмные события в дайджест (активные ветки комментариев, активности фолловеров, рутинные сводки).
Держите варианты частоты знакомыми:
Позвольте пользователю выбрать время отправки дайджеста и подтвердить часовой пояс. Дайджест, который приходит в 3:00, кажется сломанным, даже если он «корректен» по часовому поясу.
Понятность важнее сложных контролей. Пометьте каждое событие как «В реальном времени» или «Дайджест», чтобы пользователю не приходилось гадать. Если переключение события переводит его в дайджест, скажите об этом рядом с контролом.
Превью снимает тревогу. Покажите небольшой пример того, что будет в дайджесте: несколько заголовков, счётчики и самые важные элементы. Например: «3 новых комментария, 2 изменения статуса, 1 упоминание» с короткими фрагментами.
«Отправлено» означает только, что ваше приложение передало сообщение провайдеру. Пользователям важно, что произошло дальше. Для критичного оповещения «мы попытались» — не то же самое, что «вы это получили».
Простая модель выглядит так:
Когда что-то не сработало, отслеживайте причину по возможности. «Failed» слишком расплывчато. Лучше примеры — заблокировано (фильтрация оператора), bounced (почтовый ящик отклонил), неверный адрес/номер или истёкший токен (push-токен больше не действителен). Даже если вы не можете получить идеальную информацию от каждого провайдера, сохраняйте то, что доступно.
Для временных сбоев нужны правила повторных попыток. Хороший дефолт — ограниченные повторы с бэкоффом, чтобы вы не спамили провайдеров и не разряжали батареи. Пример: повтор через 1 минуту, затем через 5, затем через 30, затем остановиться и пометить как неуспешное. Перманентные ошибки вроде «неверный номер» не должны повторяться.
Для критичных сообщений показывайте пользователю простой статус. Если кто-то говорит «я не получил код сброса пароля», видимая строка вроде «SMS не доставлено: неверный номер» предотвращает фрустрацию и помогает исправить реальную проблему.
Храните журнал (audit trail) для поддержки и соответствия требованиям. Сохраняйте, кому предназначалось сообщение, какой канал был выбран, временные метки для каждого статуса и последнюю известную ошибку.
Рассматривайте настройки уведомлений как продуктовую логику, а не как кучу переключателей. Если вы сначала построите правила, UI и система отправки останутся согласованными по мере добавления новых событий.
Начните с инвентаризации возможных уведомлений. Для каждого события решите, насколько оно срочно и какие каналы подходят (push, email, SMS). Затем выберите значения по умолчанию, чтобы большинству людей не нужно было трогать настройки.
Практическая проверка: если вы не можете объяснить переключатель одним коротким предложением, он, вероятно, объединяет несколько событий и его следует разделить.
Убедитесь, что каждая отправка проходит через одну и ту же точку принятия решения. Там вы применяете выборы пользователя, тихие часы и логику дайджеста перед тем, как что-то покинет вашу систему.
Храните настройки в структуре, соответствующей тому, как люди думают: по событию, по каналу и по таймингу. Добавьте планирование для тихих часов и окон дайджеста, включая обработку часовых поясов и исключений для критичных оповещений. Логируйте полную цепочку: попытка отправки, ответ провайдера (доставлено, bounced, failed) и действия пользователя (отписки, изменения).
Пример: пользователь отключил email для «еженедельных советов», но оставил email для «оповещений безопасности», с тихими часами 22:00–07:00. Ваши правила всё равно должны позволить срочному письму для сброса пароля в 2:00 дойти, а низкоприоритетные сообщения отложить до утреннего дайджеста.
Большинству людей не мешают обновления. Им мешает ощущение, что их заперли, запутали или игнорируют. Несколько ошибок проектирования превращают экран настроек уведомлений в место, куда пользователь заходит один раз, злясь, и больше не возвращается.
Типичные паттерны:
Две правки предотвращают большинство проблем. Во-первых, сделайте так, чтобы каждый контрол отвечал на один вопрос: какое событие, в каком канале и с каким таймингом. Держите названия конкретными, например «Новая оплата выставлена» вместо «Биллинг». Во-вторых, рассматривайте доставку как нечто большее, чем «отправлено», иначе вы будете называться успешным даже когда письмо отскочило или push не дошёл.
Перед релизом пройдитесь по настройкам как реальный пользователь. Представьте, что вы устали, заняты и пришли только чтобы остановить шум, но не пропустить что-то важное.
Начните с самого громкого события. Если человек не может отключить один шумный триггер, не потеряв при этом критичные оповещения, настройки покажутся несправедливыми.
Потом проверьте тайминг. Пользователю не должно приходиться гадать, придёт ли сообщение сейчас, позже в дайджесте или вообще не придёт. UI должен это явно показывать, а примерный текст — соответствовать реальности.
Чеклист перед релизом:
Тихие часы — место, где прячется путаница. Контрол должен показывать простое окно вроде «22:00–07:00» и объяснять, что происходит с заблокированными уведомлениями (заглушены, отложены или перемещены в следующий дайджест). Если вы разрешаете исключения, пометьте их простыми словами, например «Всегда разрешать оповещения безопасности».
Наконец, протестируйте цикл от действия до доказательства. Если пользователь говорит «я не получил», ваша система должна ответить: было ли это поставлено в очередь, передано провайдеру, доставлено на устройство или отклонено?
Майя руководит командой поддержки из 12 человек. Она хочет знать обо всём, что может поставить под риск данные клиентов, но не хочет, чтобы телефон звонил при каждом комментарии, эмодзи или рутинном обновлении. Она часто в собраниях, поэтому ей нужна настройка тихая по умолчанию и громкая только когда это необходимо.
Её предпочтения выглядят так:
Она использует дайджест для фонового шума вроде активности по тикетам, смен статуса и не срочных комментариев. Если что-то становится срочным, это оповещение, а не часть дайджеста.
Тихие часы у неё установлены по будням с 21:00 до 7:00 по её локальному часовому поясу, с одним исключением: оповещения безопасности обходят тихие часы. Если обнаружен подозрительный вход в 2:00, она всё равно получает уведомление.
Отслеживание доставки — то, где её настройка перестаёт быть предположением. Когда Майя запрашивает сброс пароля, она видит, что письмо доставлено её почтовому провайдеру, а не просто помечено в приложении как «отправлено». С другой стороны, ежемесячный счёт клиента показывает bounce, поэтому команда знает, что он не дошёл до почтового ящика.
Когда кто-то говорит «я не получил», служба поддержки имеет чёткий план:
Начните с письменного списка событий. Для каждого события решите, критично оно (безопасность, биллинг, доступ к аккаунту) или опционально (комментарии, лайки, советы). Если вы не можете объяснить, зачем нужно событие, одним предложением, оно, вероятно, не должно входить в ваш первый релиз.
Пишите пользовательские метки так, как будто вы говорите с занятым человеком. Делайте их конкретными («Новый вход с нового устройства») и добавляйте однострочное превью («Мы оповестим вас сразу для безопасности аккаунта»).
Перед релизом добавьте логирование доставки, чтобы поддержка могла ответить на реальный вопрос: «Дошло ли это до меня?» Отслеживайте путь от создания до постановки в очередь, передачи провайдеру, доставки или ошибки, а также открытий, когда это доступно.
Если вы строите центр настроек внутри платформы без кода, такой как AppMaster, полезно рассматривать уведомления как полноценную продуктовую фичу: определяйте события, сохраняйте настройки для каждого пользователя в PostgreSQL и держите одну общую точку принятия решения в бизнес-логике. AppMaster (appmaster.io) разработан для такого рода логики приложения, где бэкенд-правила и UI-настройки должны оставаться согласованными по мере роста продукта.
Выпускайте фичу на небольшой процент пользователей, затем наблюдайте за показателями отписок, использованием «приостановить все», заявками в поддержку о пропавших оповещениях и темами жалоб. Если одно событие провоцирует большинство отписок, исправьте это событие прежде чем добавлять другие.
Почему пользователи отключают уведомления, даже если функция полезна?Потому что оповещение не соответствует намерению пользователя. Люди терпят частые уведомления, когда они явно помогают действовать, но выключают их, если сообщения повторяются, не относятся к делу или приходят в неподходящее время.
Какими должны быть настройки уведомлений по умолчанию для нового пользователя?По умолчанию делайте всё неинтрузивным для ненастоящих критичных случаев — пусть пользователи сами включают лишнее. Критичные элементы, вроде безопасности и некоторых биллинговых предупреждений, можно оставить включёнными по умолчанию, а всё остальное сделать легко управляемым, чтобы новый пользователь чувствовал уважение к своему времени без необходимости менять настройки.
Как понять, что у меня слишком много переключателей уведомлений?Группируйте похожие события, когда последующее действие одинаково; разделяйте только тогда, когда решение меняется. Хорошее правило: если вы не можете объяснить переключатель в одном коротком предложении — что произошло и что делать — значит он, вероятно, слишком расплывчат или широк.
Как лучше маркировать настройки уведомлений, чтобы они были понятными?Называйте переключатели реальными событиями с понятными последствиями, а не областями продукта. «Платёж отклонён» или «Новый вход с нового устройства» задают ожидания, а метки вроде «Обновления» или «Активность» заставляют пользователей гадать и чаще отключать всё.
Какие уведомления нельзя разрешать пользователю отключать?Используйте «нельзя отключить» только для редких высокорисковых оповещений — в основном это безопасность и некоторые ошибки оплаты, которые могут заблокировать доступ или остановить сервис. Если что-то нельзя отключить, объясните причину простыми словами, чтобы это выглядело как защита, а не контроль.
Как должны работать тихие часы, чтобы не вводить пользователей в заблуждение?Тихие часы должны уверенно задерживать или заглушать не срочные уведомления в выбранное пользователем время, при этом допуская короткий список исключений для критических событий. Они также должны корректно работать с часовыми поясами, чтобы одна и та же настройка не казалась «сломавшейся» при поездках или переходе на летнее время.
Когда лучше предлагать дайджест вместо уведомлений в реальном времени?Дайджесты подходят для высокочастотных низкоприоритетных обновлений: реакции, рутинная активность, статистика. Всё, что блокирует работу, требует быстрого ответа или имеет дедлайн, должно оставаться в реальном времени. Главное — предсказуемость: пользователь не должен получать и дайджест, и реальное уведомление по одному и тому же событию, если только вы явно об этом не говорите.
В чём разница между «отправлено» и «доставлено» и почему это важно?«Отправлено» означает, что вы передали сообщение провайдеру — это не значит, что пользователь получил его. Отслеживайте состояния дальше: доставлено, bounced, заблокировано или неверный адрес, чтобы поддержка могла ответить «дошло ли это до вас?» и пользователь мог исправить проблему вроде неправильного email или истёкшего push-токена.
Как обрабатывать повторные попытки при сбоях доставки уведомлений?Для временных сбоев используйте ограниченные повторы с экспоненциальным увеличением интервала, а затем помечайте сообщение как неудачное с понятной причиной. Не пытайтесь повторять отправку при перманентных ошибках вроде неверного номера, и избегайте частых повторов, которые выглядят как спам или разряжают батарею.
Как реализовать настройки уведомлений, не сделав систему запутанной?Храните персональные настройки по событию, каналу и времени, затем пропускайте каждое уведомление через единый шаг принятия решения, который применяет эти правила перед отправкой. В AppMaster это обычно означает моделирование настроек в PostgreSQL и реализацию логики тихих часов, дайджестов и исключений в одном бизнес-процессе, чтобы UI и бэкенд оставались согласованными по мере роста числа событий.
21 янв. 2026 г.
1 мин
20 янв. 2026 г.1 мин
20 янв. 2026 г.1 минЭкспериментируйте с AppMaster с бесплатной подпиской.
Как только вы будете готовы, вы сможете выбрать подходящий платный план.
