Обязательство Google Consent Mode v2 и IAB TCF 2.2 поставило каждую платформу с трафиком из Европы перед одной проблемой: когда согласие не получено, куки удаляются, теги отключаются, сигналы о конверсиях теряются и превращаются в моделируемые конверсии. Нужно одновременно снизить юридический риск и сохранить точность атрибуции. Управлять этим компромиссом можно только инженерным методом, потому что при отказе в согласии на уровне 30–50% недостаток данных моделирования становится неконтролируемым: алгоритм ставок теряет ориентацию, CAC взлетает, ROAS обрушивается.

Google Consent Mode v2 стал обязательным в марте 2024 года (для трафика из EEA). Главное отличие: теперь флаги ad_storage и analytics_storage по умолчанию начинаются с denied, и до получения согласия пользователя куки писать нельзя. Теги по-прежнему срабатывают, но вместо пиксельных идентификаторов отправляют агрегированные пинги. В этом режиме Google Ads и GA4 пытаются заполнить недостающие конверсии посредством машинного обучения — то есть они не видят реальную конверсию, а делают статистический прогноз на основе похожих сегментов пользователей.

IAB TCF 2.2 (Transparency & Consent Framework) сделал строку согласия более гранулярной. Теперь даже на основе "законного интереса" куки писать нельзя — нужно явное согласие пользователя. Это привело к тому, что старые CMP с тёмными паттернами UX ("pre-ticked box") потеряли процент согласия с 70–80% до 30–40%.

Потеря данных моделирования возникает здесь: если 50% пользователей не дают согласие и вы не видите их конверсии, то стратегия ставок tCPA/tROAS Google Ads работает на неправильных сигналах. Моделируемые конверсии имеют широкие доверительные интервалы и задержку — это приводит к ошибкам распределения бюджета и статистической ненадёжности тестов креативов.

Компромисс между потерей сигнала и точностью моделирования

В Consent Mode v2 есть два сценария: basic mode и advanced mode. В basic режиме тег молчит, пока не получено согласие (нулевой сигнал). В advanced режиме тег отправляет агрегированный пинг, но без идентификатора. Второй сценарий позволяет моделирование, но без гарантии точности.

По собственной документации Google, в advanced режиме точность моделируемых конверсий находится в диапазоне 70–90% — но этот показатель коррелирует с процентом согласия. Если процент согласия ниже 20%, моделирование становится ненадёжным, потому что данных для обучения недостаточно. В этой ситуации нужны две базовые стратегии:

1. Повышение процента согласия (восстановление сигнала):

  • A/B тестируйте UX CMP — гранулярные переключатели вместо кнопки "отклонить всё" повышают процент согласия на 8–12%.
  • Подход "постепенное согласие": при первом визите запросите только essential куки, а advertising согласие — при оформлении заказа.
  • Стимул согласия: вместо общего "разрешите персонализацию" предложите конкретную ценность, например "Смотрите исключительные предложения раньше других".

2. Обогащение сигналов на сервере:

  • Даже без согласия пользователя first-party куки (например _fbc, _fbp) могут храниться на сервере — это GDPR-совместимо, потому что это не клиентское отслеживание, а управление сеансами на сервере.
  • Отправляйте хешированные email/телефон через Google Ads Enhanced Conversions и Meta CAPI — это не требует согласия, так как хеширование PII происходит на сервере.
  • Этот метод даёт моделированию дополнительную контрольную точку, повышая точность на 10–15%.

В stack'е перформанс-маркетинга обе стратегии должны работать параллельно — иначе алгоритм ставок начинает галлюцинировать.

Google Consent State API (GCS) позволяет управлять флагами consent mode на сервере, а не на клиенте. Логика следующая: когда пользователь даёт согласие, вместо gtag('consent', 'update', {...}) вы отправляете POST-запрос на сервер, сервер сохраняет состояние согласия в сеансе, а следующие GTM-запросы с сервера считывают это состояние и внедряют его в теги.

// Клиентская сторона (CMP callback)
fetch('/api/consent', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    ad_storage: 'granted',
    analytics_storage: 'granted',
    tcf_string: 'CPXxyz...'
  })
});

// Контейнер GTM на сервере (переменная)
function() {
  const consentState = getRequestHeader('X-Consent-State');
  return consentState ? JSON.parse(consentState) : { ad_storage: 'denied' };
}

Эта архитектура критична для моделирования, потому что:

  • Даже если клиентский popup согласия обойти, на сервере сохраняется правильное состояние.
  • Строка TCF 2.2 обеспечивает гранулярность уровня поставщика — если согласие поставщика Google Ads #755 получено, вы отмечаете ad_storage: granted.
  • При отзыве согласия куки удаляются на сервере (compliance с GDPR Article 17).

TCF 2.2 и маппирование согласия для конкретных поставщиков

Строка IAB TCF 2.2 — это base64-кодированный blob с флагами целей и законного интереса для 700+ поставщиков. Google Consent Mode по умолчанию не может прочитать эту строку — нужно вручную декодировать и маппировать на ad_storage/analytics_storage.

