מדוע Optimizely Web Experimentation דורש הסכמה

אתחול Optimizely ברירת מחדל עושה מספר פעולות בצייר הראשון של הדף. הוא מגדיר עוגיית צד ראשון תחת optimizelyEndUserId המכילה את מזהה המבקר הקבוע, מעריך את המבקר מול הניסויים הפעילים, כותב את הקצאות הוריאנטים לעוגייה שנייה תחת סמני מרחב השם optimizelyOptOut, מפעיל אירוע החלטה אל logx.optimizely.com, ומחיל את שינויי הוריאנט על הדף המרונדר. כשמפעיל חיבר אינטגרציית ניתוח — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap, או Optimizely Data Platform — ה-SDK גם מפעיל אירועי חשיפת וריאנט לשכבת הניתוח, אשר אז מקשרת את הוריאנט לפרופיל הניתוח הרחב יותר של המבקר.

כל אחת מהפעילויות הללו מפעילה שער הסכמה נפרד. שמירת מזהה המבקר היא פעולת אחסון וגישה לפי Article 5(3) של הוראת ePrivacy המחייבת הסכמה מוקדמת, ניתנת בחופשיות, ספציפית, מבוססת ידע וחד-משמעית ברחבי EEA, הממלכה המאוחדת וכל תחום שיפוט שייבא את אותו תקן. קישור הקצאות וריאנט ניסיוני למזהה זה לאורך סשנים הוא עיבוד של נתונים אישיים לפי GDPR מכיוון שהשילוב של מזהה, כתובת IP וחשיפת וריאנט מספיק לזיהוי יחיד ולאפיון האינטראקציה שלו עם תכנית הניסוי. הפצה של נתוני וריאנט בין כלים — Optimizely חושף את הקצאת הוריאנט ל-Google Analytics, למשל — מוסיפה את שער הניתוח לשרשרת. ההנחיות של ה-EDPB מ-2023 היו מפורשות: ניסוי הכולל זיהוי קבוע כפוף לאותם כללי הסכמה כמו ניתוח נתונים; ה-CNIL היה הרגולטור הקולני ביותר בנקודה זו אך אינו היחיד.

מה Optimizely כותב לפני ההסכמה — ומה יש לדכא

קטע הקוד הסטנדרטי של Optimizely מתקין את ה-JavaScript SDK ישירות בראש הדף ומאתחל מיידית בטעינה. זהו ה-quickstart המתועד ומקור כשל הציות הנפוץ ביותר: ה-SDK פועל לפני שבאנר העוגיות רונדר, עוגיית optimizelyEndUserId נכתבת תוך מילי-שניות, הקצאת הוריאנט מתבצעת, ואירוע ההחלטה מופעל ללא קשר למה שהמבקר יחליט מאוחר יותר. כל רגולטור אירופי שפסק על דפוס זה פסק באותו האופן: עוגיות שהוגדרו לפני ההסכמה הן בלתי חוקיות, הקצאת הוריאנט שנלכדה לפני ההסכמה היא עיבוד בלתי חוקי, והמוציא לאור נושא באחריות.

לכן אינטגרציה תואמת חייבת למנוע מ-Optimizely לכתוב את המזהה הקבוע ולהפעיל אירועי החלטה עד שניתנה קטגוריית ההסכמה הרלוונטית. Optimizely תומך בשני דפוסים לכך. הראשון הוא תכונת ההסכמה הייעודית — העבר OPTIMIZELY_OPT_OUT=true כמחרוזת שאילתה או הגדר את עוגיית optimizely.opt_out לפני אתחול ה-SDK — שמכניסה את ה-SDK למצב opt-out שבו לא נכתב מזהה ולא מופעלים אירועים. השני הוא מצב אנונימי בלבד הנתמך בתצורת ה-SDK, שבו ה-SDK פועל במצב ללא-סשן שמקצה וריאנטים על בסיס זיהוי מקומי לסשן בלבד, ללא זיהוי קבוע בין ביקורים. מצב אנונימי מאפשר לתכנית הניסוי לפעול על בסיס עניין לגיטימי להחלטת הרינדור תוך דחיית הזיהוי הקבוע עד מתן ההסכמה.

העוגיות ואחסון שכותב Optimizely

ה-SDK של Optimizely Web Experimentation כותב בעת האתחול את המזהים הבאים, כולם אינם חיוניים ודורשים הסכמה: optimizelyEndUserId עם תפוגה של מספר שנים המכיל את מזהה המבקר הקבוע, סמני optimizelyOptOut עוקבים אחר מצב ה-opt-out, optimizelyDomainTestCookie לניסויים בין תתי-דומיינים, ועוגיות מרחב שם נוספות כשהמפעיל הפעיל זיהוי בין-דומיין. לכן משיכת ההסכמה חייבת גם להפוג את העוגיות וגם להכניס את ה-SDK למצב opt-out דרך optimizely.push({ type: 'user', attributes: { opt_out: true } }) כדי להפסיק איסוף אירועים נוסף.

מיפוי Optimizely למסגרות הסכמה

Optimizely אינו מיישם באופן טבעי את IAB TCF או את IAB Global Privacy Platform — הוא פלטפורמת ניסוי של צד ראשון, לא ספק adtech — אך הוא חושף API opt-out טבעי, תומך באינטגרציית Consent Mode מתועדת דרך Optimizely Data Platform, ומכבד את ה-CMP של המוציא לאור דרך תכונת OPTIMIZELY_OPT_OUT. הדפוס שעובר ביקורת רגולטור מתייחס לכל יכולת של Optimizely כשער נפרד הקשור לאות CMP ספציפי.

