«Unassigned» в Google Analytics 4: як не втратити дані при переході на GA4 

Якщо на вашому сайті встановлено аналітику від Google, ви ймовірно в курсі, що з першого липня 2023 року Google поступово відключає для ресурсів доступ до Universal Analytics. На заміну ж Google пропонує Google Analytics 4 — нову версію аналітики з новими особливостями. 

Ми завершили перехід на GA4 в липні 2023 року, але перед цим зіштовхнулися з проблемою, рішення якої не знайшли на теренах українськомовного інтернету — транзакції в звітах не були прив’язані до конкретних джерел трафіку. Органіка чи дірект, реклама чи реферальний трафік — ми не знали, звідки приходять люди, які купують наші продукти. Страшний сон будь-якого аналітика.

Проблему ми вирішили, бо маємо кращого в світі Head of Analytics, але в процесі зрозуміли, що маємо закрити прогалину в інформації, яку залишив Google, та поділитися нашим досвідом у блозі.

Тож як не втратити важливі дані при переході на GA4 — розповідаємо далі 👇

Передмова: як виникла проблема з «Unassigned» при нашому переході на GA4

Віктор, наш Head of Analytics, почав перехід на GA4 ще минулого року, і не дивлячись на прекрасну команду, цей перехід не був найлегшим.

Три задачі переросло в пʼять, пʼять в десять, а десять в 👇

Ми зідзвонювалися з представниками Google, виясняли, чому не сходяться дані, боролися з новими звітами, і нарешті задачі почали підходити до завершення. Залишалася одна фінальна перевірка GA4 Віктором, після якої перехід можна було вважати завершеним.

Але на цьому моменті Віктор побачив проблему, яка робила всю аналітику беззмістовною.

Тож далі ми почали розбиратися з проблемою Unassigned-трафіка.

Щоб краще зрозуміти, що таке непризначений трафік, чому він виникає та як з цим боротися — далі наводимо вільний переклад статті «How to Fix Unassigned in Google Analytics 4» Джуліуса Федоровітчіуса.

Що таке «Unassigned» в Google Analytics 4

По-перше, нам потрібно коротко оглянути групу каналів за замовчуванням. Google Analytics 4 може групувати різні джерела трафіку в більші сегменти, які дають узагальнено розуміти, які канали є найкращими для вашого бізнесу.

Наприклад, у вас може бути трафік із органічного пошуку Bing і органічного пошуку Google. Обидва ці джерела трафіку буде додано до групи каналів органічного пошуку за замовчуванням.

Наразі існує 18 груп каналів за замовчуванням:

