Google Consent Mode gcs/gcd: расшифровка параметров согласия

Каждый хит Google-тега - collect-запрос GA4, пинг Google Ads или Floodlight, syndication-запрос - несёт состояние согласия в query string через параметры Google Consent Mode gcs/gcd: gcs с коротким кодом статуса и gcd с детальным. Чтобы прочитать gcs, хватит одной официальной таблицы. С gcd сложнее: Google объясняет, зачем нужен параметр, но не публикует его кодировку, поэтому схема ниже взята из реверс-инжиниринга аналитиков и сверена с публичным декодером. Здесь оба параметра consent mode разобраны значение за значением, и показано, где ручную расшифровку пора остановить.

Что такое параметры gcs и gcd в consent mode

Google-теги добавляют оба параметра к исходящим запросам. Вы встретите их на хитах /g/collect от GA4, на измерительных пингах Google Ads и Floodlight, на syndication-запросах - везде, где Google-тег отправляет событие. В server-side GTM те же значения приходят в event data под префиксными именами x-ga-gcs и x-ga-gcd, рядом с dma и dma_cps - двумя параметрами, которые несут DMA-согласие для сервисов Google.

У параметров разные задачи, и путаница между ними - самая частая ошибка при чтении:

Раз gcs покрывает только два сигнала, страница может отправить gcs=G100, пока gcd того же хита показывает ad_user_data разрешённым после апдейта. Полная картина согласия живёт в gcd. gcs - короткий статус с обратной совместимостью, который consent mode отдаёт с самой первой версии.

Что Google документирует о gcs и gcd

Всё остальное держится на трёх официальных утверждениях. Первое: гайд по отладке согласия даёт формат gcs и полную таблицу значений: «Проверяйте параметр gcs= в URL, чтобы узнать статус согласия. Формат параметра gcs: gcs=G1 [ad_storage][analytics_storage]» - Google, Consent debugging guide. Второе: обзор consent mode сообщает, что параметр gcd «всегда отправляется в сервисы Google, независимо от того, внедрён consent mode или нет» - Consent mode overview. Третье: тот же обзор предупреждает: «Поля Google-тега могут кодироваться для более эффективной передачи. Эти поля могут меняться».

Именно из-за третьей фразы вообще появилось целое направление реверс-инжиниринга. Google так и не опубликовал алфавит gcd, поэтому схему из следующих разделов восстановил Markus Baersch (на английском её опубликовал Simo Ahava), уточнил шаблон-парсер David Vallejo, а проверка шла через публичный decode API того же Vallejo. У каждого утверждения в гайде указан источник: официальная документация, реверс-инжиниринг или гипотеза.

Как читать gcs: матрица G1--

Официальная таблица из актуального гайда по отладке согласия:

За пределами таблицы есть ещё два случая. Если параметра gcs нет вовсе, consent mode не внедрён или теги блокируются ещё до срабатывания - это базовая настройка consent mode, где теги при запрете просто не грузятся. В живом трафике встречается и префикс в нижнем регистре вроде g110: парсеры нормализуют регистр, потому что смысл несут только две цифры после G1.

Параметр отражает итоговое состояние - дефолтное, слитое с апдейтом, если он был. Пользователь, отклонивший баннер, остаётся на G100, а принявший переводит тот же хит в G111. Региональные решения о согласии сводятся в то же итоговое значение.

Как устроен gcd: 12 символов состояния согласия

Схема ниже - консенсус реверс-инжиниринга: её документирует шаблон Vallejo, и ответы публичного декодера с ней сходятся:

1    3t           3t                3t            3t                 5    l1
version ad_storage analytics_storage ad_user_data ad_personalization marker tail

По позициям:

Каждая пара согласия состоит из двух символов: первый - маркер имплицитного согласия, второй - буква состояния, в которой зашиты дефолт и апдейт. Так 13t3t3t3t5l1 читается как «имплицитно разрешено, разрешено по дефолту, апдейта нет» на всех четырёх сигналах. Публичный декодер принимает 12-символьные строки. 10-символьные значения из трафика 2023 года - та же схема без имплицитных маркеров на отдельной позиции и без хвоста, и их всё ещё можно расшифровать вручную по таблице букв ниже.

Что значат буквы в gcd: девять состояний

Буква состояния стоит на чётных позициях строки: 2, 4, 6 и 8. Это таблица, которую Baersch опубликовал через Simo Ahava, с примерами из реального трафика:

Благодаря группировке таблицу можно вычислить, заучивать её не обязательно. Каждая буква - позиция в алфавите base64url, а младшие четыре бита делятся на два поля: (index >> 2) & 3 даёт дефолт, index & 3 - апдейт, где 2 значит «запрещено», а 3 - «разрешено»:

l = index 21: low four bits 0101 - default 1, update 1: not set
p = index 25: low four bits 1001 - default 2, update 1: denied, no update
q = index 26: low four bits 1010 - default 2, update 2: denied, denied
r = index 27: low four bits 1011 - default 2, update 3: denied, granted
t = index 29: low four bits 1101 - default 3, update 1: granted, no update

Мнемоника «три на три» из статей сообщества сжимает ту же таблицу. Ряд алфавита задаёт дефолт: l-m-n - нет дефолта, p-q-r - запрещено, t-u-v - разрешено. Место внутри ряда задаёт апдейт: первая буква - апдейта нет, вторая - запрещено, третья - разрешено.

Что значат нечётные позиции: маркеры имплицитного согласия

