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

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

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

Що йде не так із відстеженням UTM#

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

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

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

Прогалини в серверних конверсіях. Піксель спрацьовує на сторінці подяки, GA4 фіксує це, Meta фіксує це, і ви йдете додому. Потім Safari випускає чергову версію ITP, кількість встановлень блокувальників реклами зростає, і ваші зареєстровані конверсії падають на третину. Примітки до випуску ITP 2.3 від Apple детально описують цей механізм: декорування посилань обмежується, 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 коротких посилання, щоб нікому не довелося вводити той самий рядок UTM 200 разів.

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

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"

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

• Коміт за принципом «все або нічого». Одинарна помилка в рядку перериває все завантаження та повертає номери проблемних рядків разом із причиною - «ряд 47: нерозпізнана змінна {{ 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 чітко про це говорить: вам потрібні події на стороні сервера, а піксель у браузері - лише додаток. GA4 Measurement Protocol стверджує те саме. Обидва протоколи приймають події в схожому форматі: серверна подія з деталями конверсії, 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

Збережіть його в першочерговому cookie (first-party cookie) на сторінці призначення (elido_click_id, термін дії 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": {
      "project_token": "pm_…",
      "service_account": "[email protected]"
    }
  }'

Крок третій - відправка конверсії (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, тому переслана подія зберігає атрибуцію оригінальної кампанії, навіть якщо користувач годину блукав сайтом перед покупкою. Повний опис механіки, включаючи обробку повернень та перемикання моделей мультиканальної атрибуції, доступний у посібнику з пересилання конверсій.

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

Три граничні випадки, в яких допоможе журнал аудиту#

Шаблони та пересилання охоплюють основні сценарії. Але на третьому тижні будь-якої серйозної кампанії обов’язково виникнуть ситуації, описані нижче. Правильна відповідь на них міститься в журналі аудиту та панелі конверсій, а не в ускладненні шаблонів.

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

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

Запізнілі конверсії. Продаж у B2B SaaS закривається через 47 днів після початкового кліку. У Elido термін зберігання кліку за замовчуванням становить 30 днів, тому до моменту конверсії дані кліку вже видалені, і ви потрапляєте у випадок «Click-id miss», описаний вище. Є два рішення, залежно від вашого циклу продажів: збільшити термін зберігання до 90 днів (доступно в плані Pro та вище) або зберігати click_id як довговічний ідентифікатор (наприклад, колонка original_click_id у записі клієнта), щоб ви могли зв’язати його під час конверсії, навіть якщо cookie вже немає. Ми бачили обидва патерни на практиці.

Журнал аудиту показує різницю між очікуваними та кінцевими 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-тест. Натисніть на одне з ваших реальних коротких посилань у чистому вікні браузера. Простежте за кліком у панелі нещодавніх кліків у Elido. Уявіть, що ви щось купили - надішліть POST-запит із конверсією purchase та цим click_id зі свого терміналу. Підтвердьте, що конверсія з’явилася в Meta Test Events та GA4 DebugView з правильним UTM-контекстом. Весь цикл займає менше 10 хвилин, якщо ви вже робили це раніше.

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

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

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

Зв’зування ідентифікаторів між пристроями (Cross-device identity stitching). Відвідувач натискає посилання на мобільному, не купує, повертається з комп’ютера і реєструється. Ви хочете, щоб обидві взаємодії були приписані одній людині. Відстеження UTM + click_id працює на рівні взаємодії; рівень ідентифікації користувача, який об’єднує ці взаємодії в один шлях - це те, для чого створені CDP (Segment, mParticle, RudderStack). Elido зберігає до 30 днів кліків на відвідувача та підтримує атрибуцію за останнім кліком, першим кліком або позиційну атрибуцію в межах цього вікна, але об’єднання даних між пристроями потребує графа ідентичності (identity graph), який ми свідомо не ведемо.

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

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

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

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

Схоже в блозі#

• Серверне відстеження GA4 через рівень перенаправлення
• Пояснення безкукісної атрибуції: що все ще працює у 2026 році
• Масовий імпорт коротких посилань із Google Таблиць (реальний робочий процес кампанії)
• Атрибуція кліків після Safari ITP: що все ще працює у 2026 році