С марта 2024 года каждый бренд, обслуживающий европейский трафик, работает с Consent Mode v2. Стандарт TCF 2.2 от IAB встроен в основу CMP с середины 2023 года. Прошло два года — и вопрос перешёл от "мы соответствуем" к "как минимизировать потери моделирования". Потому что получить 100% сигнала в GDPR-совместимом стеке физически невозможно. Когда 30–70% пользователей (в зависимости от рынка и вертикали) отклоняют куки аналитики и объявлений, на помощь приходит моделирование преобразований платформ. В этой статье мы разберём, как ограничить потери на этапе моделирования — не поверхностными ответами, а через архитектуру на стороне сервера и качество сигнала.
Логика моделирования Consent Mode v2
Google Consent Mode версии v2 принёс два ключевых изменения: параметры ad_user_data и ad_personalization разделены. Теперь пользователь может сказать "аналитика да, ремаркетинг нет". Это разделение позволяет отправлять Google Ads частичный сигнал согласия — то есть вместо полностью отключённого пикселя отправлять "этот пользователь согласился на измерение, но не на персонализацию объявлений".
Для пользователей с согласием измерение работает обычным образом. Для тех, кто не согласился, Google Ads запускает conversion modeling: статистически проецирует поведение пользователей с согласием (похожая география, устройство, браузер, сигналы кампании) на группу без согласия. Это моделирование не на 100% точно — качество зависит от процента согласия, объёма данных и разнообразия сигналов.
Потеря при моделировании возникает здесь: если процент согласия составляет 40%, Google предполагает поведение оставшихся 60%. Это предположение имеет погрешность. Особенно в кампаниях с низким объёмом (менее 50 преобразований в день) модель не находит статистической значимости и разрыв между "observed + modeled" растёт. Если в интерфейсе Google Ads колонка "Modeled conversions" выше 15% — доверие к моделированию снижается, оптимизация ставок работает вслепую.
У Consent Mode есть режимы basic и advanced. В basic режиме при отсутствии согласия тег не срабатывает — никакого сигнала. В advanced режиме тег срабатывает, но отправляет безкукийный пинг. Advanced режим предоставляет больше входных данных для модели, потому что просмотры страниц и события всё ещё передаются (без ID пользователя). Google рекомендует advanced — но использование этого режима требует TCF 2.2-совместимого CMP и анонимизации пингов. В противном случае возникает риск нарушения GDPR.
Ограничение потери сигнала через Server-Side GTM
В client-side Google Tag Manager отказ в согласии обычно означает нулевой сигнал. Server-side GTM открывает иные возможности: можно передавать на сервер какие-то first-party сигналы даже без браузерных кук. Комбинация Consent Mode v2 + sGTM создаёт следующий поток:
- Пользователь не даёт согласие.
- Client-side GTM в режиме advanced отправляет пинг (анонимный).
- Пинг падает на сервер sGTM.
- sGTM обогащает этот пинг first-party данными: город по IP, user-agent, referrer, timestamp начала сессии, целевая страница.
- Этот обогащённый пинг отправляется в Google Ads как Enhanced Conversions или в CAPI (Meta).
В этом потоке идентификатора пользователя нет (ID куки, client ID), но если есть хешированная электронная почта или номер телефона (пользователь заполнил форму и дал согласие) — они могут быть отправлены. Google сопоставляет этот хеш со своей базой данных и использует как дополнительный вход для моделирования. Для Meta CAPI та же логика — серверные события могут обеспечивать 20–40% больше совпадений, чем клиентские (бенчмарк Facebook 2024).
Однако важный момент: строить sGTM только как решение проблемы согласия недостаточно. Серверная архитектура приносит с собой задачи дедупликации, stitching событий и качества данных. Например, если одно преобразование отправлено и со стороны клиента, и со стороны сервера, оно будет подсчитано дважды. Поэтому нужно правильно использовать поле transaction_id и разработать ключ дедупликации, связывающий клиентские и серверные теги.
Пример сценария: в e-commerce сайте пользователь добавляет товар в корзину без согласия. Client-side GTM отправляет только page_view (без кук). На странице checkout пользователь вводит электронную почту. Эта почта идёт в sGTM, хешируется и отправляется в Enhanced Conversions API Google Ads. Google пытается сопоставить этот хеш с хешами Google Accounts в своей базе. Если совпадает — преобразование приписывается пользователю (не модель, а реальное совпадение). Процент совпадений 50–70% (в зависимости от вертикали). Остальное — по-прежнему моделирование, но с более богатыми входными данными, поэтому погрешность моделирования ниже.
Влияние TCF 2.2 на attribution stack
Transparency & Consent Framework 2.2 от IAB Europe сделал consent string CMP ещё детальнее. Строка TCF 2.2 теперь отдельно хранит список вендоров, список целей и информацию о законных интересах. Например, пользователь может не дать согласие на "Purpose 1: Personalized ads", но дать на "Purpose 7: Measurement". При таком раскладе tracking преобразований в Google Ads может работать, а создание списков ремаркетинга — нет.
Если вы используете CMP, не совместимый с TCF 2.2, строка согласия неполная, и Google не может правильно интерпретировать сигнал. Например, в старых версиях OneTrust или Cookiebot было TCF 2.0 — без обновления на 2.2 формат строки согласия может сбить вызов gtag('consent', 'update', ...) в Google Tag Manager. Результат: теги либо не срабатывают вообще, либо считают всех пользователей дающими согласие — нарушение GDPR.
Другой эффект TCF 2.2 — в программатик стеке, как Prebid.js. Prebid 8.0+ читает TCF 2.2 строку и добавляет её в bid request. Если пользователь не дал согласие на Purpose 2 (Select basic ads), Prebid делает анонимный бид без ID пользователя. Это может снизить CPM на 30–50% (данные Index Exchange 2025). Для издателей с низким процентом согласия — прямая потеря дохода. Но рисковать нарушением GDPR нельзя. Решение: интегрировать consent prompt в UX и повысить процент согласия. Например, CMP с посылом "Дайте согласие на персонализацию, видите меньше, но релевантнее" может повысить процент согласия с 40% до 60% (case study ConsentManager.net 2024).
Строка TCF 2.2 также интегрируется с Google Ad Manager. Limited Ads режим в GAM включается/выключается по TCF строке. Если пользователь не дал согласие на Purpose 1+2+3+4, GAM показывает limited ads (contextual targeting, анонимно). Этот режим понижает eCPM, но обеспечивает compliance. Однако некоторые премиум рекламодатели не берут limited ads inventory — это снижает fill rate. Здесь критично максимизировать процент согласия издателю.
Измерение и отслеживание потерь при моделировании
Чтобы измерить, какие потери даёт моделирование согласия, в Google Ads надо сравнить метрики "All conversions" и "Conversions". "All conversions" включает и observed, и modeled. "Conversions" — только observed. Если соотношение all_conversions / conversions выше 1.3, потеря при моделировании высока — 30% преобразований — это предположения.
Отслеживать это соотношение по кампаниям критично. Например, в branded search согласие обычно выше (пользователь уже заинтересован, вероятность согласия больше). В generic search процент согласия ниже, потеря при моделировании выше. Здесь стратегия ставок меняется: при высокой потере от моделирования лучше максимизировать преобразования, чем использовать target ROAS — потому что ROAS на modeled conversions может быть неправильным.
В Google Analytics 4 можно отслеживать статус согласия, но GA4 не имеет отчёта о modeled conversions. GA4 считает только пользователей, давших согласие. Поэтому между Google Ads и GA4 всегда будет разница в преобразованиях. Например, Google Ads показывает 100 преобразований, GA4 — 70. Это нормально — GA4 не считает безкукийных пользователей. Но отслеживать этот разрыв всё равно нужно: если процент modeled conversions в Google Ads растёт, а в GA4 остаётся стабильным — это может сигнализировать о завышенном моделировании.
Ещё способ отслеживания — BigQuery экспорт. Google Ads Data Transfer ежедневно выгружает conversion data в BigQuery. Здесь поле ConversionAction.attribution_model_settings.data_driven_attribution_status показывает "ELIGIBLE" — значит, data-driven attribution (DDA) работает. DDA анализирует путь пользователей, давших согласие, и распределяет modeled conversions на основе этого. Но если процент согласия упадёт ниже 40%, DDA становится "NOT_ELIGIBLE" и система вернётся на last-click attribution. CPA верхних воронок кажутся выше — риск обрезания бюджета.
Инженерный подход к повышению процента согласия
Надо признать: повышение процента согласия — не маркетинговая, а инженерная задача. Дизайн, размещение, текст CMP prompt — это одно, но техническая производительность не менее важна. Например, если CMP скрипт создаёт задержку загрузки 500ms, пользователи могут закрыть страницу до появления prompt. Тогда согласие дефолтит на "отклонено".
Загрузка prompt'а до попадания в viewport (критический CSS) может повысить процент согласия на 10–15%. Важна также мобильно-ориентированная разработка prompt — на десктопе процент согласия 60%, а на мобиле может упасть до 30%, потому что пользователь случайно нажимает "Отклонить" или prompt занимает весь экран и блокирует скролл.
Другой способ — прогрессивное согласие. При первом посещении просите только "аналитику", ремаркетинг — позже (при добавлении в корзину или регистрации). Этот двухэтапный подход в некоторых вертикалях может поднять процент согласия с 40% до 55% (Usercentrics 2025 whitepaper). Но нужна правильная работа TCF 2.2 string в CMP — иначе, когда пользователь даёт согласие на втором этапе, сигналы прошлых событий теряются.
Value exchange также эффективен: "Дайте согласие на объявления, получите бесплатный премиум контент". Но этот подход может нарушить GDPR принцип "freely given consent" — если вы ставите условие "без согласия ничего не видишь", согласие недействительно. Здесь тонкая линия: "согласишься — получишь бонус" легально, "не согласишься — доступа нет" нет.
Наконец, при интеграции Dijital Pazarlama инфраструктуры с consent mode надо одновременно укреплять first-party data pipeline. В каждой точке сбора email или номера телефона хешируйте данные и привязывайте к серверным тегам. Тогда, даже без куки, пользователь может быть matched через Enhanced Conversions или CAPI. При высоком проценте match потери при моделировании снижаются — прямая атрибуция вырастает.