Для веб-покупок GA4 transaction_id помогает не считать повторную отправку одного заказа новой продажей. Но пустая строка или постоянный демонстрационный номер способны скрыть разные покупки. Проверять нужно значение из реального заказа, а не наличие поля в шаблоне. Официальная справка проверена 27 октября 2026 года; описанный механизм относится к веб-потокам.

Определите источник номера в магазине

Идентификатор должен устойчиво соответствовать конкретной покупке и формироваться динамически. Не генерируйте новый случайный номер при каждом открытии страницы результата. Иначе обновление вкладки будет выглядеть как самостоятельная операция. Обсудите с разработчиком, из какой записи заказа берётся значение и на каком этапе эта запись уже подтверждена внутренней системой магазина.

Составьте учебную пару заказов A-101 и A-102. Первый должен сохранять A-101 при повторном открытии, второй обязан отличаться. Это не требование к формату номера, а проверка его смысла. Не помещайте в идентификатор имя, телефон или адрес клиента: для технической связи аналитики с внутренней записью достаточно отдельного неперсонального ключа.

Отдельно проверьте пустую строку

GA4 удаляет повторные веб-события purchase с одинаковым transaction_id; механизм не заявлен для потоков приложений. Документация отдельно предупреждает о transaction_id со значением пустой строки: такие покупки дедуплицируются. Поэтому значение, которое выглядит в коде как «поле заполнено позже», нельзя оставлять работающим поведением при ошибке получения номера.

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

Пройдите повторную загрузку и второй заказ

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

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

Сверяйте отдельные операции с учётной системой

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

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