UTM-метки теряются при редиректе, когда между кликом по объявлению и конечной страницей что-то собирает URL заново и не берёт с собой query-строку. Чаще всего виноват редирект на «голый» адрес, ещё один редирект на стороне сайта назначения, сокращатель ссылок или неверно закодированный параметр. Чтобы это починить, нужно найти хоп, на котором метки пропадают. Надёжно это делается только проверкой каждого хопа руками.
Дальше: как устроены UTM-метки, как каждый тип редиректа обращается с query-строкой, семь типичных причин потери меток, таблица нейминга, которую можно взять за основу, и простой способ проверить цепочку до того, как вы потратите на неё бюджет.
Редирект 301 или 302 сохраняет параметры только если система, которая его отдаёт, сама добавила их в новый URL. Сам протокол этого не делает. После любого изменения ссылки или домена проверяйте всю цепочку через curl -I или вкладку Network в браузере и смотрите, что utm_source и остальные метки есть в последнем URL.
UTM-метки за минуту
UTM-метка это обычный параметр в URL. Системы аналитики читают её при загрузке страницы и записывают как источник этого визита. Стандартных пять:
utm_source: откуда пришёл клик, например название сети или площадки.utm_medium: тип трафика, напримерcpc,push,email.utm_campaign: название кампании.utm_content: креатив или вариант объявления.utm_term: ключевое слово или любая дополнительная метка.
Пример: https://example.com/offer?utm_source=network1&utm_medium=cpc&utm_campaign=spring_test. Сервер, на котором лежит страница, эти параметры игнорирует. Читает их только скрипт или трекер на странице, поэтому если скрипт запустился на URL без меток, визит запишется как прямой или как переход с другого сайта.
Как редиректы обращаются с query-строкой
Ответ-редирект говорит браузеру: «иди по этому адресу». Браузер идёт ровно туда. Старую query-строку на новый адрес он не копирует. Если в новом адресе параметры есть, они дойдут. Если нет, их не будет.
| Метод | Что происходит с параметрами |
|---|---|
| 301 / 302 | Новый URL лежит в заголовке Location. Параметры сохранятся, только если система, которая отдаёт заголовок, их добавила. |
| Meta refresh | Целевой URL записан в HTML промежуточной страницы. Правило то же: что записал генератор страницы, то и получите. |
| JavaScript-редирект | Зависит от кода. location.href = url отправит то, что лежит в url. Некоторые скрипты читают location.search и добавляют его, многие нет. |
| Iframe | Адресная строка остаётся на первом домене. Назначение грузится внутри фрейма по тому URL, который вы указали. Страница во фрейме не видит параметров внешней страницы, пока вы не передали их в URL фрейма. |
Из этого два практических вывода. Первый: «вчера с 302 всё работало» ничего не говорит про meta refresh сегодня, потому что система может обращаться с ними по-разному. Второй: если вы меняете метод редиректа у ссылки, проверяйте цепочку заново.
Семь причин, почему UTM-метки пропадают
1. Правило редиректа ведёт на URL без параметров
Самая частая. В URL объявления есть ?utm_source=..., а редирект ведёт на https://offer.example.com/, и никто не добавляет исходную query-строку. Перед запуском выясните, как ваша система обрабатывает входящие параметры.
2. https в http
В старых связках посетителя бывает перебрасывает с https на http и обратно. Каждый лишний хоп это ещё одно место, где теряются данные, а при переходе на http браузеры могут ещё и обрезать реферер. Держите все хопы на https.
3. Сайт назначения делает свой редирект
Типичные случаи: example.com на www.example.com, старый путь на новый, языковой редирект по IP, добавление или удаление последнего слэша в пути. Многие из них прописаны в конфиге веб-сервера с фиксированной целью, и query-строка отбрасывается. Вы передали правильный URL, а сайт переписал его до загрузки страницы. Всегда тестируйте точный конечный URL назначения, а не только свою ссылку.
4. Сокращатели ссылок
Сокращатель это редирект со своими правилами. Если длинный URL был сохранён с параметрами, они останутся. Если вы добавляете параметры к короткой ссылке уже потом, одни сервисы их передают дальше, другие нет. Считайте сокращатель ещё одним хопом, который надо проверить.
5. На прелендинге ссылки без параметров
Посетитель пришёл с метками, прочитал прелендинг, нажал кнопку, а кнопка ведёт на оффер без них. На самом прелендинге визит посчитается верно, но на всех следующих шагах источник потерян. Добавьте параметры в ссылку кнопки небольшим скриптом или используйте click ID, который сохранит трекер. В статье про click ID и subid объясняется, почему сохранённый ID надёжнее, чем перетаскивание десятка параметров со страницы на страницу.
6. Неверное кодирование & внутри параметра URL
Если один URL передаётся значением другого параметра, например ?url=https://offer.example.com/?a=1&b=2, первый & закрывает параметр url, а b=2 становится параметром внешней ссылки. Внутренний URL нужно закодировать: %26 вместо &, %3F вместо ?, %3D вместо =. В HTML-коде обычный & записывается как &, это отдельная и легко путаемая проблема. Если в отчётах вы видите параметр с названием amp;utm_medium, дело в этом.
7. Регистр и опечатки
Это не проблема редиректа, но в отчётах выглядит так же. utm_source=FB и utm_source=fb в большинстве систем аналитики две разные строки. Одна пропущенная нижняя черта делает метку невидимой. Это решает следующий раздел.
Нейминг, который держит отчёты чистыми
Договоритесь один раз, запишите и дайте таблицу всем, кто собирает ссылки. Значения ниже даны как пример.
| Параметр | Правило | Пример |
|---|---|---|
utm_source | Строчные буквы, одно имя на источник, без пробелов | network1 |
utm_medium | Короткий список допустимых значений | cpc, push, native |
utm_campaign | Оффер, гео, месяц через нижнюю черту | offerx_de_nov |
utm_content | Номер креатива и версия | cr12_v2 |
utm_term | Плейсмент, ключ или аудитория | lookalike_1 |
Используйте только латиницу в нижнем регистре, цифры, нижнее подчёркивание и дефис. Пробелы, кириллица и символы вроде + и % создают проблемы с кодированием, которые вы заметите только в отчёте через неделю.
Как проверить цепочку
Берите настоящий URL из объявления со всеми параметрами и повторяйте проверку после каждого изменения ссылки, домена или метода редиректа.
Через curl
curl -I отправляет HEAD-запрос и печатает заголовки ответа. Флаг -L заставляет идти по редиректам и показывает каждый хоп. Некоторые серверы отвечают на HEAD иначе, чем на GET, поэтому если вывод выглядит странно, повторите с curl -s -o /dev/null -D - -L: он делает настоящий GET и печатает только заголовки.
curl -sIL "https://track.example.com/abc?utm_source=network1&utm_medium=cpc&utm_campaign=spring_test"
HTTP/2 302
location: https://offer.example.com/?utm_source=network1&utm_medium=cpc&utm_campaign=spring_test
HTTP/2 301
location: https://www.offer.example.com/
HTTP/2 200
В этом выдуманном выводе первый хоп параметры сохранил, второй потерял. Проблема на сайте назначения, а не в вашей ссылке. Не прочитав каждую строку location, вы стали бы искать причину не в той системе.
В браузере
Откройте инструменты разработчика, вкладку Network, включите «Preserve log» и загрузите ссылку. Каждый редирект виден отдельной строкой со статусом 301, 302 или 200. Нажмите на строку и прочитайте заголовок Location. Meta refresh и JavaScript-редиректы выглядят как ответ 200 и следующая навигация, поэтому смотрите URL следующей строки. Для фреймов ищите собственный запрос фрейма в том же списке.
Один раз проверьте и с телефона. Встроенные браузеры некоторых соцсетей открывают ссылки иначе, чем десктопные, и цепочка, чистая на ноутбуке, там может повести себя по-другому.
Как с параметрами работает TDS
Система распределения трафика стоит между объявлением и назначением, поэтому это ещё один хоп цепочки, и именно тот, который вы контролируете. Несколько фактов про TDS.SO, важных для работы с UTM:
- В объявление ставится одна ссылка, а правила лежат за ней. Правила и адреса назначения меняются в панели, ссылка в объявлении остаётся прежней, так что ни объявление, ни метки в нём трогать не нужно.
- Параметры URL это одно из 20+ условий правила. Например, клики с определённым
utm_campaignможно отправить на нужный URL. - Методы редиректа: 301, 302, meta refresh, двойной meta refresh, JavaScript и iframe. Они по-разному ведут себя с параметрами, поэтому при смене метода у ссылки проверьте цепочку заново.
- В логе кликов видны время, страна и город, устройство, браузер и реферер каждого клика, так что можно сравнить, что отправило объявление и что получила аналитика.
Каким бы инструментом вы ни пользовались, проверка одна: отправьте клик с известными значениями и прочитайте последний URL. Если нужно ещё и связать конверсии с источником, прочитайте когда нужен трекер: сами по себе UTM-метки не вернут конверсию к клику.
Частые вопросы
Передают ли редиректы 301 и 302 UTM-параметры?
Сам редирект нет. Он отправляет браузер на URL из заголовка Location, и параметры там есть, только если тот, кто собирал заголовок, их включил. Поэтому нужно проверять реальную цепочку.
Почему в URL объявления UTM-метки есть, а в аналитике нет?
Что-то после объявления их отбросило, либо скрипт аналитики сработал на другом URL. Пройдите цепочку через curl -sIL, потом убедитесь, что код аналитики загружается на конечной странице, а не только на промежуточной.
Можно ли ставить в объявление короткую ссылку?
Да, если вы проверили её с вашими настоящими параметрами. Считайте её ещё одним хопом и посмотрите, что она делает с query-строкой.
Что использовать, UTM-метки или click ID?
У каждого своя задача. UTM-метки описывают, откуда пришёл визит, словами, которые вы читаете в отчётах. Click ID определяет конкретный клик, чтобы партнёрка могла прислать конверсию обратно. Вторую часть разбирает статья про click ID и subid.
Важен ли порядок параметров?
Для чтения UTM нет. Системы аналитики ищут каждый параметр по имени. Порядок может иметь значение, если назначение подписывает или хеширует URL, поэтому сохраняйте его, если владелец оффера об этом просит.
Как клик проходит через методы редиректа и правила, видно на странице редиректов, а тарифы смотрите на странице цен.
Гайды и разборы о маршрутизации, фильтрации ботов и трекинге от команды TDS.SO.
Все статьи автора