У события несколько владельцев
O-17 отправлен из GTM, кода сайта и при перезагрузке. Оставить один согласованный путь отправки и защитить его от повторной обработки оплаты.
Выручка есть.
Доверие —
под вопросом.
Как проверить цифры,
прежде чем менять
рекламный бюджет
Четыре оплаченных заказа. Семь отправок purchase. И только один заказ проходит строгую сверку с первого раза.
Открыть журнал событий ↓01 / БИЗНЕС-ВОПРОСНа какие цифры
На какие цифры
можно опереться?
Если измерение сломано, оптимизация рекламы может усиливать ошибку.
В этом сценарии сначала сверяем события с реестром заказов. Затем определяем дефекты и критерии приёмки исправлений. Результат — понятный план восстановления измерения.
Решение для бизнеса
Не менять бюджет на основании дефектного потока purchase. Для оценки оплаченных заказов использовать сверенный реестр с согласованными правилами учёта.
02 / ИНТЕРАКТИВНАЯ СВЕРКАНайдите расхождения.
Найдите расхождения.
Проверьте исправления.
«После» — ожидаемый журнал в исправленной модели. Это локальная демонстрация, а не результат внедрения или отчёт из GA4.
Загрузка тестовой выборки…
| Событие | transaction_id | value | currency | Источник | Проверка |
|---|
Что обнаружил валидатор
Открыть реестр заказов — источник для сверки
| Заказ | Статус | Стоимость товаров, ₽ |
|---|
4 оплаченных заказа на 18 400 ₽. O-21 ожидает оплаты и не входит в выручку. В тесте доставка, налоги и скидки равны нулю.
Сверенный заказ: ровно одно событие с совпадающими ID, суммой и валютой. Это строгий критерий качества отправки, а не правило подсчёта покупок в GA4. Числа в value с разными валютами не суммируем.
Семь отправок ≠
семь покупок в отчёте.
В веб-потоках GA4 использует transaction_id для дедупликации покупок. Поэтому журнал отправок сам по себе не показывает, какой окажется выручка в отчёте. Пустой ID также недопустим: документация отдельно предупреждает о дедупликации событий с пустой строкой.
Здесь проверен локальный журнал. Фактические покупки и выручку в GA4 нужно проверять отдельно после обработки данных.
Правила transaction_id в документации Google ↗03 / ДИАГНОЗШесть типов дефектов.
Шесть типов дефектов.
Разные способы исправить.
Покупку нельзя надёжно связать с заказом
E3 не проходит контракт. Отправку с пустым ID блокировать, причину фиксировать в техническом журнале.
Копейки стали рублями
У E3 value=490 000 вместо 4 900. Связь с O-17 известна из тестового контекста, не из transaction_id. Привести единицы до формирования события.
Оплата не дошла до журнала
O-19 оплачен, события нет. Проверить цепочку подтверждения оплаты и доставки события. Причина пропуска этим набором не установлена.
Рублёвый заказ подписан как USD
O-20: значение суммы совпадает, валюта — нет. Брать её из того же источника, что и стоимость заказа.
Создание заказа приняли за оплату
O-21 ещё не оплачен. По контракту этого магазина purchase отправляется только после подтверждения оплаты.
P1 — блокирует использование этого потока для решений о выручке в рамках кейса. Приоритеты для реальной системы согласуются с командой. Семь замечаний — не семь независимых ошибок выручки.
04 / КОНТРАКТ ИЗМЕРЕНИЯОдна оплата.
Одна оплата.
Один устойчивый ID.
Когда отправлять
После подтверждённого перехода заказа в статус paid. Не по клику на кнопку и не просто при открытии страницы «Спасибо».
Откуда брать данные
ID, валюту, товары и суммы — из подтверждённого заказа. value согласовать с суммой price × quantity товаров; доставку и налог передавать отдельно, если они есть.
Что защищать
Один владелец отправки. Устойчивая идемпотентность по заказу в выбранной архитектуре. Для повторных попыток сохранять тот же ID; не генерировать новый.
ПРИМЕР СОГЛАСОВАННОГО PAYLOAD
dataLayer.push({ ecommerce: null });
dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: 'O-17',
value: 4900,
currency: 'RUB',
items: [{
item_id: 'SKU-17',
item_name: 'Товар A',
price: 4900,
quantity: 1
}]
}
});Пример payload для GTM. Он не реализует подтверждение оплаты, доставку события и защиту от повторов.
Почему недостаточно флага в localStorage
Он ограничен браузером, может быть очищен и не решает повторные уведомления платёжной системы. Сама отправка в сеть и её подтверждение также могут расходиться. Поэтому проектируют идемпотентную обработку, журнал попыток, повторы и последующую сверку; обещание «ровно одна доставка» здесь не даётся.
05 / ПРИЁМКАКак понять,
Как понять,
что исправление работает
| Проверка перед релизом | Ожидаемое поведение |
|---|---|
| Успешная оплата | Один корректный purchase; ID, сумма, валюта и товары совпадают с заказом |
| Перезагрузка и повторный вход на «Спасибо» | Не создают новую покупку и новый transaction_id |
| Повторное уведомление об оплате | Идемпотентная обработка; при повторе доставки используется прежний ID |
| Отказ или ожидание оплаты | purchase не отправляется по контракту сценария |
| Пустой ID или неверные единицы | Валидация отклоняет payload; есть диагностическая запись |
| Два разных оплаченных заказа | Два разных ID; второй заказ не подавляется |
| Тест браузера, согласия и сетевого сбоя | Поведение соответствует настройкам согласия; потери и повторы наблюдаемы |
| Сверка после обработки в GA4 | Проверены покупки и выручка в согласованном окне; расхождения объяснены |
Выполнено здесь
Локальные проверки модельного журнала: повторы, ID, сумма, валюта, статус оплаты и пропущенные заказы. Исправленный набор проходит их без замечаний.
Следующий шаг в реальном проектеGTM Preview → сетевые запросы → DebugView → обработанные отчёты и сверка с backend. Эти проверки на реальном ресурсе в кейсе не выполнялись.
06 / ВОСПРОИЗВОДИМОСТЬПроверить можно
Проверить можно
каждый вывод.
Сохраните четыре файла в одну папку и выполните node verify.mjs (Node.js 18+). Валидатор используется и в интерактивном журнале на этой странице.
Границы анализа
Синтетическая закрытая выборка, один завершённый интервал теста, без задержек и часовых сдвигов. В реальной сверке нужно согласовать окно, статусы, налоги, доставку, скидки, возвраты, валюты, доступность измерения и задержки обработки. Не все заказы обязаны наблюдаться в браузерной аналитике: блокировки и настройки согласия требуют отдельного учёта.
Строки after заданы как эталон. Это не восстановление потерянных событий и не автоматическое исправление истории GA4. Валидатор проверяет ограниченный контракт сверки; это не универсальный валидатор всех параметров GA4.