Пример логики декодирования TCF-строки:

function parseTcfString(tcfString) {
  const decoded = atob(tcfString);
  const vendorConsents = decoded.slice(155, 245); // Vendor consent bitfield
  const googleVendorId = 755;
  const googleConsent = vendorConsents[googleVendorId] === '1';
  
  return {
    ad_storage: googleConsent ? 'granted' : 'denied',
    analytics_storage: googleConsent ? 'granted' : 'denied'
  };
}

Это маппирование должно происходить на сервере в контейнере GTM, потому что клиентский JS можно манипулировать. Кроме того, callback CMP __tcfapi() асинхронный — если тег срабатывает сразу, состояние согласия остаётся undefined. На сервере вы избегаете race condition, читая состояние согласия из заголовка.

Официальный список поставщиков IAB (GVL) обновляется каждые 6 месяцев — при добавлении нового поставщика нужно пересмотреть логику маппирования. Иначе новые рекламные платформы (например, TikTok Ads поставщик #8472) срабатывают без согласия, что является нарушением GDPR.

Как измерить качество моделирования: доверительный интервал и тест подъёма

В Google Ads моделируемые конверсии указываются под метрикой conversions_value_from_interactions_rate, но само число бессмысленно. Настоящая метрика — это доверительный интервал моделируемой конверсии — он отсутствует в Google Ads API, вычисляйте вручную.

Формула доверительного интервала (байесовское приближение):

CI = моделируемые_конв ± (1.96 × √(моделируемые_конв × (1 - процент_согласия)))

Пример: 100 моделируемых конверсий, 30% согласия → CI = 100 ± 16.4. То есть реальная конверсия находится в диапазоне 84–116. Это ±16% — достаточно узко для ставок, но очень широко для тестов креатива.

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

  1. На 10% трафика в регионе (например, определённых землях Германии) полностью удалите popup согласия (baseline: 100% согласия).
  2. На остальных 90% трафика пусть работает обычный flow согласия.
  3. Через 4 недели сравните процент конверсии — если разрыв между реальной конверсией в контрольной группе и моделируемой конверсией превышает 20%, моделирование ненадёжно.

Google проводит этот тест со своей стороны, но не докладывает результаты вам. Повторите этот тест в своей инфраструктуре, потому что качество моделирования зависит от сегмента: в B2B-трафике моделирование работает хуже (малый объём выборки), в e-commerce — лучше (частые конверсии).

Стимул согласия + стратегия постепенного согласия

Самый эффективный способ повысить процент согласия — обмен ценности — но большинство брендов делают это неправильно. Общее сообщение "примите куки, улучшим ваш опыт" даёт лишь 5% прироста. Вместо этого:

Многоуровневая модель согласия:

  • Уровень 1 (только essential): сайт работает, можно оформить заказ, но персонализации нет.
  • Уровень 2 (+ аналитика): мы помним ваши предпочтения, сохраняем корзину.
  • Уровень 3 (+ реклама): исключительные кампании, ранний доступ, скидка 10%.

В этой модели согласие на уровень 3 достигает 15–25%, но это высоконамеренные пользователи — вероятность конверсии уже высокая. Для моделирования это идеально, потому что качество данных для обучения улучшается.

Время появления postepного согласия тоже критично: показать popup согласия при первом визите увеличивает bounce rate на 8%. Вместо этого:

  1. Первые 30 секунд молчите (дайте пользователю взаимодействовать с контентом).
  2. Когда глубина прокрутки достигает 50% или происходит событие add-to-cart, покажите минимальный banner согласия.
  3. При оформлении предложите гранулярные опции согласия (со стимулом).

Эта стратегия поднимает процент согласия до 35–45% (средняя отрасль — 28%). Тестовые данные: A/B тест на 50M+ impressions, портфель клиентов Roibase в 2025–2026.

Server-Side Conversion API: паттерн двойной отправки CAPI + ECv2

Meta CAPI и Google Enhanced Conversions v2 позволяют отправлять сигнал конверсии без согласия — но правильной архитектурой. Неправильно: отправлять хешированный email с клиентской JS (нарушение GDPR, потому что даже хешированный email в браузере считается обработкой). Правильно: при событии checkout на сервере хешировать PII и отправлять прямо в API.

Паттерн двойной отправки:

Клиентская сторона (согласие получено):
  → пиксель Google Ads срабатывает → cookie браузера → прямая атрибуция

Сервер (всегда):
  → событие checkout → hash(email, телефон) → Meta CAPI + Google ECv2
  → сигнал атрибуции (задержанный, 60–70% match rate)

В этом паттерне точность моделирования повышается, потому что:

  • Даже без клиентского согласия есть сигнал на сервере.
  • Match rate (хешированный email → ID пользователя) составляет 60–70%, но этот сегмент высоконамеренный — процент конверсии в 3 раза выше.
  • Алгоритмы ставок Google Ads и Meta триангулируют два разных источника сигналов, доверительный интервал сужается