Почему GA4 считает платёжный сервис источником заказа?

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

Как проверить, что GA4 приписывает заказ платёжному сервису?

Откройте отчёт «Привлечение трафика» и выберите измерение «Источник / канал сеанса». Названия разделов могут отличаться в зависимости от языка интерфейса. Найдите домен страницы оплаты и проверьте, есть ли у этой строки события purchase. Это событие обычно используют для передачи покупки в GA4.

Если рядом с платёжным доменом указан канал referral, аналитика связала сеанс с переходом по ссылке с этого сайта. Но домен в параметре page_referrer означает только адрес предыдущей страницы. Сам по себе такой параметр не говорит, кому GA4 приписал продажу.

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

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

Почему источник рекламы теряется после оплаты?

Представим обычный сценарий интернет-магазина: покупатель приходит по рекламе, оформляет заказ и уходит на внешний сайт для оплаты. Затем платёжная страница возвращает его в магазин. Если GA4 воспринимает этот возврат как отдельный визит с внешнего сайта, платёжный домен попадает в отчёт как источник.

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

Начните с рекламной ссылки. В ней должны быть понятные сведения об источнике и кампании: utm_source, utm_medium и utm_campaign. UTM-метки помогают аналитике разделять рекламные переходы по источникам и кампаниям. Это исходная точка проверки: если реклама не размечена и автоматическая разметка не передаёт нужные данные, сохранять после оплаты будет нечего (источник: «UTM-метки для рекламы»).

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

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

Как исключить платёжный сервис из нежелательных переходов?

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

1. Откройте администрирование нужного ресурса GA4 и выберите веб-поток своего магазина в разделе «Потоки данных».
2. Перейдите в настройки тега Google и найдите список нежелательных переходов. Если пункт скрыт, раскройте дополнительные настройки.
3. Добавьте условие для фактического домена, с которого покупатель возвращается после оплаты.
4. Сохраните правило и зафиксируйте момент изменения для последующей проверки.

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

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

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

Как проверить источник заказа после изменения настроек?

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

1. Откройте внешнюю тестовую ссылку с UTM-метками в отдельном профиле браузера.
2. Пройдите оформление заказа до возврата с платёжной страницы.
3. Найдите событие purchase в режиме отладки и проверьте transaction_id.
4. После обработки данных проверьте источник сеанса с этой покупкой в отчёте.

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

Рабочий результат выглядит так: покупка поступает с нужным идентификатором, а возврат с оплаты не становится нежелательным реферальным источником. При этом ожидаемый источник зависит от всего пути пользователя. Для теста с единственным рекламным входом проверяйте, сохранился ли именно он.

Если одна покупка появляется повторно, сначала разберите отправку события. Например, тег может срабатывать при каждом обновлении страницы подтверждения. Для такой проверки полезен разбор дублей событий GA4 и Метрики через GTM.

Когда источник теряется на разных этапах, задачу лучше оформить как аналитический аудит. Его конкретный результат — схема пути заказа, перечень разрывов и задания на исправление. Для работы понадобятся доступ к настройкам аналитики, пример проблемного заказа и описание того, как сайт отправляет purchase.

Типичные ошибки при настройке источника покупки

• Добавлять UTM-метки на внутренние ссылки магазина. Такая разметка вмешивается в данные об источнике; для внутренних переходов используйте события.
• Считать любой платёжный домен в page_referrer ошибкой атрибуции. Сначала проверьте источник сеанса с покупкой.
• Исключать все реферальные переходы. Так можно скрыть полезные источники трафика; добавляйте только домены, роль которых установили.
• Ждать исправления старых заказов после изменения настроек. Проверяйте новые покупки отдельно от исторических данных.
• Ограничиваться исключением домена, когда purchase теряет связь с сеансом. Проверьте передачу идентификаторов и работу тега на странице возврата.

Следующий шаг на две минуты: откройте в GA4 отчёт «Привлечение трафика», выберите «Источник / канал сеанса» и найдите домен своего платёжного сервиса.