UTM-метки

Происхождение и история термина

Сочетание utm_ использовалось в системе Urchin: её историческое руководство показывает ссылки с utm_source, utm_medium, utm_campaign, utm_content и utm_term. Модуль Urchin Traffic Monitor разбирал адрес, извлекал сведения о кампании и передавал их для учёта. Таким образом, уже в этой реализации были разделены данные в ссылке и программа, которая их читала. Документация относится к прекращённому продукту Urchin и не описывает работу современного Google Analytics. ^[11]

К 29 мая 2013 года официальный блог Google Analytics представлял разметку кампаний как практику, которую нужно согласовывать между сотрудниками. В руководстве Кристы Сейден предлагались единые названия кампаний, источников и способов размещения, а поле содержания использовалось для различения вариантов. Руководство описывало не только сборку отдельной строки, но и согласованный учёт кампании. Этот датированный пример не устанавливает первого автора или год появления UTM. ^[3]

В современной документации ручные UTM-параметры рассматриваются рядом с автоматической разметкой интегрированных рекламных платформ. Значения из ссылки остаются одним из способов сообщить происхождение трафика, однако система может получать более подробные сведения через идентификатор рекламного клика. Поэтому при чтении отчёта важны и название параметра, и способ получения данных. ^[2]

Суть и механизм

От названия размещения к строке отчёта

Работу удобно объяснить через четыре действия. Человек задаёт значения; посетитель переходит по адресу; система получает данные; отчёт объединяет их в группы. В диагностике Яндекс Метрики отдельно выделены создание метки, переход, загрузка счётчика и чтение данных. Потеря возможна между этими этапами, например при перенаправлении или блокировке счётчика. ^[5]

Учебный пример. Издание приглашает читателей на бесплатный вебинар. Для письма оно выбирает источник editorial_letter, способ привлечения email, кампанию webinar_2026_10 и верхнюю кнопку top_button. Получается адрес:

https://example.org/webinar?utm_source=editorial_letter&utm_medium=email&utm_campaign=webinar_2026_10&utm_content=top_button

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

Что означает каждое поле

Ниже — поля, которые поддерживает приложенный конструктор. Их назначение дано по текущей справке Google; это не полный перечень параметров платформы. ^[1]

Идентификатор, или ID, — код, позволяющий отличить кампанию от других. Google описывает utm_id именно как идентификатор кампании или продвижения; при загрузке данных о кампании нужен тот же код. ^[1] В нашем учебном словаре w2610 относится к одному вебинару. Название webinar_2026_10 удобно читать, а короткий код удобно сверять с записью в плане. Оба значения выбирает редакция: конструктор не создаёт кампанию в аналитике и не проверяет уникальность кода.

Значение в ссылке и признак в отчёте

В документации Google слово «измерение» означает характеристику данных, чаще текстовую: например, название события. ^[12] В отчёте об источниках такой характеристикой может быть источник или кампания. ^[2] Чтобы не путать её с самим процессом измерения, далее будем говорить «признак отчёта». В учебной таблице признак «источник» задаёт строки editorial_letter и partner_site, а число визитов показывает, сколько наблюдений отнесено к каждой строке.

Справка Google также описывает utm_source_platform — платформу, направляющую трафик. Для utm_creative_format и utm_marketing_tactic отдельно указано, что они пока не представлены в отчётности. Значит, наличие имени параметра в документации ещё не обещает доступного столбца или строки в отчёте. Наш конструктор ограничен шестью полями из таблицы. ^[1]

Способ привлечения и группа каналов — разные сведения. В ссылку автор записывает utm_medium=email. Группой каналов Google Analytics называет классификацию источников по заданным правилам; один из её результатов — Email. Для вручную размеченного трафика правило Email, в частности, проверяет определённые значения source или medium, включая email. Поэтому значение из ссылки служит входными данными для классификации, а не названием, которое отчёт обязан без изменений скопировать в группу каналов. ^[10]

