Сквозная аналитика на базе Matomo: как связать рекламу, заявку и продажу
Практическая архитектура сквозной аналитики: как связать рекламный клик, визит, заявку, сделку и выручку в Matomo и Nasloy ROI.
В большинстве рекламных отчётов я вижу только начало пути: показы, клики, сессии и отправленные формы. Эти данные полезны, но не отвечают на главный вопрос бизнеса — какая реклама принесла оплаченные сделки и прибыль. Кампания может давать дешёвые лиды, которые не покупают, а дорогой на первый взгляд канал — приводить клиентов с высоким средним чеком.
Сквозная аналитика соединяет разрозненные этапы в одну цепочку: реклама → визит → заявка → сделка → оплата. Для построения такой системы я использую Matomo как аналитическую основу и Nasloy ROI как доработанный сервис отчётности, атрибуции и контроля окупаемости маркетинга.
В этой статье разберу архитектуру без магии: какие идентификаторы нужны, откуда брать расходы и выручку, как не потерять заявку между сайтом и CRM и почему красивый дашборд ещё не означает, что цифрам можно доверять.
Чем сквозная аналитика отличается от веб-аналитики
Веб-аналитика отвечает на вопросы о поведении на сайте: откуда пришёл посетитель, какие страницы посмотрел, какие события выполнил и достиг ли цели. Сквозная аналитика идёт дальше и добавляет данные отдела продаж и финансов.
Я разделяю уровни так:
- рекламная платформа хранит показы, клики и расходы;
- Matomo фиксирует источник, кампанию, визит, события и конверсии;
- форма или телефония создаёт лид;
- CRM хранит квалификацию, статус, ответственного и сделку;
- учётная система подтверждает оплату, возврат и маржу;
- Nasloy ROI собирает данные в отчёт по каналу, кампании и периоду.
Без последнего участка маркетолог оптимизирует рекламу по отправке формы, хотя бизнес зарабатывает на оплате. Это особенно опасно в услугах с длинным циклом сделки, B2B, недвижимости, медицине и дорогой разработке.
Как выглядит правильная цепочка данных
Для связи этапов нужен не email в UTM-метке и не номер телефона в адресе страницы, а технические идентификаторы. На входе я сохраняю параметры кампании, рекламный click ID, идентификатор визита и время первого касания. При отправке формы создаётся внутренний lead_id. Он передаётся в CRM вместе с допустимым набором маркетинговых атрибутов.
Когда менеджер меняет статус или фиксирует оплату, CRM отправляет обратно событие с тем же lead_id или deal_id. Так продажа связывается с исходным визитом без попыток угадать клиента по фамилии.
Базовая модель содержит:
1. source, medium, campaign, content и keyword;
2. рекламный идентификатор клика, если он доступен;
3. visitor_id или иной внутренний идентификатор визита;
4. lead_id после целевого действия;
5. deal_id и этап в CRM;
6. сумму оплаты, себестоимость или валовую прибыль;
7. рекламные расходы за тот же период и разрез;
8. отметки о возврате, отмене и повторной продаже.
Почему Matomo подходит как основа
Matomo умеет собирать источники трафика, параметры кампаний, события, цели и ecommerce-операции. В официальной документации для новых ссылок рекомендован префикс mtm_, но поддерживаются и распространённые UTM-параметры. Это удобно при миграции и работе с несколькими рекламными системами.
Цели можно фиксировать по URL, событию, скачиванию, внешней ссылке или вручную через JavaScript. Для ecommerce доступны заказы, товары и выручка. Reporting API позволяет программно получать отчёты в JSON, CSV, XML и других форматах, поэтому Matomo можно связать с CRM, BI-интерфейсом и внутренним хранилищем.
Но установка счётчика — только начало. Matomo не узнает сам, что заявка прошла квалификацию и превратилась в продажу через три недели. Эту связь нужно спроектировать и реализовать.
Шаг 1. Начать с плана измерений
До кода я составляю таблицу, в которой бизнес-цель связана с измеримым действием и источником данных. Например:
- рост продаж — оплачанные сделки из CRM или учётной системы;
- снижение стоимости привлечения — расходы и новые покупатели;
- повышение качества лидов — доля квалифицированных обращений;
- улучшение сайта — конверсия между этапами воронки;
- рост повторных продаж — новые оплаты существующих клиентов.
Для каждой метрики фиксирую владельца, формулу, период обновления и допустимое расхождение. Если отдел маркетинга и финансы по-разному понимают «выручку», дашборд лишь аккуратно визуализирует конфликт.
Шаг 2. Навести порядок в разметке рекламы
Одинаковая кампания не должна называться yandex_cpc, Яндекс и ya-direct в трёх разных отчётах. Я задаю единые правила source, medium, campaign, content и term, а также сохраняю идентификаторы рекламных платформ.
Правила должны быть документированы и применяться автоматически при создании ссылок. Регистр, пробелы и транслитерация имеют значение. После редиректа параметры не должны исчезать, а посадочная страница обязана загрузить трекер до того, как пользователь успеет выполнить целевое действие.
Шаг 3. Настроить события и цели
Я не ограничиваюсь целью «спасибо за заявку». На сайте полезно видеть микроэтапы: начало заполнения, успешную серверную отправку, выбор услуги, звонок, чат, скачивание коммерческого предложения и переход к оплате.
Ключевое слово здесь — успешную. Клик по кнопке не равен заявке: форма могла вернуть ошибку, соединение оборвалось, а бот — заполнить скрытое поле. Основную конверсию лучше подтверждать сервером после валидации данных.
Для интернет-магазина использую ecommerce-события и уникальный order_id. Для услуг создаю lead_id и отправляю цель только после принятия формы системой.
Шаг 4. Передать маркетинговый контекст в CRM
В карточке лида сохраняю не все данные браузера, а минимальный набор, нужный для атрибуции и проверки качества:
- первый и последний источник;
- кампания и объявление;
- click ID;
- посадочная страница;
- lead_id и время создания;
- выбранная услуга или товар;
- согласие и техническая версия формы.
Персональные данные не нужно помещать в URL, названия событий или пользовательские измерения. Доступ к аналитике и CRM следует разделять по ролям, а срок хранения определять заранее с учётом применимых требований и политики компании.
Шаг 5. Вернуть статусы и деньги из CRM
Это участок, который чаще всего отсутствует. Форма передала лид, маркетолог увидел конверсию — и на этом связь закончилась. Я настраиваю обратный поток событий: лид принят, квалифицирован, назначена встреча, создана сделка, получена оплата, оформлен возврат.
Для каждой оплаты нужны сумма, валюта, дата и идентификатор сделки. Если возможны частичные платежи, их нельзя бездумно суммировать как новые продажи. Возвраты и отмены тоже должны корректировать результат, иначе ROMI всегда будет завышен.
Шаг 6. Загрузить расходы
Выручка без расходов показывает объём продаж, но не окупаемость. Я импортирую затраты из рекламных кабинетов по дате, каналу и кампании. При необходимости добавляю агентскую комиссию, производство креативов, коллтрекинг и другие прямые расходы.
Важно заранее решить, какие затраты входят в отчёт. ROAS обычно сравнивает рекламную выручку с расходом на размещение. ROMI может учитывать более широкий маркетинговый бюджет и валовую прибыль. Я всегда вывожу формулу рядом с показателем, чтобы цифра не выглядела универсальной истиной.
Примеры:
- CPL = рекламные расходы / количество лидов;
- CAC = расходы на привлечение / новые клиенты;
- ROAS = выручка из рекламы / рекламные расходы;
- ROMI = (валовая прибыль − маркетинговые расходы) / маркетинговые расходы × 100%.
Шаг 7. Выбрать модель атрибуции
Клиент редко покупает после одного касания. Он может увидеть рекламу, вернуться из поиска, прочитать статью и через неделю открыть сайт напрямую. Если присвоить всю ценность последнему визиту, первый канал исчезнет из отчёта. Если использовать только первый источник, недооцениваются каналы, которые помогли закрыть сделку.
Я обычно показываю рядом несколько представлений:
- first touch — откуда началось знакомство;
- last non-direct — какой канал привёл перед конверсией;
- цепочку касаний — какие источники участвовали;
- бизнес-модель распределения ценности, если данных достаточно.
Атрибуция не восстанавливает абсолютную причинность. Это управленческое правило распределения результата. Поэтому модель должна быть стабильной, понятной и одинаковой при сравнении периодов.
Что я проверяю перед запуском отчётов
Перед тем как показывать дашборд руководителю, провожу контроль качества. Создаю тестовые визиты для разных источников, отправляю формы, двигаю сделку по CRM и провожу тестовую оплату. Затем сверяю каждый этап по идентификаторам и времени.
Обязательные проверки:
- счётчик работает на всех посадочных и доменах;
- UTM и click ID сохраняются после редиректов;
- одна заявка не создаёт несколько целей;
- lead_id одинаков в форме, CRM и аналитическом слое;
- статусы CRM имеют однозначное значение;
- продажи и возвраты не дублируются;
- расходы сходятся с рекламным кабинетом;
- часовые пояса и валюты нормализованы;
- прямые и неизвестные источники не скрываются искусственно;
- тестовые данные исключены из рабочего отчёта.
Я также задаю порог допустимого расхождения и автоматические предупреждения. Полное совпадение не всегда возможно из-за блокировщиков, согласий, задержек импорта и различий в атрибуции, но причина расхождения должна быть известна.
Типичные ошибки внедрения
Первая ошибка — начинать с дизайна дашборда. В результате команда неделями выбирает цвета графиков, хотя lead_id теряется на форме.
Вторая — отправлять в аналитику только успешные данные и скрывать неизвестные источники. Отчёт выглядит лучше, но перестаёт показывать качество интеграции.
Третья — считать заявку продажей. Для дешёвого продукта разница может быть небольшой, но в B2B и услугах она полностью меняет оценку каналов.
Четвёртая — менять модель атрибуции каждый месяц под желаемый результат. Сравнение периодов становится бессмысленным.
Пятая — игнорировать возвраты, повторные оплаты и маржу. Выручка растёт на экране, а экономика проекта ухудшается.
Шестая — хранить лишние персональные данные в событиях и отчётах. Аналитическая система должна получать только то, что действительно нужно для измерений.
Как Nasloy ROI дополняет Matomo
Я развиваю Nasloy ROI как сервис сквозной аналитики на базе Matomo. Он использует данные веб-аналитики, но делает акцент на улучшенных отчётах, атрибуции каналов и контроле окупаемости маркетинга.
Вместо раздельного просмотра кампаний, целей и CRM задача сервиса — показать управленческую цепочку: сколько стоил трафик, сколько заявок он создал, какие лиды стали сделками и какую выручку принесли. Конкретный состав интеграций зависит от рекламных кабинетов, сайта, CRM и модели продаж компании.
Если нужно не только измерение, но и управление рекламой, посмотрите услугу контекстной рекламы со сквозной аналитикой. Для органических каналов полезна связка с SEO-продвижением. А подозрительные потери бюджета можно диагностировать по моему руководству о десяти признаках скликивания.
План внедрения на четыре недели
Первая неделя: план измерений, аудит счётчиков, CRM, форм, рекламы и существующих отчётов. Определяем формулы и идентификаторы.
Вторая неделя: единая разметка кампаний, события, цели, lead_id, тестовые сценарии и контроль передачи данных.
Третья неделя: интеграция CRM, статусов, продаж, возвратов и расходов. Настройка правил атрибуции.
Четвёртая неделя: сверка данных, дашборды, права доступа, документация и обучение команды. После запуска нужен регулярный контроль: сайты, формы и рекламные кабинеты меняются, поэтому аналитика без владельца постепенно ломается.
Вывод
Сквозная аналитика — это не один счётчик и не готовый график. Это договорённость о метриках, система идентификаторов и надёжный обмен данными между рекламой, сайтом, CRM и оплатами. Matomo даёт сильную основу для сбора и получения аналитических данных, а бизнес-слой превращает их в отчёт о заявках, продажах и окупаемости.
Я строю систему от вопроса «какое решение мы хотим принимать», а не от количества доступных метрик. Когда каждый рубль выручки можно проследить до сделки и маркетингового контекста, реклама перестаёт быть набором кабинетов и становится управляемой инвестицией.
Связать рекламу, заявки и продажи в Nasloy ROI
Официальные источники
Matomo: руководство по ecommerce-аналитике
Matomo: создание и настройка целей
Matomo: параметры отслеживания рекламных кампаний