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

Определите, где вы управляете измерением

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

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

Согласуйте конфигурацию обоих доменов

Официальная схема Matomo предполагает общий идентификатор сайта аналитики, добавленные адреса доменов и включённое cross-domain linking. В коде используются настройка доменов и enableCrossDomainLinking. Передача между доменами связана с параметром pk_vid и требует cookies. Настройку следует применять согласованно на обеих сторонах, включая обратный переход.

Объединение отчётов через Roll-Up само по себе не создаёт такую связку посетителей. Динамические переходы могут требовать отдельной обработки ссылки средствами трекера. Перед внедрением передайте разработчику точный маршрут и способ перехода: обычная ссылка, программное перенаправление или кнопка виджета могут вести себя по-разному.

Пройдите контрольный заказ целиком

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

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

Зафиксируйте границы результата

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

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

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