Optimizely Web Experimentation কুকি সম্মতি ইন্টিগ্রেশন গাইড: ২০২৬ সালে GDPR-এর অধীনে A/B পরীক্ষা
Optimizely সম্মতি আলোচনার ক্ষেত্রে একটি অদ্ভুত অবস্থানে দাঁড়িয়ে আছে। পরীক্ষামূলক সরঞ্জামগুলি দেখে একজন যুক্তিসঙ্গত ব্যক্তি ধরে নিতে পারেন এটি কম-ঝুঁকির বিভাগ — পরীক্ষা কোন বোতামের রঙ বেশি ক্লিক আনে সে সম্পর্কে, দর্শক কে তা নিয়ে নয়। GDPR যে কাঠামো নির্ধারণ করেছে এবং EDPB ২০২৩ সাল থেকে সক্রিয়ভাবে শক্তিশালী করছে তার অধীনে বাস্তবতা হল যে পরীক্ষা-নিরীক্ষা ঠিক একই প্রক্রিয়াকরণ বিভাগে যোগ দেয় যেমন বিশ্লেষণ বা বিপণন যখনই প্ল্যাটফর্ম একটি স্থায়ী আইডেন্টিফায়ার লেখে এবং পরীক্ষামূলক ভেরিয়েন্টগুলি তার সাথে যুক্ত করে। Optimizely Web Experimentation SDK ঠিক এটাই করে: একটি স্থায়ী আইডেন্টিফায়ার হ্যাশ করে একজন দর্শককে একটি ভেরিয়েন্টে নিয়োগ দেয়, প্রথম-পক্ষ কুকিতে নিয়োগটি লেখে যাতে দর্শক সেশন জুড়ে একই ভেরিয়েন্ট দেখতে পান, এবং সেই আইডেন্টিফায়ারের সাথে যুক্ত এক্সপোজার ও রূপান্তর ইভেন্ট নির্গত করে। এই পদক্ষেপগুলির প্রতিটি একটি সম্মতি গেট চালু করে। সুখবর হল যে Optimizely পরীক্ষামূলক বিভাগে সবচেয়ে চিন্তাশীল সম্মতি ইন্টিগ্রেশনগুলির একটি নিয়ে আসে, যার মধ্যে রয়েছে একটি ডেডিকেটেড সম্মতি অ্যাট্রিবিউট এবং শুধুমাত্র বেনামী মোডে কাজ করার ক্ষমতা। কাজটি আসলে এটি ব্যবহার করার মধ্যে।
কেন Optimizely Web Experimentation সম্মতি প্রয়োজন
একটি ডিফল্ট Optimizely প্রারম্ভিকীকরণ পৃষ্ঠার প্রথম পেইন্টে বেশ কিছু কাজ করে। এটি স্থায়ী ভিজিটর আইডেন্টিফায়ার সম্বলিত optimizelyEndUserId-এর অধীনে একটি প্রথম-পক্ষ কুকি সেট করে, সক্রিয় পরীক্ষা-নিরীক্ষার বিপরীতে দর্শককে মূল্যায়ন করে, optimizelyOptOut নেমস্পেস মার্কারের অধীনে দ্বিতীয় কুকিতে ভেরিয়েন্ট নিয়োগগুলি লেখে, logx.optimizely.com-এ একটি সিদ্ধান্ত ইভেন্ট ফায়ার করে এবং রেন্ডার করা পৃষ্ঠায় ভেরিয়েন্ট পরিবর্তনগুলি প্রয়োগ করে। যখন অপারেটর একটি বিশ্লেষণ ইন্টিগ্রেশন সংযুক্ত করেছেন — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap, বা Optimizely Data Platform — SDK বিশ্লেষণ স্তরে ভেরিয়েন্ট-এক্সপোজার ইভেন্টও ফায়ার করে, যা তখন ভেরিয়েন্টটিকে দর্শকের বিস্তৃত বিশ্লেষণ প্রোফাইলের সাথে যুক্ত করে।
এই প্রতিটি কার্যক্রম একটি পৃথক সম্মতি গেট চালু করে। ভিজিটর আইডেন্টিফায়ার ধরে রাখা ePrivacy Directive-এর Article 5(3)-এর অধীনে একটি স্টোরেজ-এন্ড-অ্যাক্সেস অপারেশন যা EEA, UK এবং একই মান আমদানি করা যেকোনো এখতিয়ারে পূর্ববর্তী, স্বাধীনভাবে প্রদত্ত, নির্দিষ্ট, অবহিত এবং দ্ব্যর্থহীন সম্মতি প্রয়োজন। সেশন জুড়ে সেই আইডেন্টিফায়ারের সাথে পরীক্ষামূলক ভেরিয়েন্ট নিয়োগগুলি যুক্ত করা GDPR-এর অধীনে ব্যক্তিগত ডেটার প্রক্রিয়াকরণ কারণ আইডেন্টিফায়ার, IP ঠিকানা এবং ভেরিয়েন্ট এক্সপোজারের সমন্বয় একজন ব্যক্তিকে আলাদা করতে এবং পরীক্ষামূলক প্রোগ্রামের সাথে তাদের মিথস্ক্রিয়া চরিত্রায়িত করতে যথেষ্ট। ভেরিয়েন্ট ডেটার ক্রস-টুল প্রচার — উদাহরণস্বরূপ Optimizely Google Analytics-এ ভেরিয়েন্ট নিয়োগ প্রকাশ করা — শৃঙ্খলে বিশ্লেষণ গেট যোগ করে। EDPB-এর ২০২৩ সালের নির্দেশিকা স্পষ্টভাবে বলেছে যে স্থায়ী পরিচয়ে জড়িত পরীক্ষা-নিরীক্ষা বিশ্লেষণের মতো একই সম্মতি নিয়মের অধীন; CNIL এই বিষয়ে সবচেয়ে সোচ্চার নিয়ন্ত্রক ছিল তবে একমাত্র নয়।
Optimizely সম্মতির আগে কী লেখে — এবং কী দমন করতে হবে
স্ট্যান্ডার্ড Optimizely স্নিপেট সরাসরি পৃষ্ঠার
-এ JavaScript SDK ইনস্টল করে এবং লোডে তাৎক্ষণিকভাবে প্রারম্ভিক করে। এটি ডকুমেন্টেড কুইকস্টার্ট এবং সবচেয়ে সাধারণ সম্মতি ব্যর্থতার উৎস: কুকি ব্যানার রেন্ডার হওয়ার আগেই SDK চলে, optimizelyEndUserId কুকি মিলিসেকেন্ডের মধ্যে লেখা হয়, ভেরিয়েন্ট নিয়োগ করা হয়, এবং দর্শক পরে যাই সিদ্ধান্ত নিক না কেন সিদ্ধান্ত ইভেন্ট ফায়ার হয়। এই প্যাটার্নে রায় দেওয়া প্রতিটি ইউরোপীয় নিয়ন্ত্রক একইভাবে রায় দিয়েছে: সম্মতির আগে সেট করা কুকি বেআইনি, সম্মতির আগে ক্যাপচার করা ভেরিয়েন্ট নিয়োগ বেআইনি প্রক্রিয়াকরণ, এবং প্রকাশক দায়িত্ব বহন করে।তাই একটি সম্মত ইন্টিগ্রেশনকে অবশ্যই প্রাসঙ্গিক সম্মতি বিভাগ প্রদান না হওয়া পর্যন্ত Optimizely-কে স্থায়ী আইডেন্টিফায়ার লিখতে এবং সিদ্ধান্ত ইভেন্ট ফায়ার করতে বাধা দিতে হবে। Optimizely এর জন্য দুটি প্যাটার্ন সমর্থন করে। প্রথমটি হল ডেডিকেটেড সম্মতি অ্যাট্রিবিউট — একটি কোয়েরি স্ট্রিং হিসাবে OPTIMIZELY_OPT_OUT=true পাস করুন বা SDK প্রারম্ভিকীকরণের আগে optimizely.opt_out কুকি সেট করুন — যা SDK-কে অপ্ট-আউট মোডে রাখে যেখানে কোনো আইডেন্টিফায়ার লেখা হয় না এবং কোনো ইভেন্ট ফায়ার হয় না। দ্বিতীয়টি হল SDK কনফিগারেশনে সমর্থিত শুধুমাত্র বেনামী মোড, যেখানে SDK সেশনলেস মোডে চলে যা শুধুমাত্র সেশন-লোকাল আইডেন্টিফিকেশনের উপর ভিত্তি করে ভেরিয়েন্ট নিয়োগ করে, পরিদর্শন জুড়ে স্থায়ী পরিচয় ছাড়া। বেনামী মোড পরীক্ষামূলক প্রোগ্রামটিকে সম্মতি প্রদান না হওয়া পর্যন্ত স্থায়ী পরিচয় স্থগিত করে রেন্ডারিং সিদ্ধান্তের জন্য বৈধ-আগ্রহের ভিত্তিতে চালাতে দেয়।
Optimizely যে কুকি এবং স্টোরেজ লেখে
Optimizely Web Experimentation SDK প্রারম্ভিকীকরণে নিম্নলিখিত আইডেন্টিফায়ারগুলি লেখে, যার সবগুলিই অ-অপরিহার্য এবং সম্মতি প্রয়োজন: স্থায়ী ভিজিটর আইডেন্টিফায়ার সম্বলিত বহু-বছরের মেয়াদ শেষের সাথে optimizelyEndUserId, অপ্ট-আউট অবস্থা ট্র্যাক করা optimizelyOptOut মার্কার, ক্রস-সাবডোমেন পরীক্ষার জন্য optimizelyDomainTestCookie, এবং অপারেটর ক্রস-ডোমেন আইডেন্টিফিকেশন সক্ষম করলে অতিরিক্ত নেমস্পেস কুকি। তাই সম্মতি প্রত্যাহার করতে অবশ্যই কুকিগুলির মেয়াদ শেষ করতে হবে এবং আরও ইভেন্ট সংগ্রহ বন্ধ করতে optimizely.push({ type: 'user', attributes: { opt_out: true } })-এর মাধ্যমে SDK-কে অপ্ট-আউট মোডে রাখতে হবে।
Optimizely-কে সম্মতি ফ্রেমওয়ার্কে ম্যাপ করা
Optimizely নেটিভলি IAB TCF বা IAB Global Privacy Platform প্রয়োগ করে না — এটি একটি বিজ্ঞাপন-প্রযুক্তি বিক্রেতা নয়, প্রথম-পক্ষ পরীক্ষামূলক প্ল্যাটফর্ম — তবে এটি একটি নেটিভ অপ্ট-আউট API প্রকাশ করে, Optimizely Data Platform-এর মাধ্যমে একটি ডকুমেন্টেড Consent Mode ইন্টিগ্রেশন সমর্থন করে এবং OPTIMIZELY_OPT_OUT অ্যাট্রিবিউটের মাধ্যমে প্রকাশকের CMP মেনে চলে। নিয়ন্ত্রকের পর্যালোচনায় টিকে থাকা প্যাটার্নটি প্রতিটি Optimizely সক্ষমতাকে একটি নির্দিষ্ট CMP সংকেতের সাথে আবদ্ধ একটি পৃথক গেট হিসাবে বিবেচনা করে।
- বেনামী পরীক্ষা-নিরীক্ষা সেশন-লোকাল আইডেন্টিফিকেশনের সাথে বৈধ-আগ্রহের ভিত্তিতে চালানো যায়, যা পরিদর্শন জুড়ে স্থায়ী পরিচয় প্রয়োজন হয় না এবং ডাউনস্ট্রিম বিশ্লেষণে প্রচারিত হয় না এমন রেন্ডারিং সিদ্ধান্তের জন্য উপযুক্ত। এই মোড কঠোরভাবে প্রয়োজনীয় বা কার্যকরী বিভাগে আবদ্ধ।
- স্থিতিশীল আইডেন্টিফায়ার সহ স্থায়ী পরীক্ষা-নিরীক্ষা বিশ্লেষণ উদ্দেশ্যে আবদ্ধ। TCF পদে এটি উদ্দেশ্য ১-এর সাথে মিলিত উদ্দেশ্য ৮-এ ম্যাপ করে; Consent Mode-এর জন্য এটি analytics_storage-এ ম্যাপ করে।
- ক্রস-টুল ইন্টিগ্রেশন — Google Analytics, Amplitude, বা Optimizely Data Platform-এ প্রচারিত ভেরিয়েন্ট এক্সপোজার ইভেন্টগুলি — প্রাপ্তিকারী সরঞ্জাম থেকে বিশ্লেষণ গেট উত্তরাধিকারসূত্রে পায় এবং সেই সরঞ্জামের গেট প্রদান না করা হলে ফায়ার করা উচিত নয়।
- পরীক্ষা-নিরীক্ষার উপরে নির্মিত ব্যক্তিগতকরণ এবং দর্শক-ভিত্তিক লক্ষ্যমাত্রা বিপণন গেট চালু করে কারণ এটি পরীক্ষামূলক পরিমাপ থেকে ব্যবহারকারী-স্তরের লক্ষ্যমাত্রায় অতিক্রম করে।
যে ইন্টিগ্রেশন প্যাটার্ন কাজ করে
রেফারেন্স ডিপ্লয়মেন্টের চারটি অংশ রয়েছে: একটি CMP যা রিয়েল-টাইম সম্মতি পরিবর্তন ইভেন্ট প্রকাশ করে, একটি ডিফার্ড বুটস্ট্র্যাপ যা অপ্ট-আউট সক্ষম বা বেনামী মোড সক্রিয় থাকা অবস্থায় Optimizely SDK প্রারম্ভিক করে, একটি সম্মতি শ্রোতা যা বিশ্লেষণ গেট খুললে SDK-কে অপ্ট-আউট থেকে বের করে এবং স্থায়ী পরিচয় শুরু করে, এবং একটি প্রত্যাহার পথ যা SDK-কে অপ্ট-আউট মোডে ফিরিয়ে দেয়, document.cookie-এর মাধ্যমে optimizely কুকির মেয়াদ শেষ করে এবং যেকোনো ডাউনস্ট্রিম বিশ্লেষণ ইন্টিগ্রেশনে প্রত্যাহার প্রচার করে।
ডিফার্ড বুটস্ট্র্যাপ সহ ওয়েব ইম্প্লিমেন্টেশন
ওয়েবে সবচেয়ে পরিষ্কার প্যাটার্ন হল SDK প্রারম্ভিকীকরণের আগে window.optimizelyOptOut = true সেট করে Optimizely স্নিপেট লোড করা। 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 ডিপ্লয়মেন্টকে অবশ্যই ক্রমানুসারে চারটি পরীক্ষা পাস করতে হবে। প্রথমত, ব্যানার দেখানো কিন্তু কোনো পছন্দ না করা একটি পরিষ্কার ব্রাউজার সেশনে SDK ফাইল ফেচ ছাড়া logx.optimizely.com-এ শূন্য অনুরোধ এবং document.cookie-এ শূন্য optimizely কুকি তৈরি করতে হবে। দ্বিতীয়ত, বিশ্লেষণ প্রত্যাখ্যান করলে সেই অবস্থা বজায় রাখতে হবে — কোনো স্থায়ী আইডেন্টিফায়ার নেই, কোনো সিদ্ধান্ত ইভেন্ট নেই, স্থিতিশীল রেকর্ডের সাথে কোনো ভেরিয়েন্ট নিয়োগ আবদ্ধ নেই। তৃতীয়ত, বিশ্লেষণ গ্রহণ করলে প্রত্যাশিত optimizelyEndUserId কুকি এবং সিদ্ধান্ত-ইভেন্ট ট্র্যাফিক তৈরি করতে হবে, সঠিকভাবে প্রয়োগ করা ভেরিয়েন্ট নিয়োগ সহ। চতুর্থত, সম্মতি প্রত্যাহার করলে অবিলম্বে আরও সিদ্ধান্ত ইভেন্ট বন্ধ করতে হবে, কুকির মেয়াদ শেষ করতে হবে এবং যেকোনো ডাউনস্ট্রিম বিশ্লেষণ ইন্টিগ্রেশনে অপ্ট-আউট প্রচার করতে হবে।
EDPB-এর ২০২৩ সালের কুকি ব্যানার নির্দেশিকা এবং পুনর্নবীকরণ ২০২৬ টাস্ক ফোর্স অগ্রাধিকারের অধীনে অডিট-ট্রেইলের প্রত্যাশা হল যে প্রকাশক Optimizely প্রকল্পে যেকোনো নির্দিষ্ট পরীক্ষামূলক এক্সপোজারের জন্য প্রমাণ করতে পারবেন যে দর্শক এক্সপোজারের মুহূর্তে বৈধ সম্মতি দিয়েছিলেন। স্ট্যান্ডার্ড প্যাটার্ন হল SDK-এর অ্যাট্রিবিউট API-এর মাধ্যমে Optimizely ভিজিটর প্রোফাইলে সম্মতি সংস্করণ এবং টাইমস্ট্যাম্প একটি কাস্টম অ্যাট্রিবিউট হিসাবে সেট করা যাতে যেকোনো পৃথক এক্সপোজার একটি নির্দিষ্ট সম্মতি লগ এন্ট্রিতে ফিরে ট্র্যাস করা যায়। সঠিকভাবে গেটেড ডিপ্লয়মেন্ট, সম্মতির আগের রেন্ডারিং সিদ্ধান্তের জন্য বেনামী-মোড হ্যান্ডলিং এবং ডাউনস্ট্রিমে প্রচারিত প্রত্যাহার পথের সাথে মিলিত, Optimizely-কে একটি লুকানো পরীক্ষা-স্তরের দায় থেকে প্রকাশকের পণ্য এবং প্রবৃদ্ধি স্ট্যাকের একটি রক্ষাযোগ্য অংশে পরিণত করে।