Почему сторонние cookies уходят в прошлое
Сторонние cookies — это небольшие файлы, которые устанавливает домен, отличный от того, который использует посетитель. Страница может загрузить трекер другой компании, и этот трекер сможет читать один и тот же cookie на многих сайтах. Это упрощало измерение поведения на разных сайтах. Но и жалобы на нарушение приватности игнорировать становилось всё сложнее.
Браузеры начали ограничивать такую модель. Safari и Firefox уже много лет блокируют многие сторонние cookies, а Chrome тоже готовил изменения. Точные сроки раньше менялись. Могут измениться и снова.
Для измерения работы сайта последствия прямые. Отчёт, который раньше показывал чистый путь от клика по рекламе до регистрации, теперь теряет части цепочки. Один и тот же человек может зайти во вторник, вернуться в пятницу и выглядеть как два не связанных между собой визита. Это не мелкая ошибка в учёте.
Ad tech долго продвигала cookie-модель. Регуляторы сопротивлялись. Пользователи тоже — в основном через блокировщики и браузеры с более строгими настройками по умолчанию. В итоге для отслеживания через сторонние cookies осталось меньше пространства, а для методов, которые остаются ближе к самому сайту, — больше.
Что означает “веб-аналитика без сторонних cookies”
Веб-аналитика без сторонних cookies означает измерение визитов, действий и тенденций без опоры на cookies, установленные внешними доменами. Проще говоря, сайт по-прежнему может считать просмотры страниц, заполнения форм и покупки, но не использует для этого сквозной межсайтовый идентификатор.
Более мягкий вариант той же идеи — аналитика с минимальным использованием cookies. Сайт может применять first-party cookie, сессионный токен или запись в серверном логе, чтобы распознавать активность на своих страницах. Это не то же самое, что отслеживать одного и того же человека на разных несвязанных сайтах. Другая задача. Другие границы.
Разница важна. Измерять общую эффективность сайта — не то же самое, что идентифицировать человека. Дашборд может показать, что вчера 240 пользователей дошли до страницы оформления заказа, не называя их поимённо. Он также может показать, что 18 из них бросили корзину на втором шаге. Это полезно и не обязательно навязчиво.
Некоторые команды всё ещё слышат слово “аналитика” и думают “слежка”. Это не одно и то же. Контент-команде часто нужен один показатель: какая статья получила 1200 просмотров за прошлую неделю. Продуктовой команде может понадобиться воронка. Ни то ни другое не требует стороннего cookie, чтобы понять, нажали ли кнопку в 15:14.
First-party аналитика: основная альтернатива
First-party аналитика собирает данные с вашего собственного сайта, под вашим доменом, с помощью ваших скриптов или серверных записей. Cookie, если он есть, исходит от самого сайта. Браузер относится к этому иначе. Во многих случаях иначе относятся и правила приватности. Именно поэтому вопрос first-party аналитика что это всё чаще звучит в обсуждениях новых систем измерения.
Обычно first-party настройка аналитики записывает URL страниц, рефереры, тип устройства, тип браузера, время сессии и события вроде кликов или отправки форм. Она также может хранить короткоживущий идентификатор сессии. Этот идентификатор помогает связать действия в рамках одного визита, а не по всему интернету. Разница не косметическая.
Такой подход обычно считают более согласованным с приватностью, потому что данные остаются привязаны к уже существующим отношениям пользователя с сайтом. Клиент, который зашёл на astrina.io и прочитал цены, взаимодействует с astrina.io, а не с трекером, который следует за ним на 50 других сайтов. Именно в этом и смысл границы.
Для многих бизнесов first-party аналитики достаточно. Странице регистрации на рассылку не нужны графы идентичностей. Центру поддержки обычно нужны числа, а не досье. Сайт всё равно может видеть, что страница 4 в статье помощи теряет читателей, и именно этот показатель часто важен.
Есть и компромиссы. First-party аналитика обычно хуже подходит для сквозной атрибуции рекламы, особенно если путь начинается в одном браузере и заканчивается в другом. Данные чище для вашего ресурса, но уже по охвату. Чистота — не то же самое, что полнота.
Как блокировщики рекламы и веб-аналитика влияют друг на друга
Блокировщики рекламы могут блокировать скрипты, пиксели и некоторые сетевые запросы. Если аналитический тег слишком похож на рекламный, он может вообще не сработать. Если расширение браузера блокирует запрос к распространённому домену трекинга, страница всё равно загрузится, но измерение исчезнет. Поэтому важно понимать, как блокировщики рекламы влияют на аналитику, прежде чем делать выводы по отчётам.
Это может приводить к недоучёту. Сайт может видеть 10 000 визитов в серверных логах и 8900 — в клиентской аналитике. Разрыв не всегда означает мошенничество или сломанный код. Иногда это просто работающий блокировщик. Иногда — и то и другое.
Эффект распределяется неравномерно. Одна аудитория может активно пользоваться блокировщиками, другая — почти нет. Техноблог с читателями, заботящимися о приватности, может терять куда больше аналитических событий, чем сайт местной пекарни. Два сайта, один и тот же инструмент, совсем разные потери. Сравнивать их становится сложно.
Командам аналитики нужно учитывать пропуски, а не делать вид, что их не будет. Если на дашборде видно, что 72% пользователей дошли до оформления заказа, реальная доля может быть немного выше или ниже — в зависимости от того, что скрыл блокировщик. Урок простой: если блокировщики распространены, считайте клиентские метрики выборочными данными.
Некоторые команды сверяют данные с серверными логами или событиями на бэкенде. Это не закрывает все пробелы, но помогает. Если платёжная система зафиксировала 320 завершённых заказов, а браузерный тег — 284, разницу стоит изучить. У чисел должен быть второй свидетель.
Ключевые способы измерять трафик без сторонних cookies
Проще всего начать с first-party cookies. Они могут хранить идентификатор сессии, запоминать согласие или удерживать возвращающегося посетителя в рамках одного опыта. Плюсы: они поддерживают базовую непрерывность внутри одного сайта. Минусы: для сквозной атрибуции между сайтами они почти не подходят.
Второй вариант — серверное логирование. Веб-сервер напрямую записывает запросы, включая URL, код ответа, реферер и user agent. Плюсы: блокировщикам сложнее это скрыть, и реальный трафик фиксируется на сервере. Минусы: оно не видит часть клиентских событий, например просмотр видео или нажатие кнопки, если это не приводит к загрузке страницы.
Аналитика на основе согласия даёт посетителям выбор до начала измерений. Если посетитель соглашается, сайт записывает более подробные события; если нет — записывает меньше или ничего. Плюсы: более прозрачный подход к согласию и, во многих случаях, более простая проверка соответствия требованиям. Минусы: число согласившихся может уменьшить размер выборки, а первый визит часто оказывается самым плохо измеряемым.
Измерение с приоритетом приватности старается хранить только то, что нужно для сессии. Инструмент может хешировать или ротировать идентификаторы, сокращать срок хранения и сохранять агрегированные показатели вместо полных историй пользователей. Плюсы: меньше рисков при утечке данных. Минусы: сложнее отладка, меньше долгосрочных выводов и меньше возможностей для работы с аудиторией.
Некоторые сайты используют смесь методов. Медиа-сайт может хранить серверные логи всего трафика, использовать first-party cookies для сессий и отправлять события с согласием пользователя для подписки на рассылку. Такой набор распространён, потому что ни один метод не решает всё. Один подход не подходит одновременно и странице оформления заказа, и архиву блога.
Если вам нужен практический взгляд на то, как отслеживание и отчётность собраны в одном месте, см. Все сайты, за которыми вы следите, — в одной панели — Astrina. Один дашборд не отменяет необходимость аккуратного измерения. Но он помогает быстрее замечать расхождения.
Что всё ещё можно измерять достаточно точно
Просмотры страниц обычно остаются измеримыми. Если браузер запрашивает страницу, сервер это видит, и first-party скрипт часто тоже может это подтвердить. Это даёт одну из самых устойчивых метрик в аналитике. Страницы всё ещё загружаются. Запросы всё ещё происходят.
Рефереры тоже часто доступны. Переход из поисковика, из социальной публикации или по ссылке из письма может всё ещё оставлять реферер или параметр кампании. Точность зависит от поведения браузера и настройки ссылок. Но направление трафика часто всё ещё видно достаточно хорошо для ежедневных решений.
Тип устройства и тип браузера обычно тоже можно определить по user agent или новым client hints, хотя эти сигналы уже не так точны, как раньше. В большинстве случаев нетрудно отличить визит с мобильного Safari от визита с десктопного Chrome. Но нельзя сделать вывод о личности человека. Это важно.
Тенденции конверсий тоже остаются полезными. Сайт по-прежнему может считать отправки форм, покупки и стартовые регистрации. Если конверсии падают с 48 до 31 после изменения лендинга, это реальный сигнал даже без сторонних cookies. Тренд лучше догадок.
Атрибуция становится слабее. Визит по платной рекламе всё ещё может быть учтён, но связать этот визит с повторным посещением через неделю уже сложнее. Многоканальные пути первыми начинают страдать. Именно здесь люди начинают спорить о “потере атрибуции” — и часто не без оснований.
Практическое правило одно: доверяйте прямому событию и с осторожностью относитесь к восстановленному пути. Завершённый заказ — это завершённый заказ. А теория о том, что к нему привели три касания рекламы, без сторонних cookies уже менее надёжна. Эти два факта нельзя ставить на один уровень.
Вопросы внедрения и приватности
Сначала — согласие. Если инструмент хранит идентификаторы или отправляет необязательные аналитические данные, многим сайтам нужен понятный поток согласия. Это означает ясный выбор, а не скрытый чекбокс, спрятанный под четырьмя абзацами юридического текста. Посетители должны понимать, что именно начинает отслеживаться и зачем.
Минимизация данных должна быть реальной, а не декоративной. Если вам нужны только дневные итоги, не храните поминутную историю три года. Если команде поддержки нужны 30 дней диагностики, не оставляйте по умолчанию 900 дней. Срок хранения — это решение, а не случайность.
Кросс-доменное отслеживание по-прежнему неудобно. Компании с основным сайтом, доменом оформления заказа и поддоменом поддержки может понадобиться единый взгляд на путь пользователя. First-party инструменты способны решать часть задачи, но каждая граница домена добавляет сложности. Один cookie на одном хосте не следует за посетителем на другой хост сам по себе.
Выбор инструмента важен. Одни продукты изначально строятся на настройках, дружественных к приватности, другие рассматривают приватность как страницу настроек. Спросите, поддерживает ли инструмент короткий срок хранения, сбор first-party данных, согласие, обрезку IP и контроль экспорта. Спросите до миграции, а не после того, как отчёт сломается.
Если вашей команде нужны ещё и регулярные проверки сайтов, настройка должна вписываться в остальной рабочий процесс. Для информации о ценах и различиях тарифов см. Тарифы — Astrina. Важна стоимость, но не меньше важны и те поля данных, которые можно сохранить, и те, которые сохранять не следует.
Ещё один практический вопрос — документация. Чистая политика приватности и короткая внутренняя заметка о том, что именно измеряется, могут сэкономить часы в будущем. Когда маркетолог спрашивает, почему кампания дала падение конверсий на 12%, ответ не должен начинаться с “кажется, блокировщик что-то сделал”.
Как выбрать подходящую аналитику для вашего сайта
Начните с бизнес-цели. Контентному сайту нужны тренды по страницам, глубина прокрутки и рефереры. Подписочному продукту нужны регистрации, стартовые триалы и платёжные конверсии. Маркетплейсу могут понадобиться все три. Настройка должна соответствовать вопросу, а не наоборот.
Затем проверьте требования к соответствию нормам. Если ваша аудитория находится в регионах с более строгими правилами согласия, вам может подойти аналитика с согласия и более коротким сроком хранения. Если у сайта низкие риски для приватности и в основном внутренние отчёты, более простого first-party подхода может быть достаточно. Одно решение по политике может убрать три технические опции.
Далее измерьте влияние блокировщиков рекламы и ограничений браузеров. Если аудитория внимательна к приватности, client-side аналитика может пропускать заметную долю событий. Если аудитория в основном внутренняя или корпоративная, разрыв может быть меньше. Не гадайте. Сравните client-side показатели с server-side логами за один месяц.
Выбирайте минимальную настройку, которая отвечает на ваш вопрос. Если вам нужны только еженедельный трафик и тренды конверсий, достаточно лёгкого набора first-party аналитики. Если нужен подробный учёт событий продукта, может потребоваться отслеживание событий с согласием. Если нужны аудиторские следы, на первом месте стоят серверные логи.
Команды, которые управляют многими сайтами, иногда предпочитают видеть всё в одном месте, чтобы сравнивать паттерны между доменами и регионами. Для этого Усі сайти, які ви ведете, — в одній панелі — Astrina может быть полезна, если работа идёт сразу с несколькими ресурсами. Один дашборд не решает политику за вас. Но он может помочь её соблюдать.
Если ваша команда встраивает отчётность в программное обеспечение, есть и путь для разработчиков. См. API для разработчиков — Astrina для структурированного доступа, который можно встроить в собственные дашборды и внутренние инструменты. Это важно, когда аналитика — уже не таблица, а рабочий процесс.
Финальная проверка проста. Если браузер блокирует трекер, вы всё ещё знаете о просмотре страницы? Если посетитель отказывается от cookies, вы всё ещё знаете о конверсии? Если на те числа, которые вы реально используете, ответ “да”, значит, система работает как надо.
