UTM-метки

10 сентября 2026 · ~16 мин чтения

маркетинг аналитика url атрибуция стандарт

UTM-метки

UTM-метки — набор параметров в конце ссылки (?utm_source=...&utm_medium=...),
которыми рекламодатель сам подписывает каждую свою ссылку, чтобы
система аналитики на сайте потом смогла сказать, из какого источника,
какой кампании и какого конкретного объявления пришёл посетитель.

История

Всё началось не в Google. В 1995–1996 годах в Сан-Диего, Калифорния,
появилась компания Urchin Software Corporation. Её делали Брет Кросби,
Скотт Кросби, Пол Мюре, Брендон Бетея и Джек Анкон — небольшая команда,
которая занималась крайне непопулярной тогда вещью: разбором логов
веб-сервера. Их продукт назывался Urchin — программа, которую хостер
ставил себе, и она превращала сырые строки access-лога в отчёты
«сколько людей, откуда, на какие страницы».

Проблема эпохи была простая и болезненная. Веб-сервер пишет в лог поле
Referer — адрес страницы, с которой человек кликнул. Этого хватало,
чтобы понять «пришёл с yandex.ru». Но не хватало, чтобы понять «пришёл с
третьего баннера из осенней кампании, который мы крутили в РСЯ по запросу
про ипотеку». Реферер знает только домен-отправитель, он ничего не знает
о твоих внутренних намерениях. А между тем интернет-реклама уже стала
бизнесом, и вопрос «какая половина рекламного бюджета потрачена впустую»
из афоризма превратился в отчёт, который с тебя требуют.

Решение Urchin оказалось наглым в своей простоте: раз система не может
узнать контекст извне — пусть рекламодатель сам допишет контекст в
ссылку
. Договорились о префиксе utm_ — это буквально сокращение
Urchin Tracking Module, «модуль отслеживания Urchin». Пять
параметров, никакой магии, просто соглашение об именах.

Дальше — три вехи:

Владельца у «стандарта» нет. Нет RFC, нет комитета, нет спецификации,
которую можно нарушить. Есть документация Google, документация Яндекса и
общая привычка. Формально это просто параметры в query-строке URL,
описанной в RFC 3986 — а уж что за имена там внутри, интернету
безразлично.

Что это такое

Возьми обычную ссылку:

https://novostroy.ru/moscow/

и допиши к ней вопросительный знак, а за ним — пары «ключ=значение»
через &:

https://novostroy.ru/moscow/?utm_source=yandex_direct&utm_medium=cpc
  &utm_campaign=osen_2026_ipoteka&utm_content=banner_3&utm_term=kupit_kvartiru

Всё. Это и есть UTM-разметка. Пять канонических параметров и их принятый
смысл:

Первые три обычно считаются обязательными, последние два — по
необходимости.

Теперь важное различие, которое стоит проговорить явно.

UTM vs Referer. Реферер проставляет браузер, автоматически, и
рекламодатель на него не влияет. UTM проставляет рекламодатель,
вручную или генератором, и браузер про него ничего не знает — для
браузера это обычная часть адреса. Отсюда все сильные и все слабые
стороны UTM разом: он говорит ровно то, что ты в него записал. Ни больше,
ни меньше, ни правдивее.

UTM vs click ID. У рекламных систем есть свои идентификаторы клика:
gclid у Google Ads, yclid у Яндекса, fbclid у Meta. Внешне это
такой же параметр в ссылке, но природа другая: click ID — непрозрачный
код, который подставляет сама рекламная система в момент клика, и
расшифровать его может только она. UTM читаемы всеми и не значат ничего,
кроме того, что ты написал. Click ID даёт точную сшивку с расходами
внутри рекламного кабинета; UTM даёт человекочитаемую разметку в любой
аналитике. Поэтому в реальных ссылках их обычно тащат вместе.

UTM vs серверная разметка. UTM живёт в адресной строке, то есть
на виду у пользователя и любых посредников. Альтернатива — передавать
источник по серверному каналу (postback, Measurement Protocol), где
пользователь ничего не видит. Об этом ниже, в альтернативах.

Аналогии из жизни

Бирка на чемодане в аэропорту. Когда ты сдаёшь багаж, на ручку
цепляют полоску с кодом рейса и аэропортом назначения. Чемодан едет по
транспортёрам, а система в любой момент знает, откуда он и куда. UTM —
такая же бирка на клике: она едет вместе с посетителем и говорит
принимающей стороне, чей он и откуда.

