Уведомления «снижение цены» и «товар в наличии» в 1С-Битрикс: возврат покупателей

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

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

Зачем нужны уведомления о цене и наличии

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

Экономически это один из самых выгодных каналов возврата. Аудитория уже тёплая: она сама выбрала товар и оставила контакт. Стоимость касания близка к нулю (особенно у push и e-mail), а конверсия из такого уведомления в заказ на порядок выше, чем из холодной рекламы. По сути вы не покупаете новый трафик, а дожимаете уже оплаченный — тот, что пришёл из поиска, контекста или прямых заходов и едва не потерялся.

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

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

Штатная подписка «Сообщить о поступлении»

Начнём с того, что уже есть в платформе. В модуле «Интернет-магазин» 1С-Битрикс встроен механизм подписки покупателя на товар — на стороне витрины он реализован компонентом bitrix:catalog.product.subscribe. Логика простая: если у товара нулевой или отрицательный остаток и в настройках каталога разрешена подписка, в карточке вместо кнопки «Купить» появляется поле «Сообщить о поступлении». Покупатель оставляет e-mail (авторизованному подставляется его почта), система сохраняет подписку, а когда количество товара становится положительным — отправляет письмо по почтовому шаблону.

Подписки хранятся в собственной таблице модуля и привязаны к товару и пользователю (или просто к e-mail для анонимного посетителя). За фактическую рассылку отвечает штатный агент: он периодически проверяет, у каких подписанных товаров появился остаток, формирует письма и помечает подписки как обработанные. То есть базовый сценарий «появился товар → ушло письмо» работает без единой строки кода — нужно лишь включить и настроить механизм.

Что даёт коробка и где её пределы, удобно свести в таблицу:

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

1. Включите подписку в настройках каталога. В параметрах модуля «Интернет-магазин» и торгового каталога разрешите подписку на товары, которых нет в наличии.
2. Разместите компонент. Добавьте bitrix:catalog.product.subscribe в шаблон карточки товара, чтобы поле «Сообщить о поступлении» показывалось при нулевом остатке.
3. Настройте почтовое событие. Проверьте почтовый шаблон уведомления о поступлении: тему, тело, ссылку на товар и корректную кодировку.
4. Убедитесь, что агент активен. Штатный агент рассылки подписок должен быть включён и запускаться достаточно часто.

Подписка на снижение цены

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

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

• Абсолютный порог. Уведомлять, если цена упала минимум на N рублей относительно зафиксированной при подписке.
• Относительный порог. Уведомлять при снижении от X процентов — это устойчивее для товаров разной ценовой категории.
• Порог «ниже, чем видел пользователь». Сравнивать не с текущей, а именно с ценой на момент подписки: важно, что для конкретного человека стало выгоднее.
• Достижение целевой цены. Продвинутый вариант — пользователь сам указывает желаемую цену, и письмо уходит при её достижении.

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

Отдельно стоит продумать поведение при обратном движении цены. Если цена снизилась, ушло письмо, а потом снова выросла — стоит ли слать «цена вернулась»? Как правило, нет: это раздражает. Логичнее фиксировать факт уведомления и при новом снижении сравнивать уже с последней уведомлённой ценой, чтобы человек получал письмо только при действительно новом, более выгодном предложении. Вопросы переоценки и ценовых политик подробно разобраны в материале про управление ценами и переоценку в 1С-Битрикс.

Как ловить события цены и остатка

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

Способ первый — обработчики событий каталога. Модуль каталога генерирует события при изменении цен и элементов. К ним подключают свои обработчики (обычно через EventManager или методы AddEventHandler), которые срабатывают ровно в тот момент, когда цена или остаток меняются программно — через API, админку или обмен, если он идёт через штатные механизмы. Наиболее востребованные точки перехвата:

Плюс событий — реакция в реальном времени: изменение поймано в ту же секунду. Минус — они не срабатывают, если данные меняются в обход ядра (прямые SQL-запросы, нестандартный импорт, отложенная запись остатков). Поэтому на события нельзя полагаться как на единственный источник истины.

Способ второй — агент со снимком данных. Это фоновый скрипт (штатный агент Битрикса или задача cron), который по расписанию проходит по товарам с активными подписками, сравнивает текущую цену и остаток с сохранённым ранее снимком и находит расхождения. Всё, что изменилось «вниз по цене» или «в плюс по остатку», ставится в очередь уведомлений. Агент медленнее событий, зато ловит любые изменения независимо от того, как они попали в базу, и служит страховкой от пропущенных пакетных обновлений.

