Рекламная аналитика без сторонних cookies: First-Party Data и новые методы отслеживания

Что случилось со сторонними cookie: хронология

Сторонний cookie (third-party cookie) — это файл, который устанавливает сервер рекламной сети или трекингового сервиса, а не тот сайт, который вы сейчас смотрите. Механика простая: вы заходите на сайт магазина, который подключил пиксель рекламной системы. Этот пиксель ставит cookie от имени рекламной сети. Когда вы переходите на другой сайт с тем же пикселем, рекламная сеть вас «узнаёт» и показывает таргетированную рекламу.

На этой механике работал весь ретаргетинг последние двадцать лет. Проблема в том, что браузеры начали её ограничивать.

Safari Intelligent Tracking Prevention

Apple запустила ITP в 2017 году как часть браузера Safari. ITP анализирует домены, с которых загружаются ресурсы, и классифицирует их как «трекеры». Cookie от таких доменов постепенно получали всё больше ограничений: сначала сокращение срока хранения, затем полная блокировка сторонних cookie по умолчанию. Дополнительно Safari начал ограничивать cookie, установленные через JavaScript (не через HTTP-заголовок Set-Cookie), сроком хранения в семь дней.

Это важно для российского рынка: iPhone и Mac занимают значительную долю устройств. Пользователи мобильного Safari — это и есть та часть аудитории, которая исчезает из ретаргетинговых списков без видимых причин.

Firefox Enhanced Tracking Protection

Mozilla включила расширенную защиту от отслеживания по умолчанию для всех пользователей Firefox в июне 2019 года. Сторонние cookie от известных трекеров блокируются автоматически — без каких-либо дополнительных настроек со стороны пользователя.

Chrome и Privacy Sandbox

Google анонсировала Privacy Sandbox в 2019 году как технологическую альтернативу сторонним cookie. Несколько раз откладывала полный отказ от cookie — и в конечном счёте в 2024 году сообщила, что не будет их блокировать принудительно, предложив пользователям самим выбирать режим приватности. Это не означает, что угроза снята: Privacy Sandbox API (Topics, Protected Audience и другие) уже работают как альтернативный метод таргетинга, и рекламный рынок постепенно к ним адаптируется.

Блокировщики рекламы: отдельный слой проблемы

Блокировщики рекламы: отдельный слой поверх политики браузеров. uBlock Origin, AdBlock Plus и десятки других расширений блокируют не только рекламные объявления, но и трекинговые пиксели, скрипты аналитики, запросы к рекламным сетям. Пользователь с блокировщиком невидим для вашей клиентской аналитики: счётчик не загружается, пиксель не срабатывает, цель не фиксируется, даже если покупка состоялась.

Блокировщики особенно распространены среди технически грамотной аудитории: разработчики, дизайнеры, маркетологи. Если ваш продукт ориентирован на эту аудиторию, потери данных могут быть выше средних.

Три уровня данных: почему первая сторона важнее

Прежде чем переходить к инструментам, нужно разобраться с базовой классификацией. Все данные о пользователях делятся на три категории.

Данные первой стороны (first-party data): то, что вы собираете напрямую от своих пользователей: формы на сайте, поведение зарегистрированных пользователей, история покупок в CRM, подписки на рассылку, обращения в поддержку. Эти данные принадлежат вам, пользователь дал согласие на их сбор, и никакой браузер не может их заблокировать: вы собираете их на своём собственном домене.

Данные второй стороны (second-party data): first-party данные партнёра, которые он передаёт вам на договорной основе. Например, ретейлер и банк обмениваются аудиториями своих клиентов. В российском рынке этот формат встречается в крупном корпоративном сегменте и внутри экосистем, когда несколько брендов одной группы обмениваются данными.

Данные третьей стороны (third-party data): то, что покупается у брокеров данных или формируется рекламными сетями на основе отслеживания пользователей по всему интернету. Это именно те данные, которые строились на сторонних cookie. Их качество снижается по мере того, как браузеры и законодатели закручивают гайки.

Сторонние данные не умерли окончательно, но стали менее надёжными: меньше охват, хуже точность, сложнее верификация. First-party данные выходят на первый план не как модный тренд, а как единственный устойчивый фундамент в условиях усиливающихся ограничений приватности.

