UTM метки для Яндекс Директа и CRM: 7 правил, чтобы ROMI не врал

UTM метки для Яндекс Директа и CRM нужно настраивать как единый контур, а не как набор ссылок «на запуск». Если правила различаются между сайтом, Метрикой и CRM, источник начинает теряться раньше, чем это видно в BI. В итоге ROMI и CPA считаются не по каналу, а по случайному следу в поле Источник.

Рабочая настройка здесь начинается не с генератора ссылок, а с одного стандарта UTM, сохранения yclid, landing_url и referrer, плюс с контроля того, что маркетинговые поля доживают до сделки и денег. Иначе сквозная аналитика ломается на переходе между кликом и CRM.

Короткий ответ

UTM метки для Яндекс Директа нужно настраивать как единый контур Директ — сайт — Метрика — CRM — сделка — отчёт. Если хотя бы на одном переходе нет стандарта, источник становится спорным, а ROMI не выдерживает даже простую ручную сверку.

  • Для стабильного канона нужен весь стандартный набор: utm_source, utm_medium, utm_campaign, utm_content, utm_term.
  • Кроме UTM, в CRM стоит хранить yclid, landing_url, referrer, исходный и нормализованный источник.
  • Самая частая точка потери данных — не Директ, а передача данных между сайтом, формой, CRM и сделкой.
  • Если источник живёт только в лиде, а деньги считаются по сделке, отчёт уже сломан.
  • Без QA-отчёта по потерям даже красивый BI остаётся аккуратной формой старого бардака.

Почему тема не про метки, а про управляемость маркетинга

До тех пор пока команда смотрит только на Метрику, может казаться, что проблема невелика. Трафик есть, кампании видны, UTM в отчётах вроде бы читаются. Но в бизнесе почти никогда нет одной системы. Есть Директ, есть сайт, есть Метрика, есть CRM, потом сделка, оплата и управленческий отчёт. Если единый стандарт и передача данных между этими слоями не договорены, аналитика перестаёт быть управленческой.

Типовые симптомы выглядят так:

  • в Метрике трафик виден, а в CRM часть лидов уже без utm_campaign;
  • поле Источник смешивает сайт, ручной ввод, повторный лид и рекламный канал;
  • сделка живёт без того source, который был у первичного лида;
  • ROMI считают по выручке, а маркетинговый контекст хранится только в заявке;
  • маркетинг и продажи начинают спорить скриншотами вместо данных.

В такой системе новый дашборд не лечит причину. Он лишь аккуратнее показывает последствия.

Что говорят официальные источники

На базовый канон здесь есть несколько жёстких официальных опор.

  1. Яндекс Метрика понимает стандартные UTM-параметры utm_source, utm_medium, utm_campaign, utm_content, utm_term. Кастомные имена вроде utm_keyword в стандартный отчёт по UTM не попадут.
  2. Если лендинг без счётчика, если ссылка редиректит и теряет метки по дороге или если URL собран некорректно, UTM в отчётах будут считаться неполно.
  3. Для точной привязки офлайн-конверсий Яндекс рекомендует собирать yclid и передавать его обратно как часть контура офлайн-конверсий.

Практический вывод простой: yclid полезен, но он не заменяет нормальную UTM-разметку и не снимает задачу с CRM.

Какие UTM метки нужны для Яндекс Директа

Если нужен рабочий, а не декоративный канон, я бы фиксировал минимум так:

Параметр Обязателен Что хранит Практический пример
utm_source Да Рекламную систему yandex
utm_medium Да Тип трафика cpc
utm_campaign Да Кампанию в бизнес-логике kurs_analitika_rf_search_brand
utm_content Да Объявление или креатив text1_offer-a
utm_term Да Запрос или таргетинг kurs_power_bi

Почему я считаю обязательным весь набор из пяти:

  • так работает стандартный отчёт Метрики по UTM;
  • так проще не терять детализацию по кампаниям и креативам;
  • если один проект хранит utm_term, а другой нет, через месяц у вас уже не канон, а локальные исключения.

