Daemon Collector: сбор данных с сайта

Daemon Collector — JavaScript-скрипт RetailCRM, который собирает поведенческие данные посетителей сайта: визиты, просмотры товаров, действия перед оформлением. Эти данные связывают анонимные визиты с клиентами и питают сегментацию, триггеры и товарные рекомендации.

Что делает Daemon Collector

Daemon Collector устанавливается на все страницы сайта и работает в фоне на стороне браузера. Он фиксирует активность посетителя и передаёт её в RetailCRM, дополняя картину клиента данными о поведении на сайте — тем, чего нет в самих заказах.

• Визиты — факт и параметры посещения страниц;
• Просмотры товаров — какие карточки смотрел посетитель;
• Связывание с клиентом — сопоставление визита с известным клиентом по контактам;
• Данные для рекомендаций — история просмотров как основа персонализации.

Установка на сайт

Скрипт подключается один раз на всех страницах — обычно перед закрывающим тегом </body> или через менеджер тегов. В коде указывается идентификатор сайта из настроек RetailCRM, чтобы данные попадали в нужный аккаунт.

1. Получите код Daemon Collector в настройках сайта в RetailCRM;
2. Разместите скрипт на всех страницах сайта;
3. Убедитесь, что он загружается асинхронно и не блокирует рендеринг;
4. Проверьте в консоли и в интерфейсе CRM, что визиты фиксируются.

Устанавливать скрипт нужно именно на всех страницах: пропуск части страниц создаёт слепые зоны в аналитике поведения и портит воронку. Через менеджер тегов подключение удобнее контролировать централизованно, но важно проверить, что тег срабатывает на всех шаблонах страниц — включая карточки товара, корзину и страницу оформления, которые и дают самые ценные данные о намерениях посетителя.

Связывание визита с клиентом

Ключевая ценность Collector — соединить анонимный визит с конкретным клиентом. Пока посетитель не идентифицирован, его действия копятся под анонимным идентификатором. Как только становятся известны контакты (авторизация, оформление, подписка), визиты привязываются к клиенту.

• По e-mail или телефону — когда посетитель их указал;
• При авторизации — если на сайте есть личный кабинет;
• При оформлении заказа — контактные данные из формы.

Отслеживание товаров

Чтобы Collector фиксировал просмотры конкретных товаров, на страницах карточек ему передают данные о товаре — идентификатор, соответствующий номенклатуре RetailCRM. Так история просмотров становится основой для рекомендаций и триггеров.

• Просмотр карточки — какой товар открывал посетитель;
• Идентификатор товара — должен совпадать с id в каталоге RetailCRM;
• Действия с корзиной — добавление и изменение состава.

Согласованность идентификаторов между сайтом, каталогом ICML и данными Collector — обязательное условие. Если id расходятся, RetailCRM не сможет связать просмотр с карточкой товара, и рекомендации потеряют точность. Поэтому источник идентификаторов делают единым: и выгрузка каталога, и разметка страниц берут id из одной системы, а не формируют его независимо на каждой стороне.

Брошенные корзины и триггеры

Данные Collector о действиях с корзиной питают один из самых востребованных сценариев — возврат брошенных корзин. Когда посетитель добавил товары, но не оформил заказ, это событие используется в автоматизации.

1. Collector фиксирует наполнение корзины и отсутствие оформления;
2. Данные связываются с клиентом по контактам;
3. Триггер RetailCRM запускает напоминание — письмо или сообщение;
4. В шаблоне выводится состав корзины и ссылка на возврат.

Здесь Collector, автоматизация и шаблоны работают в связке: скрипт собирает данные, триггер решает, когда напомнить, а Twig формирует текст сообщения. Задержку перед напоминанием подбирают эмпирически — слишком раннее сообщение раздражает, слишком позднее теряет актуальность. Обычно настраивают отсрочку в несколько часов и ограничивают частоту, чтобы один клиент не получал напоминания по каждому визиту.

Проверка и отладка

После установки скрипт нужно проверить, иначе есть риск неделями собирать неполные данные. На что смотреть:

• Загрузка скрипта — присутствует ли Collector на всех типах страниц;
• Фиксация визитов — появляются ли посещения в интерфейсе RetailCRM;
• Идентификаторы товаров — совпадают ли они с каталогом;
• Связывание — привязывается ли визит к клиенту после идентификации;
• Производительность — не влияет ли скрипт на скорость загрузки страниц.

Для SPA и сайтов с динамической навигацией отдельно проверяют, что переходы без перезагрузки страницы тоже фиксируются как просмотры.

Итог

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

Мы внедряем Daemon Collector в связке с каталогом, автоматизацией и обменом данными — с корректной передачей товарных идентификаторов, поддержкой SPA и интеграцией сценариев вроде брошенных корзин. Настраиваем так, чтобы данные были полными и работали на выручку.