Маркетинговая аналитика с ИИ

Зачем нужна карта данных

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

Карта данных решает три задачи. Первая — поиск пробелов: ясно, какие данные нужны, но не собираются. Вторая — устранение дубликатов: видно, что одна и та же информация учитывается в двух системах по-разному, и нужно выбрать одну. Третья — понимание ограничений: каждый источник имеет свои искажения, и без их учёта выводы будут неверны. Глава 6 подробно разбирает качество данных; здесь — инвентаризация источников.

Сайт и посадочные страницы

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

Ограничения сайта как источника: он видит только онлайн-поведение, не видит офлайн-продажи, не знает, кто именно посетитель (если не авторизован), теряет данные при блокировке счётчиков (что в России не редкость). Сайт также даёт данные с задержкой: счётчик фиксирует визит мгновенно, но события конверсии — только после завершения сессии. Сайт не различает пользователя, зашедшего с рекламного клика, и пользователя, который пришел напрямую, если UTM-метка не передана.

Посадочные страницы

Посадочные (landing pages) — особый тип страниц, оптимизированных под конкретную рекламную кампанию. У них обычно одна цель — получить лид. Аналитика посадочных страниц отличается от аналитики основного сайта: меньше метрик, выше требования к точности, быстрее цикл эксперимента. Каждая посадочная страница должна иметь свою цель (получить заявку, скачать PDF, зарегистрироваться) и отслеживать только эту цель. Смешивание целей посадочной страницы с общими целями сайта — частая ошибка, приводящая к неверно посчитанной конверсии.

Рекламные кабинеты

Яндекс Директ, VK Реклама, рекламные кабинеты Telegram, маркетплейсы и другие — каждый кабинет даёт данные о показах, кликах, расходах, иногда — о конверсиях. Эти данные — первичный источник информации о маркетинговых расходах. Без них невозможно посчитать CPM, CPC, CTR, CPL по каналам. Кабинет — это «бухгалтерия» рекламной кампании, и его данные должны совпадать с тем, что попадает в CRM (через UTM-разметку).

Ограничения рекламных кабинетов. Первый — атрибуция: кабинет считает продажу «своей», если в течение периода атрибуции был клик по рекламе. Это не означает, что реклама вызвала продажу (см. главу 15). Второй — задержка: данные о конверсиях появляются через несколько часов или дней после события. Третий — несовместимость методик: разные кабинеты считают по-разному (last-click, multi-touch, view-through), и прямое сравнение метрик между кабинетами часто некорректно. Четвёртый — изменения в алгоритмах: сегодня и завтра одна и та же кампания может показывать разные цифры из-за пересчёта атрибуции.

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

CRM — система управления клиентами

CRM фиксирует лиды, сделки, контакты, историю взаимодействия. Это основной источник данных о продажах. В российском МСБ чаще всего встречаются amoCRM, Битрикс24, retailCRM (в e-commerce). CRM отвечает на вопросы: сколько лидов, сколько сделок, какой статус, кто менеджер, сколько времени от первого контакта до закрытия, какие причины отказа. Без CRM аналитика маркетинга остаётся на уровне «лидов и кликов», без связи с деньгами.

Ограничения CRM. Главное — CRM содержит только то, что в неё вводят. Если менеджер не разметил источник лида, аналитика не сможет связать сделку с рекламным каналом. Если не зафиксировал причину отказа, нельзя анализировать причины потерь. CRM требует дисциплины: любой не введённый manually поле — это потерянная информация. Поэтому первый шаг в любой аналитике — проверка полноты заполнения CRM. Если по 30% сделок не указан источник, аналитика маркетинга будет ошибаться на 30%.

Системы продаж и финансовый учёт

В e-commerce это система заказов (встроенная в CMS, отдельная, или часть платформы вроде 1С). В B2B-услугах — бухгалтерская система (1С, Контур, СБИС). Эти системы знают то, чего не знает CRM: себестоимость, маржу, скидки, возвраты, повторные покупки, отгрузки, акты. Без этих данных невозможно посчитать юнит-экономику, ROMI, LTV. Связь CRM с финансовой системой — ключ к переходу от «лидов и сделок» к «прибыли и возврату инвестиций».

В российском МСБ эта связь часто отсутствует или сделана поверхностно. CRM знает, что сделка на 100 000 рублей закрыта. Финансовая система знает, что 100 000 рублей пришли. Но связи «сделка №123 в CRM = платёж №456 в 1С» нет. В итоге нельзя посчитать: какие из закрытых сделок реально оплачены, какие — нет, сколько из оплаченных — с возвратом, сколько — со скидкой. Без этого нельзя посчитать реальную маржу по каналам. Глава 5 подробно разбирает, как эту связь строить.