Симптомы: как понять, что у вас уже есть проблема с данными

Потери данных не всегда очевидны сразу. Вот признаки, которые говорят о деградации сбора данных.

Ретаргетинговые аудитории сужаются без причины. Вы не меняли настройки, трафик на сайт стабильный, но сегмент «Посетители за 30 дней» в Директе становится меньше месяц от месяца. Причина: пользователи Safari и Firefox с заблокированными сторонними cookie посещают сайт, но в ретаргетинговый список не записываются. Их доля в вашей аудитории растёт, и невидимая часть ретаргетинга вместе с ней.

Расхождение данных Директ и Метрика устойчиво высокое. Небольшое расхождение (примерно 5–15%) между данными Директа и Метрики нормально — задержки атрибуции, разные окна конверсии. Но если разрыв вырастает до 30–40% и не снижается, это сигнал: часть конверсий, которые Директ считает своими, до Метрики не доходит. Вероятная причина — клиент кликнул на объявление в браузере с блокировщиком, перешёл на сайт, но пиксель Метрики не загрузился. Конверсия случилась, Директ её не видит.

Рост доли «прямого» трафика без изменений в рекламе. «Прямые заходы» в Метрике — это всё, что система не смогла атрибутировать. Часть из них действительно прямые заходы. Но заметный рост доли прямого трафика нередко означает, что UTM-метки не передаются корректно, реферер теряется при редиректах, или cookie с источником перехода истекли до момента конверсии.

Пропасть между лидами в рекламе и сделками в CRM. Директ показывает 50 конверсий в месяц, а в CRM за тот же период 80 новых клиентов. Разница — это офлайн-конверсии, которые не передаются в рекламную систему. Алгоритм Директа оптимизирует кампании по неполным данным и принимает неверные решения.

Server-Side Tracking: отслеживание, которое не зависит от браузера

Классический способ веб-аналитики: client-side tracking. JavaScript-скрипт загружается в браузере пользователя и отправляет данные напрямую из браузера в аналитическую систему. Именно этот скрипт блокируют блокировщики рекламы и именно его cookie ограничивает Safari ITP.

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

Вместо того чтобы браузер отправлял данные напрямую в аналитику, он отправляет данные на ваш собственный сервер (или специализированный прокси-сервер на вашем домене). Ваш сервер получает событие и уже из своей среды передаёт его в нужные системы: аналитику, рекламные платформы, CRM.

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

Сравнение подходов

Кому нужен server-side tracking, а кому нет

Server-side tracking — решение для бизнеса с техническими ресурсами и масштабом, который оправдывает затраты на разработку и поддержку. Интернет-магазины с высоким трафиком, финансовые сервисы, маркетплейсы, SaaS-продукты — им SST оправдан. Для малого бизнеса с одним сайтом и прямыми продажами начать стоит с более доступных инструментов: офлайн-конверсий и идентификаторов первой стороны.

Офлайн-конверсии: как замкнуть петлю без переписывания сайта

Если клиент кликнул на объявление Директа, заполнил форму, затем менеджер позвонил ему и закрыл сделку в CRM — браузерная аналитика эту сделку не «видит». Это офлайн-конверсия: конверсия случилась, но не на сайте и не в режиме реального времени.

Яндекс.Директ и Яндекс.Метрика позволяют загружать данные об офлайн-конверсиях постфактум. Алгоритм Директа получает информацию о том, какой клик привёл к реальной сделке, а не только к заявке на сайте, и начинает оптимизировать кампанию на реальный результат.

Схема с ClientID Метрики

Наиболее распространённая реализация для рекламы в Яндексе — через ClientID.

1. Пользователь кликает на объявление в Директе. Яндекс.Метрика присваивает ему ClientID — уникальный идентификатор посещения, который записывается в cookie первой стороны на вашем домене.
2. Пользователь оставляет заявку на сайте. Форма передаёт в CRM не только имя и телефон, но и ClientID — его получают из cookie Метрики через JavaScript в момент отправки формы.
3. Менеджер обрабатывает заявку и закрывает сделку. В CRM появляется запись: клиент, дата, сумма, а рядом — ClientID.
4. Вы выгружаете данные о закрытых сделках из CRM и загружаете их в Метрику через раздел офлайн-конверсий — вручную (CSV-файл) или автоматически через API.
5. Метрика и Директ теперь знают, какой клик привёл к сделке. Алгоритм обучается на реальных данных, а не только на факте отправки формы.

