Почему отчёты о рекламных конверсиях расходятся с данными о заявках

Рекламный кабинет Google Ads, сервис веб-аналитики «Google Аналитика 4» (GA4) и система учёта клиентов и сделок (CRM) отвечают на разные вопросы. Рекламный кабинет относит результат к рекламному взаимодействию по своим правилам. Веб-аналитика строит межканальный отчет и использует собственную атрибуцию. Система учёта клиентов хранит контакт, квалификацию, сделку и оплату по дате изменения статуса.

Расхождение само по себе не доказывает ошибку. Причину можно объяснить, если команда заранее определила единицу учета, правило подсчёта конверсий (Count), основную и дополнительную роли целей (Primary и Secondary), окно конверсии, дату отчета, идентификатор рекламного взаимодействия и статус в системе учёта клиентов. Дубли, потерянные заявки и ложные события остаются дефектами и требуют исправления.

Подтвержденная отправка формы, клик по телефону, звонок длительностью 30 секунд, созданный лид, квалифицированный лид и продажа являются разными событиями. Если рекламный кабинет считает все клики по кнопкам, а система учёта клиентов показывает только уникальные обращения, числа закономерно расходятся.

Запишите определение каждого показателя. Для формы нужен успешный ответ сервера или подтвержденное событие приложения. Для звонка задают минимальную длительность и правила повторного обращения. Для квалифицированного лида указывают обязательные поля, регион, услугу и причину отказа. Продажа подтверждается оплатой или другим согласованным финансовым событием.

Затем выберите общий период. Для ежедневной диагностики можно сравнивать события по дате совершения. Для оценки рекламы учитывают дату рекламного взаимодействия и задержку конверсии. Для длинной сделки используют когорту лидов по дате создания и ждут завершения согласованного цикла.

Для лидогенерации часто выбирают правило «одна конверсия» (Count One): по действию с этой настройкой рекламный кабинет учитывает не более 1 конверсии после 1 рекламного клика. Повторные отправки по тому же действию после этого клика не увеличивают число конверсий; уникальных клиентов отдельно определяют по данным системы учёта клиентов. Для покупок правило «каждая конверсия» (Every) обычно лучше отражает несколько оплаченных заказов. Решение зависит от определения конверсии и фактической экономики.

Основная роль (Primary) означает, что действие входит в столбец «Конверсии» и участвует в назначении ставок, когда кампания использует соответствующую стандартную цель. Дополнительная роль (Secondary) служит наблюдению и входит в «Все конверсии». Если действие включено в специальную цель (custom goal), которую использует кампания, оно участвует в назначении ставок независимо от основной или дополнительной роли. Поэтому проверяйте цели аккаунта и каждой кампании.

Клик по кнопке, открытие формы, просмотр контактов и глубина прокрутки страницы полезны как диагностические события. В лидогенерации их обычно оставляют вторичными. Подтвержденная форма, квалифицированный лид или продажа получают основную роль, если система передает их стабильно и в достаточном объеме.

Оба способа допустимы. Прямое действие рекламного кабинета удобно для настройки окна конверсии, атрибуции и улучшенных конверсий (Enhanced Conversions). Импорт из веб-аналитики подходит, когда команда использует единое событие и понимает задержку и правила передачи.

Один бизнес-результат должен поступать в основные цели один раз. Параллельный прямой тег и импорт того же события из веб-аналитики могут создать две конверсии. Если оба источника нужны для сравнения, одному действию назначают дополнительную роль (Secondary), указывают его назначение и проверяют, что оно не входит в специальную цель кампании.

Перед выбором проверьте действующую архитектуру, права доступа, домены, формы и систему учёта клиентов. Перенос между способами проводят с периодом параллельной проверки и четкими названиями действий. Историю не смешивают в одном временном ряду без пометки даты изменения.

Атрибуция на основе данных (Data-driven attribution) распределяет вклад между рекламными взаимодействиями по доступным данным и правилам платформы. Доступные модели и требования меняются, поэтому проверяйте настройки конкретного действия. Атрибуцию по последнему клику (Last click) можно использовать для сравнения, но изменение модели меняет отчет.

Окно выбирают по фактической задержке между кликом и нужным событием. Для быстрого заказа часто рассматривают 7-30 дней. Для сделки между компаниями (B2B) цикл может занимать 60-90 дней и больше. Эти числа служат примерами диапазонов, а решение принимают по отчету о времени до конверсии (time lag) и данным системы учёта клиентов.

Слишком короткое окно теряет поздние сделки. Слишком длинное относит к старой рекламе события, связь которых с первоначальным кликом требует отдельной проверки. Зафиксируйте окно в методике и учитывайте его при сравнении периодов.

Конверсия после просмотра объявления без клика (View-through) особенно заметна в медийных и видеокампаниях. Выносите такие конверсии в отдельную строку отчета. Для решений по поиску и лидам сравнивайте кликовые, наблюдаемые, моделируемые и импортированные действия раздельно.

Режим согласия (Consent Mode) передает выбор пользователя и меняет поведение тегов. При выполнении требований Google часть пропусков может оцениваться моделированием. Моделируемые данные являются расчетом платформы и должны быть обозначены в отчете отдельно от заявок, зарегистрированных в системе учёта клиентов.

Проверьте согласие на хранение рекламных файлов в браузере (ad_storage), аналитических файлов в браузере (analytics_storage), передачу данных пользователя для рекламы в Google (ad_user_data) и персонализацию рекламы (ad_personalization) для разных решений пользователя. Состояние по умолчанию должно устанавливаться до тегов, а обновление происходить после выбора. Региональная и юридическая конфигурация согласуется с ответственным специалистом компании.

Серверная передача улучшает контроль доставки и качество данных, но не восстанавливает контакт, который форма не создала, и не отменяет требования к согласию. Она требует дедупликации, идентификаторов, мониторинга ошибок и защиты персональных данных.

Улучшенные конверсии для потенциальных клиентов (Enhanced Conversions for Leads) используют хэшированные данные, которые посетитель передал компании, например номер телефона или адрес электронной почты, для сопоставления лида с рекламным взаимодействием. Передача требует соблюдения правил Google, корректного сбора согласия и постоянного идентификатора лида.

Записывайте рекламные идентификаторы (GCLID, GBRAID или WBRAID), когда они доступны. В системе учёта клиентов также нужны дата, источник, метки перехода (UTM), идентификатор лида, статус, сумма и валюта. Повторная отправка статуса должна обновлять ту же запись без новой конверсии.

Менеджер данных Google (Google Data Manager) подключает собственные источники компании для импорта данных. Выбор способа зависит от системы учёта клиентов, частоты обновления, доступов и действующих возможностей аккаунта. Перед запуском проведите тест на ограниченном наборе записей и сопоставьте результат с системой учёта клиентов.

Соберите все действия из рекламного кабинета, веб-аналитики, диспетчера тегов Google (GTM), сайта, коллтрекинга и системы учёта клиентов. Для каждого укажите название, источник, условие запуска, правило подсчёта (Count), роль, окно, владельца и коммерческое назначение. Названия «лид» (lead) и «создание лида» (generate_lead) требуют проверки: они могут описывать разные формы.

Отдельно отметьте события, созданные системой управления сайтом (CMS), виджетом или сторонним скриптом. После редизайна старый тег может продолжить работу вместе с новым. Два контейнера диспетчера тегов, прямой тег в коде и импорт из веб-аналитики способны утроить учет одного обращения.

Названия должны различать действие и статус. Код успешной отправки формы (form_success) описывает подтвержденную заявку, код квалификации лида (qualified_lead) обозначает его статус в системе учёта клиентов, а код оплаты (sale_paid) относится к продаже. В документации указывают точное условие и обязательные параметры. Тогда разработчик, аналитик и менеджер говорят об одном событии.

Удаление старой цели проводят после периода проверки. Сначала назначают ей дополнительную роль (Secondary), сравнивают новый и старый учет, затем исключают из отчетов. Резкое удаление без снимка настроек осложняет сравнение истории.

Подготовьте сценарии для каждой формы, телефона, мессенджера и домена. Тест содержит время, устройство, браузер, страницу, метки перехода (UTM), контакт и ожидаемый результат. Используйте отдельный тестовый контакт, который легко найти в системе учёта клиентов и рекламном отчете.

Первый тест проверяет успешную заявку. Второй повторяет отправку в том же сеансе и выявляет дубль. Третий вызывает ошибку обязательного поля. Четвертый проверяет отказ пользователя от файлов, которые сайт записывает в браузере (cookie), согласно настройкам режима согласия. Для одностраничного приложения (SPA) дополнительно проверяют переход на другой экран без перезагрузки.

На каждом уровне нужен свой идентификатор (ID). Событие сайта получает идентификатор события (event_id), система учёта клиентов создает идентификатор лида (lead_id), а продажа получает идентификатор транзакции (transaction_id) или иной уникальный ключ. Повторная передача одного статуса должна обновить существующую запись либо отклонить дубль по правилам системы.

Проверьте задержку. Событие может появиться в отладочном режиме сразу, в стандартном отчете позже, а импорт из системы учёта клиентов пройдет по расписанию. В акте приемки запишите ожидаемое время появления данных, чтобы задержка обработки не считалась потерей.

Тест завершается после сверки интерфейса, системы учёта клиентов и рекламной платформы. Скриншот одного тега подтверждает только его запуск. Для приемки нужны запись лида, записанный идентификатор, верный статус, отсутствие дубля и появление конверсии после обработки.

Выберите один завершенный период и выгрузите расходы, рекламные конверсии, события веб-аналитики, лиды из системы учёта клиентов, квалифицированные лиды, сделки и оплаты. Сравните числа по кампаниям и формам. Общая сумма может скрыть дубль одной формы и потерю другой.

Для каждого расхождения установите причину: атрибуция, дата, окно конверсии, режим согласия, задержка импорта, повторное обращение, дубль, пропущенный идентификатор или отсутствие статуса. Обоснованная разница остается в отчете с пояснением. Дефект получает ответственного и срок исправления.

Установите контрольные отклонения по уровням. Резкий рост событий успешной отправки формы (form_success) без роста числа лидов в системе учёта клиентов указывает на дубль или потерю передачи. Стабильные лиды при падении импорта продаж указывают на сбой связи с системой учёта клиентов. Рост рекламных конверсий при прежнем расходе и отсутствии заявок требует немедленной проверки целей.

После изменения цели запишите дату, прежнюю роль, новую роль и кампании, которые используют действие. Первые отчеты после правки подписывают как переходный период. Исторические данные остаются по прежней методике и не смешиваются с новой серией без примечания.

Отчёт рекламного кабинета показывал 213 конверсий за 30 дней и показатель «стоимость лида» (CPL) 1 540 ₸, рассчитанный по тогдашним целям кампании. В системе учёта клиентов за тот же период зарегистрировано 17 лидов и 4 сделки. Показатель 1 540 ₸ нельзя считать стоимостью одного из этих лидов. Разница между числом рекламных конверсий и числом зарегистрированных лидов составляла 196.

Проверка обнаружила клик по кнопке в основных целях, дубль события при отправке формы, отсутствие тега связывания конверсий (Conversion Linker) и импорта статусов из системы учёта клиентов. Команда перевела основное действие на подтвержденную отправку, настроила защиту от дублей, улучшенные конверсии для потенциальных клиентов и импорт статусов из системы учёта клиентов.

Через четыре недели рекламный кабинет показывал 49 конверсий, а система учёта клиентов содержала 44 лида и 11 сделок. Расхождение сократилось с 196 до 5, то есть на 97,4%. Новая стоимость лида не публикуется, потому что расход второго периода в исходных данных отсутствует. Любой расчет без расхода был бы недостоверным.

Рост сделок с 4 до 11 относится к двум сравниваемым периодам и требует учета сезонности, бюджета и созревания лидов. Главный установленный результат состоит в устранении ложных событий и сближении рекламного учета с данными о лидах и сделках.

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

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

Настройка одного домена и одного рекламного аккаунта занимает 5-15 рабочих дней при своевременных доступах. Стандартный проект стоит 180 000-420 000 ₸. Проекты с несколькими доменами, сложной системой учёта клиентов или серверной передачей начинаются от 420 000 ₸.

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

Приемка включает тестовые идентификаторы, снимки настроек, отсутствие дублей, запись в системе учёта клиентов, передачу статуса и сверку отчетов после задержки обработки. Первый месяц полезно проводить еженедельный контроль форм, лидов, квалификации и импорта.

Для проверки обычно нужны права чтения или редактирования в рекламном кабинете, веб-аналитике, диспетчере тегов, сервисе для контроля сайта в поиске Google (Search Console), системе учёта клиентов и системе управления сайтом. Список зависит от дефекта. Выдавайте доступ через рабочие аккаунты с минимально достаточной ролью, включайте двухфакторную защиту и фиксируйте владельца каждого ресурса.

Пароли, резервные коды и файлы браузера (cookie) не передаются подрядчику. После завершения работ удалите временные роли и запишите список действующих пользователей. Изменения в диспетчере тегов публикуют отдельной версией с названием и описанием.

Тестовые контакты не должны попадать в продажи и отчет по лидам. Помечайте их в системе учёта клиентов, но не удаляйте до приемки, чтобы идентификаторы и события оставались проверяемыми.

Системы используют разные источники, даты, атрибуцию и задержку обработки. Сравните одну единицу учета и один период, затем отдельно запишите обоснованные различия.

Выберите один основной источник для конкретного результата. Прямой тег дает настройки рекламной конверсии, импорт из веб-аналитики использует событие аналитики. Второй вариант можно оставить для наблюдения без дубля в основных целях.

Один человек может отправить форму повторно после одного рекламного клика. Правило «одна конверсия» (Count One) не увеличивает число конверсий этого действия из-за повторной отправки после того же клика. Для нескольких оплаченных покупок чаще подходит правило «каждая конверсия» (Every).

Он передает выбор пользователя и может поддерживать моделирование при выполнении требований Google. Система учёта клиентов остается источником зарегистрированных лидов и продаж, а моделируемые данные отмечаются отдельно.

Запишите рекламный идентификатор и идентификатор лида, затем передавайте квалификацию и продажу через улучшенные конверсии для потенциальных клиентов, Менеджер данных Google или другой поддерживаемый способ. Проверьте защиту от дублей, сумму, валюту и задержку.

Для настройки целей, статусов клиентов, импорта продаж и единого отчета закажите сквозную аналитику и систему учёта клиентов в Метриум. Если учет уже проверен, но конверсия кампаний падает, используйте список проверок рекламной кампании.