Дашборд показывает число заявок, но менеджеры говорят, что покупателей не стало больше. Новый график не ответит, где возникло расхождение. Сначала договоритесь, какое решение команда принимает по данным, что считается заявкой и где подтверждается продажа. Из этих ответов получится короткий план измерения; уже по нему стоит собирать отчёт.
Ниже — пример для компании с сайтом, рекламой и CRM. Это учебная схема, а не данные клиента WiseLab. Для интернет-магазина вместо лида и сделки понадобятся заказ, оплата, возврат и их идентификаторы.
Начните с решения, которое можно изменить
Фраза «хотим видеть эффективность рекламы» слишком широкая. Решение звучит точнее: «Если кампания приводит заявки, но мало квалифицированных обращений, проверяем запросы и обещание на посадочной странице, прежде чем увеличивать бюджет». Для такого решения недостаточно события отправки формы. Нужны расход, число уникальных обращений и результат первичной квалификации в CRM.
Запишите для каждого решения владельца, показатель и действие. Если действие не меняется при любом значении показателя, этот показатель пока не нужен на первом экране.
| Решение | Основная метрика | Единица и окно | Источник истины |
|---|---|---|---|
| Оставить или пересобрать кампанию | Стоимость квалифицированного лида = расход / число квалифицированных лидов | Кампания, лид; одинаковый период клика и зрелое окно продаж | Расход — рекламная система, статус — CRM |
| Исправить форму | Доля успешных отправок = подтверждённые отправки / начатые формы | Сессия или попытка; неделя | События сайта и серверное подтверждение |
| Ускорить обработку | Доля лидов с ответом в согласованный срок | Уникальный лид; дата создания в CRM | CRM |
В первой строке расход и лиды часто живут в разных календарях: рекламный кабинет относит расход к дате показа или клика, CRM — к дате создания обращения. Зафиксируйте правило сопоставления и время дозревания сделки. Иначе сравнение последних двух дней с прошлой полной неделей может наказать кампанию за ещё не завершённые продажи.
На графике видно изменение. Причину и действие задаёт план измерения.
Разведите событие, лид и продажу
Клик по кнопке «Отправить» — попытка. Успешный ответ сервера — отправленная форма. Запись в CRM — лид. Статус «подходит по запросу и зоне обслуживания» — квалифицированный лид. Оплата или договор — бизнес-результат. Если все пять шагов назвать «конверсией», отчёт будет выглядеть полным, а сравнить рекламу с продажами не получится.
В GA4 важное событие можно отметить как key event; Google отдельно описывает создание конверсии Google Ads на основе такого события. В Яндекс Метрике цель может фиксировать значимое действие, в том числе через reachGoal. Эти механизмы помогают измерять шаги, но сами по себе не сообщают, пригоден ли лид для продажи. Документация GA4 и справка Метрики описывают настройку.
Минимальный tracking plan может выглядеть так:
| Событие | Когда отправлять | Обязательные поля | Как проверить |
|---|---|---|---|
form_start | Пользователь впервые взаимодействовал с формой | Имя формы, страница | Одна попытка не создаёт серию одинаковых стартов |
lead_submit_success | Сервер подтвердил приём обращения | Имя формы, технический ID обращения | Ошибка валидации и повторный клик не увеличивают число лидов |
lead_qualified | В CRM зафиксирован согласованный статус | ID обращения, статус, время решения | Статус связан с исходной заявкой и не приходит дважды |
Это пример спецификации, а не универсальные имена событий. В проекте важнее согласовать определения и не передавать в аналитические события телефон, почту и содержимое заявки. Для связи систем нужен технический идентификатор, а доступ к персональным данным ограничивают в CRM.
Сделайте путь обращения проверяемым
До запуска разработчик, аналитик и владелец продаж должны ответить на три вопроса:
- Где создаётся ID обращения и как он попадает в CRM?
- Как сохраняется допустимая информация об источнике, если пользователь пришёл с меткой или рекламным идентификатором?
- Что происходит при повторной отправке формы, звонке после заявки и ручном объединении дублей?
Одна таблица соответствия полезнее длинного списка событий: lead_id в журнале сайта ↔ ID сделки в CRM ↔ время и источник визита. Если идентификаторы не сходятся, не исправляйте расхождение коэффициентом «на глаз». Покажите долю несопоставленных лидов и причины.
Хороший отчёт можно пересобрать из записанных определений и событий.
Проверьте один путь целиком
Создайте тестовую заявку с пометкой, которая не попадёт в бизнес-отчёт. Убедитесь, что после успешной отправки появился один ID, событие дошло до аналитики, запись оказалась в CRM, а квалификация привязалась к тому же обращению. Повторите сценарии ошибки формы и повторной отправки. Это выявит дубли и потери до того, как по данным начнут менять бюджет.
Для технической проверки GA4 предоставляет DebugView: там видны события и их параметры при включённом режиме отладки. Яндекс описывает проверку цели через _ym_debug=2 и журнал событий. Проверка в отладчике доказывает, что событие пришло в тестовом сценарии; она не доказывает полноту всех будущих данных. После запуска сравнивайте количество подтверждённых форм на сервере, в аналитике и CRM, отдельно учитывая согласие на аналитику, блокировщики и задержки.
Если после настройки данных мало, не добавляйте ещё десять метрик. Сначала проверьте источник расхождения, дату, фильтры, часовой пояс и единицу анализа. Затем решите, достаточно ли данных для изменения кампании.
Как использовать готовый бриф WiseLab
План измерения до дашборда помогает собрать черновик: решения, формулы, события, идентификаторы и проверку. Заполните в нём реальные системы и владельцев. Сверьте предложенные им события с поведением сайта и CRM; текст брифа не подтверждает, что трекинг уже работает.
Если задача шире одного отчёта, продолжите с разбором воронки продаж и материалом о качестве лидов и офлайн-конверсиях. Первый помогает найти участок потерь, второй — связать рекламу с результатом после заявки.
Источники и дата проверки
- Google Analytics: About key events — различие события и ключевого события.
- Google Analytics: Monitor events in DebugView — проверка событий и параметров.
- Яндекс Метрика: целевое событие —
reachGoal. - Яндекс Метрика: проверка цели — отладка целевого действия.
Справки проверены 2 октября 2026 года. Пример событий и таблица решений составлены WiseLab для объяснения метода; это не готовая схема конкретного бизнеса.
Изображения: «Dashboard example», Ironholds, CC0 1.0 и «Laptop picture with notepad», Eric Bailey, CC0 1.0. Они иллюстрируют тему и не показывают кейс WiseLab.
Что думаете?
Загружаем комментарии…