لماذا يتطلب 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 مباشرةً في رأس الصفحة وتُهيّئ فوراً عند التحميل. هذا هو البدء السريع الموثّق ومصدر أكثر إخفاقات الامتثال شيوعاً: يعمل SDK قبل أن يُصيَّر لافتة ملفات تعريف الارتباط، ويُكتب ملف تعريف الارتباط optimizelyEndUserId في غضون ميلي ثانية، ويُحدَّد إسناد المتغير، ويُطلَق حدث القرار بصرف النظر عمّا يقرره الزائر لاحقاً. كل جهة تنظيمية أوروبية بتّت في هذا النمط حكمت بالطريقة نفسها: ملفات تعريف الارتباط المضبوطة قبل الموافقة غير مشروعة، وإسناد المتغير المُلتقط قبل الموافقة معالجة غير مشروعة، والناشر يتحمل المسؤولية.

يجب إذن أن يمنع التكامل المتوافق Optimizely من كتابة المعرّف الدائم وإطلاق أحداث القرار حتى تُمنح فئة الموافقة ذات الصلة. يدعم Optimizely نمطين لذلك. الأول هو سمة الموافقة المخصصة — تمرير OPTIMIZELY_OPT_OUT=true كسلسلة استعلام أو ضبط ملف تعريف الارتباط optimizely.opt_out قبل تهيئة SDK — مما يضع SDK في وضع إلغاء الاشتراك حيث لا يُكتب معرّف ولا تُطلق أحداث. الثاني هو وضع مجهول الهوية فقط المدعوم في تكوين SDK، حيث يعمل SDK في وضع بلا جلسة يُسند المتغيرات استناداً إلى التعريف المحلي للجلسة فقط، دون تعريف دائم عبر الزيارات. يسمح وضع مجهول الهوية لبرنامج التجريب بالعمل على أساس المصلحة المشروعة لقرار التصيير مع تأجيل التعريف الدائم حتى تُمنح الموافقة.

ملفات تعريف الارتباط والتخزين التي يكتبها Optimizely

يكتب Optimizely Web Experimentation SDK المعرّفات التالية عند التهيئة، وكلها غير أساسية وتستلزم الموافقة: optimizelyEndUserId بانتهاء صلاحية متعدد السنوات يحتوي على معرّف الزائر الدائم، وعلامات optimizelyOptOut تتبع حالة إلغاء الاشتراك، وoptimizelyDomainTestCookie للتجريب عبر النطاقات الفرعية، وملفات تعريف ارتباط مساحة اسم إضافية عندما يكون المشغّل قد فعّل التعريف عبر النطاقات. لذا يجب أن يُنهي سحب الموافقة كلاً من انتهاء صلاحية ملفات تعريف الارتباط ووضع SDK في وضع إلغاء الاشتراك عبر optimizely.push({ type: 'user', attributes: { opt_out: true } }) لوقف جمع الأحداث الإضافية.

تعيين Optimizely على أُطر الموافقة

لا يُطبّق Optimizely IAB TCF أو IAB Global Privacy Platform بشكل أصيل — إنه منصة تجريب من الطرف الأول، لا بائع تقنية إعلانية — لكنه يكشف عن API أصيل لإلغاء الاشتراك، ويدعم تكامل 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 يكشف عن حدث تغيير الموافقة في الوقت الفعلي، وبدء مؤجّل يُهيّئ Optimizely SDK مع تمكين إلغاء الاشتراك أو تنشيط وضع مجهول الهوية، ومستمع موافقة يقلب SDK من وضع إلغاء الاشتراك ويبدأ التعريف الدائم عند فتح بوابة التحليلات، ومسار سحب يُعيد SDK إلى وضع إلغاء الاشتراك ويُنهي ملفات تعريف الارتباط optimizely عبر document.cookie وينشر السحب إلى أي تكاملات تحليلية منبثقة.

التطبيق على الويب مع البدء المؤجّل

على الويب، النمط الأنظف هو تحميل مقتطفة Optimizely مع ضبط window.optimizelyOptOut = true قبل تهيئة SDK. اشترك في حدث تغيير الموافقة الخاص بـ CMP. عندما تتحوّل فئة التحليلات إلى true، استدعِ window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) واترك SDK يُهيّئ بشكل طبيعي. عند سحب البوابة، ادفع سمة إلغاء الاشتراك إلى true مجدداً، وأنهِ صلاحية ملف تعريف الارتباط optimizelyEndUserId، وانشر التغيير إلى أي منصات تحليلية متكاملة عبر APIs الموافقة الخاصة بها.

التجريب من جانب الخادم عبر Decision Service

يدعم Optimizely أيضاً التجريب من جانب الخادم عبر Decision Service API. قرارات الخادم ليست مُستثناة من الموافقة — الأساس القانوني يتبع البيانات — لكن التنفيذ من جانب الخادم يمنح الناشر تحكماً كاملاً في المعرّفات التي تُنشر. النمط الناجح هو تمرير معرّف جلسة مؤقت إلى Decision Service عند إغلاق بوابة التحليلات، والتحوّل إلى المعرّف الدائم فقط عند فتح البوابة. يمكن لا يزال تطبيق إسنادات المتغير التي يُعيدها Decision Service على الصفحة المُصيَّرة؛ ما يتغير هو ما إذا كانت مرتبطة بسجل زائر مستقر.

التحقق من التكامل وتتبع المراجعة

خطوة التحقق هي ما تتحقق منه الجهات التنظيمية وما يتخطاه الناشرون في أغلب الأحيان في أدوات التجريب. يجب أن يجتاز نشر Optimizely المتكامل بشكل صحيح أربعة اختبارات بالتسلسل. أولاً، يجب أن تُنتج جلسة متصفح نظيفة مع عرض اللافتة لكن دون اختيار صفر طلبات إلى logx.optimizely.com بما يتجاوز جلب ملف SDK وصفر ملفات تعريف ارتباط optimizely في document.cookie. ثانياً، رفض التحليلات يجب أن يحافظ على تلك الحالة — لا معرّف دائم، لا حدث قرار، لا إسناد متغير مرتبط بسجل مستقر. ثالثاً، قبول التحليلات يجب أن يُنتج ملف تعريف الارتباط المتوقع optimizelyEndUserId وحركة أحداث القرار مع تطبيق إسناد المتغير بشكل صحيح. رابعاً، سحب الموافقة يجب أن يوقف فوراً أحداث القرار الإضافية، ويُنهي صلاحية ملفات تعريف الارتباط، وينشر إلغاء الاشتراك إلى أي تكاملات تحليلية منبثقة.

توقّع تتبع المراجعة بموجب إرشادات EDPB لعام 2023 بشأن لافتات ملفات تعريف الارتباط وأولويات فريق العمل المتجدد لعام 2026 هو أن يستطيع الناشر إثبات، لأي ظهور تجريبي محدد في مشروع Optimizely، أن الزائر كان قد أعطى موافقة صالحة في لحظة الظهور. النمط القياسي هو ضبط نسخة الموافقة والطابع الزمني كسمة مخصصة على ملف الزائر في Optimizely عبر attribute API الخاص بـ SDK حتى يكون أي ظهور فردي قابلاً للتتبع إلى إدخال سجل موافقة محدد. النشر المحاط بالبوابات بشكل صحيح، مقترناً بمعالجة وضع مجهول الهوية لقرارات التصيير قبل الموافقة ومسار سحب ينتشر في اتجاه المنبع، هو ما يحوّل Optimizely من مسؤولية خفية على مستوى طبقة التجريب إلى جزء قابل للدفاع عنه من منتج الناشر ومجموعة النمو.