Нежелательные переходы GA4: как убрать платёжный сервис из источников возврата
Как проверить список unwanted referrals в GA4, не перепутать его с междоменным отслеживанием и объяснить сохранение старых источников в отчётах.
Содержание статьи
Если после оплаты покупка приписывается платёжному сервису, в GA4 следует проверить нежелательные переходы — unwanted referrals. Это настройка атрибуции входящего перехода, а не способ получить события с чужого сайта. Инструкция для собственного интернет-магазина подготовлена по справке, проверенной 27 октября 2026 года; она не объявляет изменение правил платформы.
Подтвердите, откуда возник источник
Возьмите несколько конкретных заказов, для которых источник выглядит подозрительно. Сопоставьте время оплаты, возврат в магазин и адрес страницы перед возвратом. Провайдер может открывать разные домены для различных методов платежа. Один похожий текст в отчёте ещё не доказывает, что все такие посещения возникли в результате одной схемы оплаты.
До настройки сохраните контрольную выборку: заказ, маршрут, ожидаемый источник привлечения, фактически наблюдаемый переход. Не записывайте туда персональные данные покупателя без необходимости. Полезно отдельно проверить рекламные метки первоначального входа по руководству по UTM. Исключение платёжного домена не создаст утраченную метку кампании задним числом.
Настройте правило для подтверждённого домена
В параметрах Google tag соответствующего веб-потока откройте список нежелательных переходов. Условия списка работают как альтернативы: достаточно совпадения одного. Для совпавших событий GA4 применяет ignore_referrer, сохраняя измерение события, но не используя такой переход как источник. Начните с точной границы нужного платёжного адреса, а не с общего слова из названия компании.
Не добавляйте все внешние сайты продавца в исключения автоматически. Партнёрская публикация, рекламная площадка и платёжный шлюз выполняют разные роли. Если исключить настоящий канал привлечения, отчёт станет удобнее на вид, но хуже объяснит продажи. Зафиксируйте бизнес-причину каждого правила и пример маршрута, ради которого оно внесено в список.
Не путайте исключение источника с соединением посетителей
Unwanted referrals не устанавливает тег на сайт провайдера и не переносит идентификаторы между вашими доменами. Для витрины и отдельного собственного checkout нужна самостоятельная проверка междоменного отслеживания. Две настройки могут понадобиться одновременно, но успешность одной не подтверждает работу другой. Оценивайте их по различным наблюдаемым признакам.
Например, покупатель приходит по рекламной ссылке, оформляет заказ на втором домене магазина и платит у внешнего провайдера. Сначала проверьте связку двух собственных ресурсов, затем — возврат после платежа. Такая последовательность не гарантирует стопроцентного измерения, зато позволяет отличить потерю идентификации от неверно выбранного источника и избежать бессистемного расширения исключений.
Проверяйте новые визиты и сохраняйте историю решения
Возвращающиеся пользователи могут по-прежнему показывать прежний источник из-за ранее обработанных событий. Поэтому не требуйте, чтобы старый платёжный домен мгновенно исчез из всей истории. Сравните новые контрольные маршруты с зафиксированными условиями проверки. Для оценки изменений методики отметьте дату включения правила и не смешивайте периоды без пояснения в управленческом отчёте.
Если разработчик задаёт ignore_referrer вручную, отдельно проверьте сам факт присутствия параметра: справка предупреждает, что даже значение false означает игнорирование перехода. Не используйте такой код как универсальный выключатель на всех страницах. После смены провайдера пересмотрите список, удаляя только понятные устаревшие условия и сохраняя объяснение каждой действующей записи для следующего специалиста.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы