UTM исчезли после редиректа: как проверить путь
Как проследить UTM от рекламной ссылки до загрузки счётчика: каждый редирект, Location, финальный URL и запись источника в аналитике.
Чтобы найти потерянную UTM, нужно увидеть первый переход, на котором она исчезла. Финальный адрес без параметров ещё не объясняет, успела ли аналитика их прочитать. А сохранённые метки не доказывают, что счётчик вообще загрузился.
Это диагностика конкретного маршрута в маркетинговой аналитике. Она дополняет правила разметки: правильно составленная ссылка может потерять параметры в сокращателе, перенаправлении домена или скрипте страницы.
Сохраните весь путь
Создайте безопасную тестовую ссылку с узнаваемой кампанией, без телефона, email и других личных данных. Откройте Network и включите сохранение журнала при переходах. Пройдите именно тот адрес, который вставлен в объявление или письмо. Прямая ссылка на конечную страницу обойдёт подозрительный участок.
Сначала посмотрите серверные перенаправления. MDN описывает HTTP-редирект через статус перенаправления и заголовок Location. Параметры не обязаны сохраняться сами: это зависит от того, какой адрес сформирован для следующего шага.
| Шаг | Что проверить | Если метка исчезла |
|---|---|---|
| Ссылка объявления | Метки присутствуют после подстановок | Исправить шаблон рекламного URL |
| Сокращатель | Location содержит нужные параметры | Проверить правило перенаправления |
| Смена домена или HTTPS | Query сохранён в новом адресе | Исправить конкретное серверное правило |
| Загрузка страницы | URL в момент запуска счётчика | Проверить очистку URL клиентским кодом |
| Отчёт | Нужные поля после обработки данных | Проверить измерение и модель источника |
После HTTP цепочка может продолжиться
Страница может менять адрес через JavaScript или отправлять человека дальше по нажатию. Посмотрите, когда это происходит относительно загрузки аналитики. Если скрипт очищает query раньше, чем счётчик увидел страницу, правильные метки в первом запросе не гарантируют атрибуцию.
Проверяйте сетевой запрос аналитики и предусмотренный отладочный режим. Не оценивайте передачу только по адресной строке после полной загрузки. Иногда параметры уже прочитаны и убраны, иногда их удалили слишком рано. Эти случаи требуют разных исправлений.
Что передать разработчику
Укажите исходный адрес, последовательность переходов и первый URL с потерей. Приложите ожидаемые имена параметров, а значения чувствительных данных удалите. Попросите сохранить разрешённую часть query, корректно собрать следующий URL и проверить его после публикации. Слепое добавление знака вопроса к адресу, где он уже есть, может создать новую ошибку.
Проверьте вариант без меток, вариант с несколькими параметрами, кодированные значения и уже существующий query. Отдельно убедитесь, что исправление не создало открытого перенаправления на произвольный внешний домен. Схема назначения должна оставаться согласованной с маршрутом сайта.
Два подтверждения после исправления
Первое — метки дошли до нужного момента загрузки страницы. Второе — в аналитике появилась запись с ожидаемыми полями. Для теста учитывайте время обработки и фиксируйте ресурс, период, часовой пояс и модель источника. Не принимайте отсутствие строки через секунду за доказанный сбой.
Если метки сохранились, но источник не дошёл до CRM, дальше нужна проверка пути заявки. Если отчёт выглядит необычно из-за автоматики, помогает проверка роботов. Исправленная ссылка завершает только свой участок цепочки.