• Афіліати (Affiliates). Користувачі потрапляють на ваш сайт або в додаток, перейшовши за посиланням на партнерському сайті.
• Аудіо (Audio). Користувачі потрапляють на ваш сайт або в додаток завдяки оголошенням на платформах для прослуховування на кшталт Spotify.
• Різні мережі (Cross-network). Користувачі потрапляють на ваш сайт або в додаток завдяки оголошенням у різних мережах, наприклад, у пошуковій і медійній.
• Прямий трафік (Direct). Користувачі потрапляють на ваш сайт або в додаток, натиснувши збережене посилання чи ввівши конкретну URL-адресу.
• Медійна реклама (Display). Користувачі потрапляють на ваш сайт або в додаток завдяки медійним оголошенням, зокрема рекламі в медійній мережі Google.
• Електронна пошта (Email). Користувачі потрапляють на ваш сайт або в додаток, натиснувши посилання в листі.
• Push-сповіщення на мобільних пристроях (Mobile Push Notifications). Користувачі відкривають ваш сайт або додаток, натиснувши посилання в push-повідомленні на мобільному пристрої.
• Звичайний пошук (Organic Search). Користувачі потрапляють на ваш сайт або в додаток, натиснувши посилання без реклами в результатах звичайного пошуку.
• Звичайні покупки (Organic Shopping). Користувачі потрапляють на ваш сайт або в додаток, натиснувши посилання без реклами на торговельному сайті, наприклад, на Amazon чи ebay.
• Звичайний трафік із соцмережі (Organic Social). Користувачі потрапляють на ваш сайт або в додаток, натиснувши посилання без реклами в соціальній мережі.
• Звичайне відео (Organic Video). Користувачі потрапляють на ваш сайт або в додаток, натиснувши посилання без реклами у відео на YouTube, в TikTok тощо.
• Інша платна реклама (Paid Other). Користувачі потрапляють на ваш сайт або в додаток завдяки рекламі на інших ресурсах, не на торговельному чи пошуковому сайті, в соціальній мережі чи відео.
• Пошукова реклама (Paid Search). Користувачі потрапляють на ваш сайт або в додаток завдяки рекламі на пошукових сайтах.
• Платна реклама на торговельних сайтах (Paid Shopping). Користувачі потрапляють на ваш сайт або в додаток завдяки платній рекламі на торговельному майданчику, наприклад, Amazon чи ebay, чи власному сайті роздрібного продавця.
• Платна реклама в соцмережах (Paid Social). Користувачі потрапляють на ваш сайт або в додаток завдяки рекламі в соцмережі.
• Платна реклама у відео (Paid Video). Користувачі потрапляють на ваш сайт або в додаток завдяки рекламі у відео.
• Перенаправлення (Referral). Користувачі потрапляють на ваш сайт або в додаток, натиснувши посилання без реклами на іншому сайті.
• SMS. Користувачі потрапляють на ваш сайт або в додаток, натиснувши посилання в текстовому повідомленні.

Існують фіксовані правила  щодо того, як Google призначає певне джерело трафіку кожній із цих груп. Наприклад, якщо відвідувач прийшов із відомого сайту соціальної мережі, а utm_medium містить «cpc», це буде додано до Paid Social.

Ви можете переглянути список усіх правил в довідці GA4, перейшовши до розділу «Канали для ручного трафіку».

Але якщо джерело трафіку (його канал, джерело чи інший параметр) не охоплюється цими правилами, група каналів за замовчуванням буде скасована, оскільки Google Analytics 4 не знає, до якої групи слід призначити це джерело трафіку.

Тепер, коли ми трохи знайомі з концепцією групи каналів за замовчуванням, давайте:

1. розберемося, як визначити, який тип трафіку відображається як «Unassigned»;
2. розглянемо різні ситуації, чому ви можете отримати Unassigned в GA4. 

Однак підкреслимо, що не всі з цих ситуацій мають відомі рішення (принаймні зараз).

Стаття з теми:

View Post

Крок 1.2. Як встановити Google Analytics на сайт

Читати статтю

Як визначити, який тип трафіку відображається як «Unassigned»

В Google Analytics 4 перейдіть до вкладки Reports > Acquisition > Traffic Acquisition. Радимо налаштувати англомовний інтерфейс GA, бо так зручніше працювати з інструкціями. 

Оскільки GA4 дозволяє налаштовувати стандартні звіти, ваша ліва бічна панель може виглядати інакше. Отже, якщо ви не бачите розділу «Acquisition» на лівій бічній панелі, просто продовжуйте клацати та шукати звіт, пов’язаний із залученням трафіку.

Параметром за замовчуванням у цьому звіті є Default Channel Group, тобто група каналів за замовчуванням.

Якщо ви бачите там «Unassigned», давайте визначати, який трафік вважається непризначеним.

Натисніть на іконку з плюсом у таблиці та додайте вимір Session source / medium. Далі в рядку пошуку введіть «Unassigned» і натисніть Enter. 

Має вийти приблизно таке:

А тепер давайте розглянемо причини, чому виникає непризначений трафік, і можливі рішення проблеми.

Чому виникає непризначений трафік

Десять причин, чому в вашій аналітиці може зʼявлятися Unassigned-трафік:

#1 Ваші параметри UTM не відповідають правилам Google

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

Якщо ви знаєте про це та готові розшукувати трафік з певних маркетингових кампаній вручну — це одна справа. 

