UTM-параметры придумали, чтобы атрибуция стала простой: добавил метку к ссылке - и в аналитике видно, откуда пришёл трафик. На практике всё наоборот: несогласованная UTM-дисциплина - одна из самых частых причин, почему данные об источниках в CRM непригодны для решений. Не потому что технология плохая, а потому что UTM никто не контролирует централизованно - метки создают вручную разные люди в разных кампаниях месяцами.
Типичные способы поломки
Самая частая проблема - несогласованное написание значений. utm_source=Facebook, facebook, FB и fb_ads - для аналитики четыре разных источника, хотя канал один: трафик размывается по вариантам, и ни один не набирает объём для нормальных выводов. То же самое с utm_medium: cpc, paid, ppc для одного и того же платного трафика.
Вторая проблема - техническая потеря параметров: сокращатели ссылок обрезают query-параметры при редиректе, почтовые клиенты и корпоративные прокси переписывают или очищают ссылки перед переходом. Пользователь кликает на UTM-ссылку в письме - и на сайт приходит без единого параметра.
Третья - потеря на multi-session пути, типичная для B2B с длинным циклом сделки: пользователь кликает на рекламу с UTM, читает лендинг, не оставляет заявку, а через неделю возвращается напрямую или находит сайт в органике. UTM с первого визита потеряны, и в CRM лид попадает как direct, хотя решение принято благодаря рекламе.
Четвёртая - опечатки при ручном создании ссылок: utm_campaign=q2_campaing вместо campaign, лишний пробел, неверный регистр. Каждая опечатка - новый уникальный “источник” в отчётах.
Почему это не мелочь
Аналитики и так тратят до 80% рабочего времени не на выводы, а на data wrangling - приведение сырых данных в пригодный для анализа вид: объединение таблиц, нормализацию типов, чистку значений. Несогласованные UTM напрямую увеличивают эту долю: вместо анализа динамики по каналам аналитик вручную сводит fb, Facebook и facebook_ads в один источник каждый отчётный период. Это не косметический дефект, а конкретная причина, по которой время уходит на подготовку данных, а не на инсайты.
Раздробленные данные искажают картину по каналам в обе стороны: канал с реальным объёмом трафика выглядит слабее, потому что треть его разъехалась по вариантам написания, а другой искусственно выглядит сильнее из-за случайно “чистых” меток. Если LinkedIn Ads в отчётах разбит на linkedin, LinkedIn, li_ads, совокупный вклад канала недооценён, и бюджет режут не туда.
Отдельная боль - сверка рекламных платформ с CRM: Google Ads показывает одно число кликов, GA4 - другое число сессий с utm_source=google, а CRM - третье число лидов с source Google. Источники не совпадают буква в букву, объединение данных не работает, и вместо анализа выручки по каналу приходится вручную разбирать расхождения.
Почему одних UTM недостаточно для B2B-пути
UTM отвечает только на вопрос “с какой кампании пришла сессия” и ничего не говорит о роли канала в цепочке касаний, а для B2B это критично. Last-click attribution - модель по умолчанию в большинстве систем - отдаёт всю ценность последнему касанию перед конверсией и системно недооценивает каналы верхней части воронки: SEO, контент, brand-кампании формируют спрос, но не закрывают сделку напрямую. PPC в такой связке часто работает как “финишер”, а SEO - как “открывающий” канал, и last-click этого не видит, даже если все UTM собраны идеально.
Multi-touch attribution (MTA) - first-click, linear, time-decay - распределяет ценность между всеми касаниями, а не только последним. Но модель работает лишь поверх полной и последовательной истории касаний одного лида: если часть визитов потеряла UTM или получила несогласованное значение источника, MTA либо разрывает цепочку на “чужих” участников, либо схлопывает несколько касаний в одно. UTM-дисциплина - предварительное условие, чтобы MTA вообще можно было построить поверх данных CRM.
Как навести дисциплину
Первое правило - никогда не создавать UTM-ссылки вручную в адресной строке. Нужен единый UTM builder: Google Campaign URL Builder, таблица с выпадающими списками или конструктор в CRM - ссылка собирается из фиксированных значений, а не печатается заново.
Второе - зафиксировать нижний регистр и единую номенклатуру для utm_source, utm_medium, utm_campaign: закрытый approved-список из 8-10 источников (google, linkedin, meta, email, partner), а не произвольное название, придуманное на лету.
Третье - сохранять в CRM полную UTM-строку при создании лида, а не только производные поля вроде “источник = реклама”: если хранится только интерпретация, невозможно переклассифицировать данные при изменении правил атрибуции.
Multi-session и click ID
UTM с первого визита нужно захватывать сразу и сохранять - в cookie или localStorage - и передавать в CRM при заполнении формы, даже спустя несколько сессий. Правило простое: first-touch UTM фиксируется один раз и не перезаписывается при повторных визитах.
Чтобы вернуть данные о продажах обратно в рекламные платформы для оптимизации ставок, UTM комбинируют с click ID (gclid, fbclid, li_fat_id): UTM отвечает на вопрос “откуда трафик”, click ID - на вопрос “какой именно клик привёл к сделке”.
Как проверить, что всё работает
Быстрый аудит: выгрузите последние 100 лидов из CRM и посмотрите на поле источника. Несколько вариантов написания одного канала (fb, Facebook, facebook_ads) - дисциплина не работает.
Дальше применима базовая логика работы с пропусками: если UTM-поле пустое менее чем у 5% лидов и пропуск случайный, можно исключить эти строки из отчёта без искажения выводов. Но если пусто у значимой доли лидов, и не случайно, а именно у трафика с определённых кампаний, это системная потеря данных, а не шум - нужно проверять редиректы, форму и cookie, прежде чем доверять отчёту. Такая диагностика занимает час, но сразу показывает, можно ли доверять текущим цифрам по каналам.
Ручная нормализация и сверка с CRM работает, но не масштабируется на десятки кампаний и несколько платформ. Prooflytics решает эту задачу автоматически: нормализует источники трафика, связывает их с click ID и CRM и показывает выручку по каналу без ручной сборки таблиц и риска, что опечатка в UTM исказит отчёт.