Менеджер видит новую заявку в CRM, разработчик показывает запись в dataLayer, а в аналитике события нет. Команда уже предлагает перенести отправку на сервер. Не спешите: сначала найдите место, где оборвался текущий путь. Иначе та же ошибка просто переедет в новый стек.
Запишите решения трёх заданий и то, чем вы сможете их подтвердить, а потом сравните с разборами. Сайт эти записи не оценивает. Данные условные; lead_sent и lead_submit придуманы для этого задания, в треке «Старт» события называются по-другому.
Ситуация 1: событие появилось, запрос не ушёл
После успешной отправки формы сайт записывает в dataLayer событие lead_sent. Нужный тег настроен на lead_submit. В режиме отладки событие видно, тег не сработал, сетевого запроса к получателю нет.
Выберите действие и объясните, что вы ожидаете увидеть после него:
- A: подождать, пока данные появятся в отчёте;
- B: согласовать имя события, исправить несовпадение и повторить отправку формы;
- C: сразу перенести отправку на сервер.
Событие есть, отправки нет
dataLayer
После формы записано lead_sent
Условие тега
Настроено на lead_submit
Имена не совпали, тег не сработал
Запрос получателю
Сетевого запроса нет
Сверить согласованное имя с разработчиком
Ситуация 2: рекламный отчёт и CRM расходятся
В рекламном кабинете 40 конверсий, в CRM за тот же календарный период 25 оплаченных заказов. Владелец считает, что система потеряла 15 продаж. Но кабинет считает конверсией отправку формы, а CRM считает оплаты.
Что можно сказать сразу? Какие определения, даты и записи вам понадобятся, прежде чем искать потерю данных? Составьте порядок сверки, который не начинается с попытки подогнать два итога друг к другу.
Ситуация 3: после соединения выросла выручка
В таблице заказов у заказа 101 сумма 10 000 ₸. В таблице позиций к нему относятся два товара. После соединения таблиц по ID заказа получилось две строки, и в каждой повторилась полная сумма 10 000 ₸. Отчёт сложил поле суммы заказа и показал 20 000 ₸.
Объясните, что произошло со строкой и какой результат нужен. Затем добавьте заказ 102: он тоже на 10 000 ₸, но у него одна товарная позиция. Сколько строк получится после соединения, какую сумму даст прежний расчёт и сколько выручки было в исходных заказах? Поможет ли суммирование только различных денежных значений?
Разбор 1: исправьте неподтверждённый переход
Правильный вариант - B. Data layer в GTM передаёт данные и события, на которые реагируют теги. Запись lead_sent подтверждает только этот шаг. Чтобы данные ушли дальше, должно выполниться условие триггера и сработать нужный тег.
Почему тег молчит, здесь уже известно: имя в условии не совпадает с именем события. Спросите разработчика, о каком имени договаривались. Если сайт правильно отправляет согласованное lead_sent, исправляйте триггер. Если договорились о lead_submit, исправлять нужно код сайта. Переименовать событие наугад в одном месте опасно: на старое имя могут опираться другие теги и отчёты.
После исправления снова отправьте форму. Посмотрите, сработал ли тег, ушёл ли запрос нужному получателю и совпадают ли параметры с тем, что вы ввели в форму. Потом убедитесь, что событие принято на стороне получателя и после обработки появилось в отчёте. На каждом шаге вы отвечаете на свой вопрос: статус «тег сработал» не говорит, верны ли адрес и данные и дошло ли событие до отчёта.
Вариант A не замечает главного: запроса нет, и ожидание его не создаст. Вариант C перестраивает систему, хотя разрыв уже найден в условии запуска. Серверная отправка решает другие задачи, а исправление имени можно проверить в текущей схеме, ничего не перестраивая.
Добавьте проверку от обратного: форма с ошибкой не должна давать событие успешной заявки, а повторное открытие страницы благодарности не должно превращать одну заявку в две. Нашли такие случаи - исправьте причину до публикации. Иначе число событий разойдётся с тем, что вы договорились называть заявкой.
Разбор 2: договоритесь, что считаете
Арифметика 40 - 25 = 15 верна, но «15 потерянных продаж» из неё не следует. Форма и оплаченный заказ - разные этапы. Один человек мог оставить несколько заявок, кто-то ещё выбирает, а кто-то заплатил уже в следующем месяце.
Для каждого отчёта выпишите событие, источник, правила, по которым результат относят к рекламе, дату, часовой пояс и то, как система обходится с повторами. Уточните, по какому времени построен период: по отправке заявки, по рекламному взаимодействию или по оплате. Затем выберите сопоставимое определение и окно, за которое заявки успевают дойти до оплаты. Длину окна берите из процесса продаж проекта: если менеджеры закрывают сделку за две недели, недельное окно занизит оплаты.
Чтобы проверить связь, нужны идентификаторы заявок и заказов, которые вам разрешено использовать. Пройдите несколько записей от формы до CRM: создана ли заявка, появилась ли оплата, была ли отмена, в какой период попала запись. Имена, телефоны и другие данные клиента, которые для сверки не нужны, в общий разбор не копируйте.
Если одна оплата не связалась с заявкой, это отдельное расхождение: у него есть место и причина, которые нужно найти. Остальную разницу не записывайте в ту же ошибку автоматически. Задача сверки - объяснить, из чего состоит разница. После неё отчёты могут показывать разные итоги, если по-прежнему считают разные вещи.
Разбор 3: верните расчёту единицу заказа
В исходной таблице одна строка была заказом. После соединения одна строка - товарная позиция. Полная сумма заказа повторилась на каждой позиции, и прямое сложение умножило деньги на число строк.
| Заказ | Сумма заказа | Позиций | Вклад в ошибочную сумму |
|---|---|---|---|
| 101 | 10 000 ₸ | 2 | 20 000 ₸ |
| 102 | 10 000 ₸ | 1 | 10 000 ₸ |
| Всего | 20 000 ₸ | 3 | 30 000 ₸ |
У заказа 101 выручка так и осталась 10 000 ₸. Для двух заказов верный итог 10 000 + 10 000 = 20 000 ₸, а прежний способ даёт 2 × 10 000 + 1 × 10 000 = 30 000 ₸. Новых оплат от соединения таблиц не появилось.
Выручку считайте по одной подтверждённой записи на каждый уникальный заказ. Есть и другой путь: если у товарных строк свои суммы и понятно, как учтены скидки, доставка и возвраты, сложите позиции и сверьте результат с итогом заказа. Но полная сумма заказа, скопированная в каждую строку, суммой позиции от этого не становится.
SUM(DISTINCT amount) не спасёт. В примере у разных заказов одинаковая сумма, и после удаления повторяющегося значения останется 10 000 ₸ вместо 20 000 ₸. Различать заказы нужно по ID, а не по сумме. Это стоит проверять и тогда, когда запрос пишет помощник: в анализе таблиц с ИИ синтаксически правильный запрос может считать не ту единицу строки.
Упражнение на своём проекте
Выберите одно событие и один отчёт своего проекта. Для события запишите, когда оно должно отправляться, его имя, обязательные параметры и получателя. Для отчёта определите, что означает одна строка и какое действие бизнеса попадает в итог. На каждом участке сохраните наблюдение по одной тестовой записи, которую вам разрешено использовать.
Если доступа к сайту клиента у вас нет, отработайте событие и тег в тренажёре с именами из этого упражнения. Потом посчитайте два заказа выше без подсказки и объясните, зачем при соединении таблиц сохранять ID.
По готовому разбору другой человек должен пройти тот же маршрут. Фраза «аналитика сломана» ничего не даёт исполнителю, а «событие есть, нужный тег не сработал, имя в условии отличается» сразу говорит, что исправить. К отчёту приложите исходный и полученный итог и объясните, откуда взялось число строк. После исправления повторите тот же пример, включая случай, когда событие отправляться не должно. Закрывайте задачу по результату, который увидели сами, а участок, который проверить не смогли, так и пометьте.