Веб-аналитика: что мы знаем о посетителях

Яндекс Метрика (в России — основной инструмент), Google Analytics (доступ ограничен), системы аналитики сайтов (для e-commerce — Вебвизор, для событий — Mixpanel-like системы). Веб-аналитика даёт данные о поведении на сайте: источник трафика, страницы, события, длительность сессии, глубина просмотра, путь пользователя. Эти данные — основа для анализа воронки от клика до конверсии.

Ограничения веб-аналитики. Главное — блокировка счётчиков. Часть пользователей используют блокировщики рекламы, часть — браузерные расширения, блокирующие трекинг. В России доля таких пользователей в B2B может доходить до 30–40%. Это означает, что веб-аналитика систематически недоучитывает определённые сегменты. Также веб-аналитика не видит офлайн-каналов: телефонные звонки, мессенджеры, обращения в офис. Их нужно учитывать отдельно, через коллтрекинг и интеграции с мессенджерами.

Коллтрекинг и телефония

Коллтрекинг — система подмены номеров телефонов на сайте для отслеживания источников звонков. Динамический коллтрекинг даёт каждому посетителю свой номер (или пул номеров), и связывает звонок с источником визита. Статический коллтрекинг — закрепляет разные номера за разными каналами (один номер в Директе, другой в VK). Коллтрекинг необходим, если по телефону приходит значительная часть лидов — без него невозможно связать звонок с рекламным каналом.

У «ПрофКонсалт» 38% лидов — звонки. Без коллтрекинга собственник не знал, какие из них пришли из рекламы, а какие — из органики. Внедрение статического коллтрекинга с тремя номерами (для Директа, VK, органики) дало разметку 80% звонков. Остальные 20% — звонки напрямую с визиток и рекомендаций — не имеют источника в коллтрекинге, но их можно отнести к «органике» как дефолт. Без коллтрекинга эти 38% лидов были бы «неизвестным каналом», и аналитика каналов была бы неточной на 38%.

Формы, чаты и мессенджеры

Формы на сайте (заявки, обратная связь) — основной источник лидов для многих ниш. Чаты на сайте (JivoSite, Tawk.to, другие) — для оперативных вопросов и квалификации. Мессенджеры (Telegram, WhatsApp) — отдельный канал, особенно в B2C. У каждого из этих источников своя специфика учёта: форма передаёт данные в CRM через интеграцию, чат — через оператора, мессенджер — часто требует ручного ввода лида в CRM.

Главное правило для этих источников — единая точка учёта. Лид из формы, лид из чата и лид из мессенджера должны попадать в CRM по одному формату, с разметкой источника. Если мессенджер не интегрирован с CRM и лиды из него вводятся вручную с опозданием в 2–3 дня, аналитика будет систематически ошибаться: сделки из мессенджеров будут выглядеть «длиннее» по циклу, чем они есть на самом деле. Внедрение единой точки учёта — типичная задача для первой недели построения Marketing Intelligence System (глава 18).

Данные электронной коммерции

В e-commerce это данные о заказах: позиции, цены, количества, скидки, способ доставки, способ оплаты, статус заказа, возвраты. Эти данные обычно хранятся в CMS (Битрикс, OpenCart, Magento-подобные), в системах управления продажами (retailCRM) или в 1С. Без этих данных невозможно посчитать средний чек, маржу, LTV, долю повторных покупок. Это самый «жирный» источник данных с точки зрения аналитики юнит-экономики.

Ограничения. Главное — согласованность с финансовой системой. Заказ в CMS может быть «оплачен», но платёж в 1С не проведён. Или заказ может быть отменён, но не удалён из выгрузки. Нужна регулярная сверка: заказы в CMS → платежи в 1С → выручка в отчёте о финансовых результатах. Если эти три источника не сходятся на 1–2%, аналитика юнит-экономики не точна.

Опросы и обратная связь

Опросы (NPS, CSAT, опросы после покупки, опросы отказавшихся) — источник качественных данных. Они говорят, почему клиент выбрал вас, почему ушёл, что не понравилось, что понравилось. Эти данные невозможно получить из «поведенческих» источников. Опросы дополняют картину, но не заменяют её: если только 5% клиентов отвечают на опрос, у вас данные о 5% — скорее всего, не представительны.

В российском МСБ опросы используются редко, и зря. Опрос «Почему вы выбрали нас?» на странице после покупки с одним открытым вопросом и тремя вариантами — даёт больше инсайтов, чем тонны данных веб-аналитики. Главное — короткий опрос (1–3 вопроса), по одной воронке (сразу после покупки или через неделю), без спама. ИИ может обрабатывать открытые ответы и группировать их по темам — это превращает 500 текстовых ответов в 8–10 категорий причин.

Данные о повторных покупках

Это данные о том, кто из клиентов сделал вторую, третью, последующие покупки. Они хранятся в CRM или системе заказов. Без них нельзя посчитать Retention, LTV, долю повторных покупок, частоту. Главный вопрос при работе с этими данными — горизонт наблюдения. Клиент, который не сделал повторную покупку за 3 месяца, не обязательно «ушёл» — у некоторых товаров цикл повторной покупки — год. Чтобы правильно считать Retention, нужно знать типичный цикл повторной покупки для вашей ниши.

У «Дома и Сад» цикл повторной покупки — 3–6 месяцев (текстиль, посуда). У «ПрофКонсалт» — год (бухгалтерское сопровождение). Сравнивать Retention за 3 месяца в этих двух бизнесах бессмысленно. Аналитик должен знать нормальный цикл для своей ниши и считать Retention за период, в 2–3 раза длиннее цикла. Глава 13 подробно разбирает когортный анализ; здесь — главное: данные о повторных покупках должны собираться достаточно долго, чтобы быть полезными.

Карта данных для сквозных кейсов

Таблица 4.1. Источники данных в кейсе «Дом и Сад»

Источник

Что знает

Чего не знает

Яндекс Метрика

Визиты, события, конверсии на сайте

Кто конкретно посетитель, офлайн-покупки

Яндекс Директ

Расходы, показы, клики, цели

Реальные сделки, возвраты, маржа

VK Реклама

Расходы, показы, клики

Сквозные конверсии без отдельной настройки

CMS (Битрикс)

Заказы, состав, статус, способ оплаты

Источник клиента, если UTM не передан

1С

Платежи, себестоимость, возвраты

Источник клиента, если нет связи с CMS

CRM (amoCRM)

Лиды, сделки, контакты, история

Финансы, если нет интеграции с 1С

Email-платформа

Рассылки, открытия, клики, отписки

Что произошло после клика

Аналогичная карта для «ПрофКонсалт» отличалась бы: вместо CMS — система заказов в CRM, вместо 1С — бухгалтерская платформа, добавляются LinkedIn-аналитика, Telegram-канал, вебинары. Принцип построения карты — тот же: перечислить все источники, указать, что каждый из них знает и не знает, отметить пробелы.

Краткие выводы

Ключевые тезисы главы 4

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

— Каждый источник имеет ограничения: сайт не видит офлайн, рекламный кабинет приписывает себе продажи, CRM зависит от ручного ввода, финансовая система — от качества связи с CRM.

— Данные о повторных покупках требуют горизонта наблюдения, в 2–3 раза длиннее типичного цикла сделки.

— Расхождение между источниками — норма, не ошибка. Главное — понимать методику каждого источника.

— Опросы и качественные данные дополняют количественную картину, но не заменяют её.

— Коллтрекинг обязателен, если звонки — значимый канал лидов.

Практическое задание

Составьте карту данных вашей компании по образцу таблицы 4.1. Для каждого источника укажите: название, что он знает, чего не знает, как часто обновляется, кто отвечает. Найдите три крупнейших пробела — данные, которые нужны, но не собираются. Для каждого пробела оцените, сколько времени и денег потребуется, чтобы его закрыть. Это и есть карта приоритетов для работы над инфраструктурой аналитики на ближайший месяц.

Глава 5. Как объединить данные в единую картину

Источники данных — разрозненные. Чтобы аналитика работала, их нужно связать в единую картину: понять, что клик по рекламе в Директе, визит на сайт, заявка в форме, сделка в CRM и платёж в 1С — это один и тот же пользователь на разных этапах. Эта задача называется «сквозная аналитика». В российском МСБ её часто пытаются решить «в лоб»: свести всё в Excel и угадывать связи вручную. Эта глава — про то, как строить сквозную аналитику правильно, какие бывают идентификаторы, как с ними работать и какие ошибки подстерегают.

Разрозненные источники: проблема фрагментации

Каждый источник данных — это своя «версия правды». Рекламный кабинет говорит, что было 1 200 кликов. Сайт говорит, что было 980 визитов с UTM-меткой этой кампании. CRM говорит, что было 240 лидов с этим источником. Финансовая система говорит, что 180 сделок с этим каналом оплачено. Все четыре цифры правильные — но они измеряют разные вещи. Клик ≠ визит (часть кликов теряется из-за редиректов, блокировок, медленных загрузок). Визит ≠ лид (часть посетителей не делают целевое действие). Лид ≠ оплаченная сделка (часть сделок отменяется или не оплачивается).

Фрагментация создаёт три проблемы. Первая — невозможно посчитать итоговую метрику (ROMI, CAC, LTV) без «пробросов» между системами. Вторая — разные источники по-разному определяют одно и то же событие (что считается «лидом»?), и без общего словаря нельзя их сравнивать. Третья — аналитик тратит часы на ручную работу, которую можно автоматизировать. Решение всех трёх — единая модель данных и единые идентификаторы.

Идентификаторы пользователей и клиентов

Идентификатор — это уникальный код, по которому можно связать события в разных системах. Для пользователя сайта это clientId (или _ym_uid в Метрике) — случайная строка, присваиваемая счётчиком и хранящаяся в cookie. Для клиента в CRM — внутренний id контакта или сделки. Для плательщика в 1С — id контрагента. Если эти три id не связаны, нельзя понять, что визит X на сайте = клиент Y в CRM = платёж Z в 1С. Связывание — это либо ручная работа (заполнять вручную «внешние id» в CRM), либо автоматическая через общий идентификатор.

Общий идентификатор в российских реалиях — чаще всего email или телефон. Когда клиент оставляет заявку, он указывает email и телефон. CRM создаёт контакт с этими данными. При оплате 1С получает от CRM эти же поля. По ним можно связать. Это не идеальный идентификатор: один человек может использовать разные email, разные телефоны, у разных людей может быть общий рабочий номер. Но в МСБ это обычно достаточный уровень точности. Более точный — единый ID пользователя через личный кабинет, но это требует разработки.

UTM-метки: язык связи рекламы и сайта

UTM-метка — это параметры в URL рекламной ссылки, которые передают счётчику и CRM информацию об источнике. Стандартные параметры: utm_source (рекламная система: yandex, vk, telegram), utm_medium (тип трафика: cpc, cpa, social, email), utm_campaign (название кампании), utm_term (ключевое слово, для контекста), utm_content (объявление или баннер). UTM-метки — основной язык связи между рекламным кабинетом и сайтом/CRM. Без них невозможно сказать, из какой кампании пришёл клиент.

Правила работы с UTM. Первое — единый шаблон. Все кампании должны размечаться по одному стандарту: utm_source=yandex, не «Яндекс», «Я», «yndx» и «yandex» одновременно. Второе — обязательность. Если кампания запущена без UTM, она будет в отчётах как «неизвестный источник» — и аналитика каналов будет неточной. Третье — передача в CRM. UTM-метки, попадающие на сайт, должны передаваться в форму заявки и далее в CRM. Без этого связь обрывается на этапе лида. Четвёртое — защита от перезаписи. Если один и тот же пользователь сначала пришёл из Директа, а потом из VK, в CRM должно остаться несколько значений UTM (multi-touch), или выбрано одно по правилу атрибуции (last-click, first-click).

Типовая ошибка в «Дом и Сад»: у 30% заявок UTM-метки отсутствовали, потому что форма не передавала их в CRM. После исправления формы и добавления скрытых полей UTM связь восстановилась. Но «история» до исправления осталась потерянной — у этих заявок невозможно восстановить источник. Это типично: ретроспективно восстановить разметку нельзя. Поэтому внедрять UTM нужно до начала сбора данных, не после.

Дедупликация: один клиент — одна запись

Дедупликация — процесс устранения повторяющихся записей. Один и тот же человек может быть в CRM как «Иван Иванов» с email ivan@example.com и телефон +7 999 111-22-33, и как «И. Иванов» с тем же телефоном, но другим email. Без дедупликации аналитика посчитает его как двух клиентов, и метрики CAC, LTV, Retention будут неточны. Дедупликация в МСБ обычно делается по двум правилам: одинаковый нормализованный телефон или одинаковый нормализованный email — это один клиент.

Нормализация — обязательна. Телефон должен быть в едином формате (например, +7XXX XXX-XX-XX без пробелов, скобок, дефисов). Email — в нижнем регистре, без пробелов. Имя — в едином формате (или не используется как ключ, потому что «Иван Иванов» = «Иван И.» = «И.И. Иванов» — формально разные строки). Без нормализации дедупликация не работает: счётчик считает «+7 (999) 111-22-33» и «+79991112233» как два разных телефона. В CRM с хорошей дедупликацией (amoCRM, Битрикс24) это часто встроено, но в 1С и в самописных формах — нет.

Единые справочники

Справочник — это список допустимых значений для поля. Например, справочник каналов: «yandex», «vk», «telegram», «email», «organic», «referral». Справочник статусов сделки: «new», «in_progress», «won», «lost». Справочник причин отказа: «price», «competitor», «timing», «no_decision». Если в разных записях CRM используются разные значения для одного и того же («Яндекс» и «yandex» в поле «канал»), аналитика не сможет их объединить. Единый справочник — обязательная предпосылка для любых отчётов по каналам, причинам, менеджерам.

Внедрение единого справочника — это не техническая, а дисциплинарная задача. Маркетологу нужно составить список допустимых значений, зафиксировать в инструкции для менеджеров, настроить в CRM выбор из списка (а не свободный ввод), проверять раз в месяц. Если менеджеры свободно вводят причины отказа, через год в CRM будет 200 разных причин, и любая аналитика превратится в ручную работу по группировке. Лучше 10 стандартизованных причин, чем 200 произвольных.

Связь рекламного контакта с лидом и продажей

Это и есть сквозная аналитика в её простейшем виде. Цепочка: показ → клик по рекламе (с UTM) → визит на сайт (с UTM в cookie) → заполнение формы (UTM передаётся в форму) → лид в CRM (UTM сохранён в полях) → сделка (UTM наследуется от лида) → платёж в 1С (сделка связана с платёжным документом). Каждый шаг имеет свой идентификатор, и каждый шаг должен передавать идентификатор следующему. Если хотя бы один шаг теряет идентификатор, цепь обрывается, и аналитика не может связать начало и конец.

Где обычно обрывается цепь. Самое частое — на шаге «форма → CRM». Форма на сайте принимает данные пользователя, но скрытые поля UTM не передаются в интеграцию. Второе по частоте — на шаге «сделка → платёж». Сделка закрыта, но платёж в 1С не связан с идентификатором сделки. Третье — на шаге «клик → визит»: пользователь кликает по рекламе, но сайт не получает UTM (из-за редиректа, блокировки, кэширования). Построение сквозной аналитики — это последовательное закрытие этих обрывов, начиная с самого важного.

Интеграции с CRM: как не превратить в хаос

Интеграций должно быть мало, и они должны быть надёжными. Типовая ошибка — подключить к CRM десяток интеграций (с Метрикой, с Директом, с VK, с Telegram, с email-платформой, с коллтрекингом, с 1С, с мессенджерами) и надеяться, что всё заработает. На практике интеграции часто конфликтуют: одна перезаписывает поле, которое должна заполнять другая; одна падает, и данные не доходят; в одной изменился формат, и теперь сделки не создаются. Аналитик не знает, чему верить.

Правила интеграций. Первое — одна интеграция на источник. Не подключайте две разные интеграции с Яндекс Метрикой — будет конфликт. Второе — единая точка входа в CRM. Все лиды должны создаваться через один шлюз (или API, или единый вебхук-обработчик), а не через пять разных. Третье — логирование. Любая интеграция должна вести журнал: что получила, что создала, что не получилось. Без журнала невозможно отладить расхождение. Четвёртое — регулярная проверка. Раз в неделю — выборочная сверка 10 последних лидов в CRM с 10 последними событиями в источнике.

Ошибки объединения данных

Самые частые ошибки объединения. Первая — двойной счёт. Один и тот же пользователь засчитывается как два клиента, потому что нет дедупликации. Вторая — потеря идентификатора. Событие фиксируется, но без UTM, и попадает в «неизвестный источник». Третья — перезапись. Второй визит перезаписывает UTM первого, и в отчёте канал выглядит как «последний», а не как «первый» (или наоборот — зависит от правил). Четвёртая — смешение методик. Данные из двух систем считаются одинаковыми, но методики у них разные (last-click в одной, multi-touch в другой), и суммирование даёт ошибку.

Чтобы избежать этих ошибок, нужно два документа: карта идентификаторов (что и какому событию присваивается) и словарь методик (как каждая система считает ключевые метрики). Без этих документов любые объединения данных — это надежда на удачу. С ними — это воспроизводимый процесс, который можно проверить и улучшить.

Почему нельзя автоматически считать все источники сопоставимыми

Это самая опасная иллюзия: «у нас сквозная аналитика, значит, все источники сопоставимы». На практике — почти никогда. Яндекс Директ и VK Реклама по-разному считают атрибуцию. Метрика и Google Analytics по-разному считают сессии. CRM и 1С по-разному фиксируют оплату. Если просто сложить данные, получится невязка, и аналитик не знает, что правильно. Решение — не «сводить воедино любой ценой», а зафиксировать методику для каждой метрики: «CAC считается по данным CRM с проверкой платежей в 1С; расхождения свыше 5% расследуются вручную».