Как Botseller отслеживает путь клиента: архитектура

Как Botseller отслеживает путь клиента: архитектура

Разбор этой статьи

AI-подкаст BotsellerСлив бюджета на Я.Директ: как first-touch возвращает выручку
0:00 / 0:00

Эту тему разобрали в подкасте. Слушай параллельно с чтением.

Путь клиента это полная цепочка касаний человека с брендом до покупки: первый клик по рекламе, чтение статьи, открытие email, повторный визит из поиска, заявка с сайта. По данным Dreamdata, средняя B2B-сделка в 2026 году требует 88 касаний по 4 каналам, а для контрактов от $100K эта цифра доходит до 417 касаний и 5 500 рекламных показов. Если CRM не видит этот путь, маркетолог теряет от 30 до 45% выручки на ложной атрибуции и неоптимизированных рекламных бюджетах.

Я Дмитрий Дьяконов, CEO Botseller AI. За три года мы построили собственную систему сквозной аналитики, встроенную прямо в CRM, без зависимости от внешних сервисов вроде Roistat и Calltouch. В этой статье разберу архитектуру под капотом: как мы собираем 100% касаний клиента, почему храним два слоя данных, как sticky-cookies переживают 90 дней между визитами, и главное, как AI-продавец Botseller использует эти данные в реальном диалоге с клиентом. Аккредитованная IT-компания Минцифры РФ.

B2B-реальность 2026: 88 касаний по 4 каналам в среднем, до 417 касаний для контрактов от $100K. Last-touch модель скрывает 95% воронки и приводит к потере 30-45% выручки

Что такое путь клиента и почему его важно измерять?

Путь клиента (customer journey) включает все взаимодействия человека с брендом: показ рекламы, клик по баннеру, просмотр статьи, открытие email, заход в Telegram-канал, заявка с сайта. Раньше маркетологи смотрели только на последний клик: «откуда пришёл лид прямо перед заявкой». Эта модель last-touch attribution работала в 2010 году, когда воронка была короткой. В 2026 году один и тот же человек видит вашу рекламу в Я.Директе, читает кейс в блоге, подписывается на Telegram, спустя месяц возвращается из поиска и оставляет заявку.

Если CRM фиксирует только последний клик (например, Google поиск), маркетолог увидит «лид пришёл из органики» и сократит бюджет на Я.Директ. Через два месяца поток лидов упадёт на 40%, потому что без Я.Директа не было первого касания. Это называется misattribution: реклама работает, но в отчётах её вклад невидим.

Современная атрибуция должна показывать всю цепочку. По данным Dataslayer 2026, 75% компаний перешли на multi-touch attribution и получили улучшение CPA на 14–36%. Гартнеровское исследование UK Digital Marketing 2025 фиксирует, что только 24% B2B-компаний пока пользуются multi-touch, остальные продолжают терять деньги на одноточечных моделях.

Что такое сквозная аналитика и чем она отличается от Google Analytics?

Сквозная аналитика связывает рекламные платформы (Я.Директ, Google Ads, Meta), веб-аналитику (Я.Метрика, GA4), CRM и платёжные системы в одну цепочку. Цель: посчитать ROI каждой кампании, кампании, объявления и ключевого слова не по кликам, а по реальной выручке, дошедшей до счёта.

Google Analytics показывает что юзер сделал на сайте: страницы, время, конверсии. Но GA не знает, какой контракт этот юзер закрыл через три недели. CRM знает про сделку, но не помнит, по какой рекламе человек впервые пришёл. Сквозная аналитика соединяет эти два мира.

Классические инструменты для России: Roistat, Calltouch, Comagic, K50. Эти сервисы стоят от 5 000 до 50 000 рублей в месяц и подключаются как внешний слой. Botseller строит сквозную аналитику иначе: мы захватываем всё внутри собственной CRM, без отдельного сервиса. Это даёт три преимущества: ноль доплат за аналитику, единая воронка с продажами, и главное, AI-продавец читает путь клиента в реальном времени.

