რატომ მოითხოვს Optimizely Web Experimentation თანხმობას

Optimizely-ის ნაგულისხმევი ინიციალიზაცია გვერდის პირველ ხატვაზე რამდენიმე რამეს აკეთებს. ის ადგენს პირველი მხარის ქუქი-ფაილს optimizelyEndUserId-ის ქვეშ, რომელიც შეიცავს მუდმივ ვიზიტორის იდენტიფიკატორს, ვიზიტორს აფასებს აქტიური ექსპერიმენტების მიმართ, ვარიანტის მინიჭებებს წერს მეორე ქუქი-ფაილში optimizelyOptOut სახელების სივრცის მარკერების ქვეშ, ასხავს გადაწყვეტილების მოვლენას logx.optimizely.com-ზე და ვარიანტის ცვლილებებს გამოყენებს გარენდერულ გვერდზე. როდესაც ოპერატორმა დააკავშირა ანალიტიკის ინტეგრაცია — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap, ან Optimizely Data Platform — SDK ასევე ასხამს ვარიანტის ექსპოზიციის მოვლენებს ანალიტიკის ფენაში, რომელიც შემდეგ ვარიანტს ვიზიტორის უფრო ფართო ანალიტიკურ პროფილს უკავშირებს.

ამ საქმიანობებიდან თითოეული ააქტიურებს ცალ-ცალკე თანხმობის კარს. ვიზიტორის იდენტიფიკატორის შენახვა ePrivacy დირექტივის Article 5(3)-ის ფარგლებში შენახვა-და-წვდომის ოპერაციაა, რომელიც მოითხოვს წინასწარ, თავისუფლად გაცემულ, სპეციფიკურ, ინფორმირებულ და ცალსახა თანხმობას 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-ს opt-out რეჟიმში დებს, სადაც იდენტიფიკატორი არ იწერება და მოვლენები არ ასხდება. მეორე SDK კონფიგურაციაში მხარდაჭერილი მხოლოდ ანონიმური რეჟიმია, სადაც SDK სესიის გარეშე რეჟიმში მუშაობს, ვარიანტებს მხოლოდ სესიის ლოკალური იდენტიფიკაციის საფუძველზე ანიჭებს, ვიზიტებს შორის მუდმივი იდენტიფიკაციის გარეშე. ანონიმური რეჟიმი ექსპერიმენტის პროგრამას რენდერის გადაწყვეტილებისათვის კანონიერი ინტერესის საფუძველზე მუშაობის საშუალებას იძლევა, მუდმივი იდენტიფიკაციის გადავადებით თანხმობის მინიჭებამდე.

ქუქი-ფაილები და შენახვა, რომელსაც Optimizely წერს

Optimizely Web Experimentation SDK ინიციალიზაციისას შემდეგ იდენტიფიკატორებს წერს, ყველა მათგანი არაარსებითია და თანხმობა სჭირდება: 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 გამყიდველი, ეს არის პირველი მხარის ექსპერიმენტის პლატფორმა — მაგრამ ის ბუნებრივ opt-out API-ს ავლენს, Optimizely Data Platform-ის მეშვეობით დოკუმენტირებული Consent Mode ინტეგრაციას უჭერს მხარს და OPTIMIZELY_OPT_OUT ატრიბუტის მეშვეობით გამომცემლის CMP-ს პატივს სცემს. ნიმუში, რომელიც მარეგულირებლის მიმოხილვაში გადარჩება, Optimizely-ის ყოველ შესაძლებლობას ცალ-ცალკე კარებად განიხილავს, რომელიც კონკრეტულ CMP სიგნალს უკავშირდება.

• ანონიმური ექსპერიმენტი შეიძლება სესიის ლოკალური იდენტიფიკაციით კანონიერი ინტერესის საფუძველზე გაეშვას, რაც სათანადოა რენდერის გადაწყვეტილებებისთვის, რომლებიც ვიზიტებს შორის მუდმივ იდენტიფიკაციას არ საჭიროებენ და ქვედა ანალიტიკაზე არ ვრცელდება. ეს რეჟიმი მკაცრ-საჭიროებებთან ან ფუნქციურ კატეგორიასთანაა დაკავშირებული.
• სტაბილური იდენტიფიკატორით მუდმივი ექსპერიმენტი ანალიტიკის მიზანს უკავშირდება. TCF ტერმინოლოგიით ეს 1-ელ მიზანთან კომბინირებულ მე-8 მიზანს ემთხვევა; Consent Mode-ისთვის ეს analytics_storage-ს ემთხვევა.
• ჯვარედინი ინტეგრაცია — ვარიანტის ექსპოზიციის მოვლენები, რომლებიც Google Analytics-ს, Amplitude-ს ან Optimizely Data Platform-ს ეგზავნება — მიმღები ინსტრუმენტისგან ანალიტიკის კარს მემკვიდრეობით იღებს და არ უნდა ასხდეს, თუ ამ ინსტრუმენტის კარი მინიჭებული არ არის.
• ექსპერიმენტის თავზე აგებული პერსონალიზაცია და აუდიტორიაზე დაფუძნებული სამიზნე მარკეტინგის კარს ააქტიურებს, რადგან ის ექსპერიმენტული გაზომვიდან მომხმარებლის დონის სამიზნემდე გადადის.

