Аналитика и CRM

Платёжные рефералы в GA4: проверка атрибуции заказа

Платёжный сервис стал источником трафика в GA4? Проверьте возврат после оплаты, выберите нужную настройку и подтвердите результат с помощью журнала тестов.

Vladlens Kecko · 2026-10-16 · 7 минут

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

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

1. Запишите симптом до изменения настроек

Выберите обработанный отчётный период и сохраните ресурс, отчёт, измерение и затронутый домен. Исследуйте сеансы через Session source / medium. Не смешивайте этот вопрос с первым источником пользователя и атрибуцией события: Google объясняет различия в руководстве по области действия источников.

Сохраните текущую конфигурацию и уточните у владельца магазина реальные сценарии оплаты. Одного названия домена недостаточно для определения его роли.

2. Выберите настройку под реальный сценарий

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

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

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

3. Разберите вымышленный пример оплаты

Представим: покупатель пришёл из размеченной рассылки, оплатил через pay.example и вернулся в магазин. Аналитик видит pay.example / referral в отчёте по сеансам. Домен и ситуация вымышлены: это не инструкция для реального провайдера и не результат клиента CPCInsider.

Задача теста — подтвердить техническую роль pay.example, проверить реферальную настройку и повторить путь с той же контролируемой ссылки кампании. Успех означает, что новые обработанные данные отражают задокументированный путь без превращения этапа оплаты в отдельный источник привлечения. Это не означает, что любая модель атрибуции должна отдавать каждую покупку рассылке.

4. Проверьте весь путь, включая неуспешные сценарии

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

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

5. Подтвердите результат в обработанных данных

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

Исправится ли историческая атрибуция?

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

Вернутся ли все отсутствующие заказы?

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

Контрольный список перед выпуском

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

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

Нужна помощь с поиском разрыва атрибуции? Изучите нашу услугу аналитики, атрибуции и CRM или запишитесь на бесплатный 30-минутный разбор роста с основателями. Обсудим реализацию и подготовим три письменных приоритета; внедрение согласуем отдельно, без обязательства нанимать CPCInsider.