Что нужно для старта: разработчик для добавления передачи ClientID в форму заявки, доступ к CRM с возможностью выгрузки данных, и интерфейс или API Метрики для загрузки конверсий. Это значительно проще, чем полноценный server-side tracking, и уже доступно большинству малых и средних бизнесов.

Схема с хэшами email и телефона

Если ClientID передать невозможно (пользователь пришёл не через Директ, или cookie были удалены до конверсии), можно загрузить конверсию по хэшу email или телефона. Вы берёте email клиента из CRM, нормализуете его (нижний регистр, без пробелов) и хэшируете по алгоритму SHA-256. Загрузить такой хэш в Метрику — значит сообщить системе: «этот адрес электронной почты совершил конверсию». Яндекс сопоставит хэш с пользователями, авторизованными через Яндекс ID, и атрибутирует конверсию.

Важно: охват матчинга зависит от того, сколько ваших клиентов пользуются аккаунтом Яндекса на тот же email. Для аудитории, активно использующей Яндекс-сервисы, схема работает хорошо. Для аудитории с корпоративными почтами охват будет частичным.

Customer Data Platform: когда нужна единая база о клиентах

Customer Data Platform (CDP): платформа, которая собирает данные о пользователях из всех источников и создаёт единый профиль каждого клиента.

Представьте типичную картину: пользователь зашёл на сайт с телефона анонимно. Через неделю открыл письмо из рассылки с ноутбука — теперь вы знаете его email. Ещё через три дня позвонил в поддержку — его узнали по номеру телефона. Потом купил через мобильное приложение. Четыре разных касания, четыре разных идентификатора — и без CDP это четыре разных «пользователя» в четырёх разных системах.

CDP, CRM и DMP: в чём разница

CRM не знает ничего об анонимных посетителях сайта, не следит за поведением в реальном времени, не занимается сшивкой разных устройств. CDP работает шире: собирает и анонимные поведенческие данные, и данные авторизованных пользователей, сшивает их в единый профиль и передаёт активированные сегменты в рекламные инструменты.

DMP строилась на сторонних cookie, и по мере их исчезновения теряет актуальность. CDP работает с идентифицированными пользователями и первичными данными, что делает её устойчивой к изменениям в политике браузеров.

Что умеет CDP

• Сшивка идентификаторов. CDP объединяет сессию на телефоне и ноутбуке в один профиль, когда пользователь авторизуется. Анонимная история добавляется к идентифицированному профилю.
• Сегментация в реальном времени. Сегменты строятся динамически на основе текущего поведения: добавил товар в корзину час назад, открыл три письма на этой неделе, не покупал последние 90 дней.
• Активация аудиторий. Готовые сегменты автоматически выгружаются в Директ, email-систему, колл-центр, без ручной выгрузки таблиц.
• Единое хранилище согласий. CDP помнит, что пользователь согласился на рекламную рассылку, но отказался от передачи данных третьим лицам.

Кому нужна CDP, а кому достаточно CRM + Метрика

CDP подходит бизнесу с несколькими каналами взаимодействия с клиентом (сайт, приложение, email, офлайн), повторными покупками и базой клиентов от нескольких тысяч в месяц, потребностью в сложной сегментации и техническими ресурсами для интеграции.

Для небольшого бизнеса с одним сайтом и несколькими сотнями клиентов в месяц CDP избыточна. Начать стоит с правильно настроенной Метрики, передачи ClientID в CRM и офлайн-конверсий. Это уже закроет большую часть проблем с потерей данных.

Из российских инструментов со схожей функциональностью стоит отметить Mindbox: платформа для retention-маркетинга с функциями CDP, ориентированная на e-commerce и сервисный бизнес. Carrot quest: более лёгкий вариант с частичными возможностями CDP для небольших онлайн-проектов.

Идентификаторы первой стороны: что работает без сторонних cookie

Когда сторонние cookie недоступны, нужен другой способ распознать пользователя. Перечислим инструменты, которые работают на первичных данных.

Email-хэш

Пользователь оставил email на сайте — зарегистрировался, купил, подписался. Вы берёте этот email, нормализуете его (нижний регистр, без пробелов) и хэшируете по алгоритму SHA-256. Получается строка вида: последовательность символов, которая не содержит оригинального email и считается псевдоанонимизированной.

Этот хэш можно загрузить в Яндекс.Директ для создания аудитории или для матчинга конверсий. Так можно показывать рекламу именно вашим зарегистрированным пользователям, исключать их из показов или находить похожие аудитории (look-alike).

Охват матчинга зависит от того, сколько ваших клиентов имеют аккаунт Яндекса на тот же email-адрес. Для аудитории, активно пользующейся Яндекс-сервисами, схема работает хорошо. Для корпоративных email-адресов, которые редко регистрируются в Яндексе, охват будет ниже.

Хэш телефона

Аналогичная механика с номером телефона. Формат имеет значение: перед хэшированием телефон нужно привести к единому стандарту (например, +7XXXXXXXXXX без пробелов, скобок и тире). Один и тот же номер в разных форматах даст разные хэши, и матчинг не сработает.

Яндекс ID

Это главное преимущество рекламы внутри экосистемы Яндекса. Если пользователь авторизован в браузере под своим аккаунтом Яндекса — Яндекс знает его через Яндекс ID. Эта идентификация не зависит от сторонних cookie, не ломается от ITP, не исчезает при переустановке браузера.

Яндекс.Метрика может использовать Яндекс ID для более точной атрибуции поведения авторизованных пользователей. Для рекламодателя это означает: ретаргетинговые сегменты на авторизованных в Яндексе пользователях работают надёжнее, чем анонимные cookie-аудиторий: они не пропадают при блокировке cookie.

Пользовательские параметры Метрики (UserParams)

Если у вас есть собственная авторизация на сайте, вы можете передавать в Метрику собственные идентификаторы пользователей, не раскрывая персональных данных. Например, внутренний user_id или хэш email. Это позволяет сшить веб-сессии с данными CRM: событие в Метрике и запись в CRM объединяются по общему идентификатору в единую картину пути клиента.

Сравнение идентификаторов

Согласие пользователей: что нельзя делать без разрешения

Сбор и использование данных первой стороны требует соблюдения российского законодательства о персональных данных (Федеральный закон № 152-ФЗ).

Email, телефон, имя — персональные данные. Их хэши остаются персональными данными в смысле 152-ФЗ, потому что технически могут быть соотнесены с конкретным человеком при наличии исходного списка.

Что нужно для легальной работы с данными

• Явное согласие на обработку персональных данных. Конкретное, свободное, осознанное. Пользователь должен понимать, что его данные будут использованы для рекламы, и поставить галочку, не предзаполненную автоматически.
• Актуальная политика конфиденциальности. С описанием того, какие данные, зачем, как долго обрабатываются и кому передаются. Упоминание рекламных платформ в списке получателей данных. Это обязательно.
• Механизм удаления данных. Пользователь вправе потребовать удалить свои данные, в том числе из рекламных аудиторий. У вас должен быть процесс, чтобы это выполнить.
• Уведомление об использовании cookie. Для российского рынка требования мягче, чем в ЕС, но это хорошая практика и часть управления репутацией.

Что нельзя: загружать в рекламные платформы данные пользователей, которые не давали согласия на передачу данных третьим лицам. Просто упомянуть рекламную аналитику в политике конфиденциальности недостаточно, нужно явное согласие.

С чего начать: план из шести шагов

Ниже путь от простого к сложному: можно начать уже сейчас, не дожидаясь бюджета на CDP и отдельного разработчика для SST.

1. Диагностика: сравните данные Директа и Метрики. Возьмите последние три месяца. Если расхождение по конверсиям устойчиво превышает 20%, потеря данных уже есть. Проверьте, установлен ли счётчик Метрики на всех страницах воронки, включая страницу «Спасибо». Убедитесь, что цели срабатывают правильно (проверьте в Вебвизоре).
2. Передайте ClientID в форму заявки. Добавьте скрытое поле, которое автоматически заполняется из cookie Метрики при отправке формы. Несложная задача для разработчика, займёт несколько часов. После этого каждая заявка в CRM будет содержать ClientID.
3. Настройте передачу офлайн-конверсий. Договоритесь с отделом продаж: когда сделка закрыта, данные (ClientID, дата, тип конверсии) выгружаются и передаются в Метрику. На начальном этапе: вручную, раз в неделю через CSV. Позже автоматически через API.
4. Обновите политику конфиденциальности и согласия. До начала активного сбора данных, а не после. Убедитесь, что пользователи дают осознанное согласие на использование данных для рекламы.
5. Создайте аудитории на основе хэшей. Выгрузите из CRM список email клиентов (например, тех, кто уже купил). Нормализуйте и захэшируйте SHA-256. Загрузите в Яндекс.Директ для ретаргетинга или look-alike.
6. Оцените необходимость более глубоких инструментов. Если предыдущие шаги закрыли основные пробелы, отлично: задача решена на текущем масштабе. Если бизнес растёт, появляются новые каналы и сложная сегментация становится критичной, стоит рассмотреть server-side tracking и полноценную CDP.

Типичные ошибки

«Метрика стоит, значит данные есть». Факт установки не означает полноту данных. Пользователи с блокировщиками, Safari с ITP, обрывы соединений при загрузке скрипта — всё это создаёт пробелы в данных. Реальный масштаб потерь зависит от аудитории: сайт для технически грамотных пользователей потеряет больше данных, чем сайт для аудитории 50+ без блокировщиков.

«Сначала внедрим CDP, потом займёмся данными». CDP: инструмент для работы с данными, которые уже есть. Если у вас не настроена передача ClientID в CRM и нет офлайн-конверсий, CDP не даст ничего, кроме дополнительных расходов на внедрение. Начните с базы.

«Соберём данные, политику напишем потом». Данные без согласия: нарушение 152-ФЗ, а не мелкая формальность. Политика конфиденциальности должна существовать до начала сбора данных.

«Хэши email = анонимность = можно без согласия». Хэш SHA-256 от email не делает данные анонимными в юридическом смысле. Они по-прежнему связаны с конкретным человеком. Согласие нужно.

«Настроили один раз и забыли». Экосистема меняется: браузеры обновляют политики, рекламные платформы изменяют требования к форматам данных. Аудит аналитики и проверку корректности передачи офлайн-конверсий стоит проводить раз в полгода.

«Server-side решит всё». SST устраняет зависимость от браузера, но не заменяет стратегию сбора first-party данных. Если пользователь заходит анонимно и не оставляет никаких контактов, server-side tracking тоже не поможет его идентифицировать. Инструменты дополняют друг друга, а не заменяют.

Граница с атрибуцией: в чём разница

Этот вопрос возникает регулярно, поэтому обозначим границу явно. Атрибуция: логика распределения заслуги за конверсию между несколькими касаниями. Пользователь нашёл сайт через SEO, потом кликнул на ретаргетинговое объявление, потом купил — кому засчитывается конверсия? Это вопрос выбора модели атрибуции: last-click, first-click, позиционная, алгоритмическая. Подробнее об этом в статье про атрибуцию в рекламе.

Но прежде чем выбирать модель, нужно, чтобы данные об этих касаниях вообще дошли до аналитической системы. Если половина сессий не записалась в Метрику из-за блокировщика, если офлайн-сделка не передана через офлайн-конверсии, если пользователь с iPhone «потерялся» из-за ITP, модель атрибуции работает с неполными данными и даёт искажённую картину.

Server-side tracking, офлайн-конверсии, идентификаторы первой стороны: инфраструктура для сбора данных. Модели атрибуции: то, что делают с уже собранными данными. Сначала собрать, потом интерпретировать.

Смежные темы: как правильно выстроить полную цепочку от клика до сделки в CRM — в статье о  сквозной аналитике. Как настроить счётчик Метрики и цели до запуска рекламы — в статье Яндекс.Метрика до запуска рекламы.