UTM-параметры пропадают после редиректа

Fix library

Признаки проблемы

Обычно проблема выглядит так: рекламный URL размечен правильно, но в GA4, CRM или партнерской системе визит приходит без utm_source, utm_medium или utm_campaign. На поверхности кажется, что кампания запущена корректно, а отчеты все равно распадаются на direct, referral или unknown.

Такое часто происходит в связке ad link -> tracker -> cloaker -> landing page, когда один из промежуточных hop пересобирает URL или финальная страница навязывает canonical-логику без query string. Если не разложить цепочку по шагам, команда начинает спорить об аналитике, хотя ошибка находится на уровне маршрутизации ссылки.

Как это доказать

Нужна не теория, а доказательство: возьмите точный боевой URL, прогоните его через Redirect Checker и сравните первый URL с финальным. Затем откройте итоговый адрес в Click ID Extractor или просто сравните query string по hop-ам, чтобы увидеть, где именно UTM исчезают или меняются.

После этого сопоставьте результат с тем, что попадает в аналитику или CRM. Когда у вас есть export цепочки, финальный decoded URL и пример сломанной сессии, разговор с разработчиком или партнером сразу переходит в плоскость конкретного фикса.

• В Redirect Checker стартовый URL содержит UTM, а один из следующих hop уже нет.
• Финальный landing URL открывается, но utm_campaign или другие параметры в query string отсутствуют.
• В UTM Builder эталонная ссылка выглядит корректно, а в боевом path часть параметров пропадает или дублируется.
• В аналитике визит идет как direct, referral или unknown, хотя рекламная ссылка была размечена.

Частые корневые причины

Почти всегда причина находится в одном из трех мест: URL пересобирается на промежуточном редиректе, финальная страница отбрасывает query string или внутренняя логика шаблона/безопасности удаляет неизвестные параметры. Это не разные симптомы одной проблемы, а разные классы поломок, и у каждого свой владелец.

Если быстро определить класс поломки, вы не тратите часы на проверку не той системы. Сначала докажите, где теряются UTM, и только потом идите в трекер, CMS, партнерскую сеть или в команду лендинга.

• Промежуточный redirect rule пересобирает URL и не переносит исходный query string.
• Партнерская или smartlink-система режет параметры, которые не входят в allowlist.
• Финальный landing template или canonical-логика удаляет query string после загрузки страницы.
• Скрипты автотеггинга или ручные правки кампаний конфликтуют с исходной UTM-разметкой.

Как исправить

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

Фикс считается завершенным только тогда, когда одна и та же размеченная ссылка проходит всю redirect chain, открывает нужный final URL и сохраняет те же UTM в downstream-системах.

1. Зафиксируйте полную цепочку редиректов

   Запустите боевой URL в Redirect Checker и сохраните каждый hop со статус-кодами и итоговым URL.

2. Сравните стартовый и финальный query string

   Проверьте, какие UTM были в начале и какие реально дошли до final destination.

3. Исправьте владеющий слой

   Обновите tracker rule, smartlink, partner redirect или landing template — в зависимости от того, где параметры теряются.

4. Соберите эталонную ссылку

   Пересоберите правильный campaign URL через UTM Builder и используйте его как reference для команды запуска.

5. Повторно проверьте боевой путь

   Еще раз прогоните ссылку через Redirect Checker и UTM Decoder, чтобы убедиться, что параметры переживают весь путь без потерь.

Используйте эти диагностические страницы

Не ограничивайтесь одним скриншотом или одним переходом. Комбинация из Redirect Checker, UTM Builder и UTM Decoder дает достаточно материала, чтобы быстро показать проблему и зафиксировать правильный вариант ссылки.

Если в той же цепочке страдают click ID, подключайте Click ID Extractor: потеря UTM и потеря fbclid/gclid часто идут вместе, потому что их режет один и тот же hop.

Выводы

Потеря UTM после редиректа — это не абстрактная проблема аналитики, а конкретная ошибка в URL path или landing logic. Как только вы видите hop, на котором ломается query string, задача становится управляемой.

После исправления сохраните working URL, export из Redirect Checker и эталон из UTM Builder в runbook команды. Тогда следующий запуск будет проверяться по шаблону, а не с нуля.

Похожие проблемы

• UTM Lost After HTTP to HTTPS Redirect
• UTM не видны в аналитике
• Редирект срезает UTM
• Слишком длинная цепочка редиректов

Материалы базы знаний

• UTM пропадают после редиректа
• Как проверять UTM-ссылки перед запуском