Где ломается: бирку печатает и клеит авиакомпания — сторона, которой
пассажир не управляет, и подделать её нельзя. UTM-метку пишет сам
рекламодатель, и любой человек может руками поправить в адресной строке
utm_source=yandex на utm_source=vk. Кроме того, бирку читают на каждом
этапе пути. UTM читается один раз — на входе. Дальше пользователь ходит по
сайту, и метка либо запоминается системой аналитики, либо теряется.

Штамп «откуда пришло письмо» на конверте. Ты получаешь конверт,
смотришь на штемпель и понимаешь, из какого города он. Дальше можно
считать, из каких регионов тебе больше пишут.

Где ломается: почтовый штемпель — свидетельство независимой третьей
стороны, ставится в момент приёма и подтверждает факт. UTM —
самодекларация: это как если бы отправитель сам писал на конверте «я из
Вологды», а почта просто везла. Плюс штемпель сохраняется на конверте
навсегда, а UTM исчезает из URL, как только пользователь перешёл на
следующую страницу или получил редирект.

Вопрос «откуда вы о нас узнали?» в анкете при первом визите. Салон
задаёт его каждому новому клиенту и потом складывает ответы в отчёт.
Точно тот же смысл: подпись источника на входе.

Где ломается: человек отвечает один раз и субъективно — «увидел
рекламу», хотя на самом деле сначала был совет подруги, потом реклама, а
решил после отзывов. UTM отвечает механически и последовательно, но
страдает от той же болезни ровно наоборот: он честно фиксирует самый
последний
источник и не видит всей цепочки. Человек хотя бы может
сказать «ну, вообще-то и то и другое». Метка так не умеет.

Главное про UTM

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

Как это работает

Пошагово, от объявления до строки в отчёте.

Шаг 1. Генерация ссылки. Маркетолог берёт целевой адрес и добавляет
параметры. Руками — только для двух-трёх ссылок. На объёме это генератор:
табличка в Excel, где колонки — параметры, а формула склеивает итоговый
URL; либо Campaign URL Builder от Google; либо скрипт. В рекламных
системах в значения подставляют макросы — плейсхолдеры, которые сама
система заменит в момент клика. У Яндекс.Директа это, например,
{banner_id} (идентификатор объявления), {phrase_id} (идентификатор
ключевой фразы), {gbid} (идентификатор группы). В шаблоне ты пишешь:

utm_content=cid|{campaign_id}|gid|{gbid}|aid|{banner_id}|phrase|{phrase_id}

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

Шаг 2. Клик. Пользователь жмёт на объявление. Рекламная система
перехватывает клик (обычно через собственный редиректор — счётчик
переходов), подставляет значения макросов, дописывает свой click ID
(yclid, gclid) и отправляет браузер на итоговый адрес — уже со всей
разметкой в query-строке.

Шаг 3. Загрузка страницы. Браузер идёт по адресу
https://site.ru/?utm_source=.... Для сервера параметры после ? — просто
текст; статическая страница чаще всего их полностью игнорирует.

Шаг 4. Счётчик читает адресную строку. На странице выполняется
JavaScript счётчика (Метрика, GA, свой трекер). Он берёт
document.location.search — ту самую query-строку, — разбирает её на пары
и находит utm_*. Разбор в псевдокоде:

params = разобрать(location.search)      # "?a=1&b=2" -> {a:1, b:2}
utm = {k: v для k, v из params если k начинается с "utm_"}

Шаг 5. Привязка к визиту. Найденные метки счётчик кладёт в свою куку
(cookie) вместе с идентификатором визита. Дальше человек ходит по сайту,
метки из адресной строки исчезают, но в куке остаются. Именно поэтому
источник «прилипает» к посетителю на весь визит, а часто и дольше:
у Google Analytics исторически окно атрибуции по кампании — 6 месяцев, у
Яндекс.Метрики визит завершается после 30 минут бездействия, а источник
хранится дольше.

Шаг 6. Отправка на сервер аналитики. Счётчик шлёт запрос (обычно
POST или загрузку однопиксельной картинки) на свой сервер, где в
параметрах едут: идентификатор счётчика, адрес страницы, метки, ID
посетителя.

