Глосарій

Сесія (Session)

Сесія (Session, сеанс) — період активної взаємодії користувача з сайтом або застосунком. За замовчуванням завершується після 30 хвилин бездіяльності. Базова одиниця вимірювання трафіку в Google Analytics.

Звивистий шлях з аватарами людей цілями і зірками — customer journey і сесії

Сесія (Session), або сеанс, — це базова одиниця вимірювання трафіку в будь-якій системі веб-аналітики. Сесія охоплює групу взаємодій користувача з сайтом або застосунком, що відбуваються в обмеженому часовому вікні: перегляди сторінок, кліки, заповнення форм, події, прокрутки, покупки. Через сесії вимірюються трафік, джерела, поведінка, конверсії та майже всі інші метрики Google Analytics. Розуміння того, як саме GA4 та Universal Analytics рахують сеанси, критично важливе для коректної інтерпретації звітів — особливо при порівнянні періодів або міграції на GA4.

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

Як рахується сесія

Кожна сесія має початок і кінець. Сесія починається, коли користувач:

  • зайшов на сайт уперше;
  • повернувся на сайт після 30 хвилин відсутності активності;
  • зайшов з новою міткою кампанії (нові UTM-параметри → нова сесія в Universal Analytics);
  • зайшов у новий день після опівночі (тільки UA, в GA4 цього правила більше немає).

Сесія закінчується:

  • через 30 хвилин бездіяльності (поріг налаштовується, про це нижче);
  • рівно опівночі за часовим поясом акаунту в Universal Analytics (у GA4 — ні);
  • при зміні utm_source / utm_medium / utm_campaign в URL у Universal Analytics.

У GA4 кожна сесія отримує унікальний ідентифікатор ga_session_id — його можна використовувати в BigQuery і для власних дашбордів.

Як побачити session_id у BigQuery

SELECT
  user_pseudo_id,
  (SELECT value.int_value FROM UNNEST(event_params) WHERE key='ga_session_id') AS session_id,
  COUNT(*) AS events
FROM `project.analytics_XXX.events_*`
GROUP BY 1, 2
ORDER BY events DESC

Сесії в GA4 vs Universal Analytics

GA4 замінив Universal Analytics 1 липня 2023 року, і підхід до сеансів у ньому принципово інший. Головні відмінності зведені в таблицю:

ПараметрUniversal AnalyticsGoogle Analytics 4
ІдентифікаторsessionID + clientIDga_session_id (event parameter)
Тайм-аут за замовчуванням30 хвилин30 хвилин (можна від 5 хв до 7 год 55 хв)
Кінець сесії опівночіТакНі
Нова сесія при зміні кампаніїТак (нова utm)Ні
Облік ботівНе враховуються відомі ботиНе враховуються за списком IAB/ABCe
«Перегляд» як обов’язкова подіяТакНі — сесія може складатися з будь-яких подій
Engaged SessionНова концепція (див. нижче)
Сесія після опівночіПерериваєтьсяПродовжується

Головний практичний наслідок: у GA4 сесій зазвичай менше, ніж було в Universal Analytics на тому самому трафіку, бо один користувач, який переходить з різних рекламних міток за день, в UA створював кілька сесій, а в GA4 — одну.

Що таке Engaged Session

Це нова концепція GA4, якої не було в UA. Engaged session (залучений сеанс) — сесія, в якій користувач:

  • провів на сайті більше 10 секунд (поріг налаштовується від 10 до 60 секунд),
  • АБО переглянув 2+ сторінки / екрани,
  • АБО здійснив хоча б одну конверсію (Key Event).

Engaged sessions потрібні для розрахунку Engagement Rate — головної поведінкової метрики GA4, що замінила старий bounce rate. Формула: Engagement Rate = Engaged Sessions / Total Sessions. Bounce Rate в GA4: 100% − Engagement Rate.

Це означає, що в GA4 сесія — це не «просто захід», а подія з виміряною глибиною залучення. На тих самих даних GA4 та UA дадуть різний bounce rate і різні числа сесій — це не баг, а інша логіка підрахунку.

Тайм-аут сесії: 30 хвилин — це базове значення

Стандартний тайм-аут — 30 хвилин, але його можна змінити в налаштуваннях:

  • GA4: Admin → Data Streams → обрати потік → Configure tag settings → Adjust session timeout. Допустимий діапазон — від 5 хвилин до 7 годин 55 хвилин.
  • Universal Analytics (легасі): Admin → Property Settings → Tracking Info → Session Settings.

Коли зменшувати (наприклад, до 5–10 хвилин):

  • Контентні сайти з короткими візитами, щоб не «склеювати» повернення в одну сесію.
  • Новинні портали.
  • E-commerce з чітко короткими сесіями вибору.

Коли збільшувати (до 1–2 годин):

  • Складні SaaS і навчальні платформи з довгими відеоуроками.
  • Відеоплеєри з тривалим переглядом.
  • Форми замовлення з довгим заповненням (нерухомість, автокредити).
  • B2B-демо-сервіси, де користувач може робити паузи.

Будь-яка зміна застосовується лише до нових даних — перерахувати минулі періоди не можна.

Сесії vs користувачі vs події

Ці три поняття часто плутають:

  • Користувач (User) — унікальний відвідувач, ідентифікується за Client ID (cookie) або user_pseudo_id у GA4. Один користувач може створити багато сесій у різні дні.
  • Сесія (Session) — одне «відвідування», одне часове вікно активності.
  • Подія (Event) — окрема дія всередині сесії: перегляд сторінки, клік, скрол, покупка. У GA4 все — події, включно з session_start і page_view.

Ієрархія: Користувач → Сесії → Події. Один користувач може за місяць створити 5 сесій, у кожній сесії — 20 подій, разом 100 подій у GA4.

Метрики: Users (унікальні), Sessions (відвідування), Events (всі дії). Як правило: Users < Sessions < Events приблизно у пропорції 1:1.5:30 для типового сайту.

Сесії та кешування

Якщо на сайті використовується агресивне кешування (Cloudflare, Varnish, статичні генератори на кшталт Hugo) і не налаштований server-side tagging, можуть виникати аномалії: один і той самий користувач визначається як новий через те, що cookie не встигає зберегтися. Ознака проблеми — дуже високий відсоток нових користувачів при стабільному трафіку і штучно завищене число сесій.

Рішення:

  1. Використовувати Google Tag Manager Server-Side для надійної установки cookie з правильним TTL.
  2. Увімкнути First-Party Cookies (за замовчуванням у GA4).
  3. Для сайтів на статичних генераторах — стежити, щоб скрипт GA4 завантажувався після основної розмітки і не блокувався кешем.
  4. Перевірити Cloudflare налаштування — Cache Everything з cookies руйнує сесії.

Сесії та cross-domain tracking

Якщо бізнес працює на кількох доменах (наприклад, основний сайт + окремий кошик або піддомен з блогом), без налаштування cross-domain tracking GA4 рахуватиме перехід між ними як нову сесію — з усіма наслідками: дублюванням користувачів, обнуленням джерела, спотворенням воронки.

У GA4 cross-domain налаштовується в Admin → Data Streams → Configure tag settings → Configure your domains. Туди вписуються всі домени, які мають вважатися одним «сайтом».

Технічно GA4 додає до URL параметр _gl (linker parameter), що зашифровано передає Client ID між доменами. Перевірка: відкрийте сайт, натисніть посилання на другий домен — у URL з’явиться ?_gl=1*xxx. Якщо немає — cross-domain не працює.

Сесії від ботів

GA4 автоматично фільтрує відомих ботів за списком IAB/ABCe (Interactive Advertising Bureau / Audit Bureau of Circulations Europe). Це включає Googlebot, Bingbot, AhrefsBot, SemrushBot та сотні інших краулерів. Бот-сесії не потрапляють у звіти.

Однак сучасні AI-боти (GPTBot OpenAI, ClaudeBot Anthropic, PerplexityBot, Google-Extended) можуть не входити у списки IAB — і деякі їх запити рахуються як сесії. Рішення:

  1. Налаштувати internal traffic exclusion за User Agent у GA4.
  2. Заблокувати непотрібних AI-ботів у robots.txt: User-agent: GPTBot \n Disallow: /.
  3. У Cloudflare увімкнути Bot Fight Mode — фільтрує до 90% автоматизованого трафіку перед GA4.

Перевірка: GA4 → Tech → Browser. Якщо у топі ‘Other’ з 30%+ — у вас бот-проблема.

Де дивитися сесії в GA4

  • Reports → Acquisition → Traffic acquisition — сесії за джерелами, каналами, кампаніями.
  • Reports → Engagement → Pages and screens — сесії та engagement за сторінками.
  • Reports → User → Demographics / Tech — сесії за аудиторіями та пристроями.
  • Explore → Free form / Funnel exploration — кастомна аналітика сесій.
  • BigQuery export — сирі дані, де кожен рядок = подія, а зв’язка user_pseudo_id + ga_session_id = одна сесія.

У Looker Studio через конектор GA4 поле називається Sessions. Зверніть увагу: показник «sessions» у звітах GA4 та в API можуть трохи відрізнятися через семплування на великих обсягах даних.

Типові помилки з аналізом сесій

  1. Порівняння сесій GA4 з UA напряму. У GA4 сесій менше через нову логіку. Тренди порівнюйте у межах однієї системи.
  2. Не налаштований cross-domain. Переходи між субдоменами рахуються як нові сесії і обнуляють джерело.
  3. Не виключений internal traffic. Команда заходить щодня, шум.
  4. Тайм-аут 30 хв для довгих сесій. Навчальні платформи, відео штучно збільшують Bounce Rate.
  5. Аналіз сесій без engaged vs all. Частина ‘сесій’ у GA4 — це bounces (5 секунд).
  6. Кешування ламає Client ID. Користувачі визначаються як нові, false-зростання трафіку.
  7. Сесії від ботів. GPTBot/ClaudeBot потрапляють у звіти. Перевірте Browser report.
  8. Не розрізняння Sessions vs Engaged Sessions у Looker Studio. Два різні поля, плутаються при ручному дашборді.

Пов’язані матеріали