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

Отделите свои домены от внешнего платёжного интерфейса

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

Для поддерживаемой связки GA4 использует одинаковый идентификатор тега из одного веб-потока на участвующих доменах. В условиях согласия на cookies идентификаторы передаются через параметр _gl в ссылках или формах. Это задача сохранения измеряемого пути посетителя. Отдельная проблема источника возврата с платёжного сервиса разобрана в инструкции по нежелательным переходам.

Проверяйте конечный URL после всех перенаправлений

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

Сравните обычную ссылку, программную кнопку и отправку формы, если магазин применяет несколько маршрутов. JavaScript-навигация или обработчики, прекращающие распространение события, могут мешать автоматической передаче. Разработчику полезнее получить конкретную неработающую кнопку и последовательность адресов, чем общую формулировку «GA4 теряет клиентов». Сначала локализуйте место потери параметра, затем выбирайте техническое исправление.

Сопоставьте путь и покупку как разные результаты

Возьмите отдельный тестовый профиль браузера и один контрольный заказ. Запишите последовательность страниц, время переходов и результат оформления. Проверьте доступную цепочку событий на обеих сторонах. Успешное соединение посещений не подтверждает корректность суммы или единственность покупки: это самостоятельная проверка transaction_id в событии purchase.

Например, путь каталога к checkout виден непрерывно, но страница результата дважды отправляет заказ. Междоменная настройка в этом случае не является причиной всех расхождений выручки. И наоборот: корректная покупка может поступить при разорванной цепочке просмотров. Раздельные критерии позволяют исправить конкретную интеграцию и не менять работающую часть измерения без основания.

Закрепите проверку за изменениями оформления

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

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