Атрибуция покупок внутри ИИ-диалогов: как метить «ассистентные» события и связать всё с CRM за 30 дней

Диалоги с нейросетями уже приводят к покупкам, и это перестаёт быть экзотикой. Вижу, как рынок пытается договориться, кому засчитывать такие конверсии, и сколько денег они на самом деле приносят. Если продолжать считать по старым правилам, бюджет поползёт в сторону самого громкого канала, а не того, кто реально влияет на выбор.

Предлагаю прагматичный план на 30 дней: метим «ассистентные» события, перестраиваем правила засчёта, синхронизируемся с агентствами по KPI и аккуратно связываем всё с CRM (система управления взаимоотношениями с клиентами — ваш «реестр» клиентов и заказов). Без избыточной теории, фокус на бизнес-результате: меньше споров, меньше двойного учёта, прозрачная воронка.

Что именно меняется в воронке

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

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

Если ассистент повлиял на выбор — это канал, и канал должен иметь свой след в данных.

Метим «ассистентные» события: что писать и куда

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

Термины сразу поясню. API — программный способ системам обмениваться данными без человека. Вебхук — автоматическое уведомление от одной системы в другую, когда что-то произошло. UTM-метки — параметры в ссылке, которые помогают понять источник и кампанию. Эта троица и соберёт мост между ассистентом и вашим заказом.

Минимальный состав «ассистентного» события, который на практике даёт управляемость. Перечислю поля, которые стоит фиксировать в первую очередь:

• conversation_id — уникальный ID диалога, чтобы связать все шаги разговора.
• recommendation_id — ID конкретной рекомендации ассистента, если он предложил товар или набор.
• assistant_origin — где шёл диалог: сайт, приложение, мессенджер, виджет.
• intent — тема запроса пользователя простыми словами: «выбрать ноутбук до 80к», «сравнить тарифы».
• timestamp — время, чтобы считать окна атрибуции.
• linkout_url — ссылка, по которой ассистент отправил пользователя оформлять, с UTM-метками и параметрами recommendation_id и conversation_id.

Сами события делаю гранулярными, чтобы видеть путь: assistant_view (пользователь открыл ассистента), assistant_recommendation (ассистент предложил товар), assistant_clickout (переход к оформлению из ассистента), assistant_add_to_cart (если поддерживается), assistant_purchase_confirmed (подтверждение оплаты из бэкенда). Это не догма, это практичный набор сигналов для бизнеса.

Куда всё писать. Первый слой — аналитика сайта/приложения, куда прилетит clickout через UTM-метки. Второй слой — ваш сервер заказа добавляет conversation_id и recommendation_id в объект заказа и отправляет эти поля в CRM и систему визуализации отчётов. Третий слой — вебхук из ассистента при показе рекомендаций, чтобы понимать долю influence даже без клика.

Правила засчёта: основной кредит оформлению, ассистент — influence

Сейчас важно установить справедливые и простые правила, чтобы команда не утонула в спорах. Я использую модель, где основной кредит получает место оформления, а ассистент фиксируется как влияние (influence) с отдельной метрикой ценности. Это сохраняет сопоставимость исторических данных и не ломает ваши отчёты по перформансу.

Базовые правила, которые можно ввести уже в этом месяце без капитального ремонта BI. Первое: заказ засчитывается один раз — по уникальному order_id, дедупликация жёсткая. Второе: если у заказа заполнен recommendation_id и разница во времени между assistant_recommendation и покупкой не превышает выбранного окна, вы добавляете флаг assisted_purchase = true и записываете источник influence = assistant_origin. Третье: окно атрибуции для influence выберите консервативным — 7 дней на старте достаточно для большинства категорий, потом откалибруете по данным.

Дальше появляются осмысленные отчёты: доля заказов с influence от ассистента, выручка по assisted-покупкам, средний чек таких заказов, сравнение конверсий по разным intent. Эти метрики не смешиваются с last-click перформансом, и конфликты бюджета снижаются. В CRM это видно как таймлайн клиента: диалог → рекомендация → переход → заказ, и это помогает продавцам и маркетологам говорить на одном языке.

Договоры и KPI с агентствами: платим за влияние, а не за шум

Когда появляются «ассистентные» продажи, старые KPI перестают отражать вклад каналов. Я предлагаю обновить рамку договора с агентством и внутренние цели так, чтобы вы платили за измеримое влияние, а не за красивую историю.

Что добавить в KPI. Во-первых, Assisted Purchases — число и доля заказов с флагом assisted_purchase. Во-вторых, Assisted Revenue — выручка по этим заказам. В-третьих, CPAa (cost per assisted purchase) — цена влияния, считается как расходы на ассистента/канал делить на число assisted-покупок. Для качества — Acceptance Rate: доля рекомендаций, по которым был клик или добавление в корзину, а также Conversion by Intent: конверсия в заказ по основным сценариям запросов.

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

План на 30 дней: быстро, прозрачно, в продакшн

Неделя 1. Определяем события и схему данных: какие поля нужны, как называем intent, где хранится conversation_id и recommendation_id. Юристы одновременно обновляют политику приватности под новые поля и информирование пользователя. Команда рисует простую схему воронки: от ассистента к заказу и CRM.

Неделя 2. Настраиваем метки и потоки. Добавляем UTM-метки и дополнительные параметры в ссылки ассистента. Включаем вебхук ассистента на события recommendation и clickout. Обновляем бэкенд оформления, чтобы он принимал и сохранял conversation_id и recommendation_id, и отправлял их в CRM и отчёты.

Неделя 3. Вводим правила атрибуции и отчёты. В аналитике добавляем флаг assisted_purchase по окну 7 дней. Строим базовые дашборды: Assisted Purchases, Assisted Revenue, Acceptance Rate, Conversion by Intent. Настраиваем дедупликацию по order_id и приоритеты источников.

Неделя 4. Синхронизируем KPI и обучаем команду. Обновляем договоры и мотивацию агентства с учётом influence-метрик и защитных механизмов. Проводим сессию для маркетинга и продаж: как читать assisted-отчёты, какие сценарии усиливать, что тестировать дальше. Запускаем A/B-тест по окнам атрибуции и формулировкам советов ассистента.

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

Если нужна быстрая ревизия вашей воронки и настройка такого контура под вашу инфраструктуру, напишите в gerasimova.tut. Я помогу собрать минимальный, но рабочий стек измерения и проведу вашу команду через первые четыре недели.