GCLID, GBRAID і WBRAID — три ідентифікатори кліка (click identifier), які Google додає до URL цільової сторінки оголошення, щоб прив'язати конверсію до конкретного кліка — у вебі, у iOS-застосунках та у пост-ATT-сценарії iOS App-to-Web. Якщо у вашу CRM, аналітику та офлайн-імпорт конверсій потрапляє не той ідентифікатор, Smart Bidding оптимізується на неповній картині реальності.
Що таке ці три ідентифікатори кліка
Ідентифікатор кліка — це короткий непрозорий рядок, який Google додає до URL цільової сторінки, коли користувач натискає на оголошення — наприклад, ?gclid=Cj0KCQ.... Той ідентифікатор, що приземлився на сторінку, має бути захоплений (зазвичай у приховане поле форми або у куку) та повернутий до Google через GA4, тег конверсії або OCI через Data Manager — щоб Google зміг зшити конверсію з кліком (Google Ads Help: About click identifiers, 2025-09-12).
GCLID — Google Click Identifier — це оригінальний ідентифікатор для оголошень, які ведуть користувача з будь-якої поверхні на веб-сторінку. Він є робочим конем OCI з 2013 року і залишається типовим для десктопа, Android та більшості iOS-браузерів, якщо доступні сторонні куки та сховище (Google Ads Help: Set up offline conversion imports, 2025-08-21).
GBRAID обробляє iOS-сценарії App-to-Web (оголошення показано в застосунку, клік веде на веб-сторінку), коли користувач надав ATT-згоду. Оскільки ATT-згода відкриває доступ до IDFA, атрибуція через GBRAID є детермінованою.
WBRAID покриває той самий шлях iOS App-to-Web, коли ATT відхилено або не визначено. Без IDFA атрибуція переходить на приватно-безпечний модельований сигнал, тож звітність є частковою за дизайном (Google Ads Help: GBRAID and WBRAID parameters, 2025-10-07).
Як кожен ідентифікатор рухається петлею вимірювання
Технічна логіка схожа для всіх трьох ідентифікаторів, але поверхні різні. Таблиця нижче підсумовує, де кожен ID народжується і які downstream-системи його споживають.
| Ідентифікатор | Джерело кліка | Призначення | Згода / сигнал | Використовується в |
|---|---|---|---|---|
| GCLID | Веб (будь-який браузер) | Веб | Куки + Consent Mode v2 | OCI, EC, GA4, тег конверсії |
| GBRAID | iOS app-поверхня | Веб | ATT надано (детерміновано) | OCI, EC, GA4 (з мапінгом) |
| WBRAID | iOS app-поверхня | Веб | ATT відхилено / невизначено (моделювання) | OCI (uploaded events), модельовані конверсії |
На практиці URL під час приземлення несе рівно один із параметрів — gclid, gbraid або wbraid. Ваш скрипт захоплення має приймати всі три і зберігати присутній разом із міткою часу, бо схема OCI Data Manager приймає одні й ті самі стовпці завантаження для будь-якого з параметрів (Google Ads Help: Upload offline conversions with GBRAID/WBRAID, 2025-11-18). Після захоплення ідентифікатор живить три downstream-шляхи:
- Онлайн-тег конверсії / EC: контейнер gtag або GTM зчитує куку та повертає її, коли спрацьовує подія конверсії.
- OCI через Data Manager: для лід-генерації ID кліка зберігається у CRM на момент сабміту форми, а пізніше завантажується проти конверсійної дії, коли угода закривається.
- GA4 cross-domain handoff: GA4 зчитує параметр на приземленні, зберігає його у куках
_gcl_*та віддає назад в Ads через зв'язані акаунти.
Що змінилося у 2025/26
Три зсуви роблять гігієну ідентифікаторів кліка значно вагомішою, ніж навіть рік тому. По-перше, рівень ATT opt-in залишається низьким — звіт Adjust Mobile App Trends 2025 повідомляє, що app-side opt-in глобально тримається на рівні 25-30%, тобто приблизно дві третини iOS-сценаріїв app-to-web приземляються з WBRAID, а не GBRAID (Adjust Mobile App Trends 2025, 2025-04-15). По-друге, обов'язкове застосування Consent Mode v2 у EEA з березня 2024 року означає, що GCLID може потрапити на сторінку, але буде стертий із кук, якщо користувач відмовив у рекламному сховищі — Google заповнює прогалину модельованими конверсіями, але лише для рекламодавців, які запустили базовий або розширений сигнал Consent Mode (Google Ads Help: Consent mode, 2025-12-09). По-третє, звіт AppsFlyer State of App Marketing 2025 щодо SKAN+iOS показує, що акаунти, які взагалі не захоплюють WBRAID, демонструють відхилення iOS web-конверсій на рівні 30-45% порівняно з акаунтами, які роблять це коректно — і ця прогалина розширюється, поки Smart Bidding вчиться на обрізаному датасеті (AppsFlyer State of App Marketing 2025, 2025-06-10).
Сукупна практична імплікація: якщо ваші CRM та конверсійний стек і досі побудовані за принципом «GCLID або нічого», ви залишаєте вимірювану частку iOS-конверсій без атрибуції і годуєте Smart Bidding упередженим сигналом.
Methodology note. Whitead аудитує ланцюг захоплення ідентифікаторів кліка через три точки: (1) скрипт захоплення на цільовій сторінці — чи зчитує він усі три параметри і чи зберігає їх із міткою часу? (2) схема CRM — чи є один стовпець click_id із прапорцем click_id_type, чи лише застарілий стовпець gclid? (3) завантаження у OCI Data Manager — чи завантажуються рядки GBRAID/WBRAID проти тієї самої конверсійної дії, чи лише рядки GCLID? Якщо хоч одна точка не проходить, правило спрацьовує у межах того самого домену відстеження конверсій, що рухає fix-conversion-tracking-missing. Severity прив'язана до частки iOS app-driven трафіку у міксі кампаній; лід-генерація та B2B SaaS-акаунти найчастіше виявляють цю прогалину, тому що enhanced-conversions-for-leads залежить від захопленого ID на момент сабміту форми.
Поширені непорозуміння
Хіба GCLID не достатньо, якщо я не запускаю App-кампанії?
Ні — тип ідентифікатора кліка визначається поверхнею кліка, а не типом кампанії. Стандартну Search-кампанію або Performance Max усе одно можуть показати на iOS app inventory (in-app browser handoffs, YouTube iOS app, Discover, Search Network partners), тож GBRAID/WBRAID приземляються на веб-цілях звичайних Search-кампаній теж (Google Ads Help: GBRAID and WBRAID parameters, 2025-10-07). Захоплюйте всі три незалежно від того, які типи кампаній ви запускаєте.
Чи треба дедуплікувати GBRAID і WBRAID проти GCLID?
Ні. Кожна подія приземлення несе рівно один із трьох; на конкретному кліку вони взаємовиключні. Шаблон проєктування CRM — один стовпець для значення плюс один стовпець для типу, а не три окремі стовпці, які потім потрібно узгоджувати.
Чи перетинається моделювання WBRAID із моделюванням Consent Mode v2?
Концептуально так, механічно ні. Моделювання WBRAID заповнює прогалину iOS-without-ATT; моделювання Consent Mode v2 заповнює прогалину EEA-without-ad-storage. Обидва живлять той самий навчальний сигнал Smart Bidding, але налаштовуються в різних місцях (Data Manager / GBRAID-WBRAID upload проти сигналу згоди у вашій CMP) і ви можете не мати одного без іншого.
Пов'язані поняття
Захоплення ідентифікаторів кліка — це сполучна тканина домену вимірювання Whitead. Див. відстеження конверсій — батьківський фреймворк, Enhanced Conversions — підкріплення хешованими PII, коли ID кліка ненадійні, Enhanced Conversions for Leads — варіант для лід-генерації, який залежить від захопленого ID на момент сабміту форми, Consent Mode v2 — шар моделювання EEA, що перетинається з WBRAID, та data-driven attribution — модель, яка споживає будь-який сигнал, що його приносять ці ID.
Джерела
- About click identifiers (GCLID, GBRAID, WBRAID) — Google Ads Help, 2025-09
- GBRAID and WBRAID URL parameters — Google Ads Help, 2025-10
- Set up offline conversion imports — Google Ads Help, 2025-08
- Upload offline conversions with GBRAID/WBRAID — Google Ads Help, 2025-11
- About Consent mode — Google Ads Help, 2025-12
- Mobile App Trends 2025 — Adjust, 2025-04
- State of App Marketing 2025 — AppsFlyer, 2025-06