מדריך אינטגרציית הסכמה של Cloudflare Zaraz: ניהול תגיות בצד השרת בקצה לשנת 2026
Cloudflare Zaraz שונה מרוב מוצרי ניהול התגיות שקדמו לו. הרעיון הוא מבני ולא הדרגתי: במקום לטעון את Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight ואת ה-JavaScript של כל ספק אחר לדפדפן המבקר, Zaraz מבצע את האינטגרציות הללו בתוך Cloudflare Workers הפועלים בקצה, מול שרת המקור של המפרסם. הדפדפן רואה סביבת ריצה קטנה יחידה של Zaraz; כלי הספקים פועלים בצד השרת. לבחירה ארכיטקטונית זו יש השלכות מצטברות על ההסכמה. משטח ה-cookie מצטמצם באופן דרמטי מאחר שרוב ה-cookies של הספקים לעולם אינם מוגדרים מלכתחילה. משטח טביעת האצבע מצטמצם מאחר שרוב ה-JavaScript של הספקים לעולם אינו פועל בהקשר הדפדפן. ונקודת אכיפת ההסכמה עוברת מבאנר JavaScript השומר על ערמה של תגיות <script> להחלטה בצד השרת הקובעת אילו אינטגרציות של Zaraz מופעלות ואיזה מטען הן מקבלות. המפרסם המחבר נכון את Zaraz ל-CMP מקבל משטח ציות קטן יותר, דפים מהירים יותר ונתיב ביקורת ברור יותר. המפרסם המתייחס ל-Zaraz כ-Google Tag Manager מהיר יותר ומדלג על חיבור ההסכמה חשוף לסיכון רגולטורי הקשה יותר לזיהוי מאחר שחלק גדול מהפעילות בלתי נראה לביקורות סטנדרטיות המבוססות על דפדפן.
מה Zaraz באמת עושה בקצה
Zaraz הוא מנהל תגיות בצד השרת הפועל בתוך Cloudflare Workers. כשמבקר טוען דף, ה-HTML של המפרסם כולל סקריפט אתחול קטן של Zaraz — בדרך כלל כמה קילובייטים — שאוסף מטען אירוע מובנה מהדפדפן (צפיית דף, לחיצה, אירוע מותאם) ושולח אותו ב-POST לנקודת קצה של Cloudflare בדומיין של המפרסם עצמו. ה-Worker מקבל את המטען הזה ומריץ כנגדו את כלי Zaraz המוגדרים: אינטגרציית Google Analytics 4 שולחת hit של Measurement Protocol, אינטגרציית Meta Pixel שולחת אירוע Conversions API, אינטגרציית Mixpanel שולחת קריאת HTTP API. ה-JavaScript של צד שלישי של הספק לעולם אינו נטען לדפדפן, ה-cookies של הספק או אינם מוגדרים כלל או נכתבים דרך הדומיין הראשוני של Cloudflare באמצעות ה-Worker, והספק מקבל רק את הנתונים שתצורת Zaraz של המפרסם מעבירה במפורש.
זה ערך הצעת הארכיטקטורה. זו גם הסיבה שתמונת ההסכמה שונה מכל מנהל תגיות בצד הלקוח. עם הגדרה מסורתית שאלת ההסכמה היא האם ה-JavaScript של הספק נטען או לא. עם Zaraz, ה-JavaScript לעולם אינו נטען בשני המקרים — השאלה הופכת להיות האם המטען בצד השרת נשלח או מדוכא, והאם המטען מכיל את המזהים שהספק זקוק להם כדי לעקוב אחר המשתמש. לשתי השאלות יש תשובות מוגדרות היטב ב-Zaraz Consent API; תפקיד המפרסם הוא למפות אותן נכון.
Zaraz Consent API וכיצד הוא שונה מ-CMPs בצד הלקוח
Zaraz מגיע עם מודול הסכמה מובנה — Zaraz Consent Tools — המתחזק מצב הסכמה לכל מבקר ושומר על אילו כלים מוגדרים מופעלים. המצב נחשף דרך API קטן של JavaScript: zaraz.consent.set({ analytics: true, marketing: false }) לרישום בחירת המשתמש, zaraz.consent.get('analytics') לקריאתו, zaraz.consent.getAll() למפה המלאה, zaraz.consent.modal() לפתיחת ממשק ההסכמה, ומאזינים לאירועים ב-zaraz.consent.onModalShown ואירועים קשורים להתנהגות ממשק מותאם. כל כלי 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 ועקב אחר המסגרת מאז. עבור מפרסמים הפועלים ב-EEA ובבריטניה תחת שותפויות פרסום המבוססות על TCF, האינטגרציה מתרגמת אוטומטית את מחרוזת ההסכמה TCF למצב מטרה של Zaraz כשהמפרסם בוחר להצטרף. עבור אזורים שאינם TCF, המפרסם ממפה מטרות מותאמות — בדרך כלל analytics, marketing, personalization, functional — ישירות לכלי Zaraz הרלוונטיים. אותו Worker אוכף את שניהם, כלומר תצורת Zaraz בודדת יכולה לשרת גם מבקר EEA דרך TCF וגם מבקר קליפורני דרך שער מטרת שיווק מותאם ללא שתי צינורות מקביליות.
מדוע Zaraz משנה את תמונת GDPR ו-ePrivacy
העמדה המשפטית תחת GDPR, ePrivacy ו-CCPA אינה פטורה מביצוע בצד השרת — הבסיס המשפטי עוקב אחר הנתונים, לא אחר ההובלה — אך משטח הציות המעשי משתנה. שלושה שינויים חשובים.
- משטח ה-cookie מצטמצם. רוב ה-cookies של הספקים לעולם אינם נכתבים מאחר ש-JavaScript הספק לעולם אינו פועל בדפדפן. ה-cookies שנותרים הם בדרך כלל מזהה הסשן של Zaraz עצמו וכל מזהים ראשוניים שהמפרסם הפיץ בכוונה. משטח ה-cookie הבלתי חיוני שהבאנר חייב לשמור עליו הוא לפיכך קטן באופן דרמטי — לפעמים רק cookie אחד או שניים לעומת תריסר ויותר שמחסנית לקוח טיפוסית מייצרת.
- גילוי העברת צד שלישי משתנה. מאחר שה-Worker שולח נתונים לספקים דרך קריאות שרת לשרת, נתיב הנתונים מדפדפן המבקר הוא לקצה של Cloudflare ומשם לספקים המוגדרים. הודעת הפרטיות חייבת לשקף זאת — Cloudflare הוא מעבד וכל כלי Zaraz הוא נמען במורד הזרם — אבל הגילוי הוא מבחינות רבות נקי יותר מהנתיב המקביל בצד הלקוח מאחר שלמפרסם יש שליטה מלאה על מה שמועבר.
- נתיב הביקורת מרוכז יותר. מאחר שכל אירוע ספק עובר דרך ה-Worker, למפרסם יש נקודה בודדת שבה ניתן לרשום את מצב ההסכמה, מטען האירוע ונמען במורד הזרם. לרגולטורים המצפים ליומן הסכמה שניתן לשאילתה יש תשובה ברורה יותר עם Zaraz מאשר עם פיזור של תגיות בצד הלקוח.
תבנית האינטגרציה שעובדת
הפריסה הייחוסית כוללת ארבעה חלקים נעים. הראשון הוא אתחול Zaraz בדף, הנטען מהדומיין של המפרסם דרך הפרוקסי של Cloudflare. השני הוא מודל Consent Tools המובנה או CMP חיצוני הקורא ל-zaraz.consent.set() כשהמשתמש עושה בחירות. השלישי הוא תצורת לוח המחוונים של Zaraz הממפה כל כלי למטרות הנכונות — כלי ניתוח למטרת analytics, כלי פרסום למטרת marketing, כלי הקלטת סשן למטרה פונקציונלית או מחקרית מחמירה יותר, וכל כלי תלוי-העברה-לצד-שלישי למטרת העברה חוצה גבולות אם הודעת הפרטיות של המפרסם חושפת זאת כבחירה נפרדת. הרביעי הוא יומן בצד השרת — Cloudflare Analytics, Logpush לאגם נתונים של המפרסם, או Worker מותאם הכותב החלטות הסכמה לאחסון שניתן לשאילתה — כדי שרשומת ההסכמה תוכל להיות מופקת לפי בקשת הרגולטור.
שלב האימות הוא אותה רצף ארבעת הבדיקות החלים על כל אינטגרציית הסכמה אך עם פיתול ספציפי ל-Zaraz. סשן דפדפן נקי עם הצגת הבאנר אך ללא בחירה שנעשתה אמור לייצר אפס בקשות מדפדפן המבקר לכל דומיין ספק ואפס cookies בלתי חיוניים — שניהם קל יותר לאשר עם Zaraz מאשר עם מחסנית בצד הלקוח מאחר שהיעדר בקשות צד שלישי הוא ברירת המחדל ולא חריג מוגדר. ביקור דחייה אמור לשמור על המצב הזה. ביקור קבלה אמור לייצר את ה-POSTים של נקודת הקצה של Zaraz הנושאים רק את האירועים שהמשתמש נתן להם הסכמה, ויומני ה-Worker אמורים להראות הפעלות כלי במורד הזרם. ביטול אמור לעצור מיידית ביצועי כלים נוספים של Worker, לפוג כל cookie שהגדיר Zaraz, ולהפעיל את אותות המחיקה או ביטול ההסכמה המתאימים לספקים המוגדרים במורד הזרם.
היכן Zaraz עדיין דורש טיפול זהיר
Zaraz אינו פתרון הסכמה לפי ארכיטקטורה שמסיר את הצורך לחשוב. שלושה תחומים דורשים טיפול מכוון. הטמעות לחיצה-לטעינה — YouTube, Twitter, Instagram, וידאו TikTok — עדיין זקוקות לאותו תבנית מציון מיקום שכל פריסת consent-first משתמשת בה, מאחר ש-Zaraz כרגע אינו מיישם פרוקסי ל-iframes של וידאו מוטמע. מזהים בצד הלקוח שהמפרסם בוחר להגדיר בדפדפן למטרות ראשוניות — מזהה משתמש מחובר, אסימון סשן, דלי בדיקת A/B — נשארים בצד המפרסם של גבול ההסכמה וזקוקים להיגיון שמירה משלהם. והודעת הפרטיות חייבת לתאר במדויק את מודל ההעברה בצד השרת, כולל תפקיד Cloudflare כמעבד ומיקום גיאוגרפי של ה-Workers המטפלים בנתונים, מאחר שקצה Cloudflare פועל במספר אזורים ותעבורת המבקר עשויה להיות מעובדת באזור שאינו שלהם. עם אלה שטופלו, פריסת Zaraz בשנת 2026 הופכת ממוצר ניהול תגיות לאחת מארכיטקטורות ההסכמה הנקיות ביותר שמפרסם יכול להפעיל: משטח cookie קטן יותר, פחות בקשות צד שלישי, אכיפה מרוכזת ונתיב ביקורת שרגולטור יכול לקרוא אותו בפועל.