Однак іноді компанії позначають свої маркетингові кампанії UTM-параметрами, які є некоректними, просто не знаючи про це. Замість того, щоб використовувати, наприклад, utm_medium=email, вони використовують utm_medium=em, або utm_medium=mail тощо. 

Ні «em», ні «mail» не будуть розпізнані GA4; таким чином, у вас буде непризначена розсилка.

Правильними значеннями utm_medium для email-маркетингових кампаній є «email», «e-mail», «e_mail», «e mail». Якщо ви використовуєте одне з цих значень, трафік вашої email-маркетингової кампанії буде призначено до групи каналів за замовчуванням «Email».

Тому завжди слідкуйте за списком правил з довідки Google-аналітики. Якщо можливо, намагайтеся використовувати значення, які GA4 розпізнає автоматично.

Крім того, ви можете створити кастомні групи каналів в GA4, які можуть розпізнавати ваші власні значення UTM. Але в цьому випадку майте на увазі, що Unassigned залишиться в групі за замовчуванням.

Але що робити, якщо більша частина вашого Unassigned-трафіку є (not set)?

Ця частина трохи болюча та дратує багатьох аналітиків. Деякі речі можна виправити, а деякі трапляються без видимої причини.

Давайте розглянемо різні варіанти. 

#2 Переконайтеся, що тег конфігурації GA4 спрацьовує першим

Схоже, що якщо тег події GA4 спрацьовує перед тегом конфігурації GA4, це також може збільшити кількість «Unassigned» джерел/каналів. Тому ви можете налаштувати тег конфігурації GA4 так, щоб він спрацьовував при Initialization — All pages тригері. 

Потім, якщо у вас є теги подій, які спрацьовують на тригері «Перегляд сторінки», спробуйте затримати їх, наприклад, встановивши їх на спрацьовування на тригерах DOM ready або Window Loaded.

Це особливо важливо для налаштувань Google Tag Manager на стороні сервера. У тегу конфігурації GA4 ви маєте вказати URL-адресу кінцевої точки на стороні сервера. Якщо тег події спрацює раніше, ніж тег конфігурації, він не знатиме URL-адреси вашого сервера, і це призведе до різних неприємних наслідків. Один з них — (not set) у звітах.

#3 Трансляція подій з інших платформ до GA4

Деякі інструменти та платформи пропонують функцію трансляції подій в GA4, наприклад, сервіси Amplitude або Segment. 

Можна припустити, що вони, ймовірно, також використовують протокол вимірювання GA4. Оскільки вони (знову ймовірно) не надсилають ідентифікатор сеансу, всі ці події буде віднесено до (not set) джерела/каналу. Отже, ви отримаєте Unassigned у GA4.

Що робити? Можливо, вам варто розглянути пряме, стандартне встановлення GA4 через Google Tag або Google Tag Manager.

#4 Тригери аудиторії

Коли в Google Analytics 4 з’явилася ця функція, вона дозволила аналітикам створювати більш складні аудиторії, і коли відвідувач потрапляє в цю аудиторію, GA4 автоматично відправляє подію.

Але пізніше виявилося, що тригери аудиторії також збільшують кількість (not set) джерел трафіку. Це відбувається не завжди, тому результати/обсяг цієї проблеми будуть відрізнятися на різних ресурсах.

Якщо ваш тригер аудиторії пов’язаний з прогнозованою аудиторією, то, швидше за все, подія не буде додана до жодної існуючої сесії. Таким чином, джерелом/каналом буде (not set) / (not set), що призводить до Unassigned в Google Analytics 4.

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

На жаль, рішення для цього немає. Тригери аудиторії обробляються в бекенді Google Analytics 4. Тому якщо ви використовуєте тригери (не плутайте з тригерами Google Tag Manager), то змиріться з тим, що ви отримаєте більше (not set) джерел трафіку, ніж зазвичай.

#5 Параметри UTM неповні чи неправильні

Якщо ви використовуєте параметри UTM, завжди вказуйте принаймні utm_source, utm_medium та utm_campaign.

