Что Zaraz на самом деле делает на периферии

Zaraz — это серверный менеджер тегов, который выполняется внутри Cloudflare Workers. Когда посетитель загружает страницу, HTML издателя включает небольшой скрипт инициализации Zaraz — обычно несколько килобайт — который собирает структурированную полезную нагрузку события из браузера (просмотр страницы, клик, пользовательское событие) и отправляет её POST-запросом на конечную точку Cloudflare в собственном домене издателя. Worker получает эту полезную нагрузку и запускает настроенные инструменты Zaraz против неё: интеграция Google Analytics 4 отправляет хит Measurement Protocol, интеграция Meta Pixel отправляет событие Conversions API, интеграция Mixpanel отправляет вызов HTTP API. Сторонний JavaScript поставщика никогда не загружается в браузере, cookie поставщика либо вообще не устанавливаются, либо записываются через собственный домен Cloudflare через Worker, и поставщик получает только данные, которые конфигурация Zaraz издателя явно пересылает.

Это архитектурное ценностное предложение. Это также причина, по которой картина согласия отличается от любого клиентского менеджера тегов. При традиционной настройке вопрос согласия — загружается ли JavaScript поставщика или нет. С Zaraz JavaScript никогда не загружается в любом случае — вопрос становится в том, отправляется ли серверная полезная нагрузка или подавляется, и содержит ли полезная нагрузка идентификаторы, нужные поставщику для отслеживания пользователя. У обоих вопросов есть чётко определённые ответы в Zaraz Consent API; задача издателя — правильно их сопоставить.

Zaraz Consent API и чем он отличается от клиентских CMP

Zaraz поставляется со встроенным модулем согласия — Zaraz Consent Tools — который поддерживает состояние согласия для каждого посетителя и ограничивает, какие настроенные инструменты срабатывают. Состояние предоставляется через небольшой JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) для записи выбора пользователя, zaraz.consent.get('analytics') для его чтения, zaraz.consent.getAll() для полной карты, zaraz.consent.modal() для открытия UI согласия, и слушатели событий на zaraz.consent.onModalShown и связанных событиях для пользовательского поведения UI. Каждый инструмент Zaraz в панели управления настраивается с одним или несколькими идентификаторами назначения, и Worker выполняет инструмент только когда соответствующие назначения предоставлены в состоянии согласия посетителя.

Выбор интеграции — использовать ли встроенное модальное окно согласия Zaraz или привязать Zaraz к внешней CMP. Встроенное модальное окно — самый простой путь: включите Consent Tools, определите назначения, настройте каждый инструмент с правильным назначением и отправьте. Путь внешней CMP — правильный выбор для организаций, которые уже стандартизированы на Cookiebot, OneTrust, Usercentrics или пользовательской CMP — Zaraz тогда работает ниже по потоку от CMP, при этом CMP вызывает zaraz.consent.set() по мере того, как пользователь проходит через баннер. Любой путь приходит к той же точке обеспечения: Worker проверяет состояние согласия перед выполнением каждого инструмента, и инструменты, чьи назначения не предоставлены, просто не запускаются.

Поддержка IAB TCF и региональные режимы

Zaraz добавил поддержку IAB TCF v2 в 2023 году и отслеживал среду вперёд с тех пор. Для издателей, работающих в ЕЭЗ и Великобритании по рекламным партнёрствам на основе TCF, интеграция автоматически переводит строку согласия TCF в состояние назначения Zaraz, когда издатель подписывается. Для не-TCF регионов издатель сопоставляет пользовательские назначения — обычно analytics, marketing, personalization, functional — соответствующим инструментам Zaraz напрямую. Тот же Worker обеспечивает оба, что означает, что единая конфигурация Zaraz может обслуживать как посетителя из ЕЭЗ через TCF, так и калифорнийского посетителя через пользовательский маркетинговый шлюз назначения без двух параллельных конвейеров.

Почему Zaraz изменяет картину GDPR и ePrivacy

Правовая позиция по GDPR, ePrivacy и CCPA не освобождается серверным выполнением — правовое основание следует за данными, а не за транспортом — но практическая поверхность соответствия меняется. Три сдвига имеют значение.

