Содержание 9 разделов ↘
Сквозная аналитика начинается с договора о данных, а не с витрины
На совещании рекламщик говорит, что кампания привела 90 лидов, руководитель продаж видит 65, а бухгалтерия — 18 первых оплат. Ни одна система не обязательно ошибается: у них разные события, даты и единицы учёта. Но объединять их в один график без правил нельзя. Сквозная аналитика — это воспроизводимая связь затрат и зрелого результата с указанием пробелов, а не формула, способная знать все мотивы покупателя.
Создайте общий словарь: клик, визит, успешная заявка, уникальный контакт, квалифицированный лид, возможность продажи, КП, выигранная сделка, оплата и возврат. Для каждого укажите систему-источник и момент события. Не пытайтесь заменить этот контракт набором UTM-меток: они лишь один из элементов связи.
Архитектура данных: какие идентификаторы нельзя терять
Записывайте в лид время обращения, источник, URL посадочной, UTM, идентификатор сессии/пользователя в допустимом формате, ID формы, ID заявки и контекст продукта. У события оплаты должен быть свой уникальный ID, ссылка на сделку и указание корректировки. Для групп компаний и партнёрских продаж нужно отдельно хранить компанию, юридического контрагента и проект: email одного сотрудника не гарантирует единую закупку.
Яндекс Метрика допускает привязку офлайн-данных по ClientID, UserID или yclid, но способы имеют разные ограничения. ClientID описывает браузер, а не неизменную реальную личность; при смене браузера он может измениться. В справке Яндекса ClientID рекомендован для офлайн-привязки. Сначала согласуйте правомерность передачи идентификаторов и минимизацию данных, затем — технологическую реализацию.
Таблица событий, которую стоит утвердить до разработки
| Событие | Источник истины | Обязательные поля |
|---|---|---|
| form_submitted | Успешный ответ сервера | event_id, время, form_id, URL |
| lead_created | CRM | lead_id, время, источник, продукт |
| lead_qualified | CRM, принятый статус | lead_id, причина/сегмент |
| deal_won | CRM | deal_id, валюта, сумма, время |
| payment_received | Учёт или платёжная система | payment_id, deal_id, сумма |
| refund_processed | Учётная система | refund_id, payment_id, величина |
Названия событий здесь — предлагаемый контракт проекта, не автоматически встроенные цели Яндекс Метрики. Сначала договоритесь о смысле, после этого сопоставьте с конкретными параметрами счётчика и CRM. Не отправляйте денежное событие дважды при повторном webhook: сервер должен хранить ключ идемпотентности.
Как передать результат из CRM назад в аналитику
Проверьте, что ID посетителя сохранён в CRM на момент успешной отправки формы. При смене статуса или оплате подготовьте офлайн-событие с корректным идентификатором, датой и типом цели. В разделе «Офлайн-конверсии» Метрики можно анализировать статус привязки и причину ошибки; только успешно связанные события работают в предусмотренных механизмах оптимизации. Не считайте число загруженных строк числом правильно атрибутированных продаж.
В документации Яндекса есть ограничения по периоду привязки событий и времени загрузки. Для длинного B2B-цикла оплаты могут наступать позже допустимого окна: не обещайте сохранить полный путь через одну только Метрику. Параллельно храните отдельную CRM-когорту с датой первого подтверждённого касания и справедливо обозначайте уровень уверенности в связи.
Семь проверок до публикации отчёта для руководства
- Создайте тестовую заявку с заранее записанными метками, URL и временем.
- Убедитесь, что цель срабатывает после успешного ответа сервера, а не по клику.
- Сверьте один и тот же ID заявки в журнале сайта и CRM.
- Проверьте присвоение менеджера и корректную причину отклонения.
- Проведите тестовую оплату/событие в изолированном режиме и отмену без дублирования.
- Загрузите офлайн-конверсию и проверьте статус привязки, а не только успешную отправку.
- Сравните за период рекламный расход, заявки, оплаченные сделки и неизвестные источники.
Для каждого шага зафиксируйте фактический результат, владельца, логи и дату. Если данные не проходят тест — не включайте их в «ROMI 400%». Достоверная таблица с пометкой «неизвестно» лучше эффектного, но ошибочного графика.
Отчёт о качестве самих данных должен существовать отдельно
Показывайте процент заявок без источника, долю дублей, количество пропущенных webhook, долю связавшихся офлайн-событий, лаг от заявки до квалификации, просроченные статусы и возвраты, не попавшие в управленческую витрину. Отсутствие привязки не означает, что конверсия не состоялась; оно означает, что система не смогла корректно определить её источник.
Не пытайтесь искусственно распределить весь «неизвестный» доход по каналам ради красивой суммы 100%. Если данные CRM закрывают только часть воронки, показывайте границы оценки, а для влияния бренда или офлайн-контактов используйте дополнительные методы исследования.
Чьи задачи это на практике
Маркетинг определяет каналы и события, отдел продаж — критерии квалификации и стадии сделки, разработка — передачу ID, CRM-администратор — поля и права, финансы — подтверждение оплат и маржи. Один «аналитик» не сможет компенсировать отсутствие решений у владельцев процессов. Назначьте ответственных за обновление документации, доступы и аудит после каждого существенного релиза формы.
Не передавайте персональные данные и коммерческие договоры в рекламные системы без правового основания и политики минимизации. Разделяйте технический ID события и персональную информацию клиента. Требования хранения данных и доступа нужно согласовывать с юридической и ИБ-командами.
Что делать, если офлайн-конверсии не связались с визитами
Не удаляйте такие оплаты из финансового отчёта и не записывайте их как нулевую выручку канала. Храните исходный денежный факт отдельно, а статус рекламной привязки — как дополнительное поле. Проверяйте формат идентификатора, время события, окно привязки, дубли и отсутствие исходного посещения. Исправление технической связки может изменить отчётную атрибуцию, но не меняет факта продажи.
В актуальной справке Метрики отмечено, что статусы привязки в отчётах временно могут отображаться неверно; долю привязанных конверсий рекомендуется смотреть на странице загрузки данных в настройках счётчика. Поэтому качество привязки нельзя утверждать по одному экрану отчёта без сверки с текущими рекомендациями платформы.
Первый полезный дашборд меньше, чем кажется
На первом экране руководителю достаточно расхода по каналам, принятых новых лидов, стоимости квалифицированного обращения, числа созревших сделок, подтверждённого валового вклада и доли неизвестной атрибуции. Развернутые отчёты должны позволять провалиться к кампаниям, продуктам и причинам проигрыша.
Начните с одного проверенного пути для ключевого продукта, исправьте ложные события, затем расширяйте на другие формы. Это надёжнее дорогой «сквозной платформы», когда события разных систем даже не имеют согласованных названий.
Источники и методика проверки: Источник 1 · Источник 2 · Источник 3 · Источник 4. Изменяющиеся условия платформ и цены необходимо повторно проверять на дату решения. Приведённые учебные сценарии не являются статистикой RAF.