სამუშაო ინტეგრაციის ნიმუში

საცნობარო განლაგებას ოთხი ნაწილი აქვს: CMP, რომელიც თანხმობის ცვლილების მოვლენას რეალურ დროში ავლენს, გადადებული bootstrap, რომელიც Optimizely SDK-ს opt-out ჩართულით ან ანონიმური რეჟიმის აქტიურობით ინიციალიზდება, თანხმობის მსმენელი, რომელიც SDK-ს opt-out-ის გარეთ გადამისამართებს და ანალიტიკის კარის გახსნისას მუდმივ იდენტიფიკაციას იწყებს, და გამოწვევის გზა, რომელიც SDK-ს opt-out რეჟიმში დააბრუნებს, document.cookie-ის მეშვეობით optimizely ქუქი-ფაილების ვადას გაასვლებს და გამოწვევას ქვემო ანალიტიკის ნებისმიერ ინტეგრაციაში გაავრცელებს.

ვებ-იმპლემენტაცია გადადებული bootstrap-ით

ვებ-ში ყველაზე სუფთა ნიმუში SDK ინიციალიზაციამდე window.optimizelyOptOut = true-ის დაყენებით Optimizely სნიპეტის ჩატვირთვაა. გამოიწერეთ 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-ს განლაგება ოთხ ტესტს რიგრიგობით უნდა გაიარდეს. პირველ რიგში, ბანერის ჩვენებით, მაგრამ არჩევანის გარეშე სუფთა ბრაუზერის სესიამ SDK ფაილის ჩამოტვირთვის გარდა logx.optimizely.com-ზე ნული მოთხოვნა და document.cookie-ში optimizely ქუქი-ფაილების ნული შედეგი უნდა გამოიღოს. მეორე, ანალიტიკის უარყოფამ ეს მდგომარეობა უნდა შეინარჩუნოს — მუდმივი იდენტიფიკატორი არ არსებობს, გადაწყვეტილების მოვლენა არ არსებობს, სტაბილურ ჩანაწერს დაკავშირებული ვარიანტის მინიჭება არ არსებობს. მესამე, ანალიტიკის მიღებამ მოსალოდნელი optimizelyEndUserId ქუქი-ფაილი და გადაწყვეტილების მოვლენის ტრაფიკი უნდა წარმოშვას, სწორად გამოყენებული ვარიანტის მინიჭებით. მეოთხე, თანხმობის გამოწვევამ დაუყოვნებლივ უნდა შეაჩეროს შემდგომი გადაწყვეტილების მოვლენები, ქუქი-ფაილების ვადა გაასვლოს და opt-out ნებისმიერ ქვემო ანალიტიკის ინტეგრაციაში გაავრცელოს.

სამრევლო ბილიკის მოლოდინი EDPB-ის 2023 წლის ქუქი-ბანერის სახელმძღვანელოების და 2026 წლის განახლებული სამუშაო ჯგუფის პრიორიტეტების ფარგლებში ის არის, რომ გამომცემელმა Optimizely-ის პროექტში ნებისმიერი კონკრეტული ექსპერიმენტული ექსპოზიციისთვის დაამტკიცოს, რომ ვიზიტორმა ექსპოზიციის მომენტში მართებული თანხმობა მისცა. სტანდარტული ნიმუში SDK-ის attribute API-ის მეშვეობით Optimizely ვიზიტორის პროფილზე თანხმობის ვერსიისა და დროის შტამპის მორგებული ატრიბუტად დაყენებაა, რათა ნებისმიერი ინდივიდუალური ექსპოზიცია კონკრეტულ თანხმობის ლოგის ჩანაწერამდე გამოძიებული იყოს. სწორად გამოყოფილი განლაგება, თანხმობამდე რენდერის გადაწყვეტილებებისთვის ანონიმური რეჟიმის დამუშავებასთან და ქვემო მიმართულებით გამავალ გამოწვევის გზასთან შეწყვილებული, ის არის, რაც Optimizely-ს დამალული ექსპერიმენტის ფენის ვალდებულებიდან გამომცემლის პროდუქტისა და ზრდის სტეკის დასაცავ ნაწილად გარდაქმნის.