В учебной кампании две рассылки могут иметь источники editorial_letter и partner_letter, но одинаковый способ привлечения email. По источнику их удобно различать, а группа Email позволяет рассматривать почтовое привлечение вместе. Если вместо email написать произвольное special_launch, это не создаст новую стандартную группу с таким названием. При проверке важно отдельно посмотреть переданное значение и получившуюся классификацию; точный результат зависит от остальных данных и правил отчёта. ^[10]

Первый приход, новый визит и регистрация

Сессия, или визит, — отдельный период взаимодействия пользователя с сайтом; событие — зарегистрированное действие в нём. В Google Analytics наиболее важные для бизнеса события можно отметить как ключевые. ^[8] В нашем примере таким действием будет завершённая регистрация на вебинар, а не простое открытие страницы.

Google разделяет признаки источника по тому, к чему они относятся. Префикс First user указывает на первое привлечение пользователя, Session — на начало сессии. Признаки уровня события применяются при отнесении ключевого действия к источникам. Это три разных вопроса к данным. ^[8]

Учебная ситуация. В понедельник читатель впервые пришёл по ссылке партнёра, посмотрел программу и ушёл. Во вторник он вернулся по письму редакции и зарегистрировался. Предположим, что аналитика распознала одного пользователя, оба визита и нужное событие. Тогда вопрос о первом привлечении ведёт к партнёру, а вопрос о начале второго визита — к письму. Эти ответы согласованы: они относятся к разным этапам пути.

Чтобы распределить учтённый результат регистрации между взаимодействиями, используют атрибуцию. Её модель задаёт правило или алгоритм такого распределения. В Google Analytics смена модели отражается в отчётах ключевых событий с признаками источника уровня события; признаки первого пользователя и сессии от этой настройки не меняются. ^[9] Поэтому в нашей истории нельзя заранее приписать всю регистрацию письму лишь потому, что оно было последним: сначала нужно назвать используемый отчёт и модель. Разметка сообщает значения, а правило атрибуции решает другой вопрос — как учесть результат по взаимодействиям.

Виды и классификации

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

В учебной кампании письмо и партнёрская публикация имеют общий utm_campaign, потому что приглашают на один вебинар. Их utm_source различается. Верхняя и нижняя кнопки в одном письме сохраняют источник и кампанию, но получают top_button и bottom_button в utm_content. Так редакция сможет отдельно посмотреть кампанию целиком и варианты внутри неё.

Ошибки тоже полезно разделить по причине. Синтаксическая ошибка нарушает устройство адреса; словарная дробит один смысл на разные написания; смысловая подставляет чужое значение, например источник прежней кампании. Конструктор может помочь с первой группой, но не узнает, действительно ли письмо относится к названной кампании. Это проверяет человек по плану размещений.

Как применяется на практике

Общий словарь и российский контекст

В Google Analytics размеченные переходы представлены в отчёте привлечения трафика. ^[1] В Метрике отчёт «Метки UTM» группирует сведения по атрибутам и значениям метки и подходит, в частности, для ссылок у партнёров и в рассылках. ^[4]

Учебный пример. Четыре сотрудника называют один вебинар webinar_oct, Webinar_oct, webinar-2026 и webinar_2026_10. Даже когда все ссылки технически открываются, общий замысел утрачен. Редакция утверждает одну запись: код, понятное описание, дату запуска и ответственного. Для каждого размещения добавляет источник и допустимые варианты содержания.

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

Ручная и автоматическая разметка

Для письма редакция сама выбирает source, medium и campaign. Рекламная платформа с настроенной интеграцией может передавать сведения автоматически. При совместном использовании Google Analytics берёт автоматически размеченные значения для источника, способа привлечения и других признаков классификации трафика. Ручные utm_content и utm_term при этом могут заполнять отдельные признаки ручного содержания и ключевого слова. ^[2]