Шаг 7. Склейка с целевым действием. Человек оставляет заявку. Форма
на сайте вместе с телефоном и именем отправляет в CRM скрытые поля с теми
же UTM, вытащенными из куки. Теперь в карточке сделки лежит вся цепочка:
кампания, объявление, ключ. Через месяц, когда сделка закроется, ты
сможешь посчитать, сколько денег принесла конкретная фраза.

Схематично:

объявление ──клик──> редиректор рекламной системы
                        │ подставляет макросы, дописывает yclid
                        ▼
                 site.ru/?utm_source=…&utm_campaign=…&yclid=…
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
   счётчик читает   форма прячет   сервер пишет
   и кладёт в куку  в hidden-поля  в access-лог
        │               │
        ▼               ▼
     отчёты        CRM / сделка

Регистр и опечатки убивают отчёт

utm_source=Yandex, utm_source=yandex и utm_source=yandex (с пробелом на конце) — это три разных источника в отчёте. Никто не сообщит об ошибке: аналитика послушно заведёт три строки, бюджет размажется, и цифры перестанут сходиться. Единственная защита — генерировать ссылки скриптом или шаблоном, а не руками, и держать словарь допустимых значений.

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

Практически все, кто покупает трафик. Точнее:

Масштаб понятен из одного факта: любая крупная e-commerce-компания
генерирует миллионы уникальных размеченных ссылок в сутки — по одной на
каждую комбинацию объявления, ключа и площадки.

Альтернативы и конкуренты

Click ID (gclid, yclid, fbclid).
Плюсы: подставляется автоматически самой рекламной системой, ничего не
надо размечать руками; точно стыкуется с расходами и позволяет системе
дообучать алгоритмы (в Яндексе это основа офлайн-конверсий).
Минусы: непрозрачен — своими глазами ничего не прочитаешь; работает
только внутри своей экосистемы; браузеры (Safari с версии 17, Firefox в
строгом режиме) начали вырезать известные click ID из ссылок ради
приватности.

Собственный редиректор. Ссылка ведёт на go.mysite.ru/abc123, там
сервер пишет в базу факт клика и отправляет пользователя дальше.
Плюсы: клик фиксируется на твоей стороне, ссылка короткая и красивая,
параметры не потерять.
Минусы: лишний прыжок замедляет загрузку и увеличивает отвал; надо
поднимать и держать сервис; поисковики и антифрод настороженно относятся
к цепочкам редиректов.

Server-side tracking / Measurement Protocol. Данные о визите
отправляются не из браузера, а с твоего сервера напрямую в аналитику.
Плюсы: блокировщики рекламы и ограничения браузеров не мешают, данные
полнее.
Минусы: сложнее в разработке и поддержке; своим сервером легко отправить
и мусор, который потом не отличить от правды; нужна отдельная логика
идентификации пользователя.

Промокоды и отдельные посадочные страницы. Старый добрый способ:
каждому каналу — свой промокод или свой лендинг.
Плюсы: работает вообще без аналитики и без кук, переживает любую чистку
ссылок; годится для радио и печати.
Минусы: грубое разрешение (канал целиком, а не конкретное объявление);
плодит копии страниц; промокод «утекает» на купонные агрегаторы и начинает
приписывать себе чужие продажи.

Когда НЕ стоит использовать

Что сделать сегодня

Открой любую свою действующую рекламную ссылку и проверь три вещи: все ли значения в нижнем регистре; нет ли utm_medium=yandex (частая путаница — там должен быть тип трафика, cpc, а название площадки идёт в utm_source); доезжают ли метки до карточки в CRM. Если хоть один пункт не сходится — весь отчёт по каналам врёт, и чем дальше, тем сильнее.

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера разбирали методику генерации рекламных ссылок для квизов
Новострой-М: пришёл xlsx с готовыми URL, и надо было понять, что в них
фиксировано, а что меняется от строки к строке. Внутри utm_content
обнаружились макросы Яндекс.Директа — идентификаторы объявления, группы и
ключевой фразы, — а в отдельном параметре сидел click ID, который
подставляется уже в момент реального клика. Параллельно шла работа над
скриптом, который генерирует такие же ссылки со случайными значениями для
тестовых прогонов формы, — и весь смысл упражнения был в том, чтобы
тестовые заявки не смешались с боевыми в отчётах.

Краткое резюме