Пуш-уведомление — самый прямой канал к клиенту: сообщение появляется на экране, минуя переполненную почту и спам-фильтры. Но у этой силы есть обратная сторона. Пара неудачных рассылок «всем и обо всём» — и пользователь не просто перестаёт читать, а отключает уведомления навсегда или сносит приложение. В отличие от email, здесь второго шанса почти нет.
Разберём, как в мобильном приложении и PWA магазина на 1С-Битрикс выстроить пуши так, чтобы они помогали продажам и не превращались в спам: как просить разрешение, сегментировать аудиторию, ограничивать частоту, связывать уведомления с событиями заказов из 1С и давать удобную отписку. Настроить надёжную передачу статусов заказов и триггеров из учётной системы помогает наша услуга автоматизации продаж и склада на 1С.
Коротко
- Разрешение на пуши просите не сразу, а мягким предподзапросом с объяснением ценности.
- Разделяйте транзакционные (ждут всегда) и маркетинговые (по согласию и с лимитом частоты) уведомления.
- Триггерные пуши о статусе заказа завязаны на обмен с 1С — их ценность держится на своевременности обмена.
- Дайте гибкую отписку по типам и ведите метрики: отписки важнее, чем разовый CTR.
Почему пуши легко превращаются в спам
Порог терпимости к пушам ниже, чем к любому другому каналу. Письмо можно проигнорировать, оставив в папке; пуш вторгается в экран здесь и сейчас. Поэтому даже небольшой перебор с частотой или нерелевантностью воспринимается как навязчивость острее, чем в рассылке.
Вторая особенность — необратимость отказа. Отписаться от email и снова подписаться легко. А если пользователь отключил разрешение на уведомления в настройках системы, вернуть его почти невозможно: приложение уже не может показать запрос повторно. Значит, право на пуши нужно беречь и тратить только на действительно полезные сообщения.
Транзакционные и маркетинговые пуши
Первое, что нужно сделать, — разделить два потока уведомлений. Они живут по разным правилам, и смешивать их нельзя.
| Признак | Транзакционные | Маркетинговые |
|---|---|---|
| Повод | Действие пользователя (заказ, оплата) | Инициатива магазина (акция, напоминание) |
| Ожидаемость | Ждут, почти не вызывают отписок | Требуют согласия и осторожности |
| Частота | По событию, не ограничивается | Строгий лимит в неделю |
| Источник данных | Обмен с 1С, статусы заказа | Сегменты, поведение, каталог |
| Риск | Низкий | Высокий при перегрузе |
Транзакционные пуши почти всегда полезны и увеличивают доверие: клиент видит, что заказ движется. Маркетинговые дают продажи, но именно они выжигают базу при неаккуратном обращении. Настраивать их нужно по-разному.
Как правильно просить разрешение
Момент запроса разрешения определяет, будет ли у вас вообще аудитория для пушей. Системное окно можно показать по сути один раз, поэтому его нельзя тратить впустую.
- Не при первом открытии. Пользователь ещё не понял ценность приложения — отказ почти гарантирован.
- Сначала мягкий предподзапрос. Свой экран с объяснением: о чём будем уведомлять и зачем.
- Системное окно — только согласившимся. Тем, кто нажал «Да» в предподзапросе.
- После ценного действия. Например, сразу после оформления заказа — уместно предложить следить за доставкой.
Сегментация вместо рассылки всем
Рассылка одного сообщения на всю базу — главный источник отписок. Разным людям нужны разные поводы:
- По истории покупок. Тем, кто покупал корм для кошек, не шлём акцию на товары для собак.
- По стадии жизненного цикла. Новичку — онбординг, постоянному — программа лояльности.
- По поведению. Бросил корзину, смотрел категорию, давно не заходил.
- По географии и складу. Акция на самовывоз актуальна тем, кому близко.
Сегменты строятся на данных о клиентах и заказах, а качество этих данных зависит от учётной системы. Логика близка к построению сегментов аудитории для ретаргетинга: сначала точно определяем, кто перед нами, потом решаем, что отправить. Поддерживать данные в порядке помогает автоматизация на 1С.
Частота и время отправки
Частота — самый частый способ случайно стать спамом. Несколько практических рамок:
- Лимит промо-сообщений. Ориентир — не больше 2–3 маркетинговых пушей в неделю на пользователя.
- Транзакционные вне лимита. Статус заказа приходит всегда, независимо от промо-частоты.
- Тихие часы. Никаких уведомлений ночью — это гарантированный путь к отключению.
- Учёт часового пояса. Отправка в удобное локальное время получателя, а не по серверному.
Помните: релевантность важнее количества. Одно точное сообщение приносит больше, чем пять общих, и не стоит вам подписчиков.
Триггерные события из 1С
Самые ценные пуши — те, что реагируют на реальные события заказа. А события эти рождаются в учётной системе. Когда 1С меняет статус заказа, эта информация через обмен попадает на сайт, и сайт отправляет соответствующее уведомление.
- Заказ принят. Подтверждение сразу после оформления.
- Оплата прошла. Особенно важно при онлайн-оплате.
- Товар отгружен / передан в доставку. С номером отслеживания, если он есть.
- Готов к самовывозу. Триггер на приезд в пункт выдачи.
Ключ к таким пушам — надёжный и своевременный обмен: уведомление о доставке, пришедшее через два дня после факта, бесполезно. Поэтому триггерные пуши настраивают вместе с автоматизацией обмена. Технически события между системами удобно передавать через вебхуки — их безопасную настройку мы разбираем в статье про безопасность REST и вебхуков в 1С-Битрикс.
Веб-пуши и PWA без нативного приложения
Пуши доступны не только владельцам нативного приложения. Веб-пуши работают через браузер и PWA: пользователь подписывается прямо на сайте и получает уведомления даже при закрытой вкладке.
- PWA как альтернатива приложению. Дешевле и быстрее нативной разработки, а канал пушей уже есть.
- Десктоп и Android. Веб-пуши здесь поддерживаются полноценно.
- iOS с оговорками. Веб-пуши работают, если сайт добавлен на домашний экран как приложение.
- Единая логика. Сегменты и триггеры те же, что для нативного приложения — меняется только транспорт.
Адаптивная мобильная версия и PWA на 1С-Битрикс строятся на композитном режиме и продуманной инфраструктуре. Как устроен быстрый фундамент под мобильную витрину, описано в материале про хостинг и инфраструктуру для 1С-Битрикс.
Персонализация и релевантность
Даже разрешённый и нечастый пуш раздражает, если он не про пользователя. Персонализация превращает уведомление из шума в пользу:
- По имени и истории. Обращение и упоминание релевантных товаров, а не безликое «У нас акция».
- Брошенная корзина. Напоминание с конкретными товарами, которые человек оставил.
- Снижение цены на избранное. Пуш о том, что подешевел товар из списка желаний.
- Наличие ожидаемого. «Товар, который вы ждали, снова в наличии».
Для этого нужны актуальные данные о каталоге, ценах и остатках — а они приходят из 1С. Чем чище обмен, тем точнее и уместнее пуши.
Отписка и управление уведомлениями
Как ни парадоксально, удобная отписка увеличивает размер живой базы. Когда единственный выход — отключить всё, пользователь отключает всё. Когда можно выключить только раздражающий тип, он оставляет остальное.
Гибкое управление уведомлениями — это и уважение к человеку, и практическая выгода: канал связи выживает там, где жёсткое «всё или ничего» его убивает.
Реализация в 1С-Битрикс пошагово
Соберём внедрение в последовательность шагов.
- Разделите потоки. Транзакционные и маркетинговые уведомления с разными правилами.
- Настройте запрос разрешения. Мягкий предподзапрос перед системным окном.
- Свяжите со статусами заказов. Триггеры на события из обмена с 1С.
- Опишите сегменты. По истории, поведению, географии и стадии жизненного цикла.
- Задайте частоту и тихие часы. Лимиты промо-сообщений и учёт часового пояса.
- Добавьте управление в кабинете. Переключатели по типам уведомлений.
- Подключите метрики. Доставляемость, CTR, конверсия, отписки — с A/B-тестом.
Чтобы выкатывать изменения в логике уведомлений безопасно и без простоев, помогает выстроенный процесс деплоя — об этом статья про CI/CD и деплой для 1С-Битрикс.
Метрики и A/B-тест пушей
Эффективность пушей нельзя оценивать по одному числу. Смотрите на комплекс:
- Доставляемость. Сколько отправленных пушей реально дошло.
- Открываемость (CTR). Доля кликнувших по уведомлению.
- Конверсия после клика. Целевые действия, а не просто открытия.
- Отписки и отключения разрешения. Главный индикатор «спамности».
Высокий CTR при растущих отписках — не успех, а выжигание базы. Улучшайте текст, время и сегмент через A/B-тест, а не по интуиции. Как корректно ставить эксперименты, разбираем в отдельном гайде по A/B-тестированию в блоге.
Частые ошибки
- Запрос разрешения при первом запуске. Массовые отказы без шанса спросить снова.
- Рассылка всем одинаково. Нерелевантность и волна отписок.
- Перебор с частотой. Несколько промо-пушей в день — прямой путь к отключению.
- Смешение потоков. Маркетинг вперемешку с транзакционными убивает доверие к каналу.
- Пуши ночью. Гарантированное раздражение и отписка.
- Запаздывающие триггеры. Уведомление о доставке через два дня после факта.
- Отписка только «всё или ничего». Пользователь отключает весь канал целиком.
Чек-лист внедрения
- Потоки разделены. Транзакционные и маркетинговые пуши идут по разным правилам.
- Разрешение через предподзапрос. Системное окно — только согласившимся.
- Триггеры из 1С работают. Статусы заказа приходят вовремя через обмен.
- Сегменты настроены. Рассылки адресные, а не «на всех».
- Частота ограничена. Лимит промо, тихие часы, учёт часового пояса.
- Управление в кабинете. Гибкая отписка по типам уведомлений.
- Метрики и A/B-тест включены. Отслеживаются отписки, а не только CTR.
Вывод
Пуши — самый прямой и самый хрупкий канал к клиенту. Право отправлять уведомления даётся один раз, и потерять его легко: перегруз частотой, нерелевантность и ночные рассылки отключают пользователя навсегда. Поэтому пуши строятся не вокруг «как чаще напомнить о себе», а вокруг «как быть полезным ровно тогда, когда это ждут».
На 1С-Битрикс для этого есть всё: транзакционные пуши на основе статусов из обмена с 1С, сегменты по данным клиентов, PWA с веб-пушами без нативного приложения. Разделите потоки, просите разрешение с умом, ограничьте частоту, дайте гибкую отписку и следите за отписками как за главной метрикой — и пуши станут каналом, которому доверяют, а не спамом, который отключают.