Есть важное исключение. Если GCLID или DCLID — служебные идентификаторы рекламного клика — нельзя использовать по назначению, наличие UTM приводит к определению общих признаков источника только по UTM. Поэтому Google рекомендует заполнить все относящиеся к задаче поля, особенно source, medium, campaign, id и source_platform. Неполная разметка может оставить часть сведений незаданной. ^[2]

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

Как измерить или проверить

Как устроен адрес и зачем нужно кодирование

В ручной записи параметры отделяют от адреса знаком ?, имя от значения — знаком =, пары — знаком &. ^[1] Фрагмент после #, например якорь #prices, является отдельной частью URL. WHATWG определяет разбор URL и программный интерфейс (API) URLSearchParams — набор средств, которыми программа читает и меняет пары имя–значение. ^[6]

Учебный пример. К адресу https://example.org/webinar?page=2#prices надо добавить кампанию и сохранить страницу 2 с якорем. В конструктор вводят исходный адрес целиком, а кампанию — отдельным значением. Готовый результат проверяют после разбора: page равен 2, utm_campaign равен выбранному коду, свойство hash, в котором программа получает фрагмент URL вместе со знаком #, равно #prices. Параметры должны оказаться перед фрагментом, а не стать частью текста якоря.

Кодирование позволяет передать специальные знаки внутри значения. URLSearchParams представляет пробел знаком +, а необходимые символы — процентными последовательностями. ^[6] В нашем конструкторе значение тест & письмо после сборки и обратного разбора остаётся одной строкой тест & письмо, а не создаёт дополнительный параметр. Если вместо обычного текста ввести уже закодированное %20, знак процента будет закодирован повторно: результат передаст буквальное %20. Поэтому в поля вводят исходный текст.

Метод set заменяет значение выбранного имени и удаляет его остальные дубликаты; delete удаляет выбранные пары. Пересборка через API может изменить написание кодировки других параметров, сохранив разобранные значения. ^[6] Если в условной системе подпись ссылки зависит от точного набора символов, одной проверки значений недостаточно: такую ссылку нельзя произвольно пересобирать без проверки правил подписи.

Конструктор версии 4

«UTM-конструктор», версия 5 — автономное приложение к статье. Оно принимает HTTP(S)-адрес, требует source, medium и campaign, а content, term и id оставляет необязательными. Пустое необязательное поле удаляет соответствующий параметр исходной ссылки. Шесть полей формы заменяются без дубликатов; другие параметры сохраняются. Неизвестные повторяющиеся UTM-поля и имена UTM с прописными буквами вызывают ошибку, чтобы неоднозначный исходный адрес исправили явно.

Конструктор сохраняет регистр значений, убирает крайние пробелы и показывает разобранные значения под результатом. Это помогает сверить смысл после кодирования. Он не открывает сайт, не проверяет перенаправления, загрузку счётчика, соответствие словарю или появление данных в аналитике. Его обязательные три поля — правило этой формы, а не утверждение о достаточности трёх значений для любой интеграции.

У каждого поля метки есть предел: 200 кодовых единиц UTF-16, то есть единиц внутренней записи текста. Обычная русская или латинская буква занимает одну такую единицу, а знак 😀 — две. Поэтому строка из 200 букв проходит, из 201 — нет; строка из 100 одинаковых 😀 проходит, из 101 — нет. Видимый знак может состоять и из нескольких частей, поэтому предел нельзя понимать как 200 любых видимых знаков. Это ограничение учебной формы, а не заявленный лимит Google или Яндекса. Кнопка «Очистить форму» удаляет введённые значения, готовую ссылку, расшифровку и сообщения; затем можно собрать новую ссылку.

Учебная метрика качества партии

Для партии подготовленных ссылок редакция задаёт собственный показатель:

Q = число ссылок, прошедших все заданные проверки / число полностью проверенных ссылок × 100%.

В учебной партии полностью проверены 40 ссылок. У двух указан старый источник, у одной неверный код кампании, ещё одна теряет параметры в тестовом перенаправлении. Это четыре разные ссылки: ошибки в данном примере не пересекаются. Остальные 36 прошли все заранее заданные условия. Тогда Q = 36 / 40 × 100% = 90%. Это доля исправных ссылок в проверенной партии. Она не означает, что собрано 90% посетителей или что кампания эффективна.

Если команда проверила только десять ссылок из сорока, знаменатель равен десяти. Результат относится к этой выборке; распространять его на все сорок без основания нельзя. При нуле проверенных ссылок отношение не определено. После исправлений следует отдельно записать результат повторной проверки, а не незаметно заменить результат первой проверки.

Проверка перед запуском: что именно должно совпасть

Продолжим учебный пример. В плане для верхней кнопки письма записаны source=editorial_letter, medium=email, campaign=webinar_2026_10, content=top_button и id=w2610. Это ожидаемые значения, с которыми сравнивают результат, а не сведения, уже обнаруженные в рабочей аналитике.

Сначала редактор собирает ссылку и читает расшифровку под результатом. Если вместо top_button там осталось старое название, ошибку исправляют в полях до отправки письма. Затем проверяют конечный адрес после реального перехода: перенаправление может убрать метки или привести на страницу без счётчика. Такие причины отдельно перечислены в диагностике Метрики. ^[5] Сам конструктор этот переход не делает.

После этого в настроенной системе проверяют появление данных о тестовом визите с выбранными признаками источника. Для нашей задачи это источник и кампания сессии, а для регистрации — ещё и заранее настроенное ключевое событие. Их нельзя заменить одним фактом открытия страницы. В Google Analytics сведения о сессиях и ключевых событиях относятся к разным областям отчёта. ^[8]

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

Ошибки, ограничения и спорные вопросы

Разметка не удостоверяет происхождение. В учебной ситуации человек переслал письмо знакомому. Ссылка сохранила код рассылки, хотя второй читатель получил её другим путём. Значение описывает разметку ссылки; оно не служит заверенным рассказом обо всех обстоятельствах распространения.

Клик не равен визиту. Яндекс объясняет расхождения разными способами регистрации взаимодействий: рекламный кабинет может считать кликом открытие информации об объявлении, а Метрика учитывает посетителей, перешедших на сайт. ^[5] Сопоставлять числа имеет смысл после согласования событий и периода, а не по одному совпадающему коду кампании.

Атрибуция не доказывает причинность. Допустим, в учебной таблице партнёр дал 10 регистраций, письмо — 20. У письма могли отличаться аудитория, предложение и время показа. Разметка разделила наблюдения, но не создала сравнимые условия. Из этих чисел нельзя вычислить, сколько регистраций исчезло бы без письма.

Название поля не делает персональные сведения допустимыми. Правила Google запрещают передавать в Analytics сведения, которые сервис может использовать или распознать как персонально идентифицирующие, включая адреса электронной почты и личные мобильные номера. Требование относится и к пути URL, и к параметрам. ^[7] В учебном конструкторе достаточно кодов кампаний; он не проверяет содержание на соответствие этой политике. Это правило сервиса, а не изложение законодательства.

Правовой аспект

Зарубежные счётчики и персональные данные. С 1 июля 2025 года часть 5 статьи 18 закона № 152-ФЗ «О персональных данных» (в редакции Федерального закона от 28.02.2025 № 23-ФЗ) не допускает при сборе персональных данных граждан России, в том числе в интернете, их запись, хранение и другие операции с использованием баз данных за пределами России. Счётчики вроде Google Analytics передают на зарубежные серверы IP-адреса и идентификаторы cookie, которые могут относиться к персональным данным; о трансграничной передаче, кроме того, заранее уведомляют Роскомнадзор (статья 12 того же закона). Нарушения влекут ответственность по статье 13.11 КоАП РФ. Использование такого счётчика на российском сайте требует юридической оценки; для сбора данных о посетителях из России применяют системы веб-аналитики с хранением данных в России, например Яндекс Метрику.

Частые вопросы

Связанные термины

• CTR (кликабельность)