Клиент зашёл, посмотрел три товара, положил один в корзину — и ушёл, не оплатив. В большинстве магазинов на этом история заканчивается. А могла бы продолжиться письмом через час: «Вы забыли товар в корзине» с этим самым товаром и кнопкой оформления. Именно такие триггерные сценарии и строит Carrot quest — но только если он правильно подключён к магазину и получает поведение и заказы, а не просто список адресов.
В этой статье — пошаговое подключение Carrot quest к интернет-магазину на 1С-Битрикс: два канала данных (скрипт и сервер), какие события передавать, как надёжно отправлять заказы, настроить брошенную корзину, сегменты и не поругаться со штатным модулем «Рассылки». Тему email-маркетинга в целом мы разбирали в статье про email- и CRM-маркетинг в Битрикс; здесь — конкретика по Carrot quest.
Коротко
- Подключение — это не импорт адресов, а передача поведения и заказов, на которых строятся триггеры.
- Данные идут двумя каналами: JS-скрипт (поведение) и серверная передача через API (надёжные заказы).
- Критичные факты — оплаченные заказы, суммы, состав — передавайте с сервера, а не из браузера.
- Разграничьте зоны с модулем Sender и ведите учёт согласий на рассылку, чтобы не спамить и не нарушать закон.
Что даёт Carrot quest интернет-магазину
Обычная рассылка работает по принципу «отправить письмо списку». Carrot quest устроен иначе: он собирает поведение каждого пользователя и запускает коммуникации от событий. Это переводит email из «веерных писем» в персональные триггерные сценарии, которые срабатывают в нужный момент.
Типовые сценарии для магазина: брошенная корзина, брошенный просмотр товара, реактивация «спящих» клиентов, допродажа сопутствующего после покупки, поздравление и напоминание о повторной закупке. Все они опираются на данные о поведении и заказах — поэтому качество интеграции определяет, будут ли триггеры вообще работать.
Скрипт и серверная передача: два канала данных
Правильное подключение использует два дополняющих канала, и путать их роли нельзя.
| Канал | JS-скрипт на сайте | Серверная передача (API) |
|---|---|---|
| Что собирает | Поведение: просмотры, клики, корзина | Факты: оформленные и оплаченные заказы |
| Надёжность | Зависит от браузера и блокировщиков | Высокая, не зависит от клиента |
| Идентификация | Анонимы и авторизованные | Авторизованные, по данным заказа |
| Для чего | Брошенная корзина, просмотры | Заказ оплачен, суммы, статусы |
Скрипт даёт поведение в реальном времени, включая анонимов, но ему нельзя доверять критичные данные. Серверная передача даёт достоверные факты о заказах. Вместе они закрывают и «мягкие» триггеры по поведению, и «твёрдые» по деньгам.
Какие события передавать
Ценность триггеров прямо зависит от богатства событий. Минимальный полезный набор для магазина:
- Идентификация пользователя. Email, имя, город, группа клиента при авторизации.
- Просмотр товара. Какой товар смотрел, с ценой и ссылкой.
- Добавление в корзину. Состав корзины, количество, суммы.
- Оформление заказа. Номер, состав, сумма, способ оплаты.
- Оплата и смена статуса. Заказ оплачен, собран, отгружен.
- Согласие на рассылку. Признак маркетингового согласия.
Подключение к 1С-Битрикс пошагово
Общая последовательность подключения на 1С-Битрикс выглядит так:
- Установите JS-скрипт. Код Carrot quest подключают в шаблоне сайта, чтобы он загружался на всех страницах.
- Настройте идентификацию. Для авторизованного пользователя передавайте email и атрибуты из его профиля.
- Пробросьте поведение корзины. События добавления в корзину и просмотра товара — с составом и ссылками.
- Настройте серверную передачу заказов. Обработчик события заказа отправляет факт оформления и оплаты в API Carrot quest.
- Передайте атрибуты клиента. Город, группа, сумма покупок, дата последнего заказа для сегментации.
- Настройте триггеры. Брошенная корзина, реактивация, допродажа — уже в интерфейсе Carrot quest.
- Протестируйте сквозной путь. Пройдите как клиент: просмотр → корзина → заказ → письмо; проверьте, что данные дошли.
Скрипт и серверную передачу удобно выносить в отдельный модуль или обработчики, чтобы не «зашивать» интеграцию в шаблон. Как устроена такая переносимая логика, мы разбирали в статье про разработку модуля Битрикс.
Передача заказов с сервера
Ключевой технический момент — почему заказы нельзя передавать только из браузера. Скрипт может не сработать: блокировщик рекламы, обрыв связи, клиент закрыл вкладку сразу после оплаты. Если триггеры про деньги («заказ оплачен», «повторная покупка») строить на браузерных событиях, часть заказов просто потеряется, а статистика поедет.
Надёжный путь — серверная передача из обработчика события заказа в 1С-Битрикс: когда заказ оформлен или сменил статус на «оплачен», сервер отправляет событие в API Carrot quest. Так факт заказа доходит гарантированно.
Как проектировать такие исходящие вызовы безопасно, с ретраями и без задвоений, мы подробно разбирали в материале про REST, вебхуки и безопасность в Битрикс.
Триггер «брошенная корзина»
Брошенная корзина — самый окупаемый триггер магазина, и он полностью зависит от данных, которые вы передаёте. Чтобы он работал, нужно:
- Событие добавления в корзину. С составом, количеством, ценами и ссылками на товары.
- Идентификация пользователя. Чтобы было куда отправлять письмо — email известен.
- Событие оформления заказа. Чтобы триггер не сработал, если клиент всё-таки оплатил.
- Актуальные ссылки на товары. В письме — конкретные позиции из корзины, ведущие на живые страницы.
Логика проста: корзина наполнена, но заказа за N часов нет — уходит письмо с этими товарами. Важно передавать именно состав корзины, а не только факт «что-то положили», иначе письмо будет безличным и слабым.
Сегменты, атрибуты и группы клиентов
Персонализация писем строится на атрибутах, которые вы передаёте вместе с идентификацией. Чем богаче профиль, тем точнее сегменты:
- Группа клиента. Опт или розница — от этого зависят и предложения, и тон письма.
- Город и регион. Для локальных акций, складов и условий доставки.
- Сумма и частота покупок. Чтобы отделить лояльных от разовых и «спящих».
- Дата последнего заказа. Основа для реактивации и напоминаний о повторной закупке.
Для B2B особенно важны группа клиента и история заказов: оптовику пишут не «скидка 10% на всё», а «пора пополнить запас по вашей номенклатуре». Если у вас несколько каналов (email, чат, мессенджеры), их полезно свести в единый профиль клиента — например, через омниканальность WhatsApp, Telegram, Email и чата в RetailCRM, чтобы история общения не была разорванной.
Разграничение с модулем «Рассылки»
В 1С-Битрикс есть собственный модуль рассылок (Sender) и транзакционные письма. Если не разграничить зоны с Carrot quest, клиент получит дубли, а вы — хаос в статистике.
Такое разделение убирает риск двойных писем и делает аналитику прозрачной: понятно, какой канал за что отвечает и что именно приносит продажи.
Согласия и требования закона
Маркетинговые письма можно слать только тем, кто дал согласие. Это не формальность: нарушение закона о рекламе и о персональных данных грозит штрафами и жалобами на спам, которые бьют по доставляемости всех ваших писем.
- Собирайте согласие явно. Отдельная галочка при регистрации или оформлении заказа, не предустановленная.
- Передавайте признак согласия. В атрибутах пользователя, чтобы Carrot quest не слал маркетинг несогласившимся.
- Разделяйте транзакционное и маркетинговое. Подтверждение заказа — всем, реклама — только согласившимся.
- Давайте отписку. Простой и рабочий механизм отписки в каждом маркетинговом письме.
Устойчивость к обмену с 1С
Каталог магазина обычно наполняется обменом из 1С, и здесь кроется частая поломка интеграции: если при выгрузке меняются URL товаров или их идентификаторы, письма о брошенной корзине начинают вести на несуществующие страницы. Клиент кликает — попадает на 404, и триггер вместо продажи приносит раздражение.
Чтобы этого не было, в события передают устойчивые идентификаторы и актуальные ссылки, а обмен настраивают так, чтобы коды и адреса товаров не «плавали». Стабильность обмена и идентификаторов — общая база для любых интеграций; она же критична для инфраструктуры и фоновых задач, о которых мы писали в материале про инфраструктуру и BitrixVM.
Частые ошибки
- Заказы передают только из браузера. Часть заказов теряется, триггеры про деньги работают неточно.
- Нет состава корзины в событии. Письмо о брошенной корзине безличное, без конкретных товаров.
- Дубли с модулем Sender. Клиент получает два письма об одном событии, растёт число жалоб.
- Нет учёта согласий. Маркетинг уходит несогласившимся — штрафы и падение доставляемости.
- Плавающие ссылки на товары. После обмена с 1С письма ведут на 404.
- Нет защиты от дублей событий. Одно событие уходит дважды, отчёты и триггеры искажаются.
- Не протестирован сквозной путь. Настроили, но не прошли как клиент — часть событий не доходит.
Чек-лист внедрения
- Скрипт установлен. Код Carrot quest грузится на всех страницах через шаблон.
- Идентификация настроена. Для авторизованных передаются email и атрибуты профиля.
- Поведение корзины пробрасывается. Просмотры и добавление в корзину с составом и ссылками.
- Заказы идут с сервера. Обработчик события заказа отправляет факты в API, есть защита от дублей.
- Брошенная корзина работает. Триггер учитывает оформление заказа и подставляет товары.
- Атрибуты для сегментов переданы. Группа клиента, город, суммы, дата последнего заказа.
- Зоны с Sender разграничены. Транзакционное — штатно, триггерный маркетинг — в Carrot quest.
- Согласия учтены. Признак согласия передаётся, отписка работает, закон соблюдён.
Вывод
Подключить Carrot quest к магазину на 1С-Битрикс — это не залить список адресов, а наладить поток данных: поведение через скрипт и надёжные заказы с сервера. На этих данных строятся окупаемые триггеры — прежде всего брошенная корзина и реактивация, которые возвращают клиентов без затрат на рекламу.
Передавайте критичные факты о заказах серверно и защищайтесь от дублей, разграничьте зоны со штатным модулем «Рассылки», ведите учёт согласий и следите за стабильностью ссылок при обмене с 1С. Тогда триггерный email превратится из «письма всем» в персональный канал, который системно приносит повторные продажи.
