Я вже наскрізно налаштовувала відстеження UTM у трьох компаніях. Щоразу ламалися ті самі п'ять речей у тому самому порядку, і щоразу виправлення було однаковим: підняти шаблонізацію на рівень кампанії, опустити передачу конверсій на сервер і поставити між ними тестовий прогон. Це і є суть цього допису. Решта - чекліст QA, що виявляє те, про поломку чого ви навіть не думали.

Якщо ви ще не певні, що робить кожен із п'яти тегів, стаття UTM-параметри пояснено - це база, на якій побудований цей конвеєр.

Для цього вам не потрібна Customer Data Platform (CDP). Вона знадобиться, якщо ваша проблема атрибуції з часом переросте у «зшити чотири анонімні дотики на трьох пристроях в одну подорож клієнта», але для випадку, який я бачу найчастіше - «послідовно тегувати кожне вихідне посилання, фіксувати клік, передавати конверсію в Meta і GA4 на сервері та пережити Safari» - з цим впорається скорочувач URL із шаблонами плюс API конверсій. Нижче - робоча версія з режимами збоїв, які я бачила на практиці.

Що йде не так у відстеженні UTM

Маркетологи, з якими я працюю, непогано розбираються в UTM. Проблема в тому, що інструменти за замовчуванням роблять просто ввести UTM один раз, складно - вимагати єдиний стандарт по всій організації, і неможливо - виправити після запуску. Раз у раз повторюються чотири режими збоїв.

Дрейф. Одна людина пише utm_source=newsletter, інша - utm_source=Newsletter, третя - utm_source=email. Через півроку ваш канал «newsletter» розпадається на дев'ять варіантів рядка в GA4. Прибрати це заднім числом - вправа з розряду «regex і молитва». Оригінальний скрипт urchinTracker(), що запровадив цю конвенцію, - продукт вебаналітики Urchin від Google до появи Analytics, ненадовго відкритий як опенсорс у 2003 році перед поглинанням, - теж не мав шару шаблонів. Конвенція завжди зводилася до «пишіть послідовно»; інструменти ніколи цього не забезпечували.

Ручне тегування в масштабі. Кампанія з флаєрами на 80 коротких посилань у чотирьох регіональних магазинах - це 320 URL-адрес, які треба ввести, вставити в таблицю, скопіювати в скорочувач і сподіватися на краще. У половини з них буде неправильний utm_content. Ніхто цього не помітить, поки кампанія не триватиме вже два тижні.

Розриви в серверних конверсіях. Піксель спрацьовує на сторінці подяки, GA4 його фіксує, Meta його фіксує - і ви йдете додому. Потім Safari випускає чергову версію ITP, кількість встановлених блокувальників реклами зростає, і ваші заявлені конверсії падають на третину. У нотатках до релізу Apple ITP 2.3 детально описано сам механізм: декорування посилань обмежується, document.referrer видаляється, і будь-який аналітичний потік, що залежить від виконання стороннього JS у браузері, тихо деградує. Конверсії й далі відбуваються на вашому сервері. Вони просто не доходять до рекламних платформ.

Відсутність тестового прогону. Першою конверсією, що пройде через новий конвеєр, стане перший реальний покупець. Якщо щось налаштовано неправильно, ви дізнаєтесь про це через три дні, коли алгоритм оптимізації вже перекине бюджет із кампанії, яка насправді працювала.

Цей допис вирішує перші три проблеми за допомогою шаблонів, масового імпорту та серверної передачі, а четверту - за допомогою кроку перевірки, який легко пропустити і дорого коштує пропустити.

UTM-шаблони робочого простору та кампанії

Шаблони піднімають проблему узгодженості на рівень вище в стеку. Ви один раз визначаєте конвенцію тегування на рівні робочого простору, накладаєте зверху перевизначення для окремих кампаній там, де це виправдано, і даєте кожному посиланню успадковувати ці правила. Одруку просто ніде подітися.

Спочатку визначте значення за замовчуванням для робочого простору. Буквальні значення фіксують змінні, які ніколи не змінюються у вашій організації (utm_medium = email для розсилок), а плейсхолдери заповнюються з даних посилання під час створення:

curl -X PUT \
  https://api.elido.app/v1/workspaces/1/utm-template \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "utm_source":   "{{ channel }}",
    "utm_medium":   "{{ medium }}",
    "utm_campaign": "{{ campaign }}",
    "utm_content":  "{{ creative }}",
    "utm_term":     "{{ audience.segment }}"
  }'

Кілька деталей, які тут важливі:

Плейсхолдери заповнюються під час створення посилання, а не під час кліку. У вашому інструменті аналітики опиняється саме те, що було задумано в момент випуску посилання, а не те, що обчислив пункт призначення посилання під час кліку. Це значно спрощує відновлення за журналом аудиту, коли через півроку щось виглядає неправильно.
Невідомі плейсхолдери одразу спричиняють помилку. Якщо у вашому масовому імпорті бракує стовпця creative, а шаблон робочого простору посилається на {{ creative }}, API повертає 422 з назвою нерозв'язаної змінної. Жодного тихого часткового застосування.
Повний довідник шаблонів, включно з плейсхолдерами link.tag.<name>, які читають з масиву тегів посилання (корисно для мультитенантних агенцій, яким потрібно вбудовувати ідентифікатор клієнта в кожну URL-адресу), - у гайді документації.

Далі накладіть шаблон кампанії. Кампанії успадковують налаштування робочого простору і замінюють ту частину, яка специфічна для кампанії:

curl -X POST \
  https://api.elido.app/v1/campaigns \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "name": "Spring 2026 - DACH",
    "utm_template": {
      "utm_campaign": "spring_2026_dach",
      "utm_term":     "{{ audience.locale }}"
    }
  }'

Усе, що не задано в кампанії, підхоплюється зі значень робочого простору за замовчуванням. Дворівневе накладання покриває більшість реальних організаційних структур: спільні конвенції на рівні робочого простору, специфічні для команди чи сезону перевизначення на рівні кампанії. Якщо вам захотілося третього рівня успадкування - це тривожний знак: зазвичай це означає, що дві кампанії насправді мають бути однією кампанією з розумнішими значеннями плейсхолдерів.

Ось чим жертвують перевизначення на рівні окремого посилання: перевизначення спрацьовує незалежно від шаблону. А ось що вони зберігають: перевизначення фіксується в журналі аудиту разом з автором, часовою міткою та різницею між розв'язаним і фінальним значенням. Через півроку, коли хтось запитає, чому в одного посилання з кампанії на 200 посилань стоїть utm_term=manual_override, ви зможете відповісти.

Масовий імпорт з Google Sheets - робочий процес, яким маркетологи насправді користуються

Маркетологи не сидять цілими днями в curl. Бриф кампанії приходить у вигляді таблиці з цільовими URL-адресами і метаданими кампанії, дедлайн запуску - п'ятниця, і питання полягає в тому, як перетворити цю таблицю на 200 коротких посилань так, щоб нікому не довелося 200 разів вводити один і той самий рядок UTM.

Назви стовпців CSV відповідають назвам плейсхолдерів у вашому шаблоні (без урахування регістру). Стовпці, які Elido не розпізнає, відкидаються з попередженням, а не копіюються мовчки - це навмисне рішення. Саме тихе копіювання призводить до того, що в GA4 з'являється utm_brand_color, бо хтось додав стовпець для внутрішньої нотатки.

destination_url,channel,medium,creative
https://shop.example.com/de,newsletter,email,hero_a
https://shop.example.com/fr,newsletter,email,hero_a
https://shop.example.com/de,paid_social,meta,carousel_v2
https://shop.example.com/fr,paid_social,meta,carousel_v2

Надішліть це як multipart:

curl -X POST \
  https://api.elido.app/v1/links/bulk \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -F "csv=@launch_q2.csv" \
  -F "campaign_id=cmp_8a2f"

Ось дві переваги цього процесу валідації, яких не дає інтерфейс для створення посилань по одному:

Комміт за принципом «усе або нічого». Один поганий рядок скасовує все завантаження і повертає номери проблемних рядків разом із причиною - row 47: unresolved variable {{ creative }} це набагато краща помилка, ніж виявити о 16:00 в п'ятницю, що 47 з ваших 200 посилань розв'язалися в рядок-плейсхолдер.
Попередній перегляд перед запуском. Рядок попереднього перегляду масового імпорту в дашборді показує розв'язану URL-адресу, включно з відрендереним рядком запиту utm_*, ще до коміту. Погляньте на друге посилання, щоб переконатися, що шаблон зробив те, що ви очікували, а потім на останнє посилання, щоб переконатися, що рядки далі по файлу не «поплили». Два погляди, одна хвилина.

Якщо у вашої таблиці немає стабільної структури - порядок стовпців змінюється, заголовки перейменовуються - кінцева точка масового імпорту буде неприємним досвідом. Рішення не в нашому інструментарії; рішення - зафіксувати схему CSV для брифів ваших кампаній і ставитися до дрейфу схеми як до помилки процесу. Ширший підхід ми обговорюємо на сторінці рішень для маркетологів.

Серверна передача конверсій у Meta CAPI та GA4

Атрибуція лише через піксель втрачає 20-40% конверсій через Safari ITP, блокувальники реклами та банери згоди. Цифра залежить від галузі - DTC ecommerce перебуває у верхній частині діапазону, B2B SaaS - у нижній, - але кожне вимірювання, яке я бачила після виходу iOS 14, показує, що надійність пікселя суттєво нижча за позначку 95%, на яку розраховують рекламні платформи. Алгоритм оптимізації отримує шумніші вхідні дані, і ваш CPA виглядає гіршим, ніж є насправді.

Документація Meta щодо Conversions API прямо про це каже: серверні події - це те, що вам потрібно, а піксель у браузері - лише доповнення. Measurement Protocol від GA4 наводить той самий аргумент. Обидва протоколи приймають однакову структуру: серверну подію з деталями конверсії, event_id для дедуплікації і, в ідеалі, хешовані ідентифікатори користувача, щоб платформи могли пов'язати конверсію з відомим відвідувачем.

Технічна реалізація, що закриває цей розрив, суто механічна. Три кроки.

Крок перший - захопіть click_id. Кожна відповідь редиректу Elido містить заголовок X-Elido-Click-Id. SDK для TS / Python / Go показують його в об'єкті відповіді редиректу; сирий HTTP теж підходить:

curl -sI https://elido.me/launch | grep -i click-id
# X-Elido-Click-Id: clk_01HYZ7T8WV6KQX3M

Збережіть його у власному (first-party) кукі на сторінці призначення (elido_click_id, TTL 90 днів - достатньо довго, щоб охопити типовий цикл оцінки SaaS-продукту, і достатньо коротко, щоб відповідати рекомендаціям ePrivacy). Зчитайте його назад під час оформлення замовлення.

Крок другий - підключіть напрямки. Передайте облікові дані (PUT) для платформ, на які хочете передавати дані. Підходить будь-яка підмножина; відсутні платформи мовчки пропускаються:

curl -X PUT \
  https://api.elido.app/v1/workspaces/1/conversion-forwarding \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "meta_capi": {
      "pixel_id": "1234567890",
      "access_token": "EAA…",
      "test_event_code": null
    },
    "ga4_mp": {
      "measurement_id": "G-ABC123",
      "api_secret": "abc_def_ghi"
    }
  }'

Mixpanel не є напрямком для конверсій. Інтеграція Elido з Mixpanel передає кожен клік по короткому посиланню як подію link_click, і підключається вона окремо в розділі «Інтеграції».

Крок третій - надішліть конверсію (POST). Коли спрацьовує замовлення, надішліть подію з click_id і деталями замовлення. event_id - ваш ключ ідемпотентності:

curl -X POST \
  https://api.elido.app/v1/conversions \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "click_id":   "clk_01HYZ7T8WV6KQX3M",
    "event_name": "purchase",
    "event_id":   "ord_98231",
    "value":      89.00,
    "currency":   "EUR",
    "user": {
      "email":  "[email protected]",
      "phone":  "+4915123456789",
      "external_id": "cust_5128"
    }
  }'

Поля ідентичності користувача хешуються SHA-256 перед передачею в Meta та GA4 - цього вимагають обидві платформи. Контекст UTM береться з рядка кліку, що відповідає click_id, тож передана подія несе оригінальну атрибуцію кампанії, навіть якщо користувач годину блукав сайтом перед оформленням замовлення. Повна механіка, включно з обробкою повернень і перемикачем моделі мультитач-атрибуції, - у гайді з передачі конверсій.

Вкладка адміністрування пікселя відстеження конверсій у дашборді Elido з полями для Meta Pixel ID, Google Ads / GA4 ID, LinkedIn Insight Tag і TikTok Pixel Code

Це закриває більшу частину розриву. Залишається невелика прогалина - відвідувачі, які блокують кукі click_id, або ті, хто приходить не через Elido, - але для кампаній, куди ви реально спрямовуєте трафік, ви перейшли від «надійності пікселя 60-80%» до «серверної надійності 95%+».

Три граничні випадки, у яких вас врятує журнал аудиту

Шаблони і передача даних покривають щасливий шлях. Наведені нижче випадки з'являються на третьому тижні будь-якої нетривіальної кампанії, і правильна відповідь на всі них знаходиться в журналі аудиту та панелі конверсій, а не в спробі спроєктувати складніший шаблон.

Один випадок не потрапив до цього списку, бо шаблоном його не вирішити: клік, що приходить без referrer і з параметром кампанії, якого ви не встановлювали. Саме так поводяться AI-асистенти, і стаття відстеження трафіку з ChatGPT розбирає, що з цим робити.

Повернення. Конверсія покупки спрацювала, клієнт повернув товар через тиждень, і заявлений дохід тепер завищений на 8%. Виправлення - надіслати той самий event_id з event_name: "refund". Meta і GA4 трактують це як негативну конверсію відносно оригінальної. Причина, з якої event_id влаштовано саме так: ідемпотентність на рівні id події означає, що ви також не зможете подвійно врахувати повернення. Повна схема задокументована в розділі граничних випадків гайду з передачі конверсій - повернення, часткові повернення і кредит магазину мають дещо різну структуру.

Промахи click_id. Конверсія спрацьовує з click_id, що не відповідає жодному відомому кліку - одрук, термін зберігання минув, неправильний робочий простір. Конверсія все одно записується проти робочого простору, але передається з порожнім UTM-контекстом. Це навмисне рішення: атрибуція типу «зловити все» корисніша, ніж просто викинути конверсію, а прапорець click_id_unknown у журналі аудиту дозволяє відфільтрувати неатрибутовану частку під час звітування. Якщо ця частка перевищує 5% конверсій, щось не так з тим, як ви зберігаєте click_id на сторінці призначення - зазвичай справа в атрибуті SameSite кукі або в області дії шляху.

Конверсії, що надходять із запізненням. Угода B2B SaaS закривається через 47 днів після оригінального кліку. Термін зберігання кліків в Elido за замовчуванням - 30 днів, тож на момент спрацювання конверсії клік уже застарів, і ви потрапляєте в описаний вище випадок промаху click_id. Два варіанти виправлення залежно від вашого циклу продажів: збільшити термін зберігання до 90 днів у робочому просторі (план Pro і вище) або зафіксувати click_id у довгостроковому власному ідентифікаторі (стовпець original_click_id у записі клієнта), щоб пов'язати його назад у момент конверсії, навіть якщо кукі вже немає. Ми бачили обидва підходи в продакшені.

Журнал аудиту показує різницю UTM між розв'язаним і фінальним значенням для кожного посилання, код відповіді передачі для кожного напрямку і кожної конверсії, а також стан зв'язку click_id з конверсією. Коли алгоритм оптимізації забирає бюджет у кампанії, яка виглядає слабкою, саме журнал аудиту дозволяє вам сказати: «ні, з кампанією все гаразд, ми просто втратили три дні передачі даних через оновлений api_secret GA4». Перевіряйте його.

QA перед запуском - тестовий прогін усього конвеєра

Не допускайте, щоб першою конверсією, яка пройде через цей конвеєр, став реальний покупець. Вартість 30-хвилинного тестового прогону лягає повністю на вас; вартість неправильно налаштованого конвеєра лягає на те, що алгоритм оптимізації два дні тягне бюджет із вашої найуспішнішої кампанії, поки ви цього не помітите. Ця асиметрія погана.

Три кроки по порядку.

Тестовий прогін масового імпорту. Кінцева точка масового імпорту приймає параметр запиту dry_run=true. Вона виконує валідацію, розв'язує шаблони і повертає посилання, які були б створені, без коміту. Відкрийте відповідь у будь-якому переглядачі JSON; розв'язана URL-адреса кожного рядка видима. Вибірково перевірте 3-5 рядків: друге посилання, останнє посилання і будь-які рядки, що перевизначали значення робочого простору за замовчуванням. Переконайтеся, що рядок запиту utm_* саме такий, яким його прописано у брифі кампанії.

Тестовий режим передачі конверсій. Meta CAPI приймає параметр test_event_code, який спрямовує подію на вкладку Test Events в Events Manager замість продакшену. Встановіть його в конфігурації передачі робочого простору, надішліть 10-20 тестових конверсій і переконайтеся, що вони доходять. Та сама ідея для GA4: встановіть debug_mode: true для подій і перевірте в DebugView. Обидва варіанти працюють у реальному часі. Мета не в тому, щоб вибірково перевірити, що API працює, а в тому, щоб виявити неправильно налаштований pixel_id або api_secret, який оновили, але забули змінити тут.

Наскрізна перевірка (smoke test). Клікніть одне зі своїх реальних коротких посилань із чистої сесії браузера. Спостерігайте за кліком на панелі останніх кліків у дашборді Elido. Вдайте, що щось купили - надішліть конверсію purchase з цим click_id зі свого терміналу. Переконайтеся, що конверсія з'явилася в Meta Test Events і GA4 DebugView з правильним прикріпленим UTM-контекстом. Весь цикл займає менше 10 хвилин, коли ви вже раз це зробили.

Коли всі три кроки пройдено, приберіть test_event_code, встановіть debug_mode: false і запускайте. Першого реального покупця чекатиме чистий конвеєр.

Панель конверсій у дашборді Elido, що показує загальну кількість конверсій і дохід, топ посилань за доходом, графік щоденного доходу за останні 30 днів і розбивку доходу за платформами

Коли вам насправді знадобиться CDP

Шаблони, масовий імпорт і серверна передача даних покривають більшу частину шляху. Але існує клас проблем, де цього недостатньо, і саме тоді правильним рішенням буде звернутися до CDP.

Зшивання ідентичності між пристроями. Відвідувач клікає посилання на мобільному, не конвертується, повертається на десктопі, реєструється. Ви хочете, щоб обидва дотики були атрибутовані одній людині. Відстеження UTM + click_id працює на рівні окремого дотику; шар ідентичності користувача, що об'єднує два дотики в одну подорож, - саме для цього створені CDP (Segment, mParticle, RudderStack). Elido зберігає до 30 днів кліків на відвідувача і підтримує атрибуцію last-touch / first-touch / position-based у межах цього вікна, але зв'язування між пристроями потребує графа ідентичності, який ми навмисно не підтримуємо.

Персоналізація зі швидкістю до 100 мс. Якщо ви рендерите сторінку призначення на основі попередніх дотиків відвідувача в реальному часі - витягуючи когорту зі сховища ознак і змінюючи головний заголовок - вам потрібне розв'язання ідентичності максимально близько до рендерингу. Це територія CDP або, частіше, платформи для експериментів на кшталт PostHog чи LaunchDarkly, накладеної зверху.

Мультитач-атрибуція в масштабі. Для більшості кампаній достатньо last-touch. Якщо ваш цикл продажів має шість дотиків протягом чотирьох місяців і вам справді потрібно врахувати вагу кожного, ви потрапляєте в територію, де починає мати значення атрибуція за ланцюгами Маркова чи значенням Шеплі. Elido підтримує last-touch / first-touch / position-based; для чогось складнішого потрібен інструмент із повноцінним графом ідентичності та модельним шаром.

Для всього іншого - а «все інше» це більшість маркетингових команд, з якими я працювала, - схеми шаблонів, масового імпорту та серверної передачі достатньо. Налаштуйте шаблон робочого простору один раз, шаблон кампанії - для кожного запуску, конфігурацію передачі - один раз для кожної інтеграції з платформою, і запускайте тестовий прогін перед кожним запуском. Якщо ви зробите всі чотири речі, у вас буде UTM-конвеєр надійніший, ніж у 80% маркетингових команд, які я перевіряла.

Налаштуйте один раз, робіть тестовий прогін перед кожним запуском і переходьте до наступної кампанії.

Схожі статті в блозі

Спробуйте Elido

Вставте URL - отримайте коротке посилання

Без реєстрації. Посилання живе 30 днів. Зареєструйтесь, щоб зберегти назавжди.

Безкоштовно, без реєстрації · 2 на день

Як наскрізно відстежувати UTM-кампанії без CDP