რას ახდენს Zaraz სინამდვილეში Edge-ზე

Zaraz არის სერვერის მხარის ტეგების მენეჯერი, რომელიც Cloudflare Workers-ში სრულდება. როდესაც ვიზიტორი გვერდს ტვირთავს, გამომცემლის HTML შეიცავს მცირე Zaraz ინიციალიზაციის სკრიპტს — ჩვეულებრივ რამდენიმე კილობაიტი — რომელიც ბრაუზერიდან სტრუქტურირებულ მოვლენის payload-ს (pageview, დაწკაპუნება, მორგებული მოვლენა) აგროვებს და POST-ით გამომცემლის საკუთარ დომენზე Cloudflare endpoint-ზე აგზავნის. Worker ამ payload-ს იღებს და მასზე კონფიგურირებულ Zaraz ხელსაწყოებს ახდენს: Google Analytics 4 ინტეგრაცია Measurement Protocol-ის hit-ს გზავნის, Meta Pixel ინტეგრაცია Conversions API მოვლენას გზავნის, Mixpanel ინტეგრაცია HTTP API გამოძახებას გზავნის. ვენდორის მესამე მხარის JavaScript ბრაუზერში არასოდეს ჩაიტვირთება, ვენდორის Cookie-ები ან საერთოდ არ დაიწერება, ან Cloudflare-ის პირველი მხარის დომენის მეშვეობით Worker-ის გზით დაიწერება, და ვენდორი მხოლოდ იმ მონაცემებს იღებს, რომლებსაც გამომცემლის Zaraz კონფიგურაცია პირდაპირ გადასცემს.

ეს არის არქიტექტურული ღირებულების წინადადება. ეს ასევე განმარტავს, თუ რატომ განსხვავდება თანხმობის სურათი ნებისმიერი კლიენტის მხარის ტეგების მენეჯერისგან. ტრადიციული კონფიგურაციით, თანხმობის კითხვაა, ჩაიტვირთება თუ არა ვენდორის JavaScript. Zaraz-ით, JavaScript არც ერთ შემთხვევაში ჩაიტვირთება — კითხვა ხდება, ხდება თუ არა სერვერის მხარის payload-ის გაგზავნა ან დადუმება, და შეიცავს თუ არა payload-ი იდენტიფიკატორებს, რომლებიც ვენდორს სჭირდება მომხმარებლის თვალყურის მიდევნებისთვის. ორივე კითხვას 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-ზე და დაკავშირებულ მოვლენებზე event listener-ები მორგებული UI ქცევისთვის. Dashboard-ში ყოველი Zaraz ხელსაწყო ერთი ან მეტი მიზნის ID-ით კონფიგურირებულია, და Worker ხელსაწყოს მხოლოდ მაშინ ახდენს, როდესაც შესაბამისი მიზნები ვიზიტორის თანხმობის მდგომარეობაში მოცემულია.

ინტეგრაციის არჩევანია, გამოვიყენოთ Zaraz-ის ჩაშენებული თანხმობის modal, თუ Zaraz-ი გარე CMP-ს დავუკავშიროთ. ჩაშენებული modal ყველაზე მარტივი გზაა: Consent Tools-ის ჩართვა, მიზნების განსაზღვრა, თითოეული ხელსაწყოს სწორი მიზნით კონფიგურაცია და გაშვება. გარე CMP-ის გზა სწორი არჩევანია იმ ორგანიზაციებისთვის, რომლებიც უკვე სტანდარტიზებულია Cookiebot-ზე, OneTrust-ზე, Usercentrics-ზე ან მორგებულ CMP-ზე — Zaraz შემდეგ CMP-ს downstream-ში მუშაობს, CMP კი zaraz.consent.set()-ს გამოიძახებს, სანამ მომხმარებელი ბანერს გადის. ორივე გზა ერთ და იმავე განხორციელების წერტილს აღწევს: Worker თითოეული ხელსაწყოს შესრულებამდე თანხმობის მდგომარეობას ამოწმებს, და ხელსაწყოები, რომელთა მიზნები მოცემული არ არის, უბრალოდ არ გაშვებულა.

IAB TCF მხარდაჭერა და რეგიონული რეჟიმები