Смена парадигмы: Web-аналитика (GA4 / Я.Метрика) видит клики, но не выручку. Внешние трекеры (Roistat, Calltouch) дают дашборд маркетологу, но не передают данные в продажный диалог. Botseller хранит всё в одной базе и AI-продавец использует данные в реальном времени

Как устроена сквозная аналитика в Botseller: два слоя данных?

Под капотом мы храним атрибуцию в двух разных таблицах базы данных. Это сделано не случайно. Каждый слой решает свою задачу, и попытка свернуть всё в одну таблицу замедлит и фильтры в карточке лида, и аналитические отчёты на масштабе миллионов событий.

Слой 1: snapshot на момент заявки. В таблице leads_table есть JSONB-поле attribution_data. Когда человек заполняет веб-форму на сайте, мы делаем снимок: какие UTM-метки в URL, какие click_id (gclid, yclid, fbclid, ttclid), какие cookies счётчиков (_ga, _ym_uid, _fbp), referrer, заголовок страницы, IP, часовой пояс, язык браузера. Этот snapshot не меняется. Он отвечает на вопрос «что мы знали об этом человеке в момент заявки».

Слой 2: timeline всех касаний. Отдельная таблица customer_touchpoints_table хранит каждое событие: page_view (просмотр страницы), form_submit (заявка), email_open, email_click, bot_subscribe (подписка на Telegram-бот), file_download (скачивание гайда), status_change (смена стадии лида). Связь с лидом через идентификатор контакта: телефон, email или анонимный UUID до создания лида. Это даёт полную хронологию: «27 апреля посмотрел три статьи, 28 апреля скачал гайд, 30 апреля оставил заявку».

Snapshot нужен для быстрого отображения в карточке лида и фильтрации в kanban. Timeline нужен для multi-touch отчётов и тёплого диалога. У них разная нагрузка: snapshot читается 1 раз при открытии карточки, timeline читается миллионы раз при построении воронки. Разделение даёт скорость на масштабе.

Два слоя хранения данных. Слой 1: Snapshot (статичная фотография момента заявки), читается 1 раз для карточки лида. Слой 2: Timeline (бесконечная лента всех событий: page_view, email_open, bot_subscribe), читается миллионы раз для отчётов и AI-контекста

Как sticky-cookies помнят клиента 90 дней?

Без cookies каждый визит на сайт это новый посетитель. Человек кликнул по баннеру РСЯ в понедельник, ушёл, вернулся в пятницу прямо на /contact и оставил заявку. Если в момент заявки мы видим только URL без UTM, в карточке появится «прямой переход», а Я.Директ не получит конверсию. Бюджет уйдёт в минус.

Чтобы этого избежать, наш скрипт pixel.js ставит на сайт клиента два cookie:

  • _bs_anon_id (365 дней). UUID v4. Выдаётся при первом визите и переживает все последующие сессии. Связывает 50 разных visit’ов в одну личность.
  • _bs_first_touch (90 дней). JSON со snapshot первого визита: UTM, referrer, landing URL, время. Sticky: НЕ перезаписывается при повторных визитах. Если человек впервые пришёл из РСЯ, а потом возвращался десять раз из поиска, в _bs_first_touch всё равно будет yandex/cpc.

Когда человек заполняет форму, наш widget читает оба cookie и кладёт в payload. Backend получает двойную картину: текущая сессия (как пришёл сейчас) + first touch (как привёл изначально). В карточке лида маркетолог видит «канал заявки: google/organic, первое касание: yandex/cpc 5 дней назад». Это позволяет правильно атрибутировать конверсию обратно в РСЯ через offline-conversions API.

Реальные сценарии, которые мы покрываем: реклама в Reels с fbclid, возврат через РСЯ после первого касания, прямой переход с предыдущим визитом из Telegram, скачивание гайда с последующей заявкой через неделю. В каждом случае first_touch остаётся стабильной точкой отсчёта.

