Аналитика и CRM

Дубли покупок в GA4: найдите отправителя и проверьте ID заказов

В GA4 больше покупок, чем в магазине? Проверьте отправителей, transaction_id, повторную загрузку и новые заказы по практической таблице тестов.

Vladlens Kecko · 2026-10-21 · 7 минут

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

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

1. Убедитесь, что проблема действительно в дублях

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

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

2. Найдите всех отправителей purchase

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

Используйте инструменты диагностики Google при согласованном тестовом оформлении. В DebugView выберите своё тестовое устройство и изучите параметры purchase. Предпросмотр тегов и журналы интеграции помогут определить отправителя; одного DebugView для этого может быть недостаточно.

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

3. Привяжите transaction_id к заказу

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

Согласуйте правила на уровне заказа:

• Завершённый заказ получает постоянный неперсональный ID из системы заказов.
• Повторная отправка сохраняет его; новый заказ получает другой ID.
• Не отправляйте константу или пустую строку и не используйте ID для несвязанных заказов или пользователей.
• Не включайте в идентификатор имя, email и другую персональную информацию.

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

4. Выполните повторяемую матрицу тестов

Это условный пример, а не результат клиента. В тестовом заказе TEST-A две позиции по €40: стоимость товаров составляет €80. Налог и доставку записывайте отдельно. Руководство Google по ecommerce объясняет параметры покупки и расчёт value.

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

5. Сверьте новые обработанные данные

Дождитесь обработки отчётов перед сравнением новых заказов с магазином. Руководство Google по диагностике рекомендует отводить стандартным отчётам 24–48 часов. Используйте одинаковые границы дат и часовой пояс, объясняя оставшиеся различия из-за согласия, возвратов и сбора данных.

Исправленный тег не переписывает историю. Зафиксируйте дату релиза в собственном журнале отчётности. Если сбор покупок уже исправен, но GA4 и Google Ads расходятся, сравните определения и область отчётов по руководству о расхождениях конверсий.

Чек-лист выпуска исправления

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

Нужна помощь с разделением проблем сбора, атрибуции и отчётности? Наша услуга по отслеживанию, атрибуции и CRM связывает эти проверки с решениями бизнеса. Запишитесь на бесплатный 30-минутный разбор роста с основателями и получите краткий письменный план из трёх приоритетов. Обязательства нанимать CPCInsider нет; объём внедрения согласуем отдельно.