Как проверить, не теряется ли источник посещения при переходе на внешний сервис оплаты

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

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

Что именно может потеряться при оплате

Источник посещения — сведения о том, откуда человек пришёл на сайт: из поиска, рекламы, письма или другого сайта. Визит, или сеанс, — группа действий, которую система аналитики объединяет в одно посещение по своим правилам.

Когда покупатель уходит на внешний сервис оплаты, он покидает домен магазина. После оплаты браузер возвращает его на сайт. При этом аналитика может увидеть адрес платёжной площадки как адрес предыдущей страницы. Такой адрес называют реферером.

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

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

При проверке разделяйте три вопроса:

• Сохранилась ли связь действий с тем же посетителем?
• Начался ли после возвращения новый визит?
• Какому источнику отчёт приписал покупку?

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

Что подготовить перед проверкой

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

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

Подготовьте простую таблицу наблюдений:

Что записать	Для чего это нужно
Исходный источник и метки перехода	Чтобы знать ожидаемый источник
Время входа на сайт и часовой пояс	Чтобы найти действия в аналитике
Номер тестового заказа	Чтобы связать сайт, оплату и отчёт
Домены по пути на оплату и обратно	Чтобы выявить промежуточные переходы
Адрес страницы после возвращения	Чтобы проверить маршрут возврата
Статус заказа и запись о покупке	Чтобы отличить посещение от оплаты

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

Пошаговая проверка пути покупателя

Шаг 1. Создайте вход с понятным источником

Для управляемого теста используйте ссылку на свой сайт с отдельными UTM-метками. UTM-метки — параметры адреса, которыми обозначают источник, тип перехода и кампанию. Например, можно задать значения utm_source=payment_test, utm_medium=test и utm_campaign=return_check.

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

Откройте ссылку в отдельном профиле браузера или приватном окне. Это поможет уменьшить влияние предыдущих посещений. Учитывайте, что приватный режим может иначе обрабатывать данные браузера, поэтому позже повторите проверку в обычном режиме.

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

Шаг 2. Убедитесь, что первый вход виден в аналитике

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

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

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

Шаг 3. Оформите заказ и зафиксируйте уход с сайта

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

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

Если специалист использует инструменты разработчика в браузере, он может сохранить цепочку переходов в разделе Network — журнале сетевых запросов. Для владельца бизнеса достаточно записать видимые адреса и последовательность действий. Технический журнал нужен, когда требуется найти незаметное перенаправление.

Шаг 4. Пройдите оплату и вернитесь предусмотренным способом

Завершите тестовую оплату и вернитесь на сайт так, как это делает покупатель: через автоматический возврат или кнопку платёжного сервиса. Не вводите адрес магазина вручную во время основного теста.

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

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

Шаг 5. Найдите заказ и сопоставьте действия до и после оплаты

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

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

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

Шаг 6. Проверьте, что запись о покупке означает подтверждённую оплату

Событие покупки — запись, которую сайт или сервер отправляет в аналитику. Она должна соответствовать принятому в бизнесе определению покупки. Открытие страницы «Спасибо» само по себе не подтверждает получение денег.

Сопоставьте запись в аналитике со статусом заказа в системе магазина. Уточните, что запускает событие: возвращение браузера, открытие страницы или подтверждение от платёжного сервиса.

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

Как понять результат проверки

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

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

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

Какие причины проверить при обнаружении подмены

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

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

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

На странице возврата теряется связь с посетителем

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

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

Покупка передаётся сервером без данных о посещении

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

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

Какие сценарии повторить

После основного теста проверьте маршруты, которыми действительно пользуются ваши покупатели:

• Оплата с автоматическим возвратом на сайт.
• Возврат кнопкой платёжного сервиса.
• Оплата через банковское приложение на телефоне.
• Отмена оплаты с возвращением в корзину.
• Успешная оплата без возвращения на сайт.
• Повторное открытие страницы результата оплаты.

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

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

Как передать проблему разработчику

Опишите наблюдение через конкретный заказ. Например: «Тестовый заказ пришёл с источником payment_test. После оплаты покупка в выбранном отчёте отнесена к платёжному домену. Возврат выполнен кнопкой сервиса в том же браузере».

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

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

Частые вопросы

Достаточно ли убрать платёжный сервис из источников?

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

Нужно ли ставить счётчик на внешнюю платёжную страницу?

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

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

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

Можно ли исправить источники старых покупок?

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

Проверить сайт бесплатно