Рабочая схема — гибрид: события дают мгновенную реакцию на точечные правки, а агент, привязанный к завершению обмена с 1С, гарантирует, что ни одно массовое изменение не потеряется. При этом оба источника пишут в единую очередь уведомлений, где уже работает дедупликация — чтобы одно и то же событие, пойманное и обработчиком, и агентом, не породило два письма.

Архитектура системы уведомлений

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

• Слой подписки. Формы «Сообщить о поступлении» и «Следить за ценой» на витрине, которые фиксируют интерес покупателя и его согласие на рассылку.
• Хранилище подписок. Таблицы с записями «пользователь — товар — тип события — эталонное значение — канал — статус».
• Слой перехвата. Обработчики событий каталога и агент-сверщик, которые обнаруживают снижение цены или появление остатка.
• Очередь уведомлений. Буфер задач на отправку с дедупликацией и учётом частоты; развязывает «обнаружение» и «доставку».
• Слой доставки. Отправители в конкретные каналы — e-mail, web-push, СМС-шлюз, мессенджеры, бот Битрикс24.
• Слой аналитики. Логи отправок, переходов и заказов, из которых считаются возврат и конверсия.

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

Каналы: email, push, СМС, мессенджеры

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

E-mail остаётся базой: он бесплатен, работает штатно через почтовые события, позволяет собрать в одном письме несколько подобревших товаров (дайджест) и показать карточку с картинкой и ценой. Главные задачи здесь — доставляемость (корректные SPF, DKIM, DMARC, репутация домена) и понятная тема письма, чтобы оно не терялось.

Web-push — лучший канал по скорости отклика. Подписка оформляется в один клик, без ввода почты, а уведомление всплывает мгновенно даже когда сайт закрыт. По CTR в первые часы после события push обычно обгоняет e-mail. Ограничение — он работает, пока жива браузерная подписка, поэтому push хорош как «быстрый» канал в связке с «долгим» e-mail.

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

Мессенджеры и бот Битрикс24 закрывают два разных сценария. Публичный бот в Telegram доводит уведомления до аудитории, которая не открывает почту, но постоянно в мессенджере. А внутренний бот Битрикс24 удобен в B2B: он оповещает менеджера, что у товара его клиента появился остаток, или пушит уведомление прямо в личный кабинет оптового покупателя. Инфраструктуру ботов и порталов мы настраиваем в рамках услуги по Битрикс24.

Хранение подписок и антиспам

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

• Кто — идентификатор пользователя или e-mail/токен анонимного посетителя.
• На что — товар или торговое предложение (SKU).
• Тип события — «появление в наличии» или «снижение цены».
• Эталонное значение — цена на момент подписки или целевая цена; для наличия — признак «ждём остаток».
• Канал — выбранный способ доставки (может быть несколько).
• Статус — активна, отправлено, отписан.
• Согласие — факт, дата и источник согласия на рассылку.
• Дата последней отправки — для контроля частоты.

На этой модели строится антиспам — без него система быстро превращается в источник раздражения и отписок. Три обязательных механизма:

Отдельно про дедупликацию после обмена. Когда 1С заливает остатки пакетом, у одного покупателя может «ожить» сразу пять товаров из его подписок. Пять отдельных писем — это спам; правильно собрать их в одно письмо-дайджест «5 товаров из ваших подписок снова в наличии». Тот же приём работает при массовой переоценке: вместо серии писем о каждой скидке — один аккуратный список. Дайджест не только бережёт нервы подписчика, но и снижает нагрузку на почтовый сервер и вероятность попасть в спам-фильтры.

«Тихие часы» — простое, но важное правило: не отправлять ночью. Событие, случившееся в 3:00 (а обмен с 1С часто идёт именно ночью), не должно будить покупателя push или СМС. Уведомления, попавшие в ночное окно, копятся и уходят утром — это и вежливее, и эффективнее по открываемости.

Связь с обменом 1С: остаток после выгрузки

Уведомление «товар в наличии» неразрывно связано с обменом 1С, потому что именно обмен — источник остатков в большинстве магазинов на Битриксе. Товар появляется в наличии не «сам по себе», а в момент, когда очередная выгрузка из 1С обновила количество. Значит, и проверять подписки логично не по абстрактному расписанию, а в привязке к завершению обмена.

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

Правильные приёмы синхронизации:

1. Привяжите проверку к концу обмена. Вешайте пакетную сверку подписок на событие завершения сессии импорта, а не на общий таймер. Как только выгрузка закончилась и остатки в базе актуальны — сразу проверяем подписки.
2. Сверяйте по снимку. Перед обменом сохраняйте снимок остатков подписанных товаров, после обмена сравнивайте — так вы поймаете именно переход «было 0 → стало больше 0», а не любое ненулевое количество.
3. Учитывайте склады и резерв. «В наличии» для покупателя — это доступный к заказу остаток с учётом резерва и нужного склада, а не сырое число из 1С. Считайте доступность так же, как её видит витрина.
4. Соблюдайте «тихие часы». Ночной обмен не должен рождать ночные push и СМС — складывайте такие уведомления в утреннюю отправку.
5. Логируйте расхождения. Фиксируйте случаи, когда событие не сработало и подписку «спас» агент, — это индикатор, что обмен идёт мимо событий и настройку стоит поправить.

Тема статусов и доступности товара тесно переплетается с уведомлениями: то, что показывается на витрине как «в наличии», «под заказ» или «предзаказ», определяет и логику подписки. Подробно эти статусы разобраны в материале про наличие, статусы и предзаказ в 1С-Битрикс. Настройку самого обмена и интеграций мы делаем в рамках профильной разработки на 1С-Битрикс.

Сегментация и триггерные сценарии

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

• По типу события. «Наличие» и «снижение цены» — разные интенты, у них разные тексты и призывы к действию. В наличии важна срочность («поступило, разбирают»), в цене — выгода («стало дешевле на X»).
• По ценности товара и клиента. Дорогой товар и постоянный покупатель заслуживают более быстрого и «дорогого» канала (push, СМС), массовый товар — e-mail.
• По давности подписки. Свежая подписка горячее: событие в первые дни закрывается лучше, чем через месяц, когда интерес остыл.
• По поведению. Открыл прошлое уведомление, но не купил — повод для мягкого напоминания или дополнительного стимула.

На сегментах строятся триггерные сценарии. Несколько рабочих примеров:

1. Возврат в наличие + срочность. Письмо «товар снова в наличии» усиливается указанием на ограниченный остаток и ссылкой на быстрый заказ. Механику дефицита и таймеров мы разбираем в статье про триггеры срочности.
2. Снижение цены + дедлайн акции. Если снижение — часть акции с датой окончания, добавьте в письмо срок действия цены: это резко повышает конверсию.
3. Догоняющее напоминание. Открыл уведомление, перешёл, но не купил — через сутки мягкое напоминание, что предложение ещё в силе.
4. Дайджест «ваши товары подобрели». Раз в период — сводка по всем подпискам пользователя с изменившимися ценой и наличием.
5. Кросс-сценарий для B2B. Оптовому клиенту уведомление дублируется его менеджеру через бот Битрикс24, чтобы тот проактивно связался и оформил заказ.

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

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

Соберём всё сказанное в практический порядок внедрения на платформе. Предполагаем редакцию с модулем «Интернет-магазин» (без него подписки на товар нет).

1. Включите штатную подписку на наличие. Разрешите подписку на отсутствующие товары в настройках торгового каталога и разместите компонент bitrix:catalog.product.subscribe в шаблоне карточки.
2. Расширьте модель подписок. Заведите хранилище с полями «тип события», «эталонная цена», «канал», «согласие», «дата последней отправки», чтобы поддержать подписку на цену и мультиканальность.
3. Добавьте форму «Следить за ценой». На карточке товара разместите вторую подписку, фиксирующую цену на момент подписки и выбор канала.
4. Подключите обработчики событий. На событиях цены (OnPriceUpdate, OnPriceAdd) и изменения остатка навесьте обработчики, которые кладут задачу в очередь уведомлений, но не рассылают синхронно.
5. Настройте агент-сверщик. Создайте агент, который после обмена с 1С сравнивает снимок цен и остатков с текущими значениями и добавляет пропущенные события в очередь.
6. Реализуйте очередь и антиспам. В слое очереди внедрите дедупликацию, кэп частоты, «тихие часы» и агрегацию в дайджест.
7. Подключите каналы. Настройте почтовые шаблоны, web-push, интеграцию со СМС-шлюзом и, при необходимости, с мессенджерами и ботом Битрикс24.
8. Привяжите рассылку к обмену. Запускайте отправку по завершении сессии импорта, а не по общему расписанию, чтобы уведомления уходили сразу после актуализации остатков.
9. Настройте согласие и отписку. Добавьте в формы галочку согласия со ссылкой на политику и ссылку «отписаться» в каждое сообщение.
10. Разметьте аналитику. Логируйте отправки, переходы (с UTM-метками) и заказы, чтобы считать возврат и конверсию.