Більшість правил в документації GA4 розглядають utm_source і utm_medium. Деякі з них розглядають utm_campaign.

Якщо посилання ваших маркетингових кампаній мають, наприклад, просто utm_campaign (example.com/?utm_campaign=upsell), то utm_medium і utm_source будуть (not set). Отже, ця кампанія буде Unassigned в Google Analytics 4.

Тому візьміть за правило завжди використовувати щонайменше 3 параметри UTM: utm_medium, utm_source, utm_campaign.

#6 Дані ще не були повністю оброблені GA4

Google Analytics потрібен певний час для обробки даних — від 24 до 48 годин. Тому, якщо ви подивитеся на свої звіти та перевірите вчорашні або сьогоднішні дані, ви можете побачити сплеск нерозподіленого трафіку.

Це нормально в GA4, тож треба просто почекати. Перевірте той самий діапазон дат завтра, і в розділі «Unassigned» в Google Analytics 4 має бути менше сеансів.

#7 Проблеми з тегуванням

Якщо ви пов’язуєте свій ресурс GA4 з різними рекламними платформами на кшталт Google Ads, Display & Video 360 тощо, то Google рекомендує використовувати автоматичне позначення тегами замість ручного тегування. Це пов’язано з тим, що автоматичне позначення тегами надає більше параметрів, ніж теги вручну.

Крім того, якщо ви використовуєте ручне та автоматичне позначення тегами разом, то source, medium та інші параметри класифікації трафіку використовують значення автоматичного тегу.

Завдяки автоматичному позначенню ви зменшуєте ймовірність втратити джерела, канали та/або інформацію про кампанію, тобто в результаті GA4 звітує про набагато меншу кількість непризначеного трафіку.

#8 Відсутня подія запуску сеансу

Цей пункт загадковий. Сесії з (not set) джерелами трафіку часто не мають події session_start, яка автоматично відправляється GA4.

Перша причина, яка спадає на думку — це тегування на стороні сервера. Можливо, у вас є налаштування, де ця подія виключена та не надсилається з вашого тегуючого сервера до GA4. Або, можливо, ваш тег чи теги події GA4 іноді спрацьовує раніше, ніж тег конфігурації GA4.

На жаль, ще не можна сформулювати точні інші причини, чому це відбувається та як цього уникнути. Зараз це найбільше схоже на помилку Google Analytics.

#9 Це також має щось спільне з ідентифікацією користувачів

GA 4 ідентифікує відвідувачів різними методами: за допомогою ідентифікатора користувача, файлів cookie, сигналів Google тощо. Одного разу у Джуліуса був проєкт, який зіткнувся з великою кількістю Unassigned-сесій. Після того, як Джуліус перевірив усі відомі рішення, він так і не зміг визначити причину. Тому почав змінювати різні налаштування, щоб побачити, чи допоможе щось.

Очевидно, зміна ідентифікатора звітності на Device-based (як Джуліус пояснює тут) допомогла, і кількість непризначених сесій значно зменшилася. Все ще важко назвати точну причину, що викликає цю проблему, але варто знати, що зміна ідентифікатора звітності також може бути варіантом вирішити це.

#10 Ви неправильно використовуєте протокол вимірювань

Протокол вимірювань або Measurement Protocol — це один із способів надсилати дані до GA4. Він призначений, щоб надсилати дані з вашого сервера (наприклад, з CRM) до Google Analytics 4. Однак він призначений для збагачення даних, зібраних вами на вебсайті, він не ініціює нові сеанси та не створює нових користувачів.

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

Якщо ваші розробники надсилають дані через Measurement Protocol поточному активному сеансу на вашому сайті, кожна подія повинна містити параметри client_id та session_id. Якщо параметр session_id не вказано (або session_id не збігається з ідентифікатором поточного активного сеансу), джерело трафіку для цього сеансу не буде встановлено.

Якщо ваші розробники надсилають дані через Measurement Protocol до сеансу, який вже закінчився (але не старше 72 годин), вони також повинні надіслати параметр timestamp_micros. Якщо цього не буде зроблено, то ви вже здогадалися — джерело/канал не буде встановлено.

