Web-push уведомления и возврат покупателей

Покупатель положил товар в корзину, отвлёкся на звонок, закрыл вкладку — и не вернулся. Через час он уже не помнит ни магазин, ни товар. Email вы, может, и отправите, но он утонет в промо-папке; SMS дорого и раздражает; звонок оператора выглядит навязчиво. А web-push — короткое уведомление прямо в браузере — приходит бесплатно, мгновенно и возвращает человека на страницу оформления одним кликом. При грамотной настройке этот канал спасает заметную долю брошенных корзин и держит покупателя в курсе цен и статусов заказа, не превращаясь в спам.

Ниже — практическое руководство по web-push для магазина на 1С-Битрикс: как устроен канал технически, как просить разрешение так, чтобы люди соглашались, три ключевых сценария возврата (брошенная корзина, снижение цены, статус заказа), сегментация против спама и способы всё это измерить. Материал собран из наших проектов по повышению конверсии интернет-магазинов (CRO) — без общих слов, только то, что работает на живых магазинах.

Что такое web-push и почему он возвращает покупателей

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

Ключевая особенность канала — он работает только с явного согласия. Браузер не позволит сайту отправить ни одного уведомления, пока пользователь сам не нажмёт «Разрешить» в системном запросе. Это принципиально отличает web-push от email-баз, купленных «на стороне», и от холодных обзвонов: в push вы попадаете только к тем, кто осознанно подписался на ваш магазин. Отсюда и высокая отзывчивость — это тёплая, лояльная аудитория, которая уже что-то у вас смотрела или покупала.

Почему именно web-push хорошо возвращает покупателей? Дело в трёх свойствах канала. Во-первых, скорость доставки: сообщение приходит за секунды, а значит триггер «вы забыли товар в корзине» срабатывает, пока намерение купить ещё живо. Во-вторых, заметность: уведомление всплывает поверх текущей работы пользователя, его трудно не увидеть, в отличие от письма, которое надо специально открыть. В-третьих, один клик до цели: push ведёт прямо на корзину или карточку товара, без промежуточных шагов вроде «войти в почту → найти письмо → нажать ссылку».

При этом важно понимать ограничения. Web-push — это узкая полоса внимания: заголовок и одна-две строки. Здесь не расскажешь историю бренда и не покажешь десять товаров. Поэтому канал силён именно в коротких триггерных сценариях, где нужно быстро вернуть человека к конкретному действию, а не в длинных маркетинговых рассылках. Лучшая стратегия — использовать web-push в связке с email и мессенджерами: push тянет обратно на сайт, а более «объёмные» каналы догревают и продают.

Web-push против email, SMS и мессенджеров

Чтобы встроить web-push в общую систему коммуникаций магазина, полезно честно сравнить его с другими каналами возврата. У каждого своя сильная сторона, и правильный ответ почти всегда — «использовать вместе», а не «выбрать один».

Из таблицы видно нишу web-push: это дешёвый, быстрый и заметный канал, которому не нужен ни телефон, ни email. Его слабость — маленький объём и то, что он «привязан» к устройству и браузеру, где человек подписался. Поэтому web-push не заменяет email-маркетинг с длинными подборками и не заменяет SMS для критичных уведомлений вроде кода из смс. Он закрывает свою задачу — быстро вернуть тёплого посетителя на сайт, — и делает это дешевле всех остальных.

Отдельно стоит сравнить web-push с оповещениями о цене и наличии, которые часто делают через email или подписку в карточке товара. Мы подробно разбирали механику таких уведомлений в материале про оповещения о цене и наличии в 1С-Битрикс; web-push — это ещё один транспорт для тех же триггеров, и часто самый быстрый.

Как устроен web-push технически

Чтобы настраивать web-push осознанно и не спотыкаться на «почему не приходит», полезно понимать, из каких частей он собран. Под капотом это несколько стандартных веб-технологий, которые работают в связке.

