Ga alternatives

Cookieless-аналітика: підходи й інструменти

Що таке cookieless-аналітика, навіщо вона потрібна, як працює server-side tracking і first-party cookies, які інструменти використовувати й чого очікувати від точності даних.

Зміст

Cookieless-аналітика — це вимірювання трафіку й поведінки користувачів без зберігання ідентифікаторів у cookie-файлах браузера. Коли Safari почав блокувати third-party cookies через ITP ще у 2017-му, а потім Firefox додав Enhanced Tracking Protection, аналітичні дані у частини аудиторії почали просто зникати. Розберемося, які підходи існують, чим різняться, і які інструменти реально можна використовувати.

Повний огляд альтернатив Google Analytics — у розділі Альтернативи Google Analytics.

До 2017 року веб-аналітика будувалася на простому принципі: поклади cookie в браузер, дай йому унікальний ID, відстежуй сесії роками. Все змінилося поступово.

Safari і ITP. Apple випустила Intelligent Tracking Prevention у вересні 2017. Спочатку ITP скорочував термін дії third-party cookies до 24 годин, потім до 1 дня, потім — повністю блокував. ITP 2.3+ (з 2019) також обмежив first-party cookies, встановлені через JavaScript: їх термін дії скоротився до 7 днів. Сайти з переважно iOS/macOS-аудиторією втратили до 40% attribution-даних.

Firefox ETP. Mozilla увімкнула Enhanced Tracking Protection за замовчуванням у вересні 2019. Third-party cookies відомих трекерів (за списком Disconnect.me) блокуються повністю.

Chrome і Privacy Sandbox. Google оголосив про відмову від third-party cookies у Chrome ще у 2020, переніс дедлайн з 2022 на 2023, з 2023 на 2024, потім на 2025. У липні 2024 Google офіційно відмовився від масового видалення third-party cookies і натомість запропонував пользувачам Chrome вибір: дозволити чи ні. Результат: більшість користувачів залишили cookies ввімкненими — але Privacy Sandbox API (Topics API, Protected Audience API) розвивається паралельно. Третьосторонні cookies у Chrome поки живуть, але майбутнє непередбачуване.

Блокувальники реклами. uBlock Origin, AdBlock Plus, Brave Browser — все це блокує аналітичні теги цілком, незалежно від cookie. За різними оцінками, від 20% до 40% desktop-користувачів мають блокувальник реклами. Ці переходи просто не потрапляють у GA4.

Три підходи до cookieless-аналітики

1. Агрегована аналітика без ідентифікаторів

Найрадикальніший підхід: відмовитися від ідентифікації користувача повністю. Система рахує перегляди сторінок і події, але не намагається прив’язати їх до конкретної людини.

Як це працює: кожен запит обробляється незалежно. Немає user_id, немає persistent cookie, немає localStorage. Щоб все ж рахувати «унікальних відвідувачів за добу», Plausible використовує щоденний хеш: IP + User-Agent + домен сайту → хеш, який скидається щоночі опівночі UTC. Ця людина прийшла вранці і ввечері — рахується один раз за цей день. Завтра — новий хеш, нова людина з точки зору системи.

Що отримуєте: кількість переглядів, унікальні відвідувачі за день/тиждень/місяць, bounce rate, UTM-параметри, країни, пристрої, джерела трафіку. Нічого більше.

Що втрачаєте: user journey між сесіями, attribution за кілька торкань, воронки між відвідуваннями, когортний аналіз.

2. First-party cookies через власний сервер

Менш радикальний підхід: залишити cookie-трекінг, але перейти на first-party cookies, встановлені безпосередньо вашим сервером (не через JavaScript).

Чому це важливо: ITP скорочує термін дії cookies, встановлених через document.cookie у JavaScript, до 7 днів. Але cookie, встановлені у HTTP-відповіді сервером (Set-Cookie header), живуть повний термін — 1-2 роки.

Наприклад, замість того щоб GA4 сам ставив _ga cookie через JavaScript (термін — 2 роки, але ITP ріже до 7 днів), ви проксуєте запит через власний сервер: сервер читає _ga cookie або генерує новий client_id і відправляє його назад браузеру через Set-Cookie. Такий cookie не підпадає під ITP.

Як налаштувати для GA4: є два шляхи.

  • Server-side GTM Container — розгортаєте GTM Server Container на своєму субдомені (наприклад, metrics.yourdomain.com), налаштовуєте GA4 Client і Tag. Запити йдуть на ваш домен, а не на analytics.google.com. Коштує від $10/міс (Cloud Run або аналоги).
  • Measurement Protocol напряму — відправляєте хіти безпосередньо з бекенду через HTTPS POST на https://www.google-analytics.com/mp/collect.

3. Server-side tracking з relay

Найбільш технічний підхід: весь трекінг переноситься на сервер. Браузер відправляє мінімальний сигнал на ваш власний endpoint, ваш сервер збагачує дані (user-agent, geo) і відправляє в аналітику.

Блокувальники реклами не можуть заблокувати запит на ваш власний домен — вони не знають, що це аналітика. Але якщо Brave Browser або uBlock Origin бачить JavaScript-тег від googletagmanager.com — вони його заблокують ще до відправки першого хіту. Server-side relay вирішує і цю проблему: на сторінці — тільки ваш JS з вашого домену.

Інструменти для реалізації: GTM Server-Side Container, Segment (Customer Data Platform), RudderStack (open-source Segment), Snowplow (self-hosted аналітика з повним контролем даних).

Інструменти cookieless-аналітики

Plausible Analytics

Plausible — легкий (< 1KB скрипт) інструмент веб-аналітики без cookie і без ідентифікаторів. Відповідає GDPR за замовчуванням, не потребує cookie-банера.

ПараметрPlausible
CookieНемає
Розмір скрипту~1 KB
ДашбордПростий, реальний час
Ціна$9/міс (до 10k переглядів)
Self-hostedТак (Docker)
User journeyНемає
Custom eventsТак
UTMТак
Фільтри воронокНі

Підходить для: контентних сайтів, блогів, SaaS-лендінгів, де важливі загальні метрики трафіку і немає потреби в атрибуції за кількома торканнями.

Не підходить для: e-commerce із складними воронками, B2B з довгим циклом угоди.

Детальний огляд — у нашому матеріалі Plausible Analytics: огляд.

Fathom Analytics

Fathom — ідеологічно схожий на Plausible, але з іншою архітектурою: використовує EU Isolation (дані зберігаються в ЄС незалежно від плану), є режим bypass ad-blockers через CNAME-запис на своєму домені.

ПараметрFathom
CookieНемає
Ціна$14/міс (до 100k переглядів)
Self-hostedНі
EU data isolationТак
Custom eventsТак
Ad-blocker bypassТак (CNAME)

Перевага над Plausible: вбудований механізм обходу блокувальників через CNAME без самохостингу.

Matomo — повнофункціональна аналітична платформа з відкритим кодом (альтернатива GA4). За замовчуванням використовує cookie, але має режим cookieless: відстеження без cookie і без localStorage, з fingerprint-підходом або чисто агрегованим.

У cookieless-режимі Matomo можна запустити без cookie-банера і залишити при цьому воронки, цілі і e-commerce-трекінг — за рахунок того, що fingerprint прив’язує сесію в рамках одного відвідування, але не між візитами.

Детальніше про Matomo — у розділі Як перейти з GA на Matomo.

GA4 не є cookieless-рішенням, але має режим роботи без даних: коли користувач відмовляється від cookie (через banner), GA4 з Consent Mode v2 все одно збирає анонімізовані агреговані ping-хіти і використовує їх для моделювання даних (behavioral modeling). Реальних даних по цих сесіях немає — Google будує ML-модель на основі тих, хто погодився.

Consent Mode v2 — обов’язковий для ринків EEA з березня 2024. Без нього Google Ads не може коректно атрибутувати конверсії у регіонах з GDPR.

Обмеження точності: що треба знати

Жодне cookieless-рішення не дає 100% точності. Ось де виникають розриви:

Проблема дублювання. Якщо одна людина зайшла з ноутбука і телефона, Plausible порахує це як два унікальних відвідувача (різні IP + User-Agent).

Проблема VPN і динамічного IP. Два різних користувачі з одного корпоративного VPN або з одного домашнього роутера матимуть однаковий IP — і Plausible злиє їх в одного.

Cross-session tracking відсутній. Якщо ваш маркетинговий цикл довший за добу, cookieless-інструменти без ідентифікаторів не покажуть атрибуцію першого торкання.

Перевага з блокувальниками. Водночас cookieless-інструменти показують реальний трафік від Safari, iOS, Firefox і від технічної аудиторії, яка масово використовує uBlock Origin. GA4 з cookie ці відвідування губить. На багатьох технічних сайтах Plausible показує на 20-30% більше відвідувань, ніж GA4 — тому що GA4 тег блокується блокувальниками, а Plausible скрипт — ні (або блокується рідше).

Порівняння інструментів за точністю:

КритерійGA4 (cookie)GA4 + server-sidePlausible
Блокувальники рекламиВтрати 20-40%Мінімальні втратиНезначні втрати
Safari ITPАтрибуція ріжетьсяЗберігаєтьсяN/A (немає атрибуції)
Cross-sessionТакТакНі
E-commerce воронкиПовніПовніБазові
GDPR без банераНіНіТак

Типові помилки при переході на cookieless

  1. Порівнювати Plausible з GA4 за абсолютними числами. Вони рахують різні речі: GA4 рахує сесії через cookie, Plausible — через денний хеш. Якщо Plausible показує на 15% більше — це нормально, не баг.

  2. Думати, що cookieless автоматично вирішує проблему ITP для GA4. ITP ріже саме GA4 cookie. Якщо ви хочете залишити GA4 і позбутися ITP-обмежень — потрібен server-side proxy, а не перехід на Plausible.

  3. Запускати cookieless-інструмент і прибирати cookie-банер для всього сайту. Якщо на сайті є Facebook Pixel, Google Ads remarketing або будь-який інший third-party трекінг — banner все одно потрібен. Cookieless лише щодо аналітики, не реклами.

  4. Ігнорувати Consent Mode v2 при використанні GA4 у ЄС. З березня 2024 Google вимагає Consent Mode v2 для коректної роботи Google Ads у EEA. Без нього конверсії атрибутуються неправильно.

  5. Вважати fingerprinting = cookieless. Fingerprinting (відстеження за комбінацією browser/screen/GPU) не є GDPR-compliant і не рекомендується як заміна cookie. Це вже гірше за cookie з точки зору приватності.

  6. Ставити два аналітичні інструменти без розуміння, якому довіряти. Якщо ви паралельно тримаєте GA4 і Plausible — заздалегідь вирішіть, яке число — джерело правди для якого рішення (GA4 = воронки і конверсії, Plausible = загальний трафік і тренди).

  7. Ігнорувати самохостинг Plausible. Plausible можна самохостити через Docker. Якщо скрипт plausible.io блокується у вашій аудиторії — власний домен вирішить проблему.

  8. Налаштувати server-side GTM і вважати завдання виконаним. Server-side container не захищає від ситуацій, коли браузер взагалі не відправляє перший запит (строгий режим Brave). Для Brave потрібен CNAME або власний JS без будь-яких зовнішніх маркерів.

Як обрати підхід: коротка таблиця

СитуаціяРекомендований підхід
Блог, контентний сайт, не потрібна атрибуціяPlausible або Fathom
SaaS, важливі воронки і ціліMatomo без cookie або GA4 + server-side
E-commerce, атрибуція доходуGA4 + server-side GTM + Consent Mode v2
Технічна аудиторія, багато блокувальниківPlausible (скрипт рідко блокується)
Строгий GDPR, немає consent-банераPlausible або Matomo cookieless
Потрібні рекламні дані (Google Ads)GA4 з Consent Mode v2 (без варіантів)

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

Часті запитання

Що таке cookieless-аналітика?

Cookieless-аналітика — вимірювання поведінки без зберігання ідентифікаторів у cookie. Замість cookie: агрегати, денний хеш або server-side ідентифікатори.

Safari блокує third-party cookies через ITP з 2017, Firefox — з 2019. Chrome відклав видалення і перейшов до моделі вибору користувача, але обмеження зростають.

За стандартної конфігурації — ні. Plausible не збирає персональні дані і не встановлює cookie.

Чи законна cookieless-аналітика за GDPR?

Так, якщо не збираються персональні дані. Plausible і Fathom GDPR-compliant за замовчуванням.

Наскільки точні cookieless-інструменти?

Вищі за охопленням (не блокуються аdblockерами), нижчі за cross-session атрибуцією. Для трафіку і тенденцій — точніші за GA4 у Safari-аудиторії.

Цю статтю пише і оновлює Андрій Коваленко — без AI-води і партнерських посилань. Помітив застарілий факт чи неточність — напиши, перепишу того ж тижня.

Хто веде сайт і чому без AI