• Поверхность cookie сокращается. Большинство cookie поставщиков никогда не записываются, потому что JavaScript поставщика никогда не запускается в браузере. Оставшиеся cookie — обычно собственный идентификатор сеанса Zaraz и любые собственные идентификаторы, которые издатель намеренно распространил. Поверхность несущественных cookie, которую должен ограничивать баннер, поэтому резко меньше — иногда всего один или два cookie против дюжины с лишним, которые производит типичный клиентский стек.
• Раскрытие сторонней передачи меняется. Поскольку Worker отправляет данные поставщикам через вызовы сервер-серверу, путь данных от браузера посетителя — к периферии Cloudflare и оттуда к настроенным поставщикам. Уведомление о конфиденциальности должно это отражать — Cloudflare является обработчиком, а каждый инструмент Zaraz — нижестоящим получателем — но раскрытие во многих отношениях чище, чем эквивалентный клиентский путь, потому что издатель имеет полный контроль над тем, что пересылается.
• Аудиторский след более централизован. Поскольку каждое событие поставщика проходит через Worker, у издателя есть единая точка, в которой можно логировать состояние согласия, полезную нагрузку события и нижестоящего получателя. Регуляторы, ожидающие запрашиваемый журнал согласия, имеют более чёткий ответ с Zaraz, чем с разрастанием клиентских тегов.

Шаблон интеграции, который работает

Эталонное развёртывание имеет четыре движущиеся части. Первая — инициализация Zaraz на странице, загружаемая из домена издателя через прокси Cloudflare. Вторая — либо встроенное модальное окно Consent Tools, либо внешняя CMP, которая вызывает zaraz.consent.set() по мере того, как пользователь делает выбор. Третья — конфигурация панели Zaraz, сопоставляющая каждый инструмент с правильными назначениями — аналитические инструменты с назначением аналитики, рекламные инструменты с маркетинговым назначением, инструменты воспроизведения сеанса с более строгим функциональным или исследовательским назначением, и любой инструмент, зависящий от сторонней передачи, с назначением трансграничной передачи, если уведомление о конфиденциальности издателя предоставляет это как отдельный выбор. Четвёртая — серверный журнал — либо Cloudflare Analytics, Logpush в озеро данных издателя, либо пользовательский Worker, который записывает решения о согласии в запрашиваемое хранилище — чтобы запись согласия могла быть произведена по запросу регулятора.

Шаг проверки — та же последовательность из четырёх проверок, которая применяется к любой интеграции согласия, но со специфичным для Zaraz поворотом. Чистый сеанс браузера с показанным баннером, но без сделанного выбора, должен производить ноль запросов из браузера посетителя к любому домену поставщика и ноль несущественных cookie — оба из которых легче подтвердить с Zaraz, чем с клиентским стеком, потому что отсутствие сторонних запросов является значением по умолчанию, а не настроенным исключением. Визит с отказом должен сохранять это состояние. Визит с принятием должен производить POST-запросы к конечной точке Zaraz, которые несут только события, на которые пользователь дал согласие, и журналы Worker должны показывать срабатывание нижестоящего инструмента. Отзыв должен немедленно останавливать дальнейшие выполнения инструментов Worker, истекать любые установленные Zaraz cookie и запускать соответствующие сигналы удаления или отказа настроенным нижестоящим поставщикам.

Где Zaraz всё ещё требует тщательной обработки

Zaraz не является решением согласия-по-архитектуре, которое устраняет необходимость думать. Три области требуют преднамеренной обработки. Встраивания click-to-load — видео YouTube, Twitter, Instagram, TikTok — всё ещё нуждаются в том же шаблоне заполнителя, который использует любое развёртывание, ориентированное на согласие, потому что Zaraz в настоящее время не проксирует встроенные видео-iframe. Клиентские идентификаторы, которые издатель решает установить в браузере для собственных целей — ID вошедшего пользователя, токен сеанса, корзина A/B-теста — остаются на стороне согласия издателя и нуждаются в собственной логике ограничения. И уведомление о конфиденциальности должно точно описывать модель серверной передачи, включая роль Cloudflare как обработчика и географическое расположение Workers, обрабатывающих данные, потому что периферия Cloudflare работает в нескольких регионах, и трафик посетителя может обрабатываться в регионе, который не является его собственным. С этими обработанными, развёртывание Zaraz в 2026 году превращается из продукта управления тегами в одну из самых чистых архитектур согласия, которую может запустить издатель: меньшая поверхность cookie, меньше сторонних запросов, централизованное обеспечение и аудиторский след, который регулятор действительно может прочитать.