Весь 2023 год большинство строк выглядели как 11p1p1p1p5 - имплицитная позиция 1, которую декодер возвращает как незаданную. В 2024-м Google-теги начали массово слать 13t3t3t3t5: та же схема, только с имплицитной 3. Поле implicit, которое публичный декодер отдаёт по каждому сигналу, подтверждает соответствие: 1 расшифровывается как «не задано», 3 - как «разрешено», 2 - как «запрещено».

Поэтому строка вроде 13r3r3r2r5 показывает пользователя, который принял всё, при том что ad_personalization несёт имплицитный запрет. Источники из сообщества связывают этот паттерн с отказами через Global Privacy Control и производными сигналами.

Самая тёмная часть формата - то, что семантически значит «имплицитно разрешено». Шаблон Vallejo читает позицию 10 как маркер Global Privacy Controls, а хвост - как container scoped defaults; в комментариях к материалам Baersch хвост трактуют ровно наоборот. Считайте обе версии гипотезами: декодер отдаёт поля global_privacy_control и containerDefaults, и на строках, проверенных для этого гайда, оба остались пустыми.

Как gcs и gcd описывают одно и то же состояние

Возьмём сайт с consent mode, где по дефолту всё запрещено, и посетителя, который принимает баннер. Хит тогда несёт gcs=G111 и значения вида gcd=13r3r3r3r5l1: буквы r значат «запрещено по дефолту, разрешено апдейтом», что в сумме даёт разрешение - ровно то, что говорит G111. До клика по баннеру тот же сайт отправляет gcs=G100 с gcd=11p1p1p1p5: p - запрет без апдейта, и G100 с этим согласен. Сайт, которому согласие не нужно, шлёт G1--, а gcd всё равно расписывает четыре сигнала, ставя буквы l там, где ничего не настроено.

Официальный текст это соответствие нигде не описывает, так что оно остаётся результатом реверс-инжиниринга. Зато оно выполняется на каждой строке, которую мы прогнали через декодер для этого гайда, и даёт быструю проверку на здравый смысл. Если на хите gcs и первые две пары gcd расходятся, сломана сама настройка согласия.

Как расшифровать gcd за минуту

Частые значения и их расшифровка, каждая проверена через декодер:

Инструменты - в том порядке, в каком за них стоит браться:

1. Tag Assistant - отладчик, который официально рекомендует Google. Он показывает состояние согласия без всякого чтения строк. Гайд Google по отладке предостерегает от вызова команды consent из custom HTML-тега, так что если состояние на странице выглядит неправильно, сначала подозревайте настройку, а уже потом параметры.
2. Публичный decode-эндпоинт - один запрос на одну строку:

curl -s "https://openapi.analytics-debugger.com/v1/google/consent/decode/13r3r3r3r5l1?mode=full"

3. Шаблон переменной для server-side GTM, чтобы расшифровывать локально: парсер Analytics Debugger или шаблон consent-state от dpezrez, который работает без исходящих запросов. Toolbox Lukas Wojcik делает то же самое в браузере, отдельно для gcs и для gcd.

Как проверить gcs и gcd в server-side GTM

Server-side tracking переносит точку проверки из браузера на ваш собственный эндпоинт, и оба параметра едут с каждым пересылаемым событием - те же значения, что браузерный тег поставил в исходящий запрос. В контейнере server-side tracking event data несёт их под префиксными именами, поэтому быстрая проверка выглядит так:

1. Откройте нужный клиент в превью серверного контейнера или залогируйте event data временной переменной.
2. Найдите x-ga-gcs: до решения по баннеру ждите G100, после согласия - G111. Если x-ga-gcs на хитах GA4 нет, запрос, скорее всего, так и не прошёл через состояние согласия веб-тега.
3. Найдите x-ga-gcd и расшифруйте его по таблице букв выше. Здесь ловится случай, который тест баннера пропускает: ad_user_data или ad_personalization в другом состоянии, чем ad_storage.
4. Если значения в веб-контейнере и серверном контейнере различаются, сверьтесь с чек-листом из гайда по миграции на server-side GTM. Почему два слоя могут расходиться вполне законно, разобрано в материале server-side tracking против браузерного пикселя.

Шаблоны сообщества, включая шаблоны stape, отдают те же префиксные поля как переменные - от имён в query string они отличаются только префиксом. Без серверного контейнера оба параметра можно прочитать прямо во вкладке Network браузера на любом запросе /g/collect, и для теста баннера этого обычно хватает. Более полный контекст согласия для cookieless-измерений описан в гайде по cookieless-атрибуции.

Почему не стоит парсить gcd в продакшен-логике

Формат уже менялся дважды: строки 2023 года были длиной 10 символов, в 2024-м добавились имплицитные маркеры и хвост до 12 символов, а у цифры-маркера появились варианты помимо 5. Гайд Baersch говорит прямо: «Это внутренние параметры Google. Их значения могут измениться без предупреждения». Парсер в продакшен-теге, шаблон на продажу или отчёт для комплаенса молча сломается на следующем сдвиге формата.

Ещё три пробела не дают считать строку источником истины. functionality_storage, personalization_storage и security_storage не попадают ни в один из параметров, так что распарсенный gcd не докажет полного покрытия согласия. Семантика имплицитных маркеров и хвоста держится на консенсусе сообщества, официального описания у неё нет. А региональные варианты согласия дают строки, которых в таблицах сообщества пока нет.

Для всего, что грозит последствиями по комплаенсу, берите инструменты, сделанные под эту задачу: Tag Assistant для состояния согласия на странице и собственное зафиксированное состояние согласия как гейт доставки. Дисциплина «храним то, на что согласился посетитель, и отправляем только совпадающее» разобрана в гайде по first-party данным и согласию. Параметры нужны для проверки, а ваша consent-платформа - для контроля исполнения.

Частые вопросы о gcs и gcd

Sources