Zaraz-მა IAB TCF v2 მხარდაჭერა 2023 წელს დაამატა და მას შემდეგ framework-ის გადაადგილებას ადევნებს. EEA-სა და UK-ში TCF-ზე დაფუძნებული სარეკლამო პარტნიორობის ფარგლებში მოქმედი გამომცემლებისთვის ინტეგრაცია ავტომატურად თარგმნის TCF-ის თანხმობის სტრიქონს Zaraz-ის მიზნის მდგომარეობაში, როდესაც გამომცემელი opt in-ს ახდენს. TCF-ის გარეთ მყოფი რეგიონებისთვის გამომცემელი მორგებულ მიზნებს — ჩვეულებრივ analytics, marketing, personalization, functional — პირდაპირ შესაბამის Zaraz ხელსაწყოებზე ათვლის. ერთი და იგივე Worker ორივეს ახდენს, ანუ ერთი Zaraz კონფიგურაცია შეუძლია EEA-ს ვიზიტორს TCF-ის მეშვეობით და კალიფორნიელ ვიზიტორს მორგებული marketing-მიზნის gate-ის მეშვეობით ემსახუროს ორი პარალელური pipeline-ის გარეშე.

რატომ ცვლის Zaraz GDPR-ისა და ePrivacy-ის სურათს

GDPR-ის, ePrivacy-ის და CCPA-ს ფარგლებში სამართლებრივი მდგომარეობა სერვერის მხარის შესრულებით არ გათავისუფლდება — სამართლებრივი საფუძველი მიჰყვება მონაცემებს, არა ტრანსპორტს — მაგრამ პრაქტიკული შესაბამისობის ზედაპირი იცვლება. სამი ცვლილება მნიშვნელოვანია.

• Cookie-ის ზედაპირი მცირდება. ვენდორის Cookie-ების უმეტესობა არასოდეს იწერება, რადგან ვენდორის JavaScript ბრაუზერში არასოდეს სრულდება. დარჩენილი Cookie-ები ჩვეულებრივ Zaraz-ის საკუთარი სესიის იდენტიფიკატორია და ნებისმიერი პირველი მხარის იდენტიფიკატორი, რომელიც გამომცემელმა განზრახ გაავრცელა. ბანერმა რომ გამოსასვლელი მოახდინოს, არა-არსებითი Cookie-ის ზედაპირი მნიშვნელოვნად უფრო მცირეა — ზოგჯერ მხოლოდ ერთი ან ორი Cookie, ტიპური კლიენტის მხარის stack-ის მიერ გამოწვეული ათეულობოდ Cookie-ის ნაცვლად.
• მესამე მხარეში გადაცემის გამჟღავნება იცვლება. იმის გამო, რომ Worker სერვერი-სერვერ გამოძახებებით ვენდორებს მონაცემებს უგზავნის, ვიზიტორის ბრაუზერიდან მონაცემების გზა Cloudflare-ის Edge-ს მიემართება, შემდეგ კი — კონფიგურირებულ ვენდორებს. კონფიდენციალურობის შეტყობინება უნდა ასახავდეს ამას — Cloudflare არის მონაცემთა დამამუშავებელი, ხოლო თითოეული Zaraz ხელსაწყო downstream მიმღებია — მაგრამ გამჟღავნება ბევრი თვალსაზრისით უფრო გამჭვირვალეა, ვიდრე ეკვივალენტური კლიენტის მხარის გზა, რადგან გამომცემელს სრული კონტროლი ექვს გადასაცემ ინფორმაციაზე.
• აუდიტის კვალი უფრო ცენტრალიზებულია. ვინაიდან ვენდორის ყოველი მოვლენა Worker-ში გაივლის, გამომცემელს ერთი წერტილი გააჩნია, სადაც შეიძლება ჩაიწეროს თანხმობის მდგომარეობა, მოვლენის payload და downstream მიმღები. მარეგულირებლებს, რომლებიც query-ს მიდგომად თანხმობის ჟურნალს ელიან, Zaraz-ით უფრო მკაფიო პასუხი ეძლევათ, ვიდრე კლიენტის მხარის ტეგების გავრცელებით.

ინტეგრაციის შაბლონი, რომელიც მუშაობს

საცნობარო deployment-ს ოთხი მოძრავი ნაწილი ახლავს. პირველია Zaraz-ის ინიციალიზაცია გვერდზე, Cloudflare-ის proxy-ს მეშვეობით გამომცემლის დომენიდან ჩატვირთული. მეორეა ჩაშენებული Consent Tools modal ან გარე CMP, რომელიც zaraz.consent.set()-ს გამოიძახებს, სანამ მომხმარებელი გზავნილებს ირჩევს. მესამეა Zaraz dashboard-ის კონფიგურაცია, რომელიც თითოეული ხელსაწყოს სწორ მიზნებზე ათვლის — ანალიტიკის ხელსაწყოები analytics მიზანზე, სარეკლამო ხელსაწყოები marketing მიზანზე, session-replay ხელსაწყოები უფრო მკაცრ functional ან research მიზანზე, და მესამე მხარეში გადაცემაზე დამოკიდებული ყველა ხელსაწყო cross-border-transfer მიზანზე, თუ გამომცემლის კონფიდენციალურობის შეტყობინება ამას ცალკე არჩევანად ასახავს. მეოთხეა სერვერის მხარის ჟურნალი — Cloudflare Analytics, Logpush გამომცემლის data lake-ში, ან მორგებული Worker, რომელიც query-ს მისაწვდომ საცავში წერს თანხმობის გადაწყვეტილებებს — რათა მარეგულირებლის მოთხოვნისამებრ თანხმობის ჩანაწერი წარმოდგენილ იქნეს.

ვალიდაციის ნაბიჯი ის ოთხი შემოწმების მიმდევრობაა, რომელიც ნებისმიერ თანხმობის ინტეგრაციაზე ვრცელდება, მაგრამ Zaraz-ის სპეციფიკური twist-ით. სუფთა ბრაუზერის სესიაში, სადაც ბანერი ნაჩვენებია, მაგრამ არჩევანი გაკეთებული არ არის, ნულოვანი მოთხოვნა უნდა მიდიოდეს ვიზიტორის ბრაუზერიდან ვენდორის ნებისმიერ დომენზე და ნულოვანი არა-არსებითი Cookie — ორივე Zaraz-ით უფრო ადვილი დასადასტურებელია, ვიდრე კლიენტის მხარის stack-ით, რადგან მესამე მხარის მოთხოვნების არარსებობა ნაგულისხმევია, და არა კონფიგურირებული გამონაკლისი. უარყოფის ვიზიტი ამ მდგომარეობას უნდა ინახავდეს. მიღების ვიზიტი Zaraz endpoint-ის POST-ებს უნდა წარმოქმნიდეს, რომლებიც მხოლოდ იმ მოვლენებს ატარებენ, რომლებსაც მომხმარებელი დაეთანხმა, და Worker-ის ჟურნალებმა downstream ხელსაწყოს შესრულება უნდა გამოავლინოს. გაუქმება Worker-ის ხელსაწყოს შემდგომი შესრულება დაუყოვნებლივ უნდა ჩერდებოდეს, Zaraz-ის მიერ Cookie-ების ვადა უნდა ეწურება, და კონფიგურირებულ downstream ვენდორებთან შესაბამისი წაშლის ან opt-out სიგნალები უნდა გაშვებოდეს.

სად სჭირდება Zaraz-ს ჯერ კიდევ ფრთხილ მოპყრობა

Zaraz არ არის არქიტექტურით-თანხმობის გადაწყვეტა, რომელიც ფიქრის საჭიროებას გამოარიდებს. სამი სფერო განზრახ მოპყრობას მოითხოვს. დაწკაპუნებით ჩასაყვანი ჩაშენებები — YouTube, Twitter, Instagram, TikTok ვიდეო — ჯერ კიდევ ამ სამყარეს ჩვეულ placeholder-ის შაბლონს საჭიროებენ, რადგან Zaraz ჯერჯერობით ჩაშენებულ ვიდეოს iframe-ებს proxy-ს არ ახდენს. კლიენტის მხარის იდენტიფიკატორები, რომლებსაც გამომცემელი ბრაუზერში პირველი მხარის მიზნებისთვის ათვლის — შესული მომხმარებლის ID, სესიის ტოკენი, A/B ტესტის bucket — თანხმობის საზღვრის გამომცემლის მხარეს რჩება და სიმკვრივის საკუთარი logic სჭირდება. და კონფიდენციალურობის შეტყობინება ზუსტად უნდა აღწერდეს სერვერის მხარის გადაცემის მოდელს, Cloudflare-ის processor-ად როლის ჩათვლით და მონაცემების დამუშავებელი Workers-ების გეოგრაფიული მდებარეობის ჩათვლით, რადგან Cloudflare edge მრავალ რეგიონში მუშაობს და ვიზიტორის ტრაფიკი შეიძლება მათი საკუთარი არა-რეგიონში დამუშავდეს. ამის გათვალისწინებით, Zaraz-ის 2026 წლის deployment ტეგების მართვის პროდუქტიდან გამომცემლის მიერ გამოყენებული ერთ-ერთ ყველაზე სუფთა თანხმობის არქიტექტურად გარდაიქმნება: Cookie-ის ზედაპირის შემცირება, ნაკლები მესამე მხარის მოთხოვნები, ცენტრალიზებული განხორციელება და აუდიტის კვალი, რომლის წაკითხვაც მარეგულირებელს შეუძლია.