Платёжный сервис стал источником продажи: диагностика

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

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

Снимите четыре точки одного пути

Сначала сохраните исходный адрес и событие входа. Затем проверьте состояние перед уходом к оплате, адрес возврата и событие покупки. Сопоставляйте один уровень источника: например, сессионный, если именно он вызвал вопрос. GA4 разделяет user, session и event scope; переход между разными полями отчёта не показывает, что источник «перезаписался».

Условный журнал проблемного пути 10:00:00 — вход на shop.example из demo / cpc. Разрешённая идентичность: U7; сессия: S1. 10:02:00 — оформление; U7, S1; источник сессии: demo / cpc. 10:02:10 — переход на pay.example; начало тестовой оплаты. 10:03:10 — возврат в магазин; referrer: pay.example. В событиях магазина: U8, S2. 10:03:12 — purchase, transaction_id: demo-001. После обработки — session source / medium: pay.example / referral.

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

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

Выберите ветку по устройству оплаты

Если pay.example — чужой платёжный сервис, который лишь возвращает покупателя, проверьте unwanted referrals. Google прямо приводит сторонних платёжных провайдеров как пример. Условие исключения должно соответствовать подтверждённому домену; исключать все внешние переходы незачем.

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

Если оформление проходит на двух ваших доменах, проверяется другая ветка: cross-domain measurement. Google описывает общий tag ID одного веб-потока и передачу идентификаторов через _gl. На чужом платёжном сайте нельзя создать такую настройку одним добавлением домена в список: требуется поддерживаемая реализация на измеряемых сторонах.

Проверьте штатные ссылки, формы и редиректы с учётом согласия. Исключение referral не склеивает cookie; cross-domain не разрешает обходить отказ пользователя. Если источник неверен ещё на первой строке, сначала выполните проверку входного редиректа.

Повторите маршрут и сравните записи

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

10:00:00 — вход: U7, S1, demo / cpc. 10:02:00 — перед оплатой: U7, S1. 10:03:10 — возврат: U7, S1; платёжный referrer не стал новым источником. 10:03:12 — purchase: demo-002, одно событие. После обработки — то же выбранное поле отчёта: demo / cpc.

Это ожидаемый пример при данных условиях, а не универсальное обещание одной сессии после любой длительности оплаты. Состояние, время и конфигурация должны входить в протокол. Отдельно проверьте обновление страницы подтверждения и другой доступный способ оплаты.

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