Google Campaign URL Builder був випущений у 2013 році. Введіть п'ять UTM-параметрів у форму, скопіюйте зібраний URL, вставте його у свій скорочувач, вставте коротке посилання в опис кампанії. Цей робочий процес не змінювався тринадцять років. Інструмент все ще працює — змінилося те, що маркетингові команди тепер працюють у таких масштабах, де цикл копіювання-вставлення стає місцем, де порушується узгодженість.
Це стаття про можливості, а не посібник. Посібник, який детально описує роботу з шаблонами та перенаправленням на стороні сервера, — це наріжний камінь відстеження UTM-кампаній. Цей допис присвячений аргументації дизайну: чому UTM-конструктор має бути всередині скорочувача, як виглядають шаблони для кожного каналу та які антипатерни зникають, коли скорочувач бере на себе етап збирання.
Застарілий робочий процес і де він дає збій#
Застарілий робочий процес складається з трьох кроків. Ви відкриваєте Google's Campaign URL Builder. Ви вводите поля source, medium, campaign, term та content. Ви копіюєте зібраний URL у скорочувач. Bitly, Rebrandly, внутрішній редиректор — не має значення, збирання відбулося раніше.
Це призводить до чотирьох передбачуваних проблем.
Форма не здійснює контролю. Одна людина вводить utm_source=newsletter, інша — utm_source=Newsletter, третя вставляє посилання з попереднього URL, де було utm_source=email. Конструктор — це форма без збереження стану; у команди немає місця для зберігання правил тегування. Через шість місяців GA4 показує фрагментований набір каналів, і його очищення перетворюється на роботу з регулярними виразами (regex) для тисяч рядків.
Форма не масштабується. Регіональна кампанія з флаєрами для 12 напрямків у 4 країнах — це 48 URL-адрес. Заповнення 48 форм вручну, копіювання-вставлення 48 коротких посилань у таблицю — маркетолог, який робить це щоп’ятниці, врешті-решт хоча б раз напише utm_campagin. Шість посилань. Три тижні до того, як хтось це помітить.
Скорочувач не знає, для чого призначені UTM-дані. Він отримав повністю зібраний довгий URL. Він не може сказати вам: «Покажи мені всі посилання, теговані для кампанії Spring DACH», тому що ця семантика була втрачена на межі систем. Контекст кампанії живе у вашій таблиці, а не в системі, що забезпечує редиректи.
Немає журналу аудиту намірів проти результатів. Через два місяці після запуску хтось запитує, чому одне конкретне посилання в партії з 200 посилань веде на utm_term=manual_override. Конструктор створив рядок URL і забув про нього. Ніхто не може сказати, хто його створив, коли і чи було це перейменування навмисним.
Власні рекомендації Google щодо найкращих практик UTM виглядають як мовчазне визнання проблеми: «будьте послідовними», «використовуйте малі літери», «документуйте свої правила». Поради правильні. Але інструмент не пропонує жодної допомоги в їх виконанні.
Що змінює UTM-конструктор усередині скорочувача#
Зміна полягає не в кращій формі. Зміна полягає в тому, що скорочувач володіє етапом збирання, а це означає, що він може зберігати шаблон, перевіряти вхідні дані на відповідність цьому шаблону, зберігати різницю між очікуваним і фінальним значенням і відмовлятися створювати посилання, які його порушують. Ті самі п'ять полів, але зовсім інша операційна форма.
Першим кроком є шаблон робочого простору. Ви пишете правило один раз на рівні робочого простору, і кожне посилання його успадковує. Буквальні значення фіксують параметри, які не змінюються; плейсхолдери заповнюються з даних посилання під час створення:
{
"utm_source": "{{ channel }}",
"utm_medium": "{{ medium }}",
"utm_campaign": "{{ campaign }}",
"utm_content": "{{ creative }}",
"utm_term": "{{ audience.segment }}"
}
Шаблон кампанії накладається зверху. Кампанія успадковує стандартні налаштування робочого простору та перезаписує лише ту частину, яка стосується конкретної кампанії — обов'язково utm_campaign, іноді utm_term, якщо сегментація прив'язана до кампанії, а не є постійною.
Що це дає на практиці:
- Новий маркетолог, який приєднується до робочого простору, не може створити посилання з неправильним значенням
utm_source. Плейсхолдер відхилить його. - Правило нормалізації регістру знаходиться в одному місці. Якщо в робочому просторі
utm_sourceвизначено як нижній регістр, кожне посилання, створене через шаблон, отримає цю нормалізацію — не потрібно стежити за цим для кожного окремого посилання. - Метадані кампанії структуровані. «Покажи мені всі посилання в кампанії Spring DACH» — це запит до власної бази даних скорочувача, а не фільтр Excel у таблиці, яку хтось міг забути оновити.
- Можливість ручного перезапису для окремих посилань залишається. Але такі випадки потрапляють у журнал аудиту з іменем користувача, міткою часу та різницею між початковим і фінальним значенням, тому на запитання «хто це зробив і навіщо» через шість місяців буде відповідь.
Повний довідник шаблонів, включаючи плейсхолдери зі шляхами через крапку, які зчитують дані з масиву тегів посилання, знаходиться в посібнику з UTM-шаблонів.
UTM-шаблони для кожного каналу — як вони виглядають насправді#
Набір шаблонів, який потрібен маркетинговій команді, не є нескінченним. Чотири канали покривають більшу частину роботи. Кожен з них має свою форму, тому що дані, які роблять посилання корисним, відрізняються.
Email. Medium фіксований. Source ідентифікує список розсилки. Campaign ідентифікує конкретну розсилку. Content ідентифікує варіант креативу під час A/B тестування головного банера.
{
"utm_source": "{{ list }}",
"utm_medium": "email",
"utm_campaign": "{{ broadcast_id }}",
"utm_content": "{{ creative }}",
"utm_term": null
}
Буквальне значення utm_medium=email усуває можливість вибору. Без нього хтось з часом тегує посилання в розсилці як utm_medium=newsletter, а інший — як utm_medium=Email, і вимір medium у GA4 фрагментується.
Organic social. Source — це платформа. Medium — social (або social-organic, якщо ви розділяєте платний і органічний трафік на рівні medium). Campaign і content містять ідентифікатор поста та варіант креативу.
{
"utm_source": "{{ platform }}",
"utm_medium": "social",
"utm_campaign": "{{ campaign }}",
"utm_content": "{{ post_id }}",
"utm_term": null
}
Плейсхолдер platform обмежений переліком (enum) — instagram, linkedin, tiktok, twitter, youtube, facebook. Будь-що інше призведе до помилки. Це найпоширеніше джерело розбіжностей для органічних соцмереж: IG для однієї кампанії, instagram для наступної.
Paid. Тут структура найважливіша, оскільки алгоритм оптимізації рекламної платформи зчитує дані про конверсії з UTM-атрибуцією. Неправильно теговані платні кліки перетворюються на неправильно атрибутовані конверсії, що призводить до того, що алгоритм забирає бюджет з кампанії, яка насправді працює.
{
"utm_source": "{{ platform }}",
"utm_medium": "{{ medium }}",
"utm_campaign": "{{ campaign_id }}",
"utm_content": "{{ ad_id }}",
"utm_term": "{{ keyword }}"
}
medium обмежений значеннями cpc, paid-social, display, video. Плейсхолдер ad_id — це власний ідентифікатор платформи, а не людиночитана мітка; мітка має бути в менеджері кампаній, а ідентифікатор — в URL.
Referral and partner. Source — це партнер. Medium — referral. Campaign відстежує угоду; content відстежує розміщення.
{
"utm_source": "{{ partner }}",
"utm_medium": "referral",
"utm_campaign": "{{ deal_id }}",
"utm_content": "{{ placement }}",
"utm_term": null
}
Плейсхолдер partner прив'язаний до списку акаунтів партнерів у вашій CRM. Партнер не зі списку змушує прийняти явне рішення, а не просто допустити непомітну помилку. Партнерські мережі, які передають параметр sub_id, можуть бути додані без порушення шаблону — Elido зберігає довільні параметри ?… з цільового URL разом із UTM-параметрами, визначеними шаблоном.
Чотири шаблони. Більшість посилань маркетингової команди вписується в одну з цих форм.
Стандартні налаштування смарт-посилань — де конструктор зустрічається з перенаправленням#
Шаблони відповідають за збирання. З боку редиректу з'являються смарт-посилання, і взаємодія між ними — це та частина, яку найлегше недооцінити на етапі проектування.
Смарт-посилання здійснює маршрутизацію залежно від контексту відвідувача — країни, пристрою, мови, часу доби. Цільовий URL є умовним, але UTM-контекст належить кампанії, а не цілі. Це важливо, тому що найпоширенішим сценарієм використання смарт-посилань у маркетингу є ситуація, коли «одна і та ж кампанія веде на цільову сторінку de-DE для німецьких відвідувачів, en-US для американських та fr-FR для французьких». Вам потрібне одне коротке посилання на кампанію, а не три. Смарт-посилання розгалужує ціль; UTM-дані залишаються незмінними для всіх гілок кампанії.
Без шаблонів для кожної умовної цілі потрібно було б збирати UTM-рядок окремо, що втричі збільшує ризик помилок. З шаблонами та маршрутизацією смарт-посилань створення UTM відбувається один раз під час створення посилання, і створений рядок передається в кожну гілку.
Пояснення смарт-посилань описує логіку маршрутизації. Деталь, важлива для гігієни UTM, полягає в тому, що правило смарт-посилання спрацьовує перед редиректом, але після створення UTM — платформа аналітики бачить узгоджене тегування кампанії незалежно від того, на яку цільову сторінку потрапив користувач. Навіть цільова сторінка за замовчуванням для випадку «ми забули написати правило для Ліхтенштейну» успадковує ті самі UTM-дані.
Антипатерни, які шаблони відправляють у минуле#
П'ять антипатернів зникають, коли скорочувач бере на себе збирання UTM. Кожен з них — це реальний сценарій збою, який, як я бачив, забирав у маркетингової команди цілий квартал.
Змішування регістрів utm_source. Найпоширеніше джерело розбіжностей з великим відривом. newsletter, Newsletter, NEWSLETTER, news_letter — один і той же канал, розділений на чотири варіанти в GA4. Вирішенням є трансформація lowercase для плейсхолдера, що застосовується під час генерації як через масове створення, так і в інтерфейсі користувача.
Невідповідність utm_medium каналу. Платна кампанія ретаргетингу в Meta була випадково позначена як utm_medium=social замість utm_medium=paid-social. Групування каналів у GA4 зчитує це як органічні соцмережі, звітність про платну рекламу показує занижені дані, а фінансовий директор запитує, чому витрати на рекламу не відображаються в атрибутованому доході. Вирішенням є використання буквального значення — без плейсхолдерів, без можливості вибору.
Пробіли в utm_campaign. utm_campaign=Spring 2026 DACH кодується в URL як Spring%202026%20DACH і порушує регулярні вирази назв кампаній, які команди використовують для аналізу воронок. Вирішенням є або трансформація slugify, або відмова на етапі валідації з пропозицією альтернативи в стилі kebab-case. Маркетологи швидко вивчають правила, коли API відхиляє неправильні варіанти.
utm_term як звалище. Без чітких правил utm_term стає полем, куди всі скидають метадані, які не влізли в інші місця. Вирішенням є визначення призначення utm_term на рівні робочого простору — зазвичай «сегмент аудиторії для платної реклами, порожньо в усіх інших випадках» — і контроль цього за допомогою плейсхолдера.
Ручні зміни без аудиту. Старшому маркетологу потрібно змінити шаблон для одного посилання через особливий випадок. Через три місяці поведінка цього посилання стає аномальною, і ніхто не може відтворити контекст. Вирішенням є не заборона змін, а їх фіксація: хто, коли, що мав би створити шаблон і на що його змінили вручну.
Як перейти із застарілого робочого процесу#
Перехід простіший, ніж здається. Три кроки в такому порядку.
По-перше, проведіть аудит ваших поточних UTM-даних. Витягніть дані кампаній за шість місяців із GA4. Згрупуйте за utm_source, потім за utm_medium, потім за utm_campaign. Варіанти, які мають бути одним рядком, але відображаються як кілька — це ваші розбіжності. Робота на один вечір і список помилок, за які буде соромно.
По-друге, створіть чотири шаблони каналів, описані вище. Буквальні значення візьміть з вашого аудиту — виберіть канонічне написання для кожного каналу та зафіксуйте його. Плейсхолдери візьміть зі своєї схеми опису кампаній, яку, можливо, доведеться формалізувати одночасно з цим. Інструкція з налаштування брендованих коротких посилань описує налаштування робочого простору з нуля.
По-третє, видаліть закладку Google URL Builder. Створення UTM тепер відбувається всередині скорочувача. Культурні зміни займають більше часу, ніж технічні.
Для кампаній, що містять сотні посилань, масовий імпорт із CSV заповнює прогалину в масштабуванні. Назви стовпців CSV збігаються з назвами плейсхолдерів; принцип «все або нічого» гарантує, що ви не опублікуєте половину кампанії з битим тегуванням. Інструкція зі створення кампанії з QR-кодами — це приклад роботи, де UTM-шаблони проходять крізь запуск QR-кодів, де друк фіналізується до того, як завершено тегування посилань.
Що шаблони не виправляють#
Дві речі, які варто назвати.
Шаблони не вирішують проблему атрибуції між пристроями. Клік на мобільному пристрої, що перетворюється на конверсію на десктопі, — це проблема ідентифікації користувача; UTM — це метадані на рівні торкання, а не ідентифікатор. Для зв’язування пристроїв потрібен граф ідентичності, для чого і призначена CDP.
Шаблони також не вирішують проблему пересилання даних на стороні сервера. Safari ITP та блокувальники реклами погіршують атрибуцію на основі лише пікселів; рішенням є пересилання конверсій через Meta CAPI та GA4 Measurement Protocol, а не кращі UTM-теги. Обидві проблеми живуть в одному конвеєрі даних, але мають різні рішення — обидві розглянуті в нашому наріжному посібнику.
Скорочувач із UTM-конструктором виправляє гігієну тегування та аудит. Він не претендує на вирішення всіх проблем далі по ланцюжку. Чесність щодо масштабів — одна з причин, чому маркетологи впроваджують шаблони швидше, ніж CDP: сфера застосування невелика, сценарії відмов конкретні, а пробний запуск короткий.
Що ще почитати#
- Відстеження UTM-кампаній від початку до кінця без CDP — основний посібник, що описує весь процес.
- Пояснення смарт-посилань — маршрутизація за країною, пристроєм, мовою — як умовні цілі взаємодіють із UTM-даними.
- Налаштування брендованих коротких посилань на вашому домені — передумова для повного володіння процесом редиректу.
- Кампанія з QR-кодами з нуля — приклад використання UTM-шаблонів у друкованій продукції.
- Можливості продукту:
/features/smart-links. - Операційна інструкція: Посібник із UTM-шаблонів у документації.