• Service Worker. Фоновый скрипт, который браузер держит «живым» даже при закрытой вкладке. Именно он получает входящее уведомление от системы и показывает его пользователю. Без зарегистрированного Service Worker web-push невозможен.
• Push API и Notification API. Браузерные интерфейсы: первый отвечает за получение сообщений от push-сервиса, второй — за отрисовку самого уведомления с иконкой, заголовком и кнопками.
• Push-сервис браузера. Промежуточное звено (FCM у Chrome, Mozilla autopush у Firefox, Apple Push для Safari). Ваш сервер не шлёт уведомление пользователю напрямую — он передаёт его в push-сервис, а тот доставляет на устройство.
• Подписка (subscription). При согласии браузер выдаёт уникальный объект подписки: адрес endpoint у push-сервиса и ключи шифрования. Его нужно сохранить у себя — это «адрес» конкретного пользователя.
• VAPID-ключи. Пара ключей, которой ваш сервер подписывает запросы к push-сервису, подтверждая, что отправитель — именно вы. Настраиваются один раз.

Полный цикл выглядит так. Пользователь заходит на сайт, страница регистрирует Service Worker и в подходящий момент запрашивает разрешение на уведомления. Человек нажимает «Разрешить» — браузер обращается к своему push-сервису и возвращает объект подписки. Сайт отправляет эту подписку на ваш сервер (в 1С-Битрикс — сохраняет в базу). Когда наступает событие (брошенная корзина, снижение цены), сервер формирует сообщение, шифрует его ключами подписки и отправляет в push-сервис браузера, а тот доставляет уведомление на устройство, где его перехватывает Service Worker и показывает.

Подписка: как просить разрешение и не отпугнуть

Вся ценность web-push начинается с подписки, и здесь совершается главная ошибка: сайт вываливает системный запрос «Сайт хочет отправлять уведомления» в первую же секунду, когда человек ещё не понял, что это за магазин. Итог предсказуем — большинство жмёт «Блокировать», и повторно попросить браузер уже не даст. Один необдуманный запрос сжигает пользователя навсегда.

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

Момент запроса важен не меньше формулировки. Просите подписку после ценностного действия, когда интерес максимален:

• После добавления товара в корзину. Логичный момент предложить «сообщим, если цена снизится» — интерес к товару уже проявлен.
• На странице оформления заказа. «Будем присылать статус заказа push-уведомлением» звучит как сервис, а не как реклама.
• При просмотре товара не в наличии. «Уведомим, когда появится» — прямая польза, ради которой человек охотно подпишется.
• После второго-третьего визита. Вернувшийся посетитель уже лоялен, ему проще предложить оставаться на связи.

Чего избегать: запроса на первой секунде, запроса на выходе (это выглядит как отчаяние), запроса без объяснения выгоды и повторного «доставания» человека, который уже отказался. Помните, что отказ в системном окне почти необратим на уровне браузера, поэтому «мягкий» слой — это не украшение, а защита вашей главной попытки.

Три сценария возврата: корзина, цена, статус

Web-push можно использовать десятками способов, но 80% отдачи дают три триггерных сценария. Они объединены одним признаком: сообщение приходит в ответ на конкретное поведение или событие и несёт человеку прямую пользу, а не абстрактную акцию. Разберём каждый подробно, а сначала сведём их в таблицу.

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

Брошенная корзина через web-push

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

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

1. Через 30–60 минут — мягкое напоминание. «Вы забыли товар в корзине» с названием товара и кнопкой «Вернуться к оформлению». На этом этапе никаких скидок — часто достаточно просто напомнить.
2. Через сутки — напоминание с аргументом. Добавьте пользу: «Товар ещё в наличии» или «Осталось 2 штуки». Здесь уместна лёгкая срочность, если она правдива.
3. Через 2–3 дня — последнее касание с выгодой. Если позволяет экономика, можно предложить бонус: бесплатную доставку или небольшую скидку. Это финальный аргумент, а не первый.

Важно не путать web-push с email-цепочкой для той же корзины: они не конкурируют, а дополняют друг друга. Push быстрее и вернёт «горячего» пользователя за первый час, email добьёт тех, кто push не увидел, и позволит показать больше — фото товара, отзывы, похожие позиции. Полную механику брошенной корзины со всеми каналами и настройками в Битриксе мы разбирали в отдельном материале про возврат брошенных корзин в 1С-Битрикс — web-push органично встраивается в описанные там цепочки как самый быстрый первый шаг.

Пара практических правил для текста push о корзине. Указывайте конкретный товар, а не «товары в корзине» — узнаваемость повышает клик. Не злоупотребляйте фальшивой срочностью: если написать «осталась 1 штука», а товар лежит месяцами, доверие рухнет после первой же проверки. И обязательно ведите по клику прямо на корзину или на страницу оформления, а не на главную — каждый лишний шаг теряет часть возвращённых.

