Единый стандарт UTM-меток нужен не ради красивых таблиц, а чтобы один и тот же канал не распадался в отчёте на несколько строк. Задача этой инструкции: собрать версионированный словарь, дать нейросети правила проверки и прогнать пять учебных ссылок через протокол, который отделяет допустимую нормализацию от ошибок, требующих уточнения. Ниже — Учебный пример: организация и ссылки вымышлены, домен example.test, это не клиентский кейс и не выполненный прогон модели. Все входы и эталон даны целиком, результат можно повторить вручную или агентом.
Определите словарь и его версию
Словарь фиксирует четыре вещи: какие источники допустимы, какой канал к каждому привязан, какие имена кампаний разрешены и какие алиасы разрешено приводить к канону. Это локальная договорённость команды, а не всемирный стандарт. У неё есть номер версии, и любое изменение выпускается как новая версия, а не как молчаливая правка файла.
Для нашего учебного примера словарь версии 1 выглядит так:
{
"version": "1",
"campaigns": ["workshop_leads_ru_202611"],
"source_medium": {
"yandex": ["cpc"],
"telegram": ["messenger"],
"email": ["email"]
},
"source_aliases": {"Yandex": "yandex"},
"required": ["utm_source", "utm_medium", "utm_campaign"],
"forbidden": "контактные данные в значениях; повтор одного UTM-параметра; неизвестные пары источник/канал"
}
Здесь важно, что допустимые пары source и medium перечислены явно, а не выводятся из общих соображений. Алиас Yandex → yandex разрешён, потому что это единственное правило приведения регистра в версии 1. Пара telegram/cpc в словарь не входит, и валидатор обязан её не исправлять, а останавливать.
Опора на официальные условия нужна, чтобы не обещать лишнего. Яндекс Метрика определяет источник перехода по метке, если она есть в первом просмотре в течение визита Как Метрика определяет источник трафика. Для мессенджеров она рекомендует utm_medium со значением messenger или social Как Метрика определяет источник трафика. При этом Метрика учитывает любые переходы по ссылке с меткой, но чтобы метка попала в отчёт, она должна быть составлена корректно Как Метрика обрабатывает метки. Регистрозависимость и классификацию конкретной системы сверяйте с её официальными условиями; одинаковое поведение разных аналитических систем не гарантировано.
Дайте ИИ правила вместо просьбы придумать метки
Просьба «придумай UTM для нашей кампании» несёт риск дрейфа: без переданного словаря модель не знает согласованных значений и может предложить правдоподобные, но не согласованные между собой метки. Правильный вход — словарь и исходные ссылки, а выход — строгий формат с явным статусом по каждой ссылке. Контактные данные в значениях запрещены, догадки о недостающих параметрах запрещены.
Полный промпт для валидатора:
Ты валидатор UTM-ссылок. Работай только по словарю и исходным ссылкам ниже.
Ничего не выдумывай и не добавляй отсутствующие параметры.
СЛОВАРЬ (версия 1):
- Разрешённые кампании: workshop_leads_ru_202611.
- Разрешённые пары source/medium: yandex/cpc, telegram/messenger, email/email.
- Разрешённые алиасы: Yandex -> yandex.
- Обязательные параметры: utm_source, utm_medium, utm_campaign.
- Запрещено: контактные данные (email, телефон, имя) в значениях;
повтор одного UTM-параметра; неизвестные пары source/medium.
ВХОДНЫЕ ССЫЛКИ:
U1 https://example.test/workshop?ref=partner&utm_source=Yandex&utm_medium=cpc&utm_campaign=workshop_leads_ru_202611#faq
U2 https://example.test/workshop?utm_source=telegram&utm_medium=messenger&utm_campaign=workshop_leads_ru_202611
U3 https://example.test/workshop?utm_source=yandex&utm_source=telegram&utm_medium=cpc&utm_campaign=workshop_leads_ru_202611
U4 https://example.test/workshop?utm_source=email&utm_medium=email&utm_campaign=unknown_launch
U5 https://example.test/workshop?utm_source=yandex&utm_medium=cpc&utm_campaign=workshop_leads_ru_202611&utm_content=person%40example.test
ПРАВИЛА РАЗБОРА:
1. Разбирай query как список пар ключ-значение, не сворачивай в объект:
повторяющийся ключ должен остаться видимым.
2. Сначала percent-decode значения для проверки; не декодируй весь URL
целиком, чтобы не испортить разделители query и fragment.
3. Сохраняй scheme, host, path, посторонние query-параметры и fragment
без изменений.
ФОРМАТ ОТВЕТА — по каждой ссылке один JSON-объект:
{"id": "U1", "status": "PASS | proposed_normalization | blocked | review",
"change": "что изменено или null",
"output": "итоговый URL или null",
"reason": "причина для blocked/review или null"}
Статусы:
- PASS — всё соответствует словарю, URL не менялся.
- proposed_normalization — изменение только по явному алиасу версии 1;
в change перечисли, что именно поменялось.
- blocked — повтор ключа, контактные данные, запрещённая пара source/medium.
Не выбирай значение молча.
- review — параметр или кампания отсутствуют в словаре, решение за человеком.
ЗАПРЕЩЕНО: угадывать кампанию, подставлять известное значение вместо неизвестного,
добавлять utm_content, менять регистр всего URL, объединять конфликтующие значения.
Промпт устроен так, что агент не «улучшает» ссылку, а описывает расхождение. Это ключевое отличие от генератора меток: нормализация разрешена только там, где словарь прямо назвал алиас.
Проверьте пять ссылок
Пять входов покрывают типичные случаи: алиас, чистый PASS, конфликт повтора, неизвестная кампания и контактные данные после декодирования. Эталонный результат по каждому входу:
| ID | Что проверяем | Статус | Итог |
|---|---|---|---|
| U1 | utm_source=Yandex при разрешённом алиасе, есть ref=partner и #faq |
proposed_normalization | https://example.test/workshop?ref=partner&utm_source=yandex&utm_medium=cpc&utm_campaign=workshop_leads_ru_202611#faq |
| U2 | Пара telegram/messenger, всё по словарю |
PASS | https://example.test/workshop?utm_source=telegram&utm_medium=messenger&utm_campaign=workshop_leads_ru_202611 |
| U3 | Два utm_source: yandex и telegram |
blocked | не выбирать последний молча |
| U4 | Кампания unknown_launch отсутствует в словаре |
review | решение за человеком |
| U5 | После URL-decoding в utm_content email-подобное значение |
blocked | убрать контактный идентификатор, выяснить разрешённую метку |
Итог по набору: один PASS, одна предложенная нормализация, две блокировки и одно уточнение. Два корректных итоговых URL — U1 и U2. В U1 меняется только утверждённый алиас, а ref=partner и #faq остаются на месте. U2 не меняется вовсе.
Проверки, которые должен пройти сам эталон:
- разбор query списком пар не теряет повторяющийся ключ;
- percent-decode применяется к значениям, а не ко всему URL;
- U1 сохраняет посторонний
refи fragmentfaq; - все пять ID покрыты ровно по одному разу;
- неизвестная кампания не заменена известной.
Если хотя бы один пункт не выполняется, результат валидатора не принимается. Это тот случай, когда проверка важнее красивого вывода.
Сохраните структуру URL
Соблазн «починить» ссылку целиком велик, но именно здесь появляется тихая потеря. Первый параметр добавляется после ?, все последующие — после &; лишние символы, например %2B, в метках недопустимы Как Метрика обрабатывает метки. Содержимое меток распознаётся корректно, если на сайте используется кодировка UTF-8 Как Метрика обрабатывает метки.
Практическое правило для агента: меняется только значение разрешённого UTM-параметра. Схема, хост, путь, посторонние query-параметры и fragment переносятся байт в байт. При дубле ключа не объединяйте источник с последним попавшимся значением — это выбор, который меняет смысл ссылки и должен уйти на уточнение.
Отдельная граница: проверка синтаксиса ссылки не доказывает, что метки доходят через редиректы и всю цепочку переходов. Диагностику потерь разбирает соседний материал Почему теряются UTM-метки после редиректа. Здесь валидатор отвечает только за корректность самой ссылки до размещения.
Внедрите стандарт и наблюдайте исключения
Внедрение начинается с версии. Номер версии хранится рядом со словарём, а каждая новая правка получает новый номер и дату. Изменения в словаре и изменения в уже собранных данных — разные решения: исторический mapping отдельно согласуют и не переписывают прошлые отчёты автоматически.
Порядок работы:
- Утвердить словарь версии 1 и зафиксировать алиасы.
- Прогнать все новые ссылки через протокол валидатора до размещения.
- Блокировки и уточнения выносить человеку, который отвечает за бизнес-факты: недостающие кампании, недопустимые пары, контактные данные в значениях.
- После запуска проверить фактический переход и отчёт по метке в аналитической системе.
- Все исключения фиксировать и возвращать в словарь как новую версию, а не как устное правило.
Последний шаг важен: стандарт живёт, пока исключения возвращаются в него. Если новая пара источник/канал повторяется, она попадает в следующую версию словаря с датой, а не в переписку. Проверка результата — фактический отчёт по UTM-метке после запуска; изменение прошлых данных не обещается и не выполняется задним числом. Как устроена сверка данных с участием нейросети, разбирает Нейросеть для анализа маркетинговых данных.
Автор метода «Машиночитаемый маркетинг»