Глубокий трекинг 90 дней Sticky Cookies. День 1: клик по баннеру РСЯ, установлен _bs_first_touch=yandex/cpc. День 15: повторный визит из Google, кука НЕ перезаписывается. День 40: прямой заход и заявка, конверсия атрибутируется обратно в РСЯ. Бюджет Я.Директа спасён от ложной органической атрибуции

Чем первое касание отличается от последнего и зачем хранить оба?

Первое касание (first-touch) фиксирует, какой канал привёл человека на сайт впервые. Последнее касание (last-touch) фиксирует, какой канал был активен прямо перед заявкой. Оба нужны для разных задач, и Botseller хранит оба автоматически.

First-touch нужен для оптимизации алгоритмов закупки рекламы. Когда лид становится оплаченным, мы можем отправить конверсию обратно в Google Ads, Я.Директ или Meta через их Conversion API. Алгоритм платформы получает сигнал «эта реклама окупилась» и начинает приводить похожих людей. Если отправлять конверсию по last-touch (например, по google/organic), Я.Директ не увидит конверсии и срежет показы РСЯ через две недели.

Last-touch нужен для коротких воронок: e-commerce, услуги МСБ с импульсной покупкой, B2C-сегменты с одним сравнением. Если ваш цикл сделки 1–7 дней и 3–5 касаний, last-touch модель достаточно точна. По исследованию Heeet 2026, для B2B с 6+ касаниями last-touch активно отговаривают использовать.

Multi-touch attribution это среднее между двумя крайностями. Распределяет вес конверсии между всеми касаниями: linear (равномерно), time-decay (последние касания весят больше), position-based (40% первому, 40% последнему, 20% среднему). Botseller хранит сырой timeline, поэтому маркетолог может построить любую модель в отчёте: достаточно агрегировать customer_touchpoints по нужной формуле.

First-touch vs Last-touch: зачем хранить оба. First-touch обучает алгоритмы Я.Директ и Meta Ads через Conversion API, чтобы платформа не срезала показы. Last-touch оценивает финальный триггер для коротких воронок 1-7 дней (e-commerce, импульсный спрос). Категорически не подходит для длинного B2B

Как мы ловим переходы внутри SPA-сайта?

Современные сайты построены на Next.js, React Router, Vue Router. Когда юзер кликает по ссылке /blog/article-X, браузер не делает полную перезагрузку: фреймворк меняет URL через history.pushState и подгружает только новый компонент. Стандартный pixel-tracker не видит этих переходов, потому что грузится один раз и больше не запускается.

Без патча получалось так: человек попадал на главную, pixel.js фиксировал page_view главной. Дальше юзер кликал по /pricing, потом по /blog/case-1, потом по /contact и оставлял заявку. В таблице customer_touchpoints была одна запись (главная), вместо четырёх. Карточка лида показывала «1 касание», а на самом деле было 4. Маркетолог не видел, какие страницы прогрели клиента.

Мы патчим history.pushState, history.replaceState и слушаем событие popstate (для кнопок «назад/вперёд» браузера). На каждое изменение URL отправляем page_view с заголовком страницы (document.title) и путём (window.location.pathname). Дополнительно поставили dedupe в RAM: если на тот же URL уже был fetch за последние 30 секунд, повторный не шлём (защита от F5-spam и hot-reload в режиме разработки).

В карточке лида теперь маркетолог видит хронологию: «Тарифы → Кейс салона красоты → Сравнение с Salebot → Контакты → Заявка с сайта». Это уже готовый сюжет для звонка: «Здравствуйте, вижу вы читали наш кейс по салону красоты, у вас тоже бьюти-сфера?».

Слепое пятно SPA-сайтов (React, Vue, Next.js). Без патча обычный pixel видит только 1 событие: загрузку первой страницы. URL меняется через history.pushState без перезагрузки, и переходы по «Тарифы → Кейс → Контакты → Заявка» теряются. Botseller патчит pushState/replaceState и ловит весь маршрут прогрева

