Реклама и CRM показывают разные результаты
Рекламный кабинет считает клики и заявки, CRM — сделки, а учётная система — оплаты. Без общего идентификатора нельзя понять, где данные потерялись и какой источник привёл подтверждённый результат.
Услуги / Маркетинг
Связываем источник обращения, действия на сайте, звонки, статусы CRM и подтверждённую выручку — чтобы руководитель видел не набор несвязанных отчётов, а проверяемый путь от канала до результата.

Сквозной отчёт начинается не с dashboard, а с единого идентификатора, систем-владельцев и проверки каждого перехода данных.
Коротко
Настройка сквозной аналитики — это проектирование и внедрение маршрута данных от рекламного источника и сессии сайта до обращения, CRM-статуса и подтверждённого результата. Работа включает не только dashboard, но и единые определения, идентификаторы, интеграции, контроль качества и регламент исправления сбоев.
Диагностика
Сквозная аналитика нужна, когда управленческий вопрос нельзя проверить в одной системе. Мы сначала находим конкретные потери данных и только после этого выбираем сервисы и глубину интеграции.
Рекламный кабинет считает клики и заявки, CRM — сделки, а учётная система — оплаты. Без общего идентификатора нельзя понять, где данные потерялись и какой источник привёл подтверждённый результат.
Телефония хранит номер и запись разговора отдельно от формы, сессии сайта и карточки клиента. Один человек может выглядеть как несколько обращений, а источник звонка остаётся неизвестным.
Параметры теряются при переходах между доменами, повторном визите, редиректе или ручном создании сделки. В отчёте растёт категория «прямой трафик», хотя часть обращений пришла из платных каналов.
Маркетинг видит отправленную форму, но не узнаёт, была ли заявка целевой, состоялся ли договор и подтверждена ли оплата. Оптимизация заканчивается на верхнем уровне воронки.
Каждую неделю сотрудник выгружает файлы, меняет формулы и сопоставляет названия кампаний. Ошибка обнаруживается поздно, а методика отчёта зависит от конкретного человека.
Результат
Результат описывается через передаваемые артефакты и работающий контур. Клиент сохраняет административные доступы, документацию и возможность проверить происхождение показателя.
Документируем рекламные кабинеты, домены, формы, телефонию, CRM, учётную систему и точки передачи. Для каждого события фиксируем название, обязательные параметры, владельца и допустимую задержку.
Согласуем, что считается обращением, квалифицированной заявкой, сделкой, продажей, возвратом и выручкой. В словаре указаны формула, источник, период обновления и ответственный за качество.
Настраиваем передачу client ID, UTM, call tracking ID и бизнес-статусов между системами. Каждый значимый факт создаётся одной системой-владельцем, а остальные получают контролируемую копию.
Собираем dashboard с уровнями от канала и кампании до обращения, сделки и подтверждённого результата. Разрезы выбираются под управленческие вопросы, а не под максимальное число графиков.
Передаём перечень автоматических и ручных проверок: пропуски идентификаторов, дубли, задержки загрузки, изменение справочников, расхождения сумм и ответственный порядок исправления.
Границы
До старта фиксируем системы, бизнес-вопросы, уровень детализации и критерии приёмки. Это отделяет обязательный контур от возможных улучшений и не позволяет проекту бесконечно расширяться.
Проверяем счётчики, цели, контейнеры тегов, формы, телефонию, CRM-поля, статусы, импорт расходов и факт выручки. Выделяем измеримые разрывы и данные, которых пока нет.
Определяем сущности, идентификаторы, события, атрибуцию, систему-владельца и период обновления. Отдельно описываем повторное обращение, несколько сделок одного клиента и возврат.
Реализуем события сайта, передачу рекламных параметров, call tracking, CRM webhooks или API, загрузку расходов и подтверждённых результатов. Добавляем журнал ошибок и повторную обработку там, где это возможно.
Проходим путь тестового обращения из каждого основного канала, сверяем идентификаторы и значения на каждом переходе. Результат принимается по заранее согласованной матрице сценариев.
Фиксируем архитектуру, доступы, справочники, правила изменения тегов, порядок проверки и ограничения модели. Команда клиента получает не только dashboard, но и способ поддерживать его после запуска.
Архитектура данных
Каждый переход имеет идентификатор, систему-владельца и проверку доставки. Неизвестный источник остаётся неизвестным: мы не распределяем его между каналами искусственно.
Рекламная система, поиск, социальная сеть, партнёр или офлайн-код передают кампанию и параметры входа.
Сайт фиксирует client ID, UTM, событие и согласованный минимум технического контекста после разрешённого уровня consent.
Форма, звонок или сообщение создают единое обращение с идентификатором канала и защитой от повторной отправки.
CRM возвращает квалификацию, этап, причину потери и ответственного по согласованному справочнику состояний.
Оплата или иной принятый бизнес-факт поступает из системы, где он действительно подтверждается, а не из ручного статуса отчёта.
Для передачи статусов и защиты от дублей может потребоваться интеграция CRM с сайтом и сервисами.
Процесс
У каждого этапа есть входные данные, действие, самостоятельный результат и критерий приёмки. Клиент может остановиться после диагностики и использовать её как техническую основу для другого подрядчика.
Вход: доступы и описание текущего процесса. Действие: инвентаризация систем и контрольные обращения. Результат: карта потерь и список рисков. Приёмка: каждая проблема подтверждена примером или проверкой.
Вход: выбранные бизнес-вопросы и доступные данные. Действие: описание событий, идентификаторов, справочников и контрактов. Результат: схема целевого контура. Приёмка: владельцы систем согласовали источники фактов.
Вход: утверждённая схема и тестовая среда. Действие: настройка тегов, API, webhooks, загрузок и отчёта. Результат: минимальный сквозной маршрут. Приёмка: тестовые события проходят все точки без ручного исправления.
Вход: рабочий маршрут и реальные данные ограниченного периода. Действие: сверка расходов, обращений, статусов и результатов. Результат: журнал расхождений. Приёмка: критические разрывы устранены либо явно описаны как ограничение.
Вход: стабилизированный контур. Действие: обучение, документация и настройка регулярных проверок. Результат: регламент эксплуатации. Приёмка: назначенные сотрудники могут проверить загрузку и локализовать типовой сбой.
Сценарии
Архитектура зависит от пути клиента и способа подтверждения результата. Поэтому сеть, длинная B2B-продажа и e-commerce не получают одну и ту же шаблонную модель.
Компания объединяет формы, динамический call tracking и CRM. Руководитель сравнивает каналы по квалифицированным обращениям и подтверждённым сделкам, сохраняя возможность провалиться до конкретной записи.
Маркетинговый источник сохраняется при нескольких контактах и стадиях. В отчёте отдельно видны первичное обращение, квалификация, предложение и результат, а модель не приписывает всю ценность последнему визиту без оговорки.
Единые определения применяются к филиалам и продуктам, но права и справочники учитывают организационную структуру. Расхождения можно сравнивать, не смешивая разные типы продаж в одной средней конверсии.
Заказ, оплата, отмена и возврат поступают из учётной системы. Маркетинговый отчёт отделяет созданный заказ от подтверждённой выручки и не дублирует повторную передачу одного события.
Инструменты
| Инструмент | Зачем нужен |
|---|---|
| Яндекс Метрика | Поведение на сайте, источники и согласованные события. Счётчик загружается только после соответствующего согласия пользователя. |
| Tag Manager или собственный слой событий | Единые названия и параметры действий сайта. Выбор зависит от требований к доступам, локализации и сопровождению. |
| отслеживание звонков | Связывает звонок с сессией и рекламным источником в пределах возможностей выбранного сервиса и правил обработки данных. |
| система управления клиентами (CRM) | Хранит обращение, квалификацию, этап, ответственного и причину завершения. Статусы должны иметь одинаковое значение для продаж и аналитики. |
| API, webhooks и ETL | Передают события и справочники между системами. Для критичных операций нужны журнал, повтор, дедупликация и контроль задержки. |
| SQL и BI | Объединяют проверенные данные и отображают нужные разрезы. BI не заменяет исправление источника, если событие не передаётся или определяется неверно. |
Фрагмент проекта
В проекте ресторана сайт, Яндекс Метрика и Calltouch использовались как часть измеряемого маркетингового контура. Ниже показаны реальные production-экраны. Они подтверждают наличие сбора и отчётности, но сами по себе не доказывают причинность продаж.


