چرا 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، UK و هر حوزه قضایی که همین استاندارد را وارد کرده دارد. مرتبط کردن اختصاص‌های نوع آزمایشی با آن شناسه در طول جلسات پردازش داده شخصی زیر GDPR است زیرا ترکیب شناسه، آدرس IP و نمایش نوع برای شناسایی یک فرد و توصیف تعامل آن‌ها با برنامه آزمایشی کافی است. انتشار نوع داده بین ابزارها — Optimizely اختصاص نوع را به Google Analytics نمایش می‌دهد، برای مثال — دریچه تحلیلی را به زنجیره اضافه می‌کند. راهنمای EDPB سال ۲۰۲۳ صریحاً گفته است که آزمایشی که شناسایی دائمی را درگیر می‌کند تابع قوانین رضایت یکسانی با تحلیل است؛ 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 این به هدف ۸ همراه با هدف ۱ نگاشته می‌شود؛ برای Consent Mode این به analytics_storage نگاشته می‌شود.
• یکپارچه‌سازی بین ابزارها — رویدادهای نمایش نوع منتشرشده به Google Analytics، Amplitude، یا Optimizely Data Platform — دریچه تحلیلی را از ابزار دریافت‌کننده به ارث می‌برد و نباید شلیک کند اگر دریچه آن ابزار اعطا نشده باشد.
• شخصی‌سازی و هدف‌گیری مبتنی بر مخاطب بر روی آزمایش ساخته‌شده دریچه بازاریابی را فعال می‌کند زیرا از اندازه‌گیری آزمایشی به هدف‌گیری در سطح کاربر عبور می‌کند.

الگوی یکپارچه‌سازی که کار می‌کند

استقرار مرجع چهار بخش دارد: یک CMP که رویداد تغییر رضایت بلادرنگ را در معرض قرار می‌دهد، یک راه‌اندازی معوق که SDK Optimizely را با خروج فعال یا حالت ناشناس فعال راه‌اندازی می‌کند، یک شنونده رضایت که SDK را از خروج خارج می‌کند و شناسایی دائمی را وقتی دریچه تحلیلی باز می‌شود شروع می‌کند، و یک مسیر انصراف که SDK را به حالت خروج برمی‌گرداند، کوکی‌های optimizely را از طریق document.cookie منقضی می‌کند و انصراف را به هر یکپارچه‌سازی تحلیلی پایین‌دستی منتشر می‌کند.

پیاده‌سازی وب با راه‌اندازی معوق

در وب پاک‌ترین الگو بارگذاری قطعه کد Optimizely با window.optimizelyOptOut = true تنظیم‌شده قبل از راه‌اندازی SDK است. در رویداد تغییر رضایت CMP مشترک شوید. وقتی دسته‌بندی تحلیلی به true تغییر کرد، window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) را فراخوانی کنید و بگذارید SDK به‌طور معمول راه‌اندازی شود. وقتی دریچه انصراف می‌دهد، ویژگی خروج را دوباره به true برگردانید، کوکی optimizelyEndUserId را منقضی کنید و تغییر را از طریق API‌های رضایت مربوطه آن‌ها به هر پلتفرم تحلیلی یکپارچه منتشر کنید.

آزمایش سمت سرور از طریق Decision Service

Optimizely همچنین از طریق Decision Service API آزمایش سمت سرور را پشتیبانی می‌کند. تصمیمات سمت سرور از رضایت معاف نیستند — مبنای قانونی داده‌ها را دنبال می‌کند — اما اجرای سمت سرور کنترل کامل بر اینکه کدام شناسه‌ها منتشر می‌شوند را به ناشر می‌دهد. الگویی که کار می‌کند ارسال یک شناسه جلسه موقتی به Decision Service وقتی دریچه تحلیلی بسته است و تغییر به شناسه دائمی فقط وقتی دریچه باز است. اختصاص‌های نوع برگشتی توسط Decision Service هنوز می‌توانند به صفحه رندرشده اعمال شوند؛ آنچه تغییر می‌کند این است که آیا آن‌ها به یک رکورد بازدیدکننده پایدار مرتبط هستند.

اعتبارسنجی یکپارچه‌سازی و مسیر حسابرسی

مرحله اعتبارسنجی چیزی است که تنظیم‌گرها بررسی می‌کنند و ناشران اغلب در ابزارهای آزمایشی از آن می‌گذرند. یک استقرار Optimizely به‌درستی یکپارچه‌شده باید به ترتیب چهار آزمون را بگذراند. اول، یک جلسه مرورگر تمیز با نمایش بنر اما بدون انتخاب باید صفر درخواست به logx.optimizely.com فراتر از واکشی فایل SDK و صفر کوکی optimizely در document.cookie تولید کند. دوم، رد کردن تحلیل باید آن حالت را حفظ کند — هیچ شناسه دائمی، هیچ رویداد تصمیم، هیچ اختصاص نوع مرتبط با یک رکورد پایدار. سوم، پذیرش تحلیل باید کوکی optimizelyEndUserId مورد انتظار و ترافیک رویداد تصمیم را با اختصاص نوع به‌درستی اعمال‌شده تولید کند. چهارم، انصراف از رضایت باید فوراً رویدادهای تصمیم بیشتر را متوقف کند، کوکی‌ها را منقضی کند و خروج را به هر یکپارچه‌سازی تحلیلی پایین‌دستی منتشر کند.

انتظار مسیر حسابرسی زیر دستورالعمل‌های بنر کوکی EDPB سال ۲۰۲۳ و اولویت‌های به‌روزشده گروه کاری ۲۰۲۶ این است که ناشر بتواند برای هر نمایش آزمایشی خاص در پروژه Optimizely ثابت کند که بازدیدکننده در لحظه نمایش رضایت معتبر داده بود. الگوی استاندارد تنظیم نسخه رضایت و تایم‌استمپ به‌عنوان یک ویژگی سفارشی در پروفیل بازدیدکننده Optimizely از طریق attribute API SDK است تا هر نمایش فردی به یک ورودی خاص در گزارش رضایت قابل ردیابی باشد. یک استقرار به‌درستی دروازه‌بندی‌شده، همراه با مدیریت حالت ناشناس برای تصمیمات رندرینگ قبل از رضایت و یک مسیر انصراف که پایین‌دستی منتشر می‌شود، همان چیزی است که Optimizely را از یک مسئولیت پنهان در لایه آزمایشی به یک بخش قابل دفاع از محصول و پشته رشد ناشر تبدیل می‌کند.