Схематично «пульт» настройки уведомлений в админской части выглядит так — набор переключателей каналов, порогов и правил частоты:

Юридические аспекты и согласие

Уведомления о цене и наличии — это рассылка по персональным данным, поэтому их нельзя внедрять «на глазок». В российском поле работают два ключевых закона: 152-ФЗ «О персональных данных» (регулирует сбор и обработку e-mail, телефона, идентификаторов) и 38-ФЗ «О рекламе» (рассылка допускается только с предварительного согласия получателя). Игнорирование этого — реальные штрафы и репутационные риски, а не формальность.

Что нужно сделать, чтобы система была юридически чистой:

• Получать явное согласие. В форме подписки — отдельная галочка (не предустановленная) со ссылкой на политику обработки персональных данных и согласие на рассылку.
• Фиксировать факт согласия. Сохраняйте дату, время, IP и текст, с которым согласился пользователь. Это доказательство на случай претензий.
• Давать отписку в один клик. В каждом письме и сообщении — рабочая ссылка «отписаться», которая мгновенно деактивирует подписку без дополнительных шагов.
• Разделять транзакционное и рекламное. «Вы подписались на товар X» ближе к сервисному сообщению, «загляните, у нас акции» — реклама. Не подмешивайте промо в сервисные уведомления без отдельного согласия.
• Соблюдать специфику каналов. Для СМС и мессенджеров правила о согласии особенно строги — храните подтверждение подписки на каждый канал.
• Хранить данные корректно. Обеспечьте защиту базы подписок и возможность удаления данных по запросу субъекта.

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

Метрики: возврат и конверсия

Чтобы система уведомлений считалась работающей, её эффект нужно измерять, а не «чувствовать». Ключевая ценность здесь — возвращённые покупатели и заказы, которых без уведомления не случилось бы. Набор метрик, который стоит вести:

Чтобы эти цифры были достоверными, размечайте ссылки в уведомлениях UTM-метками и связывайте переход с заказом в аналитике. Отдельно ведите атрибуцию: заказ, оформленный в течение окна атрибуции после клика по уведомлению, засчитывается каналу уведомлений. Так вы отделите реальный вклад триггеров от заказов, которые случились бы и без них.

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

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

• Рассылают письмо синхронно прямо в обработчике события — обмен с 1С и админка начинают тормозить, а часть уведомлений теряется при сбоях.
• Полагаются только на события каталога — пакетные обновления остатков из 1С проходят мимо, и подписчики не получают уведомлений.
• Не привязывают рассылку к завершению обмена — уведомление о наличии приходит с задержкой в часы, когда покупатель уже купил у конкурента.
• Шлют письмо на каждый тик цены без порога и дедупликации — подписчик получает спам и отписывается.
• Считают «в наличии» по сырому числу из 1С, без учёта резерва и складов — покупатель приходит по уведомлению, а товара для заказа нет.
• Не собирают несколько сработавших подписок в дайджест — после большого обмена одному человеку уходит пачка отдельных писем.
• Игнорируют «тихие часы» — ночной обмен рождает ночные push и СМС, которые будят и раздражают.
• Не оформляют согласие на рассылку и отписку — юридические риски по 152-ФЗ и 38-ФЗ плюс рост жалоб на спам.
• Не размечают аналитику — эффект уведомлений невозможно доказать, и канал первым попадает под сокращение бюджета.

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

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

1. Подписка на наличие включена. Штатный компонент catalog.product.subscribe размещён, форма «Сообщить о поступлении» показывается при нулевом остатке.
2. Подписка на цену работает. Форма «Следить за ценой» фиксирует эталонную цену на момент подписки и выбранный канал.
3. Изменения ловятся двумя источниками. Обработчики событий каталога и агент-сверщик работают вместе, оба пишут в единую очередь.
4. Рассылка асинхронная. Обработчики только ставят задачу в очередь, отправку выполняет отдельный агент.
5. Синхронизация с обменом. Проверка подписок привязана к завершению сессии импорта из 1С, доступность считается с учётом резерва и складов.
6. Антиспам настроен. Работают дедупликация, порог значимости, кэп частоты, «тихие часы» и агрегация в дайджест.
7. Каналы подключены. Настроены нужные каналы (e-mail, push и др.), пользователь может выбрать канал при подписке.
8. Согласие и отписка. В формах есть галочка согласия со ссылкой на политику, в каждом сообщении — отписка в один клик; факт согласия сохраняется.
9. Аналитика размечена. Логируются отправки, переходы с UTM и заказы; считаются возврат и конверсия из уведомления.

Вывод

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