• ניסוי אנונימי יכול לפעול על בסיס עניין לגיטימי עם זיהוי מקומי לסשן, שמתאים להחלטות רינדור שאינן דורשות זיהוי קבוע בין ביקורים ואינן מתפשטות לניתוח מורד. מצב זה מקושר לקטגוריה הנחוצה בהחלט או הפונקציונלית.
• ניסוי קבוע עם מזהה יציב מקושר למטרת הניתוח. במונחי TCF זה ממופה למטרה 8 בשילוב עם מטרה 1; עבור Consent Mode זה ממופה ל-analytics_storage.
• אינטגרציה בין כלים — אירועי חשיפת וריאנט המופצים ל-Google Analytics, Amplitude, או Optimizely Data Platform — יורשת את שער הניתוח מהכלי המקבל ואסור שתופעל אם שער הכלי לא ניתן.
• פרסונליזציה ומיקוד מבוסס-קהל הבנוי על גבי ניסויים מפעיל את שער השיווק מכיוון שהוא חוצה ממדידה ניסיונית למיקוד ברמת משתמש.

דפוס האינטגרציה שעובד

הפריסה הרפרנסית כוללת ארבעה חלקים: CMP החושף אירוע שינוי הסכמה בזמן אמת, bootstrap נדחה המאתחל את ה-SDK של Optimizely עם opt-out מופעל או מצב אנונימי פעיל, מאזין הסכמה הוהפך את ה-SDK מ-opt-out ומתחיל זיהוי קבוע כשנפתח שער הניתוח, ונתיב משיכה המחזיר את ה-SDK למצב opt-out, מפוג את עוגיות optimizely דרך document.cookie, ומפיץ את המשיכה לכל אינטגרציות הניתוח במורד.

יישום וב עם ה-bootstrap הנדחה

בוב הדפוס הנקי ביותר הוא לטעון את קטע הקוד של Optimizely עם window.optimizelyOptOut = true מוגדר לפני אתחול ה-SDK. הירשמו לאירוע שינוי ההסכמה של ה-CMP. כשקטגוריית הניתוח עוברת ל-true, קראו ל-window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) ותנו ל-SDK להאתחל כרגיל. כשהשער נמשך, דחפו את תכונת ה-opt-out חזרה ל-true, הפוגו את עוגיית optimizelyEndUserId, והפיצו את השינוי לכל פלטפורמות הניתוח המשולבות דרך ה-API הסכמה שלהן.

ניסוי צד-שרת דרך Decision Service

Optimizely תומך גם בניסוי צד-שרת דרך Decision Service API. החלטות צד-שרת אינן פטורות מהסכמה — הבסיס המשפטי עוקב אחרי הנתונים — אך הרצת צד-שרת נותנת למוציא לאור שליטה מלאה על אילו מזהים מופצים. הדפוס שעובד הוא להעביר מזהה סשן ארעי ל-Decision Service כששער הניתוח סגור, ולעבור למזהה הקבוע רק כשהשער פתוח. הקצאות הוריאנטים שהוחזרו ע"י ה-Decision Service עדיין ניתן להחיל על הדף המרונדר; מה שמשתנה הוא האם הן קשורות לרשומת מבקר יציבה.

אימות האינטגרציה ושביל הביקורת

שלב האימות הוא מה שרגולטורים בודקים ומה שמוציאים לאור מדלגים עליו לעיתים קרובות בכלי ניסוי. פריסת Optimizely משולבת כראוי חייבת לעבור ארבעה מבחנים ברצף. ראשית, סשן דפדפן נקי עם הבאנר מוצג אך ללא בחירה חייב לייצר אפס בקשות ל-logx.optimizely.com מעבר לשליפת קובץ ה-SDK ואפס עוגיות optimizely ב-document.cookie. שנית, דחיית ניתוח חייבת לשמור על מצב זה — אין מזהה קבוע, אין אירוע החלטה, אין הקצאת וריאנט קשורה לרשומה יציבה. שלישית, קבלת ניתוח חייבת לייצר את עוגיית optimizelyEndUserId המצופה ותעבורת אירועי החלטה, עם הקצאת הוריאנט מיושמת כראוי. רביעית, משיכת ההסכמה חייבת לעצור מיד אירועי החלטה נוספים, להפוג את העוגיות, ולהפיץ את ה-opt-out לכל אינטגרציות הניתוח במורד.

הציפייה לשביל ביקורת לפי הנחיות הבאנר של ה-EDPB מ-2023 ועדיפויות כוח המשימה המחודשות ל-2026 היא שהמוציא לאור יוכל להוכיח, לכל חשיפה ניסיונית ספציפית בפרויקט Optimizely, שהמבקר נתן הסכמה תקפה ברגע החשיפה. הדפוס הסטנדרטי הוא להגדיר את גרסת ההסכמה וה-timestamp כתכונה מותאמת אישית בפרופיל המבקר של Optimizely דרך attribute API של ה-SDK, כך שכל חשיפה בודדת ניתנת למעקב חזרה לרשומת יומן הסכמה ספציפית. פריסה מאורגנת כראוי, בשילוב עם טיפול במצב אנונימי להחלטות רינדור לפני הסכמה ונתיב משיכה המופץ במורד, היא מה שהופך את Optimizely מחבות נסתרת ברמת שכבת הניסוי לחלק ניתן להגנה של המוצר וסטאק הצמיחה של מוציא לאור.