-
Переход
Исходная рекламная ссылка
-
Заказ
ID и сохранённый источник
-
Оплата
Серверное подтверждение
-
Возврат
Сверка аналитики и CRM
Если после оплаты рекламный заказ оказался в переходах с сайта банка, сначала проверьте маршрут покупателя и правила атрибуции. Возврат с платёжной страницы может стать нежелательным реферальным переходом, но источник также меняют новые UTM, потеря идентификатора посетителя или логика записи полей в CRM.
Разделите три разных факта
Создание заказа, подтверждённая оплата и возвращение покупателя на сайт — разные события. Пользователь может оплатить и закрыть банковское приложение, не открывая магазин снова. Может вернуться после отмены платежа. Страница «Спасибо» сама по себе не подтверждает поступление денег.
Метрика определяет возврат из поддерживаемой платёжной системы по рефереру. Эта цель сообщает о переходе обратно, а не об успешной оплате. Финансовый статус заказа следует получать из проверенного серверного уведомления или предусмотренной провайдером проверки платежа. Связь ведите по устойчивому ID заказа.
Соберите цепочку одного заказа
Для согласованного теста используйте учебный товар и тестовый режим провайдера, если он доступен. Не публикуйте токены, полные платёжные ссылки и данные покупателя в отчёте. Запишите входную страницу, исходные UTM, ID заказа, переход к оплате, адрес возврата и источник, сохранённый в CRM.
Учебный пример: заказ DEMO-101 создан после ссылки с utm_source=yandex и utm_medium=cpc. После возврата приложение повторно записало поле «Последний источник» значением bank.example. Рекламный источник заказа при создании остался yandex. В таком случае проблема отчёта — выбор поля или его перезапись, а не обязательно настройка счётчика.
Что проверить в GA4
В настройках потока GA4 есть список нежелательных переходов. Google приводит сторонние платёжные сервисы как один из сценариев его применения. Добавляйте конкретный домен, который действительно появляется в вашем маршруте, а не маску на все внешние сайты.
Проверьте настройку тега на странице возврата и передачу идентификаторов. Исключение реферала не восстанавливает исчезнувшие cookies и не заменяет междоменное измерение на собственных доменах. Платёжный домен, на котором вы не управляете тегом, нельзя просто считать ещё одним своим сайтом. После изменения сравнивайте новые тесты; исторические строки автоматически правильными не станут.
Что проверить в Метрике и CRM
В Метрике сопоставьте визит, источник и модель атрибуции выбранного отчёта. Источник заказа в CRM может рассчитываться совсем иначе. Уточните, хранит ли интеграция первое касание, последнее касание до заявки или текущий реферер при каждой загрузке страницы.
Сохраните первоначальные метки при создании заказа в отдельные поля. Для последующих посещений используйте другие поля, если они нужны бизнесу. URL возврата не должен содержать новые рекламные метки, имитирующие кампанию самого банка. Все перенаправления должны сохранять необходимые служебные идентификаторы без попадания персональных данных в URL.
Четыре сценария приёмки
- Оплата успешна, покупатель вернулся. Заказ оплачен, покупка передана один раз, исходный источник сохранён по правилам проекта.
- Оплата успешна, вкладка закрыта. Сервер всё равно обновляет статус заказа; browser-событие может не отправиться.
- Оплата отменена, покупатель вернулся. Возврат не превращается в оплату.
- Уведомление провайдера пришло повторно или страница обновлена. Не создаются второй заказ и повторная покупка.
Результат проверки — таблица с ID теста, статусом оплаты, событиями счётчика и полями CRM. Для структуры purchase используйте анализатор ecommerce-событий, для рекламной ссылки — проверку пути UTM до CRM.
Как понять, что исправление помогло
Сначала повторите те же сценарии на новых заказах. Затем сравните долю платёжных доменов в источниках, сохранность рекламных меток и число оплаченных заказов в независимом реестре. Падение «банковских» переходов полезно только вместе с сохранением настоящих продаж. Если число покупок тоже уменьшилось, проверьте, не отключили ли событие целиком.
