Consent Mode v2 и TCF 2.2: управление потерей моделирования

Google Consent Mode v2 и IAB TCF 2.2 теперь обязательны. С марта 2024 года Google Ads перестает работать с ремаркетингом и таргетингом по аудиториям для трафика из ЕЭЗ + Великобритания без Consent Mode. Но когда вы обеспечиваете правовое соответствие, вы сталкиваетесь с новой проблемой: 40-70% пользователей отклоняют analytics cookie, потеря конверсий достигает 15-35%. Архитектура consent modeling от Google пытается закрыть этот разрыв — но только если она настроена правильно. В этой статье мы разбираем слои имплементации, интеграцию TCF и чек-лист качества данных для минимизации потери при моделировании, используя реальные сценарии.

Что такое Consent Mode v2 и почему моделирование неизбежно

Google Consent Mode — это протокол, который передает статус согласия пользователя (granted/denied) в качестве сигнала платформенным API. В v2 добавлены два новых параметра: ad_user_data (могут ли быть собраны данные для персонализации) и ad_personalization (может ли пользователь быть добавлен в аудиторию ремаркетинга). Без этих двух параметров трафик из ЕЭЗ не может входить в персональный таргетинг Google Ads.

Классическая проблема Consent Mode в том, что если пользователь отклоняет analytics cookie, Google Analytics не может записать событие конверсии. В этом случае ваша кампания Google Ads лишается данных о конверсиях — алгоритм ставок работает вслепую. Здесь на сцену выходит consent modeling: Google пытается спрогнозировать поведение пользователей, которые отклонили согласие, опираясь на похожие когорты пользователей, которые дали согласие, и таким образом смоделировать количество конверсий.

Для того чтобы моделирование работало, требуются два критических входных параметра: (1) достаточный объем данных с granted-согласием (минимум 100 конверсий в день, идеально 1000+), (2) правильная передача статуса согласия (gtag('consent', 'update', {...})). Если оба этих условия не выполнены, моделирование переходит в режим "insufficient data" и потеря не закрывается.

Факторы, влияющие на потерю при моделировании

Согласно документации Google за Q4 2024, consent modeling в аккаунтах с уровнем отказа в согласии около 50% обеспечивает среднее восстановление 70%. То есть если потеря согласия составляет 50%, моделирование может снизить это до 15%. Но этот процент зависит от следующих переменных:

• Объем трафика с granted-согласием: Если ниже 100 в день, модель становится слабой.
• Имплементация CMP: Если CMP совместима с IAB TCF v2.2 (OneTrust, Cookiebot, Usercentrics) и правильно выполняет маппирование purposes + vendors, качество сигнала повышается.
• Использование server-side GTM: Если сGTM контролирует статус согласия на бэкенде, это добавляет first-party контекст и усиливает входные данные для моделирования.
• Разнообразие типов конверсий: Если вместе отслеживаются checkout электронной коммерции + add-to-cart + pageview, модель учится на более широком воронке.

Когда моделирование слабое, стратегия ставок Google Ads (Target ROAS, Max Conversions) недоработает, потому что настоящий сигнал конверсии отсутствует. Чтобы компенсировать это, требуется интеграция offline conversion import или CAPI (Conversions API) с бэкенд-трансфером в Google.

Интеграция TCF 2.2: маппирование Purposes и Vendor List

IAB Transparency and Consent Framework (TCF) 2.2 разделяет согласие пользователя на 10 категорий purposes (целей). Для работы Google Ads требуется минимум Purpose 1 (store/access info) и Purpose 2 (personalization). TCF consent string генерируется CMP и читается через callback __tcfapi затем преобразуется в Consent Mode в GTM.

На практике это работает так: когда пользователь нажимает "Принять" в banner'е CMP, CMP устанавливает tcData.purpose.consents в объект вида {1: true, 2: true, ...}. Этот объект читается в Custom JavaScript variable GTM и маппируется следующим образом:

var tcData = window.__tcfapi || {};
var purposes = tcData.purpose.consents;

if (purposes[1] && purposes[2]) {
  gtag('consent', 'update', {
    ad_storage: 'granted',
    ad_user_data: 'granted',
    ad_personalization: 'granted'
  });
} else {
  gtag('consent', 'update', {
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied'
  });
}

При выполнении этого маппирования нужно обратить внимание на три момента:

1. Проверка Vendor List: Если Google (vendor ID 755) находится в TCF vendor list и пользователь одобрил его, сигнал может быть отправлен. Иначе должен оставаться ad_storage: 'denied'.
2. Модель Legitimate Interest: Purposes 2-7-9-10 также могут работать через "legitimate interest" (законный интерес). В России это юридически рискованно — Russian law не полностью признает эту модель.
3. Периодичность возобновления согласия: В TCF 2.2 согласие должно быть обновлено в течение 13 месяцев. Если ваш CMP не имеет механизма автоматического обновления, согласие должно переходить в denied при истечении срока.

Выбор CMP и чек-лист контроля качества

