Проверить, где именно расходятся данные о заявках
Заказчик – B2B-компания, которая получает заявки с сайта и использует Google Ads как один из основных каналов привлечения.
В отчётах сайта, Google Analytics 4, Google Ads и CRM количество заявок различалось. По общей статистике было невозможно понять, сколько обращений действительно поступило, сколько корректно зафиксировала аналитика и какие данные использовались для оценки рекламы.
Для аудита взяли период 45 дней и сопоставили четыре источника:
→
GA4
→
Google Ads
→
CRM
За эталонную точку приняли успешную обработку заявки сервером сайта. То есть не нажатие кнопки и не открытие страницы благодарности, а факт, что форма прошла проверку и сайт подтвердил её отправку.
Уже на первом сопоставлении стало видно: речь идёт не об одном расхождении. GA4 считал больше фактически отправленных заявок, CRM получал меньше, а Google Ads одновременно содержал и лишние конверсии, и пропущенные рекламные обращения.
Сначала определили фактическое количество заявок
В качестве контрольного слоя использовали журнал успешных отправок на стороне сайта.
За анализируемые 45 дней сервер подтвердил 186 уникальных заявок. Именно от этого числа дальше проверяли GA4 и CRM.
На момент аудита постоянного идентификатора заявки, проходящего через все системы, не было. Для сверки обращения сопоставили по времени отправки, форме и обезличенным контактным данным.
Так агрегированные цифры превратились в конкретные записи, и стало видно, на каком этапе теряется или дублируется каждая заявка.
Почему GA4 показывал 201 конверсию при 186 заявках
В GA4 за тот же период было зарегистрировано 201 событие отправки формы. Их разобрали поштучно.
Проблема работала сразу в обе стороны: GA4 одновременно завышал число конверсий и пропускал часть реальных заявок.
Откуда появились лишние события
Проверка настройки формы и событий показала две причины.
В одном из сценариев конверсия могла регистрироваться после действия пользователя до окончательного подтверждения успешной записи заявки на сервере.
Часть заявок могла повторно фиксироваться при повторном открытии или обновлении завершающего состояния формы.
→
событие аналитики
→
ошибка отправки
Для GA4 конверсия уже произошла. Для бизнеса заявки не существовало.
CRM потеряла семь подтверждённых заявок
Следующим этапом сопоставили серверный журнал с CRM.
Причина уже находилась не в аналитике. Сайт заявку принял, но карточка лида в CRM не появилась.
При проверке интеграции обнаружили, что обработка неуспешной передачи не гарантировала повторную отправку. Если интеграция получала ошибку или не дожидалась нормального ответа CRM, часть обращений могла остаться только на стороне сайта.
Аналитика могла показать конверсию, сайт мог принять заявку, но отдел продаж её не получал.
Проверка Google Ads дала ещё одно расхождение
Из 186 подтверждённых обращений 103 относились к трафику Google Ads по данным рекламных идентификаторов и источника перехода.
При этом Google Ads показывал 111 конверсий.
Одновременно из 103 фактических рекламных заявок 7 не удалось корректно связать с конверсией Google Ads.
Лишние события частично компенсировали пропущенные, поэтому итоговая сумма выглядела правдоподобно. Это и есть одна из причин, почему одних агрегированных цифр недостаточно.
Две дополнительные потери данных находились уже внутри CRM
CRM-лидов без достаточного источника
15,64% карточек не позволяли однозначно восстановить рекламный источник.
структурированная квалификация лидов
67,60% лидов имели формализованный результат первичной квалификации.
В первом случае рекламные параметры не сохранялись как постоянные данные заявки. Пользователь мог прийти по рекламе, перейти на другую страницу, вернуться позже и отправить форму, а в CRM уже попадала карточка без полноценной связки с первоначальным переходом.
Во втором случае бизнес уже знал качество лида, но аналитическая цепочка заканчивалась на факте «форма отправлена».
Что было нормальным различием, а что – ошибкой измерения
Цель аудита не состояла в том, чтобы механически сделать одинаковое число во всех системах. Сначала разделили методологические различия и реальные технические ошибки.
| Нормальное различие | Ошибка измерения |
|---|---|
| Google Ads и GA4 могут по-разному относить конверсию к дате. | Событие срабатывает до успешной отправки. |
| Разные модели атрибуции распределяют ценность по-разному. | Одна заявка фиксируется повторно. |
| Отличаются доступные каналы атрибуции. | Реальная заявка отсутствует в GA4. |
| Возможна разница часовых поясов. | Заявка сайта не создаётся в CRM. |
| Учитываются разные окна конверсии. | Теряется рекламный идентификатор. |
| Отчёты обновляются с задержкой. | Квалификация остаётся только в комментарии. |
Главный результат – одна заявка вместо четырёх несвязанных отчётов
После поштучного сопоставления картина стала выглядеть так:
→
182 корректно в GA4
→
179 дошли до CRM
Для рекламного сегмента:
→
96 корректно сопоставлены
При этом верхнеуровневые отчёты показывали 201 событие GA4 и 111 конверсий Google Ads. Основные проблемы скрывались не в итоговых суммах, а внутри самих событий.
Перестроили схему измерения вокруг одной заявки
По результатам аудита подготовили новую схему учёта.
→
GA4
→
Google Ads
→
CRM
→
квалификация
Разделили факт заявки и бизнес-результат
Вместо одного общего конверсионного действия предусмотрели несколько уровней.
→
лид создан в CRM
→
лид квалифицирован
→
лид стал клиентом
Само успешное отправление формы остаётся важным аналитическим событием. Но для оценки и оптимизации рекламы основная ценность переносится на квалифицированный или конвертированный лид.
Что передали заказчику
Четыре системы стали одной проверяемой цепочкой
До проверки сайт, GA4, Google Ads и CRM фактически отвечали на разные вопросы.
После аудита появилась единая контрольная точка – конкретная заявка, которую можно провести через всю цепочку.
Связанные материалы VozniNet
Нужно проверить, где теряются или дублируются ваши конверсии?
Сверим сайт, аналитику, рекламные системы и CRM, отделим нормальные различия атрибуции от технических ошибок и подготовим схему корректного учёта заявок.

