Наталія Федоренко
Вебаналітик у PROANALYTICS.TEAMПорівняння джерел трафіку між GA4 та session_traffic_source_last_click в BigQuery
Якщо коротко, то ця стаття про наступне: я дослідила 15 проєктів і порівняла кількість юзерів в розбивці по джерелу / каналу трафіку з інтерфейсу GA4 і значення в об’єкті session_traffic_source_last_click.manual_campaign в BigQuery.
Причина проведення дослідження – поява самого об’єкта session_traffic_source_last_click, та заяви, що це джерело сесії по моделі атрибуції last non-direct з інтерфейсу GA4. Тому, зібравши дані за певний період, я вирішила дослідити чи це справді так.
Швидкий висновок: дані збігаються менше, ніж в половині випадків, і зазвичай в BQ менше google / cpc, ніж в інтерфейсі GA4.
Але давайте по порядку:
Передісторія
Наприкінці липня Google додав в схему експорту GA4 об’єкт session_traffic_source_last_click (далі STSLC). Спочатку з’явились тільки manual_campaign і google_ads_campaign. Через декілька місяців, якраз під час проведення дослідження і написання цієї статті, додались ще cross_channel_campaign, sa360_campaign, cm360_campaign, dv360_campaign:
Я прийняла рішення продовжити дослідження полів manual_campaign і не чекати ще декілька місяців, поки зберуться дані в cross_channel_campaign. Можливо, з часом я проведу перевірку і cross_channel_campaign. Якщо вам було б цікаво дізнатись її результати, відмічайтесь у коментарях.
А от щодо manual_campaign і google_ads_campaign, то майже одразу їх протестували і заявили, що вони співпадають з інтерфейсом, тобто що це не last click атрибуція, що виходить із назви об’єкта і навіть із довідки, а last non-direct з інтерфейсу.
Ось лінк на одну з таких заяв:
У мене ці заяви викликали певну недовіру, бо у Google апдейти виходять частно доволі сирими. Але якщо і справді так, життя стало б набагато простішим, бо кожен зміг би будувати потрібні репорти по джерелам на основі сирих даних за найпопулярнішою моделлю атрибуції - last non-direct. До цього ж, для вирішення такого завдання треба було добре знати SQL і писати довгу складну логіку обробки даних.
І от із моменту появи STSLC на момент написання статті пройшло декілька місяців, ми вирішили, що пора дослідити ці поля і порівняти їх з інтерфейсом.
Методологія дослідження
Перед тим, як перейти до результатів цього дослідження, ви маєте знати як воно проводилось.
Середній період даних – близько 1.5 місяця. Більшість проєктів мали багато історичних даних, там я брала за 2 місяця, але були і зовсім нові підключення до BQ, де дані збирались всього 2-3 тижні.
З інтерфейсу GA4 вивантажувався звіт з блоку Explore (Дослідити). Я виводила Session source / medium i Total Users за той же період, що в SQL скрипті, перед цим змінивши Reporting Identity (Способи ідентифікації) на Device-Based (Залежно від пристрою) там, де метод був іншим. Ми вирішили вирівняти умови тестування для всіх проєктів, бо не на всіх збирається user_id. Деколи функціоналу реєстрації / логіну немає.
Але звісно, за можливості, треба визначати джерела на основі, в першу чергу user_id – внутрішнього ідентифікатора користувача з власної бази.
Чому я рахувала саме юзерів, хоча досліджую параметри сесій?
В довідці описано багато стосовно того, як інтерфейс рахує сесії. Він застосовує певний алгоритм, який не доступний в BigQuery, що в свою чергу дає розбіжність в кількості сесій. Це, благо, не відноситься до звичайного client ID – Total Users в блоці Explore (Дослідити) при Device-based reporting identity і COUNT(DISTINCT user_pseudo_id) в BigQuery однакові. Тому для зменшення кількості факторів, які впливають на розбіжність, я рахувала саме юзерів.
З STSLC я забирала поля source i medium з об’єкта manual_campaign і агрегувала юзерів функцією COUNT(DISTINCT user_pseudo_id).
Далі результати зводила в Power BI, де додатково об’єднала весь (not set) з (direct) / (none), щоб звертати на невизначений трафік увагу тільки, якщо дійсно є різниця.
До речі, в STSLC загалом немає (direct) / (none). Якщо проводити дедуктивне порівняння з інтерфейсним числом (direct) / (none) трафіку, то замість нього передається (not set) / (not set). А от інтерфейсне (not set) - це схоже просто відсутність будь-яких значень в STSLC.
Результат та таблиця порівнянь
Результат був трохи неочікуваним. Дані з полів STSLC суттєво відрізнялись від інтерфейсу в 60% випадків, а саме в 9 проєктах з 15.
Google сам каже, що дані між експортом в BigQuery та інтерфейсом можуть різнитися на 2-5%, тому не слід чекати 100% точності. Ось довідка. Я ігнорувала розбіжність до 5%.
Порівняно з інтерфейсом в BigQuery:
- В 7 випадках (47%) було менше
google / cpc. - В 4 випадках (27%) було більше
directтрафіку. - В 4 випадках (27%) було більше
google / organic. І у всіх них було меншеgoogle / cpc, що наштовхнуло на думку, що частинаcpcвизначилась, якorganic. - В 4 випадках (27%) замість
google / cpc, який в інтерфейсі назначається за замовчуванням всьому рекламному трафіку з Google, в BQ були інші значення – або кастомні мітки, напр. google_pm, або піддомени рекламної мережі Google. - В 2 випадках (13%) було багато дивного трафіку з YouTube.
| Порівняно з інтерфейсом GA4 в BigQuery | дані між полями BQ і GA4 зійшлись | замість google / cpc щось інше | більше direct трафіка | більше google / organic | менше google / cpc | дивний трафік з YouTube |
| кількість проєктів | 6 | 4 | 4 | 4 | 7 | 2 |
| доля від всіх | 40% | 27% | 27% | 27% | 47% | 13% |
| проєкт 1* | - | - | - | - | + | - |
| проєкт 2 | - | + | - | - | - | - |
| проєкт 3 | - | + | + | + | + | + |
| проєкт 4 | - | - | + | - | + | - |
| проєкт 5 | - | - | - | + | + | - |
| проєкт 6 | + | - | - | - | - | - |
| проєкт 7 | + | - | - | - | - | - |
| проєкт 8 | + | - | - | - | - | - |
| проєкт 9 | + | - | - | - | - | - |
| проєкт 10 | + | - | - | - | - | - |
| проєкт 11 | - | + | + | + | + | + |
| проєкт 12* | - | - | - | - | + | - |
| проєкт 13 | - | + | - | + | + | - |
| проєкт 14** | - | - | + | - | - | - |
| проєкт 15 | + | - | - | - | - | - |
*У проєктах 1 і 12 трафіку з реклами загалом було мало, але розбіжність при цьому була 70% і 98% відповідно. Перекос був на користь інших джерел, але по ним розбіжність була менше 5% через їхній численний трафік, тому вона не була включена в таблицю як суттєва.
**У проєкті 14 в BigQuery було на 6% більше (direct) / (none) і при цьому на 2% менше google / organic, через що я не включила цю розбіжність в таблицю, але по абсолютній різниці виглядало так, що істотна частина різниці органічного трафіку записалась в direct. Перевіривши цю гіпотезу в BigQuery, я побачила, що ситуація насправді дещо гірша – не тільки google / organic частково потрапив в direct. Були і інші джерела, які Google записав як direct.
Я продовжила перевіряти гіпотези щодо причин, чому ж в STSLC більше прямого трафіка і google / organic.
Щодо google / organic я знайшла закономірність – зазвичай таке траплялось через відсутність utm-розмітки: навіть за наявності gclid, навіть з gbraid, що однозначно вказує на рекламний клік, часто в джерелах було записано google / organic.
На цьому моменті я думала ще раз наголосити на важливості utm-розмітки, але другий скрін трохи навів на мене смуток…
Бо навіть за наявності розмітки, Google може її “не побачити”, і приписати рекламний перехід з Google, скажімо …інстаграму.
Але таких випадків, як на другому скріні значно менше, тому utm мітки здатні суттєво покращити трекінг – не забувай про них!
Ось приклад, який може це підтвердити – проєкт 13, де менше google / cpc, більше google / organic і наче замість google / cpc щось інше:
Тут очевидно, що те, що мало б визначитись як google / cpc, записане в BigQuery в джерело syndicatedsearch.goog / referral. Що виглядає помилкою, але насправді нею не є, як і у випадку з google / organic. Причина в тому, що логіка джерел в manual_source орієнтується на utm розмітку. Але її у випадку з syndicatedsearch.goog немає, тому джерелом і визначився домен сайту, з якого був перехід (page_referrer):
Інтерфейс в своїй моделі визначення джерел орієнтується і в т.ч. і на gclid, тому там він може використати дані по gclid з рекламного кабінету (звісно, якщо Google Ads підключений до GA4), і вивести вам такий трафік, як google / cpc, навіть незважаючи на відсутність розмітки.
Узагалі, навіть якщо порахувати в BigQuery юзерів з google / cpc і з syndicatedsearch.goog / referral, число все одно не співпаде з GA4, але на цю різницю так само впливає відсутність міток, бо частина google / cpc потрапляє в google / organic, і дає перекос на користь органіки.
Сподіваюсь, цими прикладами мені вдалось донести важливість utm-розмітки, і що не варто покладатись тільки на автопомітку.
Окремі цікаві кейси
Давайте тепер пройдемось по іншим, більш цікавим кейсам зі скріншотами.
А саме по проєктам 3 і 11, де розбіжностей найбільше.
Проєкт 3
Скріншот з інтерфейсу GA4. Виділила період і останні 4 цифри ID ресурсу. Бік-о-бік порівняння буде нижче.
Скріншот із BigQuery. Ті ж 4 останні цифри ID ресурсу. Той же період у запиті.
А от і скрін для порівняння даних. Співпав тільки bing / organic… А google / cpc розподілився між органікою, google_pm, doubleclick i syndycatedsearch.
У цьому проєкті посилання з google_pm не мали utm_medium, тому Google визначав то organic, то referral згідно своїх алгоритмів обробки. Моя думка тут в тому, що мало додавати мітки, треба ще й використовувати їх правильно.
Проєкт 11
Інтерфейс GA4:
Результати в BigQuery:
І скріншот для порівняння:
Тут, я думаю, навіть коментарі зайві і достатньо просто порівняти перші рядки…
Фінальні думки
Результати цього дослідження мене здивували. Я очікувала побачити дані, як в звіті Traffic Acquisition (Джерела трафіку) в GA4. Звісно, що він далекий від ідеалу, проте було відчуття, що тепер є атрибуція по сесії, яку треба буде трошки допилити, і можна використовувати. Але результати ви бачили самі. Комусь “пощастило” більше, і дані між session_traffic_source_last_click та інтерфейсом майже однакові, а десь вони дуже різні.
Основна причина розбіжності – або відсутність utm-розмітки, або її нелогічна структура.
Звісно, ви можете використовувати мітку типу utm_source=google_ads&utm_medium=ppc, але скоріш за все в інтерфейсі ви все одно побачите google / cpc, бо загальноприйнята і “логічна” назва цього джерела саме така. І Google оброблює свій рекламний трафік саме як google / cpc. Тут довідка.
Задовго до цього порівняння і до того, як з’явились нові поля, ми в команді, звісно, мали власний скрипт на SQL по визначенню джерел сесій по моделі last non-direct і використовували його на наших проєктах. Після появи нових полів було враження, що скрипт втратив свою цінність. Але перед тим, як відправляти його на пенсію, я вирішила перевірити це і подивитись, що він визначить на проєктах, де дані між інтерфейсом і STSLC зійшлись. На мою думку, немає сенсу порівнювати там, де дані відрізнялись бо тут зрозуміло, що власний скрипт виправив би ті нюанси з визначенням джерел в STSLC. Цікаво було дізнатись, чи може власна логіка обробки визначати джерела ще краще, ніж інтерфейс і STSLC одночасно.
Наприкінці червня 2024 ми з Максом провели вебінар, де розповіли про визначення джерел в інтерфейсі GA4, а також поділились нашим скриптом для BigQuery. Якщо цікаво, ви можете переглянути запис на PROANALYTICS.ACADEMY.
В результаті в 5 проєктах з 6 наш скрипт визначав джерела справді краще і загалом показував менше direct трафіку. Нижче на скріні приклад типової картини порівняння в цих 5 проєктах:
page_referrer- сторінка, з якої перейшли,page_location- сторінка, на яку перейшли,source_medium- значення з полів session_traffic_source_last_click.manual_campaign.source і session_traffic_source_last_click.manual_campaign.medium,source_medium_proanalytics_script- значення source і medium в результаті обробки тих же даних нашим скриптом
Я не маю іншого пояснення, чому Google не визначив джерело за наявності розмітки і реферера, окрім того, що це баг. За довідкою ці джерела мали б бути. І саме за принципами з довідки працює і наш скрипт, але, звісно, з певними покращеннями, оскільки сирі дані дають повну свободу обробки. Покращення заключається не тільки у виправленні подібних помилок. Скрипт також:
- ігнорує платіжні системи за всю історію даних, а не тільки з часу виключення їх в списку рефералів,
- не враховує внутрішню розмітку, що є в цілому поганою практикою,
- об'єднує піддомени соцмереж в одну назву (facebook/instagram) та відносить такий трафік в канал social, замість referral,
- не визначає як джерело трафіку повернення на сайт після реєстрації / логіну з акаунту Google / Microsoft / YouTube,
- виправляє нелогічну розмітку Google Ads на google / cpc та явно визначає трафік, який не був розмічений utm. До речі, в інтерфейсі у такого трафіку буде кампанія “(organic)”.
Нові поля – це хороший крок вперед. При правильній розмітці ви дійсно можете отримати атрибуцію last non-direct "з коробки". Проте це рішення, як ви бачите, має свої баги і недоліки, які можна пофіксити тільки написавши власну логіку визначення джерел.
І наостанок:
Як самостійно порівняти дані на своєму проєкті
Якщо ви хочете самостійно перевірити, чи співпадають дані в STSLC з інтерфейсом, тоді зробіть наступне:
- Запустіть в BigQuery цей скрипт, попередньо змінивши в ньому “project_id.analytics_dataset” на ID свого проєкту та датасет з даними GA4, який має формат
analytics_{{ID потоку}}.
А також змініть період даних на потрібний.
SELECT
IFNULL(IF(source_medium = '(not set) / (not set)', '(direct) / (none)', source_medium), '(not set)') AS source_medium,
COUNT(DISTINCT user_pseudo_id) AS users
FROM (
SELECT
user_pseudo_id,
CONCAT(
COALESCE(session_traffic_source_last_click.manual_campaign.source, '(not set)'), ' / ',
COALESCE(session_traffic_source_last_click.manual_campaign.medium, '(not set)')) AS source_medium,
FROM
-- change project_id.analytics_dataset to your project id and analytics dataset
`project_id.analytics_dataset.events_20*`
WHERE user_pseudo_id IS NOT NULL
AND PARSE_DATE('%y%m%d', _table_suffix)
-- start and end of the data period
BETWEEN '2024-08-01'
AND '2024-08-31'
)
GROUP BY 1
ORDER BY 2 DESCРезультати збережіть в таблицю будь-яким із способів:
2. В інтерфейсі GA4 перейдіть в Reporting Identity (Способи ідентифікації) та змініть метод на Device-Based (Залежно від пристрою), якщо до цього він був іншим. Після звірки зможете повернути, як було до цього.
3. Далі йдемо в Explore (Дослідити), і там побудуйте звіт за той же період, який у вас в першому пункті, з параметром Session source / medium (Джерело / канал сесії) та показником Total Users (Всі юзери). І теж вивантажте результат в таблицю.
4. Порівняйте розбіжність з допомогою VLOOKUP або іншим звичним чином. Якщо різниця по каналам в рамках 5%, можете використовувати дані з STSLC. Якщо ні, то використовувати їх не раджу, і краще писати власну логіку. Якщо ж вам потрібна допомога у вирішення такої складної задачі - ви можете звернутись за допомогою до нашої команди аналітиків.
Comments