Сроки и стоимость
Самостоятельный результат — карта текущего контура, подтверждённые потери, требования к данным и план реализации. Этот этап можно использовать независимо от дальнейшего подрядчика.
Количество доменов и рекламных кабинетов, число форм и номеров, модель CRM, доступность API, качество справочников, глубина до выручки, требования к хранению и состав dashboard.
После диагностики работа делится на этапы с результатом и критериями приёмки. Лицензии внешних сервисов и регулярное сопровождение указываются отдельно, чтобы не смешивать разработку с операционными расходами.
Оценка выдаётся после проверки доступов и систем. Фиксированный срок без этой информации был бы обещанием, которое не учитывает качество CRM, внешние API и объём восстановления данных.
Ограничения
Аналитика не делает неполные данные полными и не заменяет управленческое решение. Ограничения документируются рядом с показателями, чтобы dashboard не создавал ложную уверенность.
Если статусы меняются задним числом или сделки закрываются без причины, dashboard воспроизводит эту неопределённость. Нужны минимальные обязательные правила и владелец качества.
Cookies, устройства, браузеры, звонки и офлайн-контакты не всегда можно надёжно связать с одним человеком. Модель должна показывать неизвестную долю, а не распределять её искусственно.
Рекламная система, CRM или телефония могут изменить лимиты и контракт. Интеграция требует мониторинга, журналов и бюджета на сопровождение.
Состав передаваемых данных, правовое основание, локализация и сроки хранения проверяются до запуска. В отчёт не включаются персональные поля, если для решения достаточно агрегата.
Изменение выручки нельзя автоматически приписывать аналитике или каналу. Отчёт помогает увидеть связи, но управленческий вывод учитывает предложение, наличие, цены и обработку обращений.
Одна модель распределения ценности не является абсолютной истиной. В отчёте фиксируются правило расчёта, окно, допущения и сценарии, где вывод нельзя делать уверенно.
Состав персональных данных и consent-механика сверяются с политикой обработки данных и фактической архитектурой клиента.
Частые вопросы
Сквозная аналитика связывает рекламный источник и действия на сайте с обращением, статусами CRM и подтверждённым бизнес-результатом. Она показывает путь данных между системами и позволяет проверить, на каком этапе возникла потеря или расхождение.
Метрика показывает источники и поведение на сайте. Сквозной контур добавляет звонки, CRM-статусы, расходы и подтверждённые результаты из других систем. Метрика может быть важным источником, но не заменяет весь маршрут.
Нет. Архитектура зависит от объёма, доступных API и требуемой глубины. Иногда достаточно Метрики, CRM и контролируемой выгрузки; в других случаях нужен call tracking, хранилище и BI. Выбор делается после аудита.
Можно измерить рекламу и сайт, но связать обращение с квалификацией, сделкой и выручкой будет значительно сложнее. Для первого этапа допустим ограниченный реестр, если у него есть единые статусы и ответственный за заполнение.
Модель выбирается под управленческий вопрос и доступные данные. В отчёте фиксируются окно и правила расчёта. Мы не выдаём last click, first click или распределённую модель за абсолютную причинность.
Через контрольные обращения, сверку идентификаторов на каждом переходе, сравнение агрегатов между системами, поиск дублей и пропусков, мониторинг задержки и журнал изменений справочников.
Рабочие аккаунты, счётчики и рекламные кабинеты должны принадлежать клиенту либо быть оформлены так, чтобы клиент сохранял административный доступ. Порядок передачи доступов и документации фиксируется до запуска.
Срок зависит от числа систем, готовности CRM, доступности API и качества данных. Сначала оценивается самостоятельная диагностика, затем реализация делится на этапы с отдельными критериями приёмки.
Нет. Аналитика не заменяет предложение, рекламу и работу отдела продаж. Она делает путь данных проверяемым и помогает раньше обнаруживать потери, но бизнес-результат зависит от решений, принятых на основе этих данных.
Обсудить задачу
Начнём с самостоятельной диагностики: карта источников, CRM-статусов, разрывов и границ первого рабочего контура.