Порядок параметров не важен. Важно другое: одинаковые имена и одинаковая логика на всём проекте.

Что нужно сохранять кроме UTM

Самая частая методическая ошибка — обсуждать только UTM и забывать, что CRM и сквозная аналитика живут на более широком наборе полей. Я бы считал обязательным минимум такого вида:

  • source_raw;
  • source_normalized;
  • utm_source, utm_medium, utm_campaign, utm_content, utm_term;
  • yclid;
  • landing_url;
  • referrer;
  • lead_created_at;
  • client_id или другой идентификатор сессии;
  • признак manual / import / recovered;
  • ключи связи между лидом, контактом, сделкой и оплатой.

Если часть этих данных живёт только в URL, а в CRM хранится лишь красивое поле Источник, то это не канон. Это надежда, что потом кто-то как-нибудь склеит правду вручную.

Где команды ломают стандарт UTM

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

Плохой подход выглядит так:

  1. один специалист пишет utm_source=yandex;
  2. второй использует utm_source=yandex_direct;
  3. третий сохраняет в CRM просто Директ;
  4. менеджер руками меняет значение на реклама;
  5. аналитик потом пытается из этого собрать единый отчёт.

Рабочий подход другой:

  1. есть один справочник допустимых значений;
  2. исходное значение хранится как пришло;
  3. нормализованное значение строится по прозрачным правилам;
  4. ручные источники не маскируются под рекламные;
  5. первый источник и последний источник вводятся только если бизнес реально понимает, зачем они нужны.

Пример минимальной договорённости:

  • utm_source=yandex всегда и без исключений;
  • utm_medium=cpc для платного клика из Директа;
  • utm_campaign описывает оффер, гео и тип кампании, а не внутреннюю фантазию одного трафик-менеджера;
  • utm_content отвечает за креатив или вариант объявления;
  • utm_term хранит запрос или таргетинг, если это действительно полезно бизнесу.

Главное здесь не красота строки, а то, что она одна на весь проект.

Где чаще всего ломается передача данных между Директом, сайтом и CRM

1. Редиректы и промежуточные страницы

Метрика прямо предупреждает: если после клика пользователь проходит через редирект и метки теряются по дороге, данные в отчётах будут неполными. На практике это одна из самых частых причин, почему трафик «есть», а UTM в CRM уже нет.

2. Внешние формы, квизы и виджеты

UTM могут жить в адресной строке, но не попадать в данные формы. Визуально всё работает, лид создаётся, маркетинг спокоен, а потом выясняется, что в CRM доехали только имя и телефон.

3. CRM хранит только одно поле «Источник»

Когда в одном поле смешаны сайт, рекламный канал, ручной ввод и повторное обращение, аналитика перестаёт отвечать на вопрос «откуда пришёл лид». Она начинает отвечать на вопрос «какой ярлык кто-то в последний раз записал в карточку».

4. Сделка и деньги живут без маркетингового контекста

Если source хранится только на уровне лида, а выручка считается по сделке или оплате, у тебя уже есть разрыв. Это та же проблема, о которой я писал в статье про лиды без источника, только здесь источник ломается ещё раньше, на входе.

Какой канон нужен CRM

Для CRM я бы фиксировал такие правила:

  • хранить source_raw и source_normalized отдельно;
  • не затирать исходные UTM при ручной обработке;
  • копировать маркетинговые поля в сделку и дальше в денежную сущность;
  • выделять отдельные статусы manual, import, unknown, recovered;
  • логировать дедупликацию и переиспользование старого контакта.

Это кажется бюрократией ровно до первого конфликта между маркетингом и продажами. Потом выясняется, что без этой «бюрократии» никто не может доказать, какой канал реально принёс деньги.

Нужен ли yclid, если уже есть UTM

Да, нужен. Но не как замена.

UTM решают задачу описания трафика и кампании на уровне ссылки и отчётов. yclid нужен для более точной связи клика и конверсии, особенно если потом возвращать офлайн-конверсии в Метрику и Директ. Практический вывод такой:

  • UTM нужны для стабильного канона отчётности;
  • yclid нужен для связывания клика и конверсии;
  • CRM должна хранить и то, и другое, а не выбирать «что-то одно, потому что так проще».

Чек-лист на 7 дней

День 1. Зафиксировать канон

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

День 2. Проверить ссылки в Директе

Проверить не «есть ли UTM вообще», а одинаковы ли правила во всех кампаниях, не ломаются ли метки на редиректах и стоит ли счётчик Метрики на всех лендингах.

День 3. Проверить формы и данные формы

Убедиться, что форма реально отправляет UTM, yclid, landing_url и referrer, а не просто показывает их в браузере.

День 4. Проверить CRM-поля

Понять, какие поля сохраняются в лиде, какие доходят до сделки и какие реально доступны в выгрузке для отчёта.

День 5. Разобрать дедупликацию

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

День 6. Собрать QA-отчёт

Минимум четыре вопроса:

  1. сколько лидов в день без utm_campaign;
  2. сколько лидов без source_raw;
  3. сколько записей теряют источник на переходе lead -> deal;
  4. какая доля у manual / import / unknown.

День 7. Привязать к деньгам

Проверить, что эти поля живут в том факте, на котором потом считают CPA, ROMI и выручку. Если на этом этапе деньги и источник живут в разных мирах, полезно перечитать ещё и материал про метрики без DWH: проблема редко бывает только в одном поле.

Что не надо делать

  • не плодить кастомные названия вроде utm_keyword, если вы ждёте их в стандартном отчёте UTM;
  • не хранить в CRM только «красивый» источник без source_raw;
  • не считать, что yclid автоматически решит проблему передачи данных между сайтом и CRM;
  • не додумывать задним числом source там, где система его реально не знает;
  • не спорить по скриншотам, когда можно собрать плоский QA-отчёт по потерям.

FAQ

Какие UTM обязательны для Яндекс Директа?

Для рабочего канона я рекомендую все пять стандартных параметров: utm_source, utm_medium, utm_campaign, utm_content, utm_term. Именно их понимает стандартный отчёт Метрики по UTM.

Можно ли переименовать UTM-параметры под себя?

Нет, если ты хочешь видеть их в стандартном отчёте UTM. Кастомные имена можно передавать как обычные URL-параметры, но это уже другой тип отчёта.

Нужен ли yclid, если уже есть UTM?

Да. yclid полезен для связывания клика и конверсии, особенно в офлайн-конверсиях. Но он не заменяет UTM и не отменяет задачу нормально передать маркетинговые поля в CRM.

Почему в Метрике UTM есть, а в CRM их нет?

Потому что между кликом и CRM есть ещё сайт, форма, интеграция, дедупликация и переход в сделку. Потеря обычно случается на одном из этих стыков.

Что важнее: UTM или CRM-канон?

Они не конкурируют. UTM без CRM-канона ломаются на передаче данных. CRM без UTM оставляет вас с полем Источник, в котором намешано всё подряд.

Вывод

UTM метки для Яндекс Директа перестают быть «маркетинговой мелочью» в тот момент, когда бизнес пытается считать деньги, ROMI и каналы в одной системе. Если в этот момент у команды нет общего канона, она начинает управлять не трафиком, а шумом в полях.

Рабочее решение скучнее, чем хочется: один стандарт UTM, обязательные поля, хранение yclid, проверка редиректов, QA по потерям и перенос источника до сделки и выручки. Зато именно это превращает UTM из формальности в управляемый контур.

Официальные источники

  1. Яндекс Метрика: Отчеты по Директу
  2. Яндекс Метрика: Отслеживание конверсий по yclid
  3. Яндекс Метрика: По параметрам URL