Кликнули — ещё не значит отправили

1. Начните с вопроса, на который нужен ответ

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

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

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

2. Что делает dataLayer

Это слой данных на странице: приложение помещает туда сообщения, а Google Tag Manager использует их для запуска тегов. В одном сообщении можно передать название события и его параметры. Важно добавлять данные через push, сохраняя существующий массив, и придерживаться одинаковых имён параметров.

Само сообщение не создаёт отчёт в GA4. Для этого нужны настроенные триггер и тег. На новой загруженной странице необходимые значения следует передать заново. Сообщения обрабатываются по очереди. Передавайте событие вместе с относящимися к нему параметрами: так тег получает нужные значения в нужный момент.

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

3. Договоритесь о событии до написания кода

Ниже — фрагмент для обработчика успешного результата. Он не отправляет форму и не проверяет ответ сервера самостоятельно. Разработчик должен встроить его в нужный участок приложения.

// Вызывать в обработчике подтверждённого создания заявки.
// Повторный вызов также добавит событие: защита от дублей — в приложении.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'lead_created',
  form_id: 'consultation_sidebar',
  service_type: 'analytics_audit'
});

Не добавляйте этот фрагмент прямо на клик по кнопке. И не вызывайте его на каждом показе сообщения «Спасибо»: повторное открытие окна не означает новую заявку.

Как связать пример с GA4 через GTM

1. Убедитесь, что в контейнере настроен Google tag для нужного потока GA4.
2. Создайте переменные уровня данных для form_id и service_type.
3. Создайте триггер «Специальное событие» с точным именем lead_created.
4. В теге события GA4 укажите generate_lead и передайте оба параметра из переменных. Подключите созданный триггер.

Внутреннее имя события сайта и имя события в GA4 могут различаться. Главное — зафиксировать соответствие. В теге указываются имя события и параметры, а триггер определяет, когда его отправлять. В нашем примере сообщение lead_created запускает передачу generate_lead в GA4.

Чтобы анализировать собственный параметр service_type в отчётах, создайте для него специальный параметр уровня события в GA4. Сначала убедитесь, что он действительно поступает. Google указывает срок 24–48 часов для появления данных в отчётах после настройки; мгновенного результата ожидать не стоит. Имя параметра в настройках должно точно совпадать с передаваемым: service_type. Его область действия — событие, потому что услуга относится к конкретному обращению.

4. Проверяйте не только успешный сценарий

В GTM Preview найдите lead_created, проверьте значения переменных и срабатывание нужного тега. Затем посмотрите исходящий запрос в инструментах браузера: событие должно уходить в выбранный поток. Срабатывание тега ещё не равно получению данных системой.

В GA4 откройте DebugView с включённым режимом отладки для тестового устройства и найдите generate_lead. Сверьте параметры. При ограничениях сбора данных или настройках согласия события могут не отображаться — это отдельная ветка диагностики. Включите отладку для своего устройства, выберите его в DebugView и повторите отправку формы. Откройте появившееся событие и проверьте значения параметров: одного названия события для проверки недостаточно.

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

5. Что легко упустить

Повторный ответ и повторная заявка — разные вещи

Защита от дублей должна учитывать конкретную операцию. Флаг «уже отправляли в этой сессии» может скрыть вторую настоящую заявку. Согласуйте с разработчиком, как различаются повторная обработка и новое обращение.

Успех HTTP-запроса не всегда означает успех бизнеса

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

Имя формы должно пережить смену дизайна

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

Отчёт о заявках ещё не показывает их качество

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

Продолжить изучение

Событие может отправляться в нужный момент, но содержать параметры предыдущего действия.