При выборе CMP обязательна сертификация TCF 2.2. OneTrust и Cookiebot сертифицированы, но вы можете нарушить стандарт IAB, добавив кастомные purposes в конфигурацию. Чек-лист контроля качества:

Шаг 6 критичен: даже при denied-согласии gtag('event', ...) ping должен быть отправлен, cookie просто не должен устанавливаться. Эти ping'и служат входными данными для Google моделирования.

Гибридная архитектура согласия через Server-Side GTM

Наиболее эффективный способ повысить качество сигнала в Consent Mode v2 — это построить архитектуру "гибридного согласия" через server-side GTM (sGTM). В этой модели:

1. Client-side: Статус согласия пользователя читается из CMP и отправляется в Google через gtag('consent', 'update', ...).
2. Server-side: sGTM container проверяет consent header во входящем HTTP request'е. Если согласие granted, server-side событие, поступившее с бэкенда (например, завершение checkout'а), отправляется напрямую в Google Ads Conversion endpoint.

Преимущество этого подхода в том, что даже для пользователей, использующих iOS ATT-отказ или ad blocker'ы, может быть отправлен server-side conversion сигнал. Потому что server-side событие независимо от browser cookie'ов пользователя — оно привязано к backend order ID. Google сопоставляет это через gclid (Google Click ID).

Пример сценария: пользователь использует ad blocker, client-side GTM вообще не загружается. Но на checkout'е бэкенд отправляет HTTP POST в sGTM:

{
  "event_name": "purchase",
  "client_id": "hashed_user_id",
  "gclid": "abc123",
  "value": 250.00,
  "currency": "RUB",
  "consent_ad_storage": "denied"
}

sGTM передает это событие в Google Ads, и поскольку consent_ad_storage: denied, cookie не устанавливается, но конверсия все еще входит в input для моделирования. Для этого требуется Google Ads Conversion Linker tag в sGTM + server-side Client ID маппирование.

Шаги имплементации sGTM

1. Разверните sGTM container: Deploy на Google Cloud Run или Cloudflare Workers.
2. Отправьте событие с бэкенда: Отправляйте событие завершения checkout'а с order ID + gclid + consent flag.
3. Настройте Google Ads tag в sGTM: Введите Conversion ID + Conversion Label, в секции "User-Provided Data" выполните маппирование client_id.
4. Добавьте enforcement согласия: Используя Custom Template в sGTM выполните проверку согласия — если ad_user_data: denied, обязательны маскирование IP + хеширование user_id.

Важный момент в этой архитектуре: для соответствия GDPR client_id, отправляемый с бэкенда, должен быть хеширован SHA-256. Отправка raw email или user ID является нарушением трансфера данных.

Отчетность о потере при моделировании и оптимизация

В интерфейсе Google Ads в разделе "Conversions > Measurement" есть столбец "Modeled conversions". Этот столбец показывает количество конверсий, смоделированных для пользователей, отклонивших согласие. Вот как его читать:

• Observed conversions: Реальные конверсии от пользователей с granted-согласием.
• Modeled conversions: Прогнозируемые конверсии для пользователей с denied-согласием.
• Total conversions: Сумма Observed + Modeled.

Для расчета потери при моделировании используйте простую формулу: (1 - (Modeled / (Всего трафика × Коэффициент отказа согласия))) × 100. Например:

• Всего clicks: 10,000
• Коэффициент отказа согласия: 50% (5,000 человек denied)
• Observed conversions: 150
• Modeled conversions: 60

Ожидаемые конверсии (если бы согласие было): 150 × 2 = 300 (потому что 50% denied). Фактически всего 210 конверсий (150 + 60). Потеря: (1 - (210 / 300)) × 100 = 30%.

Тактики улучшения моделирования

Оптимизируйте эти точки для повышения производительности моделирования:

1. Увеличьте объем трафика с granted-согласием: Сделайте кнопку "Принять" более заметной в banner'е CMP. Но это не должно быть dark pattern — просто улучшите layout, не обманывайте пользователя.
2. Добавьте события воронки: Отправляйте в Google Ads не только purchase, но также add-to-cart, begin_checkout и другие события воронки. Модель улавливает более широкий сигнал intent.
3. Offline conversion import: Импортируйте реальные данные о заказах с бэкенда в Google Ads. Это обходит моделирование, но есть ограничение по API (максимум 2,000 конверсий в день на аккаунт).
4. Enhanced conversions: Отправляйте email/phone хеши вместе с событием конверсии. Это обеспечивает first-party match и повышает точность моделирования.

Примечание: Enhanced conversions находятся в серой зоне GDPR. Если пользователь дал согласие, отправка хеша email'а — это законно, но если он отклонил согласие, отправка этих данных даже в хешированном виде — это нарушение. Поэтому enhanced conversions следует запускать только при ad_user_data: granted.

Компромиссы реального мира: Compliance vs. Performance

Наконец, давайте посмотрим на компромиссы трех разных подходов к стратегии согласия: