Какво всъщност прави Zaraz на ръба

Zaraz е мениджър на тагове от страна на сървъра, изпълняващ се вътре в Cloudflare Workers. Когато посетител зарежда страница, HTML на издателя включва малък скрипт за инициализация на Zaraz — обикновено няколко килобайта — който събира структурирана полезна товар на събитие от браузъра (преглед на страница, клик, персонализирано събитие) и я POST-ва до крайна точка на Cloudflare в собствения домейн на издателя. Worker получава тази полезна товар и изпълнява конфигурираните Zaraz инструменти срещу нея: интеграцията на Google Analytics 4 изпраща успех на Measurement Protocol, интеграцията на Meta Pixel изпраща събитие на Conversions API, интеграцията на Mixpanel изпраща HTTP API повикване. JavaScript на третата страна на доставчика никога не се зарежда в браузъра, бисквитките на доставчика или изобщо не се задават, или се записват чрез домейна на 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 с zewnętrzen CMP. Вграденият модал е най-простият път: активирайте Consent Tools, дефинирайте целите, конфигурирайте всеки инструмент с правилната цел и публикувайте. Пътят с zewnętrzен CMP е правилният избор за организации, които вече стандартизират с Cookiebot, OneTrust, Usercentrics или персонализиран CMP — тогава Zaraz работи надолу по веригата от CMP, като CMP извиква zaraz.consent.set(), докато потребителят преминава през банера. И двата пътя стигат до същата точка на прилагане: Worker проверява състоянието на съгласие преди изпълнение на всеки инструмент, а инструментите, чиито цели не са предоставени, просто не работят.

Поддръжка на IAB TCF и регионалните режими

Zaraz добави поддръжка на IAB TCF v2 през 2023 г. и е следил напредъка на рамката оттогава. За издатели, работещи в EEA и Великобритания при рекламни партньорства, базирани на TCF, интеграцията автоматично преобразува низа за съгласие TCF в състояние на цел на Zaraz, когато издателят се включи. За региони без TCF издателят директно съпоставя персонализирани цели — обикновено analytics, marketing, personalization, functional — към съответните Zaraz инструменти. Същият Worker прилага и двата, което означава, че единна конфигурация на Zaraz може да обслужва EEA посетител чрез TCF и калифорнийски посетител чрез персонализирана маркетингова цел, без два паралелни тръбопровода.

Защо Zaraz променя картината на GDPR и ePrivacy

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

• Повърхността на бисквитките се свива. Повечето бисквитки на доставчика никога не се записват, защото JavaScript на доставчика никога не работи в браузъра. Останалите бисквитки обикновено са собственият идентификатор на сесията на Zaraz и всички идентификатори от първа страна, които издателят умишлено е разпространил. Повърхността на несъществени бисквитки, която банерът трябва да контролира, е следователно драматично по-малка — понякога само една или две бисквитки срещу дузината и повече, произведени от типичен клиентски стек.
• Разкриването на трансфер на трети страни се променя. Тъй като Worker изпраща данни на доставчиците чрез сървър-сървър повиквания, пътят на данните от браузъра на посетителя е до ръба на Cloudflare и оттам до конфигурираните доставчици. Политиката за поверителност трябва да отразява това — Cloudflare е обработващ и всеки Zaraz инструмент е получател надолу по веригата — но разкриването в много отношения е по-ясно от еквивалентния клиентски път, защото издателят има пълен контрол върху това, което се препраща.
• Одитната следа е по-централизирана. Тъй като всяко събитие на доставчик преминава през Worker, издателят има единна точка, в която могат да се регистрират състоянието на съгласие, полезната товар на събитието и получателят надолу по веригата. Регулаторите, очакващи queryable журнал за съгласие, имат по-ясен отговор с Zaraz, отколкото при разпространението на клиентски тагове.

Моделът на интеграция, който работи

Референсното внедряване има четири движещи се части. Първата е инициализацията на Zaraz в страницата, заредена от домейна на издателя чрез прокси на Cloudflare. Втората е или вграденият модал на Consent Tools, или zewnętrzен CMP, който извиква zaraz.consent.set(), докато потребителят прави избори. Третата е конфигурацията на таблото на Zaraz, съпоставяща всеки инструмент с правилните цели — инструменти за анализи към целта за анализи, инструменти за реклама към маркетинговата цел, инструменти за повторно изпълнение на сесии към по-строга функционална или изследователска цел и всеки инструмент, зависещ от трансфера на трети страни, към целта за трансграничен трансфер, ако политиката за поверителност на издателя го представя като отделен избор. Четвъртата е журнал от страна на сървъра — или Cloudflare Analytics, или Logpush към езерото от данни на издателя, или персонализиран Worker, записващ решенията за съгласие в queryable хранилище — за да може записът за съгласие да бъде представен при поискване от регулатора.

Стъпката за валидиране е същата последователност от четири проверки, прилагана за всяка интеграция на съгласие, но с Zaraz-специфична особеност. Чиста браузърна сесия с показан банер, но без направен избор, трябва да произведе нулеви заявки от браузъра на посетителя до домейна на доставчик и нулеви несъществени бисквитки — и двете са по-лесни за потвърждаване с Zaraz, отколкото с клиентски стек, тъй като отсъствието на заявки от трети страни е по подразбиране, а не конфигурирано изключение. Посещение с отказ трябва да запази това състояние. Посещение с приемане трябва да произведе POST-ове до крайната точка на Zaraz, носещи само събитията, за които потребителят е дал съгласие, а журналите на Worker трябва да показват задействанията на инструмента надолу по веригата. Оттеглянето трябва незабавно да спре допълнителни изпълнения на инструмента на Worker, да изтече всички бисквитки, зададени от Zaraz, и да задейства подходящи сигнали за изтриване или отписване към конфигурираните доставчици надолу по веригата.

Където Zaraz все още изисква внимателно боравене

Zaraz не е решение за съгласие по архитектура, което премахва необходимостта от мислене. Три области изискват умишлено боравене. Вграждания с кликване за зареждане — YouTube, Twitter, Instagram, видео TikTok — все още се нуждаят от същия модел на заместващ елемент, използван от всяко внедряване с приоритет на съгласието, тъй като Zaraz понастоящем не проксира вградени видео iframes. Клиентски идентификатори, които издателят избира да зададе в браузъра за цели от първа страна — ID на влязъл потребител, токен на сесия, кофа за A/B тест — остават от страна на издателя на границата на съгласието и се нуждаят от собствена логика за управление. Политиката за поверителност трябва точно да описва модела за трансфер от страна на сървъра, включително ролята на Cloudflare като обработващ и географското местоположение на Workers, обработващи данните, тъй като ръбът на Cloudflare работи в множество региони и трафикът на посетителя може да бъде обработен в регион, различен от техния. С тези обработени, внедряване на Zaraz през 2026 г. се трансформира от продукт за управление на тагове в една от най-чистите архитектури за съгласие, които издателят може да стартира: по-малка повърхност на бисквитките, по-малко заявки от трети страни, централизирано прилагане и одитна следа, която регулаторът действително може да прочете.