Снижение цены и появление в наличии

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

Снижение цены. Если товар, который человек смотрел или отложил, подешевел, push с новой ценой и размером выгоды («−900 ₽») часто мгновенно возвращает к покупке. Здесь работает не абстрактная «скидка на всё», а конкретная выгода именно на нужный товар. Технически триггер вешается на изменение цены товара с проверкой, у кого этот товар в корзине или избранном.

Появление в наличии. Классический сценарий «уведомить, когда появится» из карточки товара. Пользователь оставляет запрос на товар, которого нет на складе; как только приход появляется, push сообщает об этом первым. Скорость здесь критична: на дефицитные позиции кто первый пришёл, тот и купил, и push выигрывает у email за счёт мгновенной доставки.

Оба триггера тесно связаны с обменом с 1С и складским учётом: цена и остатки в магазин чаще всего приходят именно оттуда. Поэтому push-уведомления о цене и наличии стоит завязывать на события изменения товара, которые генерирует обмен. Механику подписок на цену и наличие, хранение запросов и обработку прихода мы подробно разбирали в статье про уведомления о цене и наличии в 1С-Битрикс; web-push здесь — просто ещё один, самый быстрый канал доставки тех же событий.

Статусы заказа без звонков и SMS

Третий сценарий часто недооценивают, потому что он не про продажи «в лоб», а про сервис. Но именно сервисные push формируют лояльность и снижают нагрузку на поддержку. Покупатель хочет знать, что происходит с его заказом: приняли, собрали, передали в доставку, привезли в пункт выдачи. Раньше это закрывали звонком оператора или платными SMS; web-push делает то же самое бесплатно и мгновенно.

Сервисные push о статусе имеют побочный, но важный эффект для маркетинга: они приучают пользователя к тому, что уведомления от вашего сайта полезны. Человек, который привык получать «заказ передан в доставку», спокойнее отнесётся к «цена на отложенный товар снизилась» — канал не ассоциируется у него со спамом. Поэтому сервисные и маркетинговые push стоит рассматривать как единую систему доверия.

Что стоит и не стоит слать в статусах:

• Слать: ключевые вехи — «заказ принят», «оплачен», «собран», «передан в доставку», «прибыл в пункт выдачи», «доставлен». Это события, которых человек ждёт.
• Не слать: технические микростатусы вроде «менеджер открыл заказ» или каждое движение по внутренним этапам CRM — они не нужны покупателю и создают шум.
• Аккуратно: запрос отзыва после доставки — уместен, но одним касанием и без давления.

Технически статусные push удобно завязывать на смену статуса заказа в 1С-Битрикс или в связанной CRM. Каждому «человеческому» статусу сопоставляется шаблон сообщения, а «технические» статусы просто не имеют шаблона и не порождают push. Так покупатель получает ровно те вехи, которые ему важны.

Сегментация и частота: как не спамить

Главный риск web-push — превратиться в раздражитель, от которого отписываются и который портит впечатление о магазине. Граница между «полезно» и «спам» проходит по двум осям: релевантность (то ли я получил) и частота (не слишком ли часто). Управлять нужно обеими.

Сегментация. Не шлите всем одно и то же. Разбейте базу подписчиков по поведению и интересам:

• По корзине: есть незавершённая корзина — только сценарий возврата корзины, а не посторонние акции.
• По интересам: категории просмотренных и купленных товаров — не предлагайте детские товары тому, кто берёт автозапчасти.
• По стадии: новый подписчик, активный покупатель, «спящий» — тон и частота сообщений разные.
• По заказам: есть активный заказ — приоритет у статусных push, маркетинг притормаживается.

Частота и тихие часы. Установите жёсткий лимит — обычно не больше 3–4 сообщений в неделю на человека, а лучше меньше. Триггерные push (корзина, статус) считаются отдельно от маркетинговых: сервисное «заказ доставлен» не должно съедать лимит промо. Обязательно настройте тихие часы, чтобы уведомления не приходили ночью — push, разбудивший человека в 3 часа, гарантированно ведёт к отписке.

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

Реализация в 1С-Битрикс

Подключить web-push к магазину на 1С-Битрикс можно двумя принципиально разными путями. Выбор зависит от того, что важнее: быстрый старт или полный контроль над данными и сценариями.

Путь первый — внешний сервис рассылок. Sendpulse, Gravitec, Sendpush и аналоги берут на себя всю техническую часть: Service Worker, хранение подписок, отправку через push-сервисы браузеров, интерфейс сегментов и аналитику. Вам нужно вставить их скрипт на сайт (через строковую константу, шаблон сайта или готовый модуль из Маркетплейса 1С-Битрикс) и передавать события. Это самый быстрый способ запустить web-push за день-два.

1. Зарегистрируйтесь в сервисе и получите код виджета подписки и идентификатор проекта.
2. Разместите Service Worker в корне сайта (файл вида sw.js) — сервис даёт готовый, его нужно положить в корень, иначе подписка не охватит все страницы.
3. Подключите скрипт подписки в шаблоне сайта, настройте «мягкую» подсказку и момент запроса.
4. Свяжите триггеры. Брошенную корзину и статусы заказа передавайте в сервис через его API или готовый модуль: на событие OnSaleOrderSaved или изменение статуса заказа отправляйте запрос в сервис.
5. Настройте сегменты и сценарии в интерфейсе сервиса: цепочку возврата корзины, тихие часы, лимиты частоты.

Путь второй — собственная реализация. Если важен полный контроль, отсутствие абонентской платы и хранение подписок на своей стороне, web-push делают на ядре Битрикса. Схема такая:

1. Service Worker и подписка. Свой sw.js в корне, скрипт подписки, генерация VAPID-ключей. Объект подписки после согласия отправляется на сервер AJAX-запросом к своему обработчику.
2. Хранение подписок. Заведите highload-блок (или пользовательскую таблицу через D7-ORM) с полями: endpoint, ключи, ID пользователя, сегмент, дата. Так подписки лежат у вас и доступны для выборок.
3. Обработчики событий. На события ядра — OnSaleOrderSaved (статус заказа), изменение цены/остатков товара при обмене с 1С, наступление таймаута брошенной корзины — вешаете обработчики, которые ставят задачу на отправку push.
4. Отправка. Формирование и шифрование сообщения по Web Push Protocol и отправка в push-сервис браузера. Массовые рассылки выносите в агент или очередь (например, через модуль bitrix:main и пул задач), чтобы не блокировать хиты.
5. Отложенные сценарии. Брошенную корзину проверяйте агентом по расписанию: раз в N минут ищете корзины без заказа старше порога и ставите на отправку.

На практике часто выбирают гибрид: подписку и хранение делают своими, а тяжёлую отправку доверяют внешнему транспорту. Какой бы путь вы ни выбрали, критично одно — не блокировать пользовательские хиты синхронной отправкой push. Всё, что можно, выносите в фон: агенты, очереди, отложенные задачи. Иначе рассылка на тысячу подписчиков «повесит» сайт. Если своя реализация вызывает вопросы, эту часть логичнее отдать на работы по повышению конверсии (CRO), где push-сценарии проектируются вместе с остальной механикой возврата.

Как это выглядит в админке 1С-Битрикс

При собственной реализации основные настройки web-push живут в нескольких местах админки: highload-блок с подписками, обработчики событий в модуле и агент проверки брошенных корзин. Схематично панель управления push-сценариями выглядит так:

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

Метрики и A/B-тесты

«Push вроде работает» — не метрика. Чтобы понимать реальный вклад канала и улучшать его, нужно мерить всю воронку и сравнивать варианты через эксперименты. Вот показатели, за которыми стоит следить.

Отдельно про честную атрибуцию. Легко приписать push все заказы, где был клик, но часть этих людей купила бы и так. Чтобы измерить реальный вклад, используйте контрольную группу: случайная часть подписчиков не получает конкретный триггер, и разница в конверсии между «получившими» и «не получившими» показывает чистый эффект push. Это тот же принцип, что и в обычном A/B-тестировании, и о нём подробно — в материале про A/B-тестирование и CRO в 1С-Битрикс.

Что тестировать в push: момент запроса подписки, текст «мягкой» подсказки, задержку первого напоминания о корзине (30 минут против часа), наличие и размер скидки в третьем касании, время отправки статусных push. Меняйте по одному параметру за тест, иначе не поймёте, что именно сработало.

Правовые и репутационные нюансы

Web-push — согласованный канал по своей природе, но пара правовых и этических моментов всё же есть, и лучше закрыть их сразу.

• Согласие есть на уровне браузера. Пользователь явно нажал «Разрешить», и это и есть его согласие на канал. Отдельной галочки «согласен на обработку ПДн» web-push обычно не требует, потому что не собирает телефон, email или имя — только технический адрес подписки.
• Упомяните канал в политике. В политике конфиденциальности и правилах сайта стоит указать, что вы используете web-push, какие данные при этом обрабатываются (endpoint подписки, поведение на сайте) и как отписаться. Это и требование прозрачности, и защита от претензий.
• Разделяйте сервис и рекламу. Сервисные push о статусе заказа — это часть исполнения обязательств перед покупателем. Маркетинговые push — реклама. Не маскируйте второе под первое: «статус заказа» с зашитой акцией подрывает доверие быстрее всего.
• Отписка в один шаг. Дайте отключить push прямо из уведомления или в личном кабинете, не заставляя лезть в настройки браузера. Простая отписка — это и этично, и практично: она снижает жёсткие блокировки сайта.

Репутационная сторона важнее формальной. Один навязчивый или нерелевантный push стоит дороже, чем кажется: человек не просто отпишется, он запомнит магазин как источник спама. Поэтому золотое правило web-push простое — отправляйте только то, за что пользователь сказал бы «спасибо, что напомнили», а не «когда это кончится».

Частые ошибки

• Запрашивают подписку на первой секунде, без «мягкого» слоя и без объяснения выгоды — большинство жмёт «Блокировать», и попытка сожжена навсегда.
• Шлют всем одно и то же — общую акцию вместо триггера на корзину или интерес конкретного пользователя, из-за чего канал воспринимается как спам.
• Игнорируют тихие часы — push приходит ночью и приводит к волне отписок и жёстких блокировок сайта в браузере.
• Ведут по клику на главную, а не на корзину или карточку товара — каждый лишний шаг теряет часть возвращённых покупателей.
• Забывают про HTTPS и корень сайта для Service Worker — подписка либо не работает, либо охватывает не все страницы.
• Отправляют push синхронно в пользовательском хите — массовая рассылка «вешает» сайт вместо отправки в агенте или очереди.
• Не чистят «мёртвые» подписки — endpoint устаревают, delivery rate падает, а вы этого не видите без мониторинга.
• Используют фальшивую срочность («осталась 1 штука» на складском товаре) — работает один раз, а потом убивает доверие ко всем сообщениям.
• Мерят только клики и не считают отписки и выручку канала — невозможно понять, спамите вы или помогаете.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность web-push перед запуском:

1. HTTPS и Service Worker. Сайт на HTTPS, sw.js лежит в корне и регистрируется на всех страницах, VAPID-ключи сгенерированы.
2. Двухуровневая подписка. Есть «мягкая» подсказка с выгодой, системный запрос вызывается только после согласия и в удачный момент (корзина, оформление, товар не в наличии).
3. Хранение подписок. Подписки сохраняются (HL-блок или сервис), привязаны к пользователю и сегменту, «мёртвые» endpoint чистятся.
4. Триггер «корзина». Цепочка из 2–3 касаний с нарастающей паузой, ведёт прямо на корзину, скидка — только на последнем шаге.
5. Триггеры «цена» и «наличие». Завязаны на изменение товара при обмене с 1С, шлют только тем, кто проявил интерес к товару.
6. Статусы заказа. Push на «человеческие» вехи (собран, передан в доставку, доставлен), технические микростатусы отключены.
7. Сегменты и частота. База сегментирована, лимит 3–4 в неделю, тихие часы настроены, сервисные и промо push считаются раздельно.
8. Отправка в фоне. Массовые рассылки идут через агент или очередь, пользовательские хиты не блокируются.
9. Отписка и политика. Отписка в один шаг доступна, канал упомянут в политике конфиденциальности.
10. Метрики и контроль. Настроены opt-in, delivery, CTR, отписки и выручка канала; для оценки эффекта есть контрольная группа.

Вывод

Web-push — это самый быстрый и дешёвый способ вернуть тёплого посетителя на сайт, но он живёт на доверии. Работает он ровно до тех пор, пока каждое сообщение приносит пользу: напоминает о забытой корзине, сообщает о падении цены или везёт статус заказа. Постройте канал на трёх триггерных сценариях, просите подписку через «мягкий» слой в удачный момент, сегментируйте базу и держите разумную частоту — и web-push станет заметным источником спасённых корзин и лояльности, а не поводом заблокировать ваш сайт. А чтобы отделить реальный эффект от иллюзии, всегда меряйте выручку канала через контрольную группу.