Server-side и cookieless-аналитика: чем отличаются

Коротко: server-side описывает канал доставки данных: события идут через ваш сервер или ваш домен, а не напрямую в сервис аналитики. Cookieless описывает метод подсчёта: идентификаторы не записываются в cookie и localStorage браузера. Первое отвечает на вопрос, куда и как уезжают данные, второе — на вопрос, что остаётся в браузере посетителя. На практике подходы часто используются вместе.

Как работает server-side tracking

Классический счётчик аналитики живёт в браузере посетителя: скрипт собирает событие и отправляет запрос на домен сервиса аналитики. Блокировщики знают адреса популярных трекеров из публичных списков и режут такие запросы — на этапе загрузки скрипта или на этапе отправки события. Сколько теряет классический счётчик, мы разбирали в статье о потерях cookie-аналитики.

Server-side tracking меняет маршрут данных. Событие отправляется на ваш домен или поддомен: скрипт отдаётся с вашего же домена, а сервер принимает событие и пересылает его в сервис аналитики. Для блокировщика запрос неотличим от запроса к вашему сайту: в списках трекеров ваш домен как вендор аналитики не значится, поэтому потери от фильтрации снижаются. У такого маршрута есть и вторая сторона: настройка требует работ с доменом и инфраструктурой, то есть внедрение сложнее, чем вставка одной строки кода.

Как работает cookieless-аналитика

Cookieless — характеристика метода подсчёта, а не маршрута. Аналитика не записывает в браузер ни cookie, ни localStorage-свойства: идентификаторов посетителя на устройстве просто нет. Для контраста — как описан метод Метрики в справке Яндекса: «Для учета посетителей Метрика использует анонимные идентификаторы браузеров, которые сохраняются в cookie, а также в localStorage-свойства».

Подсчёт при этом переносится на сервер. ДэйРика, например, считает визиты и посетителей на базе дня: событие приходит на сервер без метки устройства, сервер агрегирует активность и отличает нового за день посетителя от уже посчитанного, ничего не записывая в браузер. Повторный заход в тот же день не удваивает посетителя, но и сквозной истории конкретного человека между днями не существует. Механика подсчёта разобрана в статье «Аналитика без cookie: как считается посетитель». Побочный эффект метода для бизнеса: раз cookie аналитики на устройстве не появляются, повода показывать согласие на аналитические cookie тоже не возникает.

Чем server-side отличается от cookieless

Критерий	Server-side	Cookieless
Что описывает	канал доставки данных	метод подсчёта посетителей
Где происходит обработка	ваш сервер или поддомен	на сервере аналитики при приёме событий
Идентификатор в браузере	возможен и запрещён — по вашему выбору	не записывается никогда
Обход блокировщиков	да: скрипт с вашего домена не в списках трекеров	не гарантируется: домен вендора может быть в списках
Баннер про аналитические cookie	нужен, если схема пишет cookie	не возникает
Сложность внедрения	выше: настройка домена и проксирования	минимальная: одна строка кода

Строки таблицы не складываются в рейтинг «лучше — хуже»: подходы отвечают на разные вопросы, и выбор одного из них не отменяет другой.

Как подходы комбинируются

• server-side с cookie — доставка через ваш домен плюс идентификаторы в cookie вашего же домена: максимум точности между визитами, минимум приватности, баннер с согласиями остаётся;
• server-side без cookie — маршрут через ваш домен, но идентификаторы не пишутся: полная доставка и отсутствие записываемых меток одновременно;
• cookieless без прокси — обычный скрипт с домена вендора, идентификаторы не пишутся: быстрый старт, но домен вендора в списках блокировщиков может встречаться;
• cookieless плюс прокси — подсчёт без записи в браузер и first-party доставка вместе: так устроена ДэйРика, прокси при этом включается опционально.

Что делает ДэйРика

По умолчанию ДэйРика работает в cookieless-режиме: не записывает идентификаторы в браузер, отдаёт счётчик ~1 КБ одной строкой, автоматически собирает 13 событий, считает цели, воронки и выручку, хранит данные в России. Конверсии уходят в Яндекс Директ по yclid и в VK Рекламу по rb_clickid.

Прокси-трекер — опция для сайтов, где важна полнота доставки: скрипт и приём событий живут на домене клиента, и блокировщики по публичным спискам такой трекер не режут. Порядок включения разобран в документации прокси-трекера. Терминология из этой статьи в конфигурации ДэйРики встречается так: cookieless — базовый метод подсчёта, server-side — опциональный режим доставки через first-party домен.

Какой подход выбрать

Ориентиры по ситуациям:

• классический счётчик заметно теряет визиты из-за блокировщиков — добавляйте first-party доставку, это server-side по каналу;
• нужен быстрый старт без работ с инфраструктурой — cookieless-счётчик одной строкой;
• требуется контроль над потоком данных на уровне своей инфраструктуры — server-side приём событий, дороже во внедрении и поддержке;
• нужны полнота и отсутствие записываемых меток одновременно — комбинация cookieless плюс прокси.

Итог: server-side и cookieless отвечают на разные вопросы и выбираются не вместо друг друга, а вместе. Если задача звучит как «считать всех и не писать ничего в браузер посетителя», рабочая конфигурация — cookieless-подсчёт с опциональной first-party доставкой, как в ДэйРике.

Похожие статьи

Определения server-side tracking и cookieless — общеупотребительные технические понятия. Способ учёта посетителей Метрики — справка Яндекса. Режимы ДэйРики — документация прокси-трекера; потери классических счётчиков — статья «Почему cookie-аналитика теряет 40% трафика».