Что добавляет AI-слой к классическому трекингу
Трекер из основной методики даёт структурированную таблицу: обращение, источник, ClientID, UTM. Этого достаточно для подсчёта конверсий по каналам, но не для понимания причин различий. AI-анализ работает поверх этой таблицы и закрывает три разрыва.
| Разрыв | Классический трекинг | AI-слой поверх |
|---|---|---|
| Качество обращения | Все email равны — считается только факт | Классифицирует обращение по тексту и пути: целевое / спам / нецелевое / прогрев |
| Поведение до контакта | UTM последнего визита | Анализ всей цепочки визитов из Logs API: какие страницы, сколько касаний, какой паттерн |
| Объяснение различий каналов | «Канал A конвертит 12%, B — 4%» | Гипотезы о причинах разницы на основе паттернов поведения и текста обращений |
Методологическая граница. AI генерирует гипотезы и классификации, а не истину. Любой вывод модели о причинах различий между каналами — это предположение для проверки экспериментом или ручной валидацией, а не основание сразу перекраивать бюджет. Это прямое следствие ограничения «атрибуция ≠ причинность» из основной методики Майкор-аудита.
Архитектура: данные → хранилище → Claude Code → отчёт
Архитектура состоит из четырёх этапов и переиспользует то, что у меня уже развёрнуто на проекте: трёхслойную модель данных и PostgreSQL-парсер. AI-слой не вводит новой инфраструктуры — это скрипты и агенты Claude Code, работающие поверх существующего хранилища.
- Сбор. Событийный трекер пишет обращения, Logs API Метрики отдаёт визиты по ClientID.
- Хранилище. PostgreSQL: таблица обращений плюс сырые визиты, связанные по ClientID.
- AI-анализ. Claude Code читает выборку из базы, классифицирует и ищет паттерны.
- Отчёт. Структурированный вывод: сегменты, гипотезы, рекомендации с пометкой достоверности.
Принцип, на котором держится вся методика: сырые данные собираются детерминированным кодом, а AI применяется только там, где нужна интерпретация неструктурированного — тексты писем, паттерны путей. Считать конверсии и суммы AI не должен, это работа SQL.
Источники данных Яндекс.Метрики
Для AI-анализа нужны два потока из Метрики, оба привязываются к обращению через ClientID.
| Источник | Что даёт | Как использую в AI-анализе |
|---|---|---|
| Logs API (визиты) | Полная цепочка визитов по ClientID: страницы, длительность, источники, устройство | Реконструкция пути пользователя до письма — вход для анализа паттернов |
| Reporting API | Агрегаты по всем целям и источникам | Объёмы обращений по типам (email, звонок, форма) для кросс-канального разреза и контекст для интерпретации |
| Цели (reachGoal) | Факт email-обращения, привязанный к визиту | Якорь, к которому подтягиваются визиты до и после |
| Офлайн-конверсии | Связь обращения со сделкой и суммой | Метка качества: целевым считаю обращение, ставшее сделкой |
Logs API отдаёт данные с задержкой и за ограниченный период — выгрузку делаю регулярно и складываю в PostgreSQL. AI работает уже с накопленным хранилищем, а не дёргает API на каждый запрос.
Задачи, которые решает AI-анализ
4.1. Кросс-канальный анализ: email на фоне других обращений
Прежде чем разбирать email по источникам трафика, отвечаю на верхнеуровневый вопрос: значим ли email-канал на фоне звонков, форм и мессенджеров вообще. Это два разных вопроса. Первый — «стоит ли заниматься email-каналом» (сравнение типов обращений между собой). Второй — «какой источник приносит email» (атрибуция внутри канала). Сначала первый, потом второй — иначе можно оптимизировать источники для канала, который сам по себе маргинален.
AI-слой здесь даёт то, чего голый учёт не умеет: размечает обращения всех типов по единым категориям качества и сравнивает каналы коммуникации на равных. Не «звонков 200, писем 80», а «целевых звонков 60%, целевых писем 30%». Картина значимости канала после такой разметки меняется.
От этого зависит, что считает код, а что — человек. Кросс-канальный анализ корректен, только когда обращения разных типов сведены в одно хранилище и размечены одинаково. На практике встречаются три ситуации.
| Где лежат данные по типам | Как делаю кросс-канальный разрез |
|---|---|
| Все типы в одной CRM или базе | Идеальный случай. SQL сводит обращения всех типов в одну таблицу, AI классифицирует по единым категориям, сравнение каналов полностью детерминировано по объёмам. |
| Email и формы — свои, звонки — внешний коллтрекинг | Звонки выгружаю из коллтрекинга в то же PostgreSQL по расписанию, привожу к общей схеме. Если выгрузки нет — беру долю звонков как агрегат из коллтрекинга и передаю AI как факт, тексты звонков в классификацию не идут. |
| Каждый тип в своём сервисе, общего хранилища нет | Самый частый случай (см. 4.1.1). Кросс-канальный разрез по объёмам делаю вручную, AI применяю только внутри тех типов, что доступны как тексты. Не выдаю сравнение каналов за точное, если источники несопоставимы. |
Принцип тот же, что и во всей методике: объёмы и доли — из данных (SQL или ручная сводка проверяемых цифр), а AI приводит обращения к единым категориям качества. Если какой-то тип обращений недоступен как структурированные данные, AI не достраивает его по догадке — это помечается как пробел в данных.
4.1.1. Когда каждый тип обращений в своём сервисе: рабочий процесс
Самая частая реальность: письма в почте, формы у своего трекера, звонки в коллтрекинге, мессенджеры в виджете или CRM. Единого хранилища нет. Возникают две независимые проблемы: объёмы по типам несопоставимы (разные системы по-разному считают «обращение», период и дедупликацию) и тексты для классификации разрознены. Основной подход для этой ситуации — ручная сводка объёмов плюс AI-классификация по доступным текстам. Он не требует интеграций и даёт ответ на главный вопрос «значим ли email» уже в первом периоде.
- Сводка объёмов. Раз в период выписать число обращений по каждому типу из его системы за один и тот же период в одну таблицу: email, звонок, форма, мессенджер. Свести к общему пониманию «обращения» (исключить пропущенные звонки и спам, если их не считаем лидами).
- Доля канала. Посчитать share_email = email / сумма всех типов. Это живая проверка значимости по данным, а не по прикидке. Применить пороги: <3% маргинальный, 3–10% заметный, >10% значимый.
- AI по доступным текстам. Выгрузить тексты тех типов, что реально доступны (обычно email и формы), и прогнать через классификатор по единым категориям качества. Сравнить долю целевых там, где тексты есть.
- Честная пометка пробелов. Типы без текстов (например, звонки без расшифровок) участвуют в сравнении только по объёму, но не по качеству. Это прямо помечается в отчёте — сравнение каналов по качеству неполное.
Ограничения, которые держу в голове. Ручная сводка трудозатратна и не автоматизируется — это плата за отсутствие интеграций. Объёмы из разных систем сопоставимы лишь приблизительно: дедупликацию «один человек написал и позвонил» приходится делать глазами, а определение «обращения» в каждой системе своё. Поэтому выводы минимальной стратегии — это ориентир для решения «заниматься ли email вообще», а не точная атрибуция.
Куда расти потом. Если ручная сводка становится регулярной рутиной, следующий шаг — свести типы обращений в единую нормализованную таблицу в PostgreSQL (поля: время, канал, ClientID, ключ дедупликации, текст, статус сделки), куда каждый сервис выгружается по расписанию. Тогда и объёмы, и качество считаются детерминированно по всем каналам. Это целевое состояние, к которому ведёт трёхслойная архитектура Майкор-аудита, но переход оправдан только когда объёмы и частота анализа окупают интеграцию с каждым сервисом.
4.2. Классификация качества обращений
Модель размечает входящие письма по категориям: целевой запрос, запрос КП, спам или реклама, нецелевое обращение, информационный вопрос. Те же категории применяются и к другим типам обращений (расшифровки звонков, тексты форм и сообщений), что и делает возможным кросс-канальное сравнение из 4.1. Это снимает главную слабость голого трекинга — он считает все обращения одинаковыми. После классификации конверсия по каналам и источникам пересчитывается уже по целевым обращениям, и картина меняется.
4.3. Анализ поведенческих паттернов до обращения
На вход подаются цепочки визитов из Logs API для обращений, ставших сделками, и для пустых. Модель ищет различия: число касаний, типы просмотренных страниц, временной паттерн. Результат — гипотезы вида «целевые письма приходят после просмотра страницы с ценами и повторного визита», которые затем проверяются на данных.
4.4. Сегментация источников с объяснением
Вместо сухой таблицы «источник — конверсия» AI группирует источники и предлагает интерпретацию различий. Выполняется после кросс-канального разреза (4.1) и только для каналов, прошедших порог значимости. Интерпретация маркируется как гипотеза и сопровождается указанием, на каком объёме данных она построена.
4.5. Черновики ответов с учётом контекста
Зная путь пользователя (что смотрел, какой источник), модель готовит черновик ответа менеджеру: на какие страницы человек заходил, что вероятно его интересует. Это ускоряет обработку, но отправляет ответ всегда человек — AI только готовит черновик.
Конвейер на Claude Code: настройка и память
Сборка повторяет подход к структурированной памяти проектов: основной контекст, накопленные выводы и журнал инцидентов лежат в отдельных файлах внутри проекта. Ниже — структура под задачу анализа обращений.
В контекст проекта обязательно кладу:
- Схему таблиц PostgreSQL (поля обращений, визитов, связь по ClientID)
- Жёсткое правило: все числа берутся из результата SQL, не вычисляются моделью
- Категории классификации обращений (фиксированный список, чтобы разметка была сопоставимой между запусками)
- Порог достаточности данных: ниже скольких обращений выводы помечаются как ненадёжные
- Требование маркировать каждый вывод о причинах как гипотезу
Этапы одного запуска анализа:
- Выгрузка. Скрипт регулярно тянет визиты из Logs API в PostgreSQL.
- Подготовка выборки. SQL отбирает обращения за период и подтягивает к ним цепочки визитов. AI получает уже готовую структуру, а не сырой API.
- Анализ. Claude Code классифицирует обращения, сопоставляет паттерны целевых и пустых, формулирует гипотезы.
- Отчёт. Структурированный вывод плюс обновление накопленных наблюдений по каналам.
Промпты агентов и контроль галлюцинаций
Анализ разбивается на узкие роли — это снижает риск, что модель «придумает» закономерность. По аналогии с пайплайном Researcher → Writer → Reviewer здесь работают три роли.
| Агент | Вход | Задача | Запрет |
|---|---|---|---|
| Классификатор | Тексты обращений | Разметить по фиксированным категориям | Не считать статистику |
| Аналитик путей | Цепочки визитов плюс метки качества | Найти различия в паттернах, дать гипотезы | Не утверждать причинность; помечать как гипотезу |
| Ревьюер | Выводы аналитика плюс агрегаты из SQL | Проверить, что каждый вывод опирается на данные и достаточный объём | Вычёркивать необоснованные утверждения |
Защита от галлюцинаций цифр. Главный риск AI-аналитики — модель «округляет» или придумывает числа. Решение архитектурное: все агрегаты вычисляет SQL, а агенту они передаются как факты во входных данных. Ревьюер сверяет любое число в отчёте с переданными агрегатами и вычёркивает то, чего нет в источнике. Это тот же принцип верификатора, что в пайплайне Майкор-аудита.
В промпте каждого агента жёстко закреплено четыре правила: любой вывод о причине — это гипотеза с явной пометкой; числа, которых нет во входных данных, использовать запрещено; при малой выборке (меньше 30 наблюдений) к выводу добавляется пометка «низкая достоверность: N=…»; предлагать менять бюджет агенту запрещено — он предлагает только то, что стоит проверить.
Стоимость, окупаемость и границы применимости
AI-слой добавляет к стоимости владения две статьи: разовую разработку конвейера и переменную стоимость токенов на анализ. Поскольку анализ запускается периодически (раз в неделю или месяц), а не на каждое обращение, расход на модель невелик и масштабируется с объёмом.
| Статья | Характер | Замечание |
|---|---|---|
| Разработка конвейера | Разовая (CAPEX) | Поверх существующего PostgreSQL и парсера — дешевле, чем с нуля |
| Токены на анализ | Переменная | Зависит от объёма обращений; пакетная обработка раз в период, не на каждое письмо |
| Поддержка промптов | Периодическая | Пересмотр категорий и правил при изменении ниши |
Когда AI-слой не оправдан. Если базовый email-трекинг не прошёл пороги основной методики (мало обращений, доля <3%) — AI-слой тем более не нужен: интерпретировать нечего, а на малых N выводы недостоверны. AI-анализ имеет смысл только когда поток обращений достаточен для классификации и сравнения сегментов, то есть начиная с десятков целевых обращений в период.
Где AI-слой даёт наибольшую отдачу. B2B с дорогими сделками и неоднородными обращениями: там разметка качества и анализ путей экономят время менеджеров и уточняют, какие каналы дают целевые, а не любые письма. Чем выше чек и разнороднее поток — тем выше отдача интерпретации поверх голых цифр.
Документ дополняет основной подход к оценке целесообразности email-трекинга. AI применяется только для интерпретации неструктурированных данных; все количественные показатели вычисляются детерминированным кодом и верифицируются перед включением в отчёт. Архитектура переиспользует существующий стек: Logs API Яндекс.Метрики, PostgreSQL, Claude Code со структурированной памятью проектов.
Если хотите проверить, готов ли ваш стек к AI-анализу обращений, запишитесь на аудит — я начинаю с проверки целостности данных и показываю, что нужно закрыть в первую очередь.