Ось відео-туторіал, в якому Джуліус показує, як правильно використовувати Measurement Protocol. 

Що саме створювало непризначений трафік в нашій аналітиці та як ми це вирішили

Наша проблема з GA4 виникла саме через останню причину з перерахованих у попередньому розділі — через проблему з протоколом вимірювання.

Яке рішення знайшли

Коли в пошуках рішення сторінки в Google почали завершуватися, Віктор нарешті натрапив на статтю одного ізраїльського аналітика на імʼя Or Blan. 

Or Blan допомагав клієнту мігрувати на GA4 та зіштовхнувся з тою самою проблемою, що і ми: звіти, що пов’язували конверсію з відвідуваннями користувачів, не працювали, і ніхто не знав, чому. Далі перекладаємо та вільно переказуємо його статтю.

Коли він почав розбиратися в проблемі, то виявив, що його клієнти не передавали параметр session_id у протоколі вимірювання в GA4. Через те що GA4 на відміну від універсальної аналітики побудований на подіях, а не на сесіях, ми і маємо додатково передавати session_id.

Google, м’яко кажучи, не найкраще попрацював над документацією GA4 і на момент написання статті там нічого не було щодо ідентифікатора сесії. Однак Or Blan зміг знайти цю примітку до релізу від травня 22-го року, в якій вводився параметр session_id. Подальші дослідження привели його до цієї теми, в якій хтось на ім’я Кевін з команди Google Analytics API визнає, що Google потрібно оновити свою документацію з цього питання, але не може вказати конкретні терміни.

Тож нижче ви знайдете відповідь, як додати session_id до протоколу вимірювання GA4 та де цей ідентифікатор взяти. 

Згідно з Google: «Для того щоб активність користувача відображалася в стандартних звітах, таких як Realtime, engagement_time_msec і session_id повинні бути передані як частина параметрів для події».

Це означає, що session_id має бути частиною масиву параметрів корисного навантаження як такого:

{
"client_id": "123123123",
"events": [
  {
    "name": "offline_purchase",
    "params": {
      "engagement_time_msec": "100",
      "session_id": "123456"
    }
  }
]}

Отже, тепер, коли ми знаємо, куди його покласти, нам потрібно знайти, як витягнути session_id та звідки. 

Коли запускається подія session_start, GA створює новий session_id, але він не є частиною файлу cookie _ga, як це було в Universal, він є частиною нового файлу cookie, який містить container_id і виглядає приблизно так: _ga_XXXXXXXXXXXX, де X означає ідентифікатор потоку.

Тут ви можете побачити приклад, в якому виділена частина — це session_id:

Це ідентифікатор сеансу в файлі cookie.

Безпосередньо перед session_id знаходиться session_count, тобто числовий лічильник сеансів, в даному випадку — це перший сеанс. 

Тепер все, що вам потрібно зробити, це вказати вашому розробнику на це число, яке потрібно витягнути з клієнта, а потім передати його в протокол вимірювання як параметр session_id в масиві params.

Як отримати ідентифікатор сесії

Щоб отримати ідентифікатор сесії, ви можете використати цей скрипт:

function getSessionNumber() {
// replace ABCDEFG with your GA Stream ID
  const pattern = /_ga_ABCDEFG=GSd.d.(w+).(d+)/;
  const match = document.cookie.match(pattern);
  const sessionNumber = match?.[2];

  if (!sessionNumber) {
    // Cookie not yet available; wait a bit and try again.
    window.setTimeout(() => getSessionNumber(callback), 200);
    return;
  }

  return sessionNumber;
}

Якщо ви використовуєте GTM, можете скористатися цим скриптом:

function getSessionId() {
  var pattern = /_ga_0J0X8GBMJE=GSd.d.(w+).(d+)/;
  var match = document.cookie.match(pattern);
  var sessionId = match && match[1];

  if (!sessionId) {
    return;
  }

  return sessionId;
}