Как AI-продавец читает путь клиента в промпте?

Это главное преимущество Botseller, которого нет у Roistat, Calltouch и аналогичных сервисов. У них сквозная аналитика заканчивается отчётом для маркетолога. У нас она продолжается в системный промпт AI-продавца, который ведёт диалог с клиентом в мессенджере.

Когда лид пишет в Telegram, наш бот перед формированием ответа подгружает контекст: какие страницы юзер посещал, какие гайды скачивал, какие email открывал, по какой рекламе пришёл, был ли уже у нас в чате две недели назад. Этот блок данных вкладывается в системный промпт LLM:

[КОНТЕКСТ КЛИЕНТА] Источник: Я.Директ, кампания spring_b2b Первое касание: 5 дней назад Прочитанные статьи (за 7 дней): - Кейс: салон красоты на автопилоте - Salebot vs Botseller: конструктор или ИИ? - Тарифы Botseller Скачанные материалы: PDF "Гайд по настройке бота" Источник заявки: реклама Я.Директ [ИНСТРУКЦИЯ] Учитывай что клиент уже сравнил тебя с Salebot, читал кейс салона и скачал гайд. Не объясняй базу. Веди разговор от его уровня знания. Сегмент: бьюти. Возраст знакомства: 5 дней.

В результате бот не пишет «здравствуйте, я ИИ-помощник Botseller, чем могу помочь». Он пишет «здравствуйте, по вашим вопросам вижу что присматриваетесь к замене Salebot для салона. Что главное хотите получить от ИИ-бота: запись на услуги, продажу абонементов или работу с базой?».

Roistat даёт отчёт. Botseller продаёт. Это разница между reporting-сервисом и operating-системой.

Синтез: как ИИ-продавец читает путь клиента. Сырой timeline (читал кейс салона, сравнивал с Salebot) попадает в системный промпт LLM как INJECT-блок, и бот пишет персонализированный ответ в Telegram вместо стандартного «здравствуйте, чем помочь». Roistat reporting vs Botseller operating

Что мы можем и НЕ можем зафиксировать?

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

ЧтоМожемЧастичноНе можем
UTM-метки в URL
Click ID (gclid, yclid, fbclid, ttclid, vk_aid_id)
Cookies счётчиков (_ga, _ym_uid, _fbp, _fbc, _ttp)
First touch на 90 дней
Просмотры страниц блога / тарифов / кейсов
Скачивания PDF / лид-магнитов
Cross-device (телефон → десктоп)После идентификации по email/phone
Какой Reels именно посмотрел в MetaТолько если utm_content задан вручную
Сколько процентов YouTube-видео досмотрел❌ Закрытое API
Полные сообщения в Telegram-канале (до подписки)❌ Закрытое API
iOS Safari ITP блокирует cookies через 7 дней❌ Принять как ограничение
Adblock / uBlock блокирует pixel-fetch❌ ~5–15% посетителей

iOS ITP и AdBlock закрывают примерно 10–20% реальных касаний. Для оставшихся 80–90% мы видим полный путь. Cross-device связывание происходит ретроспективно: когда человек впервые идентифицирует себя (оставит email/phone), мы привязываем все его pre-lead анонимные касания (по _bs_anon_id) к этому контакту.

Честный чек-лист видимости, три зоны. Зелёная (100%): UTM-метки, Click ID, cookies на 90 дней, SPA-переходы, скачивания PDF. Жёлтая (частично): cross-device после идентификации по email/phone. Красная (объективные ограничения): iOS Safari ITP блокирует cookies 7 дней, AdBlock режет pixel у 10-15% посетителей, досмотры YouTube и чтение постов TG до подписки доступны только через закрытые API

Почему встроено в CRM, а не интеграция с Roistat?

У нас было два варианта: интегрироваться с Roistat (как делает простая CRM Botseller) или построить свою систему. Мы выбрали второй путь по трём причинам.

Первое: цена. Roistat стартует от 5 000 рублей в месяц на минимальном тарифе с базовыми функциями. Для МСБ это +60 000 рублей в год сверху на сервис, который собирает то, что мы и так собираем для AI-продавца. Логичнее показать эти данные клиенту сразу в карточке лида, без второй подписки.

Второе: AI-продавец. Я уже рассказал выше. Внешний сервис не передаёт контекст в промпт LLM. Чтобы сделать такое поверх Roistat, нужно настроить webhook от Roistat, написать middleware-сервис, который собирает данные перед каждым ответом бота, добавить кэш чтобы не упирать в API-лимиты Roistat. Это месяцы работы, а у нас всё работает из коробки.

Третье: единая воронка. У клиента не должно быть двух источников правды. CRM показывает «лид оплачен», Roistat показывает «по этому клику конверсия». Если цифры расходятся, начинается спор кто прав. Мы храним всё в одной базе, и расхождения невозможны по определению.

Когда Roistat нужен дополнительно: enterprise B2B со множеством офлайн-воронок (звонки + встречи + ивенты). Тогда наша атрибуция покрывает мессенджеры и веб, а Roistat дотягивает звонки и POS-данные. Эти два слоя не конфликтуют, а дополняют. Связку Roistat и Botseller для крупного B2B разберём в отдельной статье. Если у вас сейчас стоит Roistat и вы оцениваете замену, посмотрите интеграцию Botseller с amoCRM или почитайте как простая CRM Botseller масштабируется на крупный бизнес.

Три причины почему мы не интегрировались с Roistat: цена (от 60 000 руб/год для МСБ за дублирующий слой данных), трение AI-контекста (передача через middleware вместо прямого доступа в промпт LLM), единый источник правды (одна база данных вместо двух с риском рассинхрона)

Как пользоваться сквозной аналитикой Botseller на своём сайте?

Вся атрибуция работает из коробки после установки двух скриптов. Это занимает 10 минут.

Шаг 1: pixel.js на ВСЕ страницы сайта. Один скрипт в <head> или через Google Tag Manager. Он ставит cookies, отправляет page_view на каждую страницу (включая SPA-переходы), захватывает first_touch при первом визите. Подробная инструкция есть в быстром старте Botseller.

Шаг 2: widget.js на странице с формой. Одна строка <script src="...widget.js?id=UUID">. Виджет рендерит форму в iframe, при submit’е читает все cookies + UTM из текущего URL, отправляет на webhook вместе с данными формы. Лид появляется в CRM с полной атрибуцией.

После этого карточка любого лида показывает: канал, кампанию, ключевое слово, click ID для возврата конверсии в Я.Директ/Google Ads/Meta, timeline всех касаний с заголовками статей. AI-продавец автоматически использует эти данные в диалоге.

Если вы используете внешние формы (Tilda, Tally, GetCourse), мы поддерживаем интеграцию через REST API: ваш фронт собирает атрибуцию через JS-helper и отправляет в наш webhook. Эта схема описана в документации Botseller. Чтобы посчитать ROI и сравнить с текущим сервисом, воспользуйтесь калькулятором экономии.

Внедрение за 10 минут: архитектура сложная, интеграция элементарная. Шаг 1: pixel.js в head всех страниц (ставит sticky-cookies, ловит SPA-роутинг, фиксирует first-touch). Шаг 2: widget.js одной строкой на странице с формой (рендерит форму, читает cookies + UTM, лид рождается с полной ДНК аналитики)

FAQ

Что такое путь клиента простыми словами?

Путь клиента (customer journey) это все шаги человека от первого знакомства с брендом до покупки. Один и тот же человек может увидеть рекламу в Reels, перейти по ней на сайт, прочитать кейс, скачать гайд, подписаться на Telegram-канал, через две недели вернуться из поиска и оставить заявку. Все эти события вместе формируют путь клиента. Сквозная аналитика собирает их в один отчёт, чтобы маркетолог понимал, какая комбинация каналов реально приводит к продажам.

Чем сквозная аналитика отличается от Google Analytics или Я.Метрики?

Google Analytics и Я.Метрика показывают что юзер делал на сайте: страницы, время, конверсии. Они не знают, какой контракт этот юзер закрыл через две недели. CRM знает про сделку, но не помнит, по какой рекламе человек пришёл изначально. Сквозная аналитика связывает оба источника: реклама → сайт → заявка → сделка → выручка. Botseller встраивает эту связку прямо в CRM, без необходимости поднимать отдельный сервис.

Что такое UTM-метки и зачем они в CRM?

UTM-метки это параметры в URL после знака «?»: utm_source=yandex, utm_medium=cpc, utm_campaign=spring. Маркетолог добавляет их в ссылки рекламных кампаний, чтобы система аналитики знала, откуда пришёл клик. Когда человек попадает на сайт и заполняет форму, Botseller автоматически читает UTM из URL и сохраняет в карточке лида. Маркетолог потом видит, какая кампания и какое объявление привело конкретного человека.

Можно ли увидеть, из какой статьи блога пришёл клиент?

Да. После установки pixel.js Botseller отслеживает каждый просмотр страницы (включая внутренние переходы в SPA-сайтах). В карточке лида во вкладке «Маршрут» отображается полная хронология с заголовками страниц: «Кейс салона красоты → Сравнение с Salebot → Тарифы → Заявка с сайта». Это даёт менеджеру готовый сценарий первого звонка с тёплыми крючками.

Безопасно ли хранить такие данные с точки зрения 152-ФЗ?

Cookies и UTM сами по себе не являются персональными данными в строгом смысле 152-ФЗ. Это псевдо-анонимные идентификаторы. Но IP-адрес и user-agent вместе с другими данными могут считаться ПДн в трактовке Роскомнадзора. Поэтому: на форме заявки должен быть чекбокс согласия с политикой обработки персональных данных, политика должна упоминать использование cookies и систем аналитики. Это стандартная практика, и Botseller помогает её реализовать через готовую форму с согласием.

Что если клиент заходит с разных устройств: с телефона и с компьютера?

До идентификации (пока человек не оставил email/phone) Botseller считает разные устройства разными посетителями: у каждого свой _bs_anon_id. Это ограничение всех cookie-based трекеров. После заявки мы идентифицируем человека по контактным данным и связываем все его прошлые анонимные сессии с этого момента. Cross-device обогащение работает на будущее: следующая сессия с того же браузера будет связана с уже известным лидом.

Можно ли подключить Roistat дополнительно к Botseller?

Да. Мы отдаём webhooks при создании лида и смене статуса, поэтому Roistat (или любой другой сервис) может принимать эти события и обогащать ими свой отчёт. На практике это нужно крупным B2B с множеством офлайн-воронок: звонки в колл-центре + встречи + ивенты. Для МСБ и e-commerce достаточно встроенной аналитики Botseller.


Сквозная аналитика без отдельного сервиса это не маркетинговая обещалка, а конкретная архитектура: два слоя данных, sticky-cookies на 90 дней, патч SPA-роутинга, AI-промпт с контекстом всего пути. Каждая деталь решает свою проблему, и вместе они дают то, что не делает ни один внешний трекер: AI-продавец в моменте использует данные пути клиента, чтобы вести персонализированный диалог.

Сквозная аналитика Botseller заканчивается не отчётом для маркетолога. Она заканчивается продажей в диалоге с ИИ. Запустить Botseller за 10 минут или открыть калькулятор окупаемости ROI

Запустите Botseller за 10 минут и получите сквозную аналитику в карточке каждого лида, без подключения Roistat и Calltouch. Если хотите сравнить с альтернативами, посмотрите сравнение Botseller с Salebot или почитайте про архитектуру AI-бота под капотом.