First-party data consent приходится учитывать явно, когда выбор посетителя и отправка с сервера происходят в разных системах. Очередь должна понимать, какие данные можно передать конкретному приёмнику. Перенос запроса из браузера на сервер сам по себе не даёт разрешения на передачу.
Здесь разбираются технические проверки. Допустимые способы использования данных, регионы и сроки хранения задаются утверждёнными правилами вашей организации и применимыми требованиями платформ. Успешный ответ API не подтверждает соблюдение закона.
Отделите происхождение данных от решения об отправке
У данных из вашей формы или оформления заказа есть определённый источник. Сохраните связь с ним, относящийся к событию выбор посетителя и версию правил обработки. Само наличие записи в базе не означает разрешения на отправку.
Состав запроса в conversions API должен соответствовать утверждённым правилам для приёмника и цели использования. Хэширование меняет представление значения, но не разрешает неопределённость с согласием. Подготовка идентификаторов отдельно разобрана в гайде о хэшировании и нормализации.
Определите, как интеграция хранит согласие, отказ и неизвестное состояние. Отсутствующее значение не должно незаметно становиться разрешением. Укажите владельца правил, чтобы разработчик не выбирал удобное для успешной отправки поведение самостоятельно.
Настройте начальное состояние и обновления Google
Гайд Google по consent mode для сайтов описывает начальное состояние и последующие обновления. В реализации через gtag.js команда начального состояния должна предшествовать командам отправки измерений, включая config и event. Среди сигналов описаны ad_storage, analytics_storage, ad_user_data и ad_personalization.
Если инструмент согласия загружается асинхронно, wait_for_update задаёт ожидание в миллисекундах. В примере Google это 500 миллисекунд. Такое ожидание не является сроком действия согласия и не подтверждает, что пользователь согласился.
Consent mode самостоятельно не сохраняет выбор пользователя. Это должна делать ваша система управления согласием, применяя нужное обновление на следующих страницах. Google также описывает смену ранее выданного разрешения на отказ. Проверьте этот сценарий вместе с первым согласием.
В Google Tag Manager используются собственные API, включая setDefaultConsentState и updateConsentState. Следуйте своему способу реализации. Перенос браузерной команды в посторонний серверный запрос не сохраняет её смысл автоматически.
Передайте в очередь контекст решения
Запись очереди может ссылаться на событие, источник, время выбора, нужные состояния и версию правил, не копируя лишние персональные данные. Это рекомендация для проверяемой реализации, а не общая схема API разных платформ.
| Ситуация | Что проверить | Что записать в результате |
|---|---|---|
| Выбор неизвестен | Правило для неизвестного состояния | Удержание, удаление или ограниченная обработка с причиной |
| Выбор получен до отправки | Связь с нужным событием и целью | Версию правил и выбранную обработку |
| Выбор изменился в очереди | Правило изменения или отзыва | Допустима ли запланированная отправка |
| Назначен повтор | Актуальные условия и поля запроса | Почему попытка отправлена или подавлена |
| Настройка приёмника отсутствует | Есть ли подтверждённое соответствие полей | Конкретный вопрос владельцу конфигурации |
Одной старой записи согласия недостаточно, чтобы определить последствия последующего отзыва для очереди. Это поведение нужно задать отдельно. Идентичность самого события при повторной доставке сохраняйте; механизм рассмотрен в гайде о повторах и идемпотентности.
Настройте каждый приёмник отдельно
Проверьте договорённость для конкретного способа отправки. Флаг ограниченной обработки, поле отказа и состояние согласия тега могут иметь разные значения. Похожие названия не позволяют заменять одно другим.
Гайд Meta требует точного action_source. Поле указывает, где произошло действие, и не является заявлением о согласии. Событие сайта не получает другой источник только потому, что его пересылает сервер.
Для TikTok сначала проверьте актуальную схему событий и документацию применимого механизма обработки данных. Эта статья не задаёт поля согласия или условия их применения для TikTok. Непроверенное соответствие оставьте открытым вопросом, а не копируйте в него настройки Google.
Для других полей тоже важно происхождение. Отдельный разбор client IP и user agent в серверных событиях помогает проверить источник этих значений.
Сравните выбор с реальным исходящим запросом
Подготовьте случаи без выбора, с согласием, с отказом, с изменением решения и с задержанным повтором. Ожидаемую обработку запишите до теста. Затем проверьте, был ли запрос и что он содержал. Посмотрите и последующие очереди, если они есть.
Успешный HTTP-ответ не проверяет правильность обработки согласия. Отказ API тоже не доказывает, что система учла выбор посетителя. Сравните результат с утверждённым правилом и найдите этап, на котором поведение разошлось с ожидаемым.
Журнал должен объяснять решение, но необходимость диагностики не означает бессрочного хранения всех идентификаторов. Доступ и сроки хранения задаются утверждёнными правилами. Полезный результат аудита описывает воспроизводимую ошибку, например превращение неизвестного состояния в разрешение при повторе, и компонент, который нужно исправить.
Учитывает ли очередь записанный выбор посетителя?
Не отправляйте токены и пароли.
Источники
Sources
Обсудите настройки согласия в вашей связке GTM и CAPI