TL;DR
- Cookieless - это не только про удаление third-party cookies в Chrome. Это общий сдвиг: браузеры, мобильные ОС, законы, consent banners и ad blockers забирают у маркетинга часть привычных сигналов.
- В апреле 2025 Google отказался от отдельного нового prompt для полного отказа от third-party cookies в Chrome и оставил текущую модель выбора пользователя. Это не отменяет privacy-сдвиг.
- Safari, Firefox, iOS ATT, Incognito, consent mode и блокировщики уже давно делают браузерный пиксель неполным источником данных.
- Защита от потери данных - не “обойти privacy”, а собрать честную first-party инфраструктуру: согласие, собственные ID, CRM, server-side события, clean rooms, моделирование и incrementality.
- Главная ошибка бизнеса - думать, что если Chrome не убил cookies полностью, можно ничего не менять.
1. Что на самом деле значит cookieless
В старой модели рекламная система могла узнавать пользователя через сторонние cookies, mobile advertising ID и пиксели, которые работали прямо в браузере или приложении. Это давало удобный, но хрупкий мир: ретаргетинг, lookalike-аудитории, post-view атрибуция, длинные окна конверсий и отчеты рекламных кабинетов, которые выглядели почти как правда.
Проблема в том, что пользовательский браузер и операционная система стали активной стороной в этой схеме. Safari ограничивает трекинг. Firefox блокирует часть cross-site механик. Apple через App Tracking Transparency требует разрешение на трекинг между приложениями и сайтами. Consent banners меняют поведение тегов до и после согласия. Ad blockers режут запросы к известным рекламным доменам.
Важно: cookieless не означает, что данные исчезают. Исчезает легкость, с которой чужие платформы собирали данные за вас. Выживает тот, кто умеет получать согласие, хранить собственные идентификаторы и связывать события с реальными сделками.
2. Что изменилось после разворота Chrome
Долгое время рынок готовился к тому, что Chrome полностью отключит third-party cookies. В 2024 Google уже тестировал ограничения на части пользователей. Но 22 апреля 2025 Google написал, что сохранит текущий подход к выбору пользователя в Chrome и не будет выкатывать новый standalone prompt для third-party cookies.
Это сильно меняет тон статьи: нельзя больше писать “Chrome скоро убьет cookies” как гарантированный дедлайн. Правильнее говорить так:
| Сигнал | Текущий смысл для маркетинга |
|---|---|
| Third-party cookies в Chrome | Не исчезли полностью, но зависят от настроек пользователя, режима браузера и будущих tracking protections |
| Safari / Firefox | Уже давно более жесткие к cross-site tracking |
| iOS ATT | Приложения должны спрашивать разрешение на tracking между чужими приложениями и сайтами |
| Consent Mode | Теги должны менять поведение по состоянию согласия |
| Ad blockers | Могут блокировать пиксели, скрипты и запросы к известным доменам |
| Server-side APIs | Становятся нормальным способом передавать конверсии, но требуют consent и качества данных |
Вывод простой: “Chrome передумал” не значит “privacy закончился”. Это значит, что рынок получил меньше одного большого дедлайна, но больше постоянной неопределенности.
3. First-party data как новая база аналитики
First-party data - это данные, которые компания собирает напрямую в своих продуктах и каналах: сайт, приложение, CRM, программа лояльности, платежи, call center, email, WhatsApp, офлайн-точки.
Сильная first-party модель не начинается с пикселя. Она начинается с понятного обмена:
| Что просит бизнес | Что получает пользователь | Почему это работает |
|---|---|---|
| Чек, доступ к кабинету, статус заказа | Есть понятная причина оставить контакт | |
| Телефон | Доставка, консультация, бонусы | Контакт нужен для сервиса, а не только рекламы |
| Логин | История заказов, персональные цены | Пользователь видит пользу от авторизации |
| Consent | Контроль над типами обработки | Согласие становится частью продукта, а не темной формой |
Плохая first-party стратегия выглядит так: “давайте заставим всех оставить телефон”. Хорошая выглядит иначе: “давайте дадим причину авторизоваться и честно объясним, как данные улучшают сервис”.
4. Как меняется измерение маркетинга
В privacy-среде нельзя опираться только на один источник истины. Отчет Meta, GA4 и CRM будут расходиться, и это нормально. Задача не в том, чтобы сделать все числа одинаковыми. Задача - понять, для какого решения нужен каждый источник.
| Решение | Лучший источник | Почему |
|---|---|---|
| Оптимизация кампании внутри Meta | Meta Events + CAPI | Алгоритму нужны сигналы в своей системе |
| Анализ поведения на сайте | GA4 + BigQuery | Видны события, страницы, аудитории, funnel |
| Решение о бюджете | Сквозная аналитика + CRM + финансы | Нужны деньги, маржа, возвраты, статусы сделок |
| Проверка инкрементальности | Geo holdout / lift test | Нужен ответ: были бы продажи без рекламы или нет |
| Ретеншн и LTV | CRM / CDP / billing | Нужны повторные покупки и жизненный цикл клиента |
Privacy ломает иллюзию точной атрибуции до пользователя. Взамен приходится строить систему из нескольких уровней: observed data, modeled data, CRM facts и эксперименты.
5. Consent Mode без иллюзий
Consent Mode не заменяет cookie banner. Это не юридический “щит” и не способ собрать все данные без согласия. Его задача - передать Google состояние согласия пользователя и заставить теги менять поведение.
Есть два базовых режима:
| Режим | Что происходит до согласия | Когда подходит |
|---|---|---|
| Basic Consent Mode | Google tags не грузятся до выбора пользователя | Более строгая privacy-позиция, меньше данных для моделирования |
| Advanced Consent Mode | Теги грузятся с denied-состояниями и могут отправлять cookieless pings | Нужно больше данных для моделирования, но требуется аккуратная юридическая оценка |
Практически это означает, что маркетолог больше не может сказать разработчику: “просто поставь GTM”. Нужно описать default consent, update-события, порядок загрузки CMP, поведение Google tags, поведение non-Google tags и правила для server-side отправки.
6. Что делать бизнесу
Шаг 1. Провести privacy-аудит тегов
Составьте список всех тегов: Google, Meta, TikTok, LinkedIn, Hotjar, call tracking, chats, CRM widgets, affiliate scripts. Для каждого тега ответьте:
- кто владелец;
- какие данные собирает;
- зачем он нужен;
- когда грузится;
- зависит ли от consent;
- можно ли отправлять через server-side;
- есть ли риск утечки PII.
Шаг 2. Навести порядок в идентификаторах
Минимальный набор:
| ID | Где живет | Зачем нужен |
|---|---|---|
client_id | analytics/browser/server cookie | Связать визиты и события |
lead_id | сайт/CRM | Связать форму и сделку |
deal_id | CRM | Связать продажу и статус |
transaction_id | платежи/ERP | Связать оплату, возврат, маржу |
hashed_email / hashed_phone | server-side / ad APIs | Улучшить match quality при наличии consent |
Шаг 3. Перенести критические события на сервер
Не все события нужно отправлять server-side. Начните с тех, которые влияют на обучение алгоритмов и деньги:
lead;qualified_lead;purchase;refund;subscription_started;subscription_cancelled;offline_purchase.
Шаг 4. Отделить аналитику от ретаргетинга
Раньше один пиксель пытался делать все. Сейчас лучше разделять задачи:
- GA4 и BigQuery - для анализа поведения;
- CRM и BI - для денег;
- Meta CAPI / Google Enhanced Conversions / TikTok Events API - для оптимизации рекламных алгоритмов;
- lift tests - для проверки реального вклада рекламы.
7. Локальный контекст СНГ/РК
В Казахстане и СНГ privacy часто воспринимают как европейскую проблему. Это опасное упрощение. Даже если юридическое давление слабее, технические ограничения работают у всех пользователей одинаково. iPhone в Алматы и Астане режет рекламные идентификаторы так же, как iPhone в Лондоне. Safari не спрашивает, где зарегистрирован бизнес. Ad blocker не знает, что у вас локальная школа английского.
Для локального бизнеса особенно важны три вещи:
- CRM-дисциплина. Если менеджеры не ведут статусы, никакой cookieless-стек не спасет аналитику.
- Телефон и мессенджеры. Для многих ниш это главный first-party канал, но его нужно связывать с рекламными ID и consent.
- Offline conversions. Продажа может случиться в кассе, WhatsApp или после звонка. Эти события надо возвращать в рекламные платформы и BI.
8. Частые ошибки
| Ошибка | Что ломается |
|---|---|
| “Chrome не удалил cookies, можно подождать” | Команда продолжает зависеть от браузерного пикселя |
| “Server-side обходит privacy” | Риск юридических и репутационных проблем |
| “Нам нужен CDP, и все решится” | Без ID, consent и CRM-дисциплины CDP станет дорогим хранилищем мусора |
| “Соберем телефоны любой ценой” | Пользователь не доверяет форме, конверсия падает |
| “Будем смотреть только рекламный кабинет” | Платформа оптимизирует свою цель, не вашу маржу |
9. Практический чеклист
- На сайте есть понятный consent banner, а не декоративная кнопка “OK”.
- GTM получает default и update consent state в правильном порядке.
- Non-Google tags не стреляют до нужного согласия.
- Критические события есть в CRM и имеют стабильные ID.
-
lead_id,deal_id,transaction_idсвязаны в BI. - Пиксельные события дедуплицируются с server-side событиями.
- В рекламные платформы уходят не только лиды, но и qualified / paid события.
- Есть план проверки инкрементальности, хотя бы простым geo holdout.
10. Видео
11. Главный совет
Не стройте аналитику вокруг чужого cookie. Стройте ее вокруг собственного отношения с клиентом: согласие, понятная польза, стабильный ID, CRM-статус и факт оплаты. Privacy не убивает маркетинг. Она убивает ленивую зависимость от пикселя.
Sources / Notes
- Google Privacy Sandbox: Next steps for Privacy Sandbox and tracking protections in Chrome
- Google Tag Manager Help: About consent mode
- Google Developers: Consent mode overview
- Apple Support: If an app asks to track your activity
- Meta Developers: Conversions API Gateway