Коротко: когда браузер и сервер отправляют одну покупку без общего идентификатора, рекламная платформа может получить две конверсии вместо одной. Для Meta обе доставки связывают одинаковые
event_nameиevent_id. В GA4 повторные web-покупки сокращает уникальныйtransaction_id. После настройки цифры нужно сверить с магазином или CRM — наличие параметра ещё не доказывает правильный счёт.
В рекламном кабинете может быть больше покупок, чем в магазине. Команда видит низкий CPA, повышает рекламный бюджет, а выручка не растёт в том же темпе. Иногда причина находится не в кампании, а в том, что один заказ пришёл через Pixel и CAPI как два отдельных события.
Дубли и пропуски искажают решения по-разному. Двойной счёт может создать уверенность, что реклама приносит больше подтверждённых продаж; отсутствие событий может скрыть результат. Универсальной доли таких ошибок нет.
Почему Meta и Google получают дубли событий
В гибридной архитектуре одно действие доставляется несколькими маршрутами:
- Browser event: JavaScript на сайте отправляет Pixel- или GA4-событие.
- Server event: backend, GTM Server Container или партнёрская интеграция отправляет то же действие через API.
Без общего ключа получатель не может надёжно понять, что это две доставки одного заказа.
Для Meta типовой случай — Purchase из Pixel и Purchase из Conversions API. Для Google Analytics 4 дубли появляются, если одна покупка уходит из web tag и затем повторно через server-side маршрут или Measurement Protocol без стабильного transaction_id.
Но архитектура — не единственная причина. Дубль также создают:
- повторная загрузка thank-you page;
- повторный webhook платёжной системы;
- две активные интеграции CMS;
- повторная отправка запроса после timeout;
- разные правила создания события в браузере и backend;
- тестовая конфигурация, оставленная рядом с production-тегом.
Позиция Canem Errant: сначала найдите все источники одной конверсии, затем настраивайте дедупликацию. Иначе новый параметр маскирует часть проблемы, но не устраняет её.
Что такое event_id и как Meta использует его для дедупликации
event_id — уникальный идентификатор конкретного события. Для browser- и server-копии одной конверсии должны совпадать:
event_name;event_id.
Общий ключ описан в архивном Direct Integration Playbook Meta. Обе доставки должны идти в один dataset. Отправляйте их своевременно и проверяйте актуальные правила своей интеграции: одинаковые строки не гарантируют подавление любого позднего retry.
Pixel: event name = Purchase, eventID = purchase_789
CAPI: event_name = Purchase, event_id = purchase_789
Обе доставки относятся к одному событию.Для GA4 transaction_id относится к покупке как к бизнес-транзакции. Google указывает, что Analytics дедуплицирует web-покупки с одинаковой transaction_id; идентификатор должен быть уникален для заказа, не использоваться у разных покупателей и не содержать персональные данные. Подробности — в справке Minimize duplicate key events with transaction IDs.
| Платформа | Идентификатор и область проверки |
|---|---|
| Meta Pixel + CAPI | Одинаковые event_name и event ID, один dataset; browser eventID и server event_id. |
| GA4 web stream | Непустая transaction_id одного заказа; проверяется обработанная покупка. |
| Магазин / CRM | Подтверждённый заказ, заявка или сделка, сумма, валюта и возврат. |
event_id и transaction_id могут совпадать для простой покупки, но выполняют разные задачи. Главное — не генерировать новый идентификатор при повторной доставке того же действия.
Как реализовать общий event_id
Реализация состоит из трёх частей: источник события, browser-тег и server-тег.
Шаг 1. Создайте ID в исходной системе
Для покупки надёжным источником обычно является backend или подтверждённый order ID. Страница получает уже созданное значение и не меняет его после перезагрузки.
// The backend has already confirmed the order and created its stable ID
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'purchase',
event_id: `purchase_${orderData.id}`,
ecommerce: {
transaction_id: orderData.id,
value: orderData.total,
currency: orderData.currency,
items: orderData.items,
},
});Проверьте непустую уникальную ID заказа до применения учебного кода. Для формы или другого события можно создать UUID один раз на сервере или в приложении и сохранить его для обеих отправок и повторов. Date.now или новый случайный ID при каждой доставке меняют идентичность действия. Создание в GTM само по себе не является ошибкой; ошибка — независимая генерация разных значений.
Шаг 2. Передайте ту же ID в Pixel
В web container прочитайте event_id из dataLayer и передайте её в параметре eventID соответствующего Pixel event. Не создавайте новое случайное значение внутри каждого тега.
Шаг 3. Передайте ту же ID в CAPI
Server container или backend получает уже существующую event_id и отправляет её в Meta вместе с тем же event_name.
Ключевое правило: идентификатор создаётся один раз в системе, которая знает о бизнес-событии, а затем переносится через оба канала. Это может быть backend, storefront или общий event service — важно не конкретное место, а единый источник значения.
После реализации проверьте повторную загрузку страницы, retry запроса и повторный webhook. Одна и та же покупка должна сохранять один идентификатор.
Как дедуплицировать покупки в Google Analytics 4
Для GA4 передавайте одну и ту же уникальную transaction_id во всех копиях purchase этого заказа. Документированное правило относится к web streams, не app streams. При совместной отправке браузером и Measurement Protocol проверьте всю реализацию и обработанные покупки: универсальное окно 24 часа или одинаковое поведение всех экспортов здесь не предполагается.
Практические правила:
- Используйте order ID из магазина, а не ID сессии.
- Не добавляйте новый timestamp или случайный suffix при повторной отправке.
- Не отправляйте пустую строку: Google предупреждает, что одинаковая пустая
transaction_idможет привести к неправильной дедупликации. - Не включайте email, телефон, имя или другие персональные данные.
- Передавайте идентификатор внутри параметров
purchaseкак в web-, так и в server-side маршруте.
GA4-дедупликация с transaction_id относится к web streams и покупкам. Она не заменяет idempotency на стороне магазина, обработку webhook и контроль повторных заказов.
Если два события видны в DebugView, это ещё не доказывает двойной учёт в итоговых отчётах. Для проверки используйте стабильный тестовый order ID, дождитесь обработки данных и сопоставьте результат с магазином.
Какие ошибки ломают дедупликацию чаще всего
| Ошибка | Что происходит | Что проверить первым |
|---|---|---|
event_id отсутствует | Meta не может связать Pixel и CAPI | Payload обеих доставок |
| ID генерируется отдельно в двух тегах | Значения различаются | Где именно создаётся ID |
| К ID добавляется новый timestamp | Retry становится новым событием | Стабильность значения после повторной отправки |
Совпадает ID, но не event_name | Meta видит разные типы событий | Регистр и название события |
| ID есть только в Pixel или только в CAPI | Второй канал не имеет ключа | Mapping server tag |
transaction_id пуста или повторяется у разных заказов | GA4 может недосчитать или неверно объединить покупки | Источник order ID |
| Purchase запускается до оплаты | Технически уникальное событие не равно продаже | Бизнес-условие создания события |
| Работают две CMS-интеграции | Одна покупка отправляется несколько раз разными системами | Полный список тегов, приложений и webhooks |
Отдельно проверьте названия: для Meta Purchase и purchase могут оказаться разными событиями, даже если ID совпадает. Один формат должен быть закреплён в спецификации интеграции.
Как проверить дедупликацию
В Meta Events Manager:
- Откройте Test Events для нужного dataset.
- Выполните контролируемую тестовую покупку или другое безопасное тестовое действие.
- Найдите browser- и server-доставку.
- Сравните
event_nameиevent_id. - Проверьте diagnostics и статус обработки события.
В server logs и GTM Preview:
- найдите входящий запрос по ID;
- убедитесь, что retry сохранил значение;
- проверьте, какой tag отправил событие;
- исключите второй container, plugin или webhook;
- не выводите access token и персональные данные в открытый журнал.
В Google Analytics 4:
- проверьте
purchaseиtransaction_idв DebugView; - не делайте вывод только по Realtime;
- после обработки отчёта сравните заказ с данными магазина;
- убедитесь, что одна
transaction_idне используется у разных заказов.
В бизнес-системе:
Составьте таблицу из четырёх колонок: order ID, магазин/CRM, Meta, GA4. Начните с нескольких конкретных заказов. Согласуйте период, часовой пояс, оплату и возвраты. Приписанные рекламе заказы — отдельная группа по правилам атрибуции; она не обязана совпадать со всеми заказами магазина. Видимость двух доставок в Test Events или DebugView сама по себе не доказывает двойной обработанный результат. Проверьте отказ от consent: backend не должен обходить разрешённые цели.
Что изменится в отчётах после исправления
Если раньше часть покупок считалась дважды, количество конверсий в рекламном кабинете может снизиться, а CPA — вырасти. Само изменение счёта не доказывает ухудшение рекламы; реальный результат оценивается отдельно. Учебный пример: €1 000 расходов и 100 покупок дают CPA €10. После удаления 20 дублей остаётся 80 покупок, CPA — €12,50 при прежних расходах.
Размер изменения нельзя честно предсказать универсальным процентом. Он зависит от того, сколько источников отправляло события, как работал retry и какие заказы считались дважды.
Дальше оценивайте:
- количество и сумму заказов при согласованных определениях;
- долю browser- и server-событий с учётом blockers, consent и правил доставки;
- отсутствие повторов после reload и webhook retry;
- связь Meta-конверсий с подтверждёнными продажами;
- изменения CPA и ROAS только после стабилизации данных.
В текущей работе с чешским интернет-магазином Erkado мы настраиваем серверный трекинг и анализируем рекламные данные. Задача проверки: понять, какие действия учитываются и где события расходятся с заказами магазина. Подробнее о составе работы в кейсе Erkado.
Вывод: после дедупликации цифры могут выглядеть менее впечатляюще, но становятся пригоднее для решений. Цель — не сохранить красивый CPA, а связать рекламный отчёт с реальными заказами и продажами.
Часто задаваемые вопросы
Что такое дедупликация событий и зачем она нужна Meta Ads?
Она связывает browser- и server-копии одного действия, чтобы одна покупка не считалась дважды. Для Meta совпадают event_name и event_id.
Чем event_id отличается от transaction_id?
event_id идентифицирует конкретное событие и используется Meta для сопоставления Pixel и CAPI. transaction_id идентифицирует заказ и используется GA4 для дедупликации web-покупок и обработки e-commerce данных.
Где создавать event_id — на сайте или в GTM?
В системе, которая первой достоверно знает о событии: часто это backend или storefront. ID создаётся один раз, а GTM и CAPI только переносят её. Генерировать разные значения в web- и server-tag нельзя.
Как понять, что дедупликация сломана?
Сравните browser- и server-доставки одного действия в Meta Test Events. Проверьте совпадение имени, ID и dataset, затем обработанные покупки. Различия объёмов каналов и два видимых запроса сами по себе не доказывают причину; наличие параметра также не доказывает правильный счёт.
Уменьшится ли число конверсий после исправления?
Возможно, если раньше существовали дубли. Размер изменения зависит от конкретной ошибки. Снижение числа в кабинете не является потерей продаж, если оно приближает отчёт к подтверждённым заказам.
Если Meta, GA4 и магазин показывают разные результаты, выберите один подтверждённый заказ и проследите его ID по всем системам. Посмотреть услугу Tracking & CAPI или описать проблему.
