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 между сессиями, атрибуцию по нескольким касаниям, воронки между визитами, когортный анализ.

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 (через баннер), 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 трекинг — баннер всё равно нужен. 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-инструменты?

Выше по охвату (не блокируются adblockers), ниже по cross-session атрибуции. Для трафика и тенденций — точнее GA4 у Safari-аудитории.

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

Кто ведёт сайт и почему без AI