Перейти до контенту
whitead

Виправлення: неконсистентність UTM між авто-тегуванням і ручними тегами

знахідка google ads оновлено 2026.05.20 8 хв читання
// зміст · 7 розділів
  1. Чому це важливо
  2. Як перевірити проблему
  3. Як виправити
  4. Як підтвердити, що виправлення спрацювало
  5. Діагностичний чек-лист — пройди всі п'ять пунктів через 7-14 днів після розгортання
  6. Пов'язані правила та концепції
  7. Джерела

Коли авто-тегування (auto-tagging) Google Ads (GCLID) і вручну дописані параметри utm_* стикаються на одному й тому ж кінцевому URL, зшивка GA4 ламається непередбачувано — частина сесій приземляється у google / cpc, частина витікає у (direct) / (none), а Smart Bidding оптимізується проти напівпорахованого сигналу. Розв'яжи стратегію тегування до того, як налаштовувати моделі атрибуції чи потоки імпорту.

Чому це важливо

Авто-тегування (auto-tagging) Google Ads додає до кожного вихідного кліку параметр gclid (або gbraid/wbraid для iOS-app трафіку). GA4, коли пов'язаний із Ads-акаунтом, читає цей GCLID і присвоює сесії джерело google / cpc з коректними метаданими кампанії, групи оголошень і ключового слова — навіть якщо жодного параметра utm_* немає. Це підтримуваний шлях, який сам Google рекомендує для будь-якого акаунту, що використовує Smart Bidding чи enhanced conversions.

Проблеми починаються тоді, коли оператор також зашиває utm_source=google&utm_medium=cpc&utm_campaign=... у кінцевий URL або в трекінговий шаблон рівня кампанії. В аудитах виринають три режими відмови:

  1. Перезапис source/medium. За замовчуванням перемагає авто-тегування (auto-tagging) GCLID, але якщо у властивості ввімкнено Allow manual tagging to override auto-tagging (або GCLID втрачається на хопі редиректу), ручні UTM беруть гору — і тоді будь-яка одруківка (utm_source=Google, utm_medium=ppc, utm_medium=paidsearch) маршрутизує сесію в Unassigned або кастомний канал замість Paid Search. Крихкість — це шлях редиректу / override, а не дефолт.
  2. GCLID, зрізаний редиректом. Коли ручні UTM живуть на трекінговому шаблоні, який робить 302-редирект (Bitly, ClickMeter, vanity-CRM-редиректори), деякі реалізації передають utm_* далі, але втрачають gclid — GA4 далі бачить google / cpc, але Google Ads не може заінжестити офлайн-конверсію назад, бо offline conversion import спирається на GCLID.
  3. Втрата параметрів на стороні браузера. Safari ITP та певні скрипти consent-банерів стирають query string при крос-доменній навігації; якщо GCLID — єдиний ідентифікатор, GA4 атрибутує до (direct). Ручні UTM на цільовій сторінці виживають довше, але є радше одинокою точкою крихкості, а не дублюючим сигналом.

Правило Whitead (utm_consistency) — це ai_review-чек на рівні акаунту, який спрацьовує на MEDIUM, коли дві або більше кампаній показують суперечливі схеми тегування, і на LOW, коли патерн проявляється в одній кампанії. Чек інспектує tracking_url_template, final_url_suffix і final_urls разом — детекція колізій вимагає всіх трьох зрізів, бо оператори часто правлять шаблон і забувають про URL рівня оголошення.

Як перевірити проблему

  1. Відкрий Інструменти → Конверсії → Налаштування → підтверди, що Авто-тегування = Увімкнено. Якщо вимкнено, весь акаунт працює без GCLID і шлях виправлення інший (див. крок 1 у "Як виправити" нижче).
  2. Відкрий Кампанії → обери будь-яку активну кампанію → Налаштування → Параметри URL кампанії. Інспектуй поля Трекінговий шаблон і Суфікс кінцевого URL. Будь-яке буквальне значення utm_source= / utm_medium= / utm_campaign= тут — кандидат на видалення.
  3. Зроби реальний клік на брендовому оголошенні в режимі інкогніто й скопіюй URL приземлення з адресного рядка. Здоровий URL містить gclid=... і не містить utm_source/utm_medium/utm_campaign. Прийнятні доповнення: utm_content=hero_v3, utm_term=spring_promo (як мітки варіанту креативу, а не канальної атрибуції).
  4. У GA4 відкрий Звіти → Залучення → Залучення трафіку, відфільтруй Session source/medium за брендовим доменом за останні 14 днів і порівняй сесії google / cpc з кліками з Google Ads → Кампанії за те саме вікно. Розрив >5% на брендовому трафіку — у парі з нетривіальним рядком (direct) / (none) — підтверджує витік.

Кроки 1-3, які виявляють буквальне utm_source=google поруч з активним параметром gclid, = знахідка підтверджена. Крок 4 квантифікує вплив і встановлює базову лінію після фіксу.

Як виправити

Заплануй одну робочу сесію на 45 хвилин: 15 хв на інвентаризацію, 20 хв на редагування, 10 хв на верифікацію першого редиректу.

  1. Підтверди, що авто-тегування ввімкнено на рівні акаунту. Інструменти → Конверсії → Налаштування → перемкни Авто-тегування на Увімкнено і збережи. Це передумова — кожен наступний крок припускає, що GCLID — джерело правди.

  2. Інвентаризуй усі ручні UTM. Витягни експорт через Google Ads Editor (Account → Export → Selected campaigns → CSV). Відфільтруй будь-який рядок, у якого колонка Tracking template, Final URL suffix або Final URL містить utm_source=, utm_medium= чи utm_campaign=. Збережи список — це твої цілі для видалення.

  3. Прибери з трекінгових шаблонів UTM, що визначають канал. В Editor (або в UI) очисти utm_source, utm_medium і utm_campaign з кожного трекінгового шаблону й суфікса кінцевого URL. Скелет шаблону залиш, якщо використовуєш його для параметрів ValueTrack ({lpurl}?{ignore}, {campaignid}, {adgroupid} для збагачення sGTM) — вони не конфліктують із GCLID.

    # До (конфліктно):
{lpurl}?utm_source=google&utm_medium=cpc&utm_campaign={_campaign}

# Після (GCLID як правда, лише ValueTrack):
{lpurl}?{ignore}&utm_content={creative}&utm_term={keyword}

  4. Залиш utm_content і utm_term лише для маркування варіантів. Ці два параметри безпечно зберігати, бо GA4 не використовує їх для канальної атрибуції — вони з'являються в кастомних звітах для A/B-аналізу. Стандартизуй значення у lower-case snake_case, щоб уникнути фрагментації типу Hero_V3 vs hero_v3.

  5. Зафіксуй у GA4 атрибуцію за GCLID-first. У GA4 → Адмін → Зв'язки з продуктами → Зв'язки з Google Ads підтверди, що пов'язаний Ads-акаунт показує Auto-tagging: Enabled. У Адмін → Потоки даних → веб-потік → Налаштувати параметри тегу → Список небажаних referral-доменів додай будь-які CRM-/redirector-домени, що стирають query string, аби GA4 перестав атрибутувати ці відскоки до referral-трафіку.

  6. Перевипусти і прогони димовий тест. Запуш зміни з Editor, зачекай 30 хвилин на пропагацію, потім повтори інкогніто-клік з кроку 3 в "Як перевірити". URL приземлення тепер має показувати лише gclid + опційно utm_content/utm_term.

"We recommend turning on auto-tagging... Auto-tagging works automatically with Google Analytics 4 properties and helps you see how effective your ads are at driving valuable activity on your site."
— Google Ads Help, About auto-tagging (доступ 2026-05-20)

Як підтвердити, що виправлення спрацювало

Діагностичний чек-лист — пройди всі п'ять пунктів через 7-14 днів після розгортання

  • Авто-тегування ввімкнено на рівні акаунту, і жоден трекінговий шаблон кампанії не повертає utm_source / utm_medium / utm_campaign.
  • Живий брендовий клік дає URL приземлення, який містить gclid= і жодного канало-визначального utm_* параметра.
  • GA4 → Залучення трафіку, відфільтрований за брендовим доменом, показує сесії google / cpc в межах ±5% від загальної кількості кліків Google Ads за 14-денне вікно.
  • Частка (direct) / (none) на брендових цільових сторінках становить <5% від загального брендового трафіку (без урахування справді прямих заходів).
  • Значення utm_content і utm_term використовують єдину конвенцію регістру (lower snake_case) — жодних дублікатів Hero_V3/hero_v3 у варіантному звіті.

Якщо всі п'ять проходять, перезапусти аудит — правило utm_consistency переходить зі стану failed у passed.

Methodology note. Правило utm_consistency у Whitead працює на рівні акаунту як ai_review-чек (prompt_id: check_utm_consistency). Воно читає до 20 кампаній (поля: name, type, tracking_url_template, final_url_suffix) і до 30 оголошень (поля: headlines, campaign_id, final_urls) за один прогін аудиту. Промпт оцінює три класи колізій: (1) авто-тегування, що мається на увазі з контексту акаунту, ОДНОЧАСНО з буквально присутніми utm_source/utm_medium/utm_campaign у шаблоні або кінцевому URL; (2) неконсистентні конвенції UTM між кампаніями в одному акаунті (наприклад, utm_medium=cpc в одній кампанії та utm_medium=paidsearch в іншій); (3) трекінгові шаблони, що роблять 302-редирект через сторонній домен, відомий зрізанням GCLID. Шкала severity: severity_score >= 2 (дві або більше зачеплених кампаній або два класи колізій водночас) → MEDIUM; >= 1 → LOW; < 1 → passed. У severity_rationale правила явно зазначено, що проблема стосується звітності, а не витрат, тому вона обмежена рівнем MEDIUM, навіть коли зачеплено кожну кампанію в акаунті. Чек вимагає нуль днів історії та нуль днів conversion lookback — він інспектує лише конфігурацію — тож виконується першого ж дня будь-якого нового аудиту акаунту. За дефолтним clarification-хінтом правила: якщо альтернативні схеми тегування (Adobe Analytics, серверні кастомні параметри) використовуються свідомо, оператор має позначити знахідку як accepted-risk, а не сліпо виправляти.

Пов'язані правила та концепції

  • GCLID, GBRAID, WBRAID — ідентифікатори, які додає авто-тегування, і призначення кожного.
  • Розбіжність конверсій GA vs Ads — сестринська знахідка, коли розриви в зшивці генерують виміряну розбіжність у звітності.
  • Імпорт GA4 ↔ Google Ads — потік імпорту, який залежить від консистентної зшивки.
  • Data-driven attribution — модель атрибуції, точність якої деградує, коли сесії витікають у (direct).
  • Enhanced conversions — вторинний шар зшивки, що частково компенсує втрати UTM/GCLID, але не замінює їх.
  • Серверний GTM для Google Ads — стійка вимірювальна підкладка, що доповнює чисте URL-тегування.

Джерела

// чи було корисно?
// анонімно · не зберігаємо персональні дані
← Назад до Wiki