Γιατί το Optimizely Web Experimentation απαιτεί συγκατάθεση

Μια προεπιλεγμένη αρχικοποίηση Optimizely κάνει αρκετά πράγματα στην πρώτη αποτύπωση της σελίδας. Ορίζει ένα cookie πρώτου μέρους υπό optimizelyEndUserId που περιέχει το μόνιμο αναγνωριστικό επισκέπτη, αξιολογεί τον επισκέπτη έναντι των ενεργών πειραμάτων, γράφει τις αναθέσεις παραλλαγών σε ένα δεύτερο cookie υπό τους δείκτες χώρου ονομάτων 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 εκτελείται πριν αποδοθεί το banner cookies, το cookie optimizelyEndUserId γράφεται εντός χιλιοστών του δευτερολέπτου, γίνεται η ανάθεση παραλλαγής και εκτελείται το συμβάν απόφασης ανεξάρτητα από το τι αποφασίζει αργότερα ο επισκέπτης. Κάθε ευρωπαϊκή ρυθμιστική αρχή που έχει αποφανθεί για αυτό το μοτίβο έχει αποφανθεί με τον ίδιο τρόπο: τα cookies που ορίστηκαν πριν από τη συγκατάθεση είναι παράνομα, η ανάθεση παραλλαγής που καταγράφηκε πριν από τη συγκατάθεση είναι παράνομη επεξεργασία και ο εκδότης φέρει την ευθύνη.

Μια συμμορφωμένη ενσωμάτωση πρέπει επομένως να εμποδίζει το Optimizely από το να γράφει το μόνιμο αναγνωριστικό και να εκτελεί συμβάντα απόφασης μέχρι να χορηγηθεί η σχετική κατηγορία συγκατάθεσης. Το Optimizely υποστηρίζει δύο μοτίβα για αυτό. Το πρώτο είναι το αποκλειστικό χαρακτηριστικό συγκατάθεσης — περάστε OPTIMIZELY_OPT_OUT=true ως συμβολοσειρά ερωτήματος ή ορίστε το cookie optimizely.opt_out πριν από την αρχικοποίηση SDK — που θέτει το SDK σε λειτουργία εξαίρεσης όπου δεν γράφεται αναγνωριστικό και δεν εκτελούνται συμβάντα. Το δεύτερο είναι η λειτουργία μόνο ανώνυμης υποστηριζόμενη στη διαμόρφωση SDK, όπου το SDK εκτελείται σε λειτουργία χωρίς συνεδρία που αναθέτει παραλλαγές βάσει αποκλειστικά τοπικής ταυτοποίησης συνεδρίας χωρίς μόνιμη ταυτοποίηση σε επισκέψεις. Η ανώνυμη λειτουργία επιτρέπει στο πρόγραμμα πειραματισμού να εκτελείται βάσει νόμιμου συμφέροντος για την απόφαση απόδοσης ενώ αναβάλλει τη μόνιμη ταυτοποίηση μέχρι να χορηγηθεί συγκατάθεση.

Τα cookies και αποθηκευτικό χώρο που γράφει το Optimizely

Το Optimizely Web Experimentation SDK γράφει τα ακόλουθα αναγνωριστικά κατά την αρχικοποίηση, όλα από τα οποία είναι μη βασικά και απαιτούν συγκατάθεση: optimizelyEndUserId με πολυετή λήξη που περιέχει το μόνιμο αναγνωριστικό επισκέπτη, δείκτες optimizelyOptOut που παρακολουθούν την κατάσταση εξαίρεσης, optimizelyDomainTestCookie για πειραματισμό διαμέσου υποτομέων και επιπλέον cookies χώρου ονομάτων όταν ο χειριστής έχει ενεργοποιήσει διαυλακική ταυτοποίηση. Η ανάκληση συγκατάθεσης πρέπει επομένως τόσο να λήξει τα cookies όσο και να θέσει το SDK σε λειτουργία εξαίρεσης μέσω optimizely.push({ type: 'user', attributes: { opt_out: true } }) για να σταματήσει η περαιτέρω συλλογή συμβάντων.

Αντιστοίχιση Optimizely σε πλαίσια συγκατάθεσης

Το Optimizely δεν εφαρμόζει εγγενώς IAB TCF ή IAB Global Privacy Platform — είναι πλατφόρμα πειραματισμού πρώτου μέρους, όχι προμηθευτής adtech — αλλά εκθέτει εγγενές 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 — κληρονομεί την αναλυτική πύλη από το εργαλείο λήψης και δεν πρέπει να εκτελεστεί εάν η πύλη αυτού του εργαλείου δεν έχει χορηγηθεί.
• Εξατομίκευση και στόχευση βάσει κοινού που χτίζεται πάνω στον πειραματισμό ενεργοποιεί την πύλη marketing επειδή διαβαίνει από πειραματική μέτρηση σε στόχευση επιπέδου χρήστη.

Το μοτίβο ενσωμάτωσης που λειτουργεί

Η αναφορά ανάπτυξης έχει τέσσερα μέρη: ένα CMP που εκθέτει συμβάν αλλαγής συγκατάθεσης σε πραγματικό χρόνο, μια αναβεβλημένη εκκίνηση που αρχικοποιεί το Optimizely SDK με ενεργοποιημένη εξαίρεση ή ενεργή ανώνυμη λειτουργία, έναν ακροατή συγκατάθεσης που αναστρέφει το SDK εκτός εξαίρεσης και ξεκινά μόνιμη ταυτοποίηση όταν ανοίγει η αναλυτική πύλη, και μια διαδρομή ανάκλησης που επαναφέρει το SDK σε λειτουργία εξαίρεσης, λήγει τα cookies optimizely μέσω document.cookie και διαδίδει την ανάκληση σε τυχόν κατάντη αναλυτικές ενσωματώσεις.

Υλοποίηση στο web με την αναβεβλημένη εκκίνηση

Στον ιστό το καθαρότερο μοτίβο είναι να φορτώσετε το απόσπασμα Optimizely με window.optimizelyOptOut = true ορισμένο πριν από την αρχικοποίηση SDK. Εγγραφείτε στο συμβάν αλλαγής συγκατάθεσης του CMP. Όταν η κατηγορία ανάλυσης μεταβαίνει σε true, καλέστε window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) και αφήστε το SDK να αρχικοποιηθεί κανονικά. Όταν η πύλη ανακληθεί, ωθήστε το χαρακτηριστικό εξαίρεσης πίσω στο true, λήξτε το cookie optimizelyEndUserId και διαδώστε την αλλαγή σε τυχόν ενσωματωμένες αναλυτικές πλατφόρμες μέσω των αντίστοιχων API συγκατάθεσής τους.

Πειραματισμός στην πλευρά διακομιστή μέσω του Decision Service

Το Optimizely υποστηρίζει επίσης πειραματισμό στην πλευρά διακομιστή μέσω του Decision Service API. Οι αποφάσεις πλευράς διακομιστή δεν εξαιρούνται από τη συγκατάθεση — η νομική βάση ακολουθεί τα δεδομένα — αλλά η εκτέλεση στην πλευρά διακομιστή δίνει στον εκδότη πλήρη έλεγχο επί ποιων αναγνωριστικών διαδίδονται. Το μοτίβο που λειτουργεί είναι να περάσετε ένα εφήμερο αναγνωριστικό συνεδρίας στο Decision Service όταν η αναλυτική πύλη είναι κλειστή και να μεταβείτε στο μόνιμο αναγνωριστικό μόνο όταν η πύλη είναι ανοιχτή. Οι αναθέσεις παραλλαγών που επιστρέφει το Decision Service μπορούν ακόμα να εφαρμοστούν στη σελίδα που αποδίδεται· αυτό που αλλάζει είναι εάν είναι δεσμευμένες σε σταθερή εγγραφή επισκέπτη.

Επικύρωση της ενσωμάτωσης και του ελέγχου ιχνηλασιμότητας

Το βήμα επικύρωσης είναι αυτό που ελέγχουν οι ρυθμιστικές αρχές και αυτό που οι εκδότες παραλείπουν συχνότερα στα εργαλεία πειραματισμού. Μια σωστά ενσωματωμένη ανάπτυξη Optimizely πρέπει να περάσει τέσσερις δοκιμές σε σειρά. Πρώτον, μια καθαρή συνεδρία προγράμματος περιήγησης με εμφανιζόμενο banner αλλά χωρίς επιλογή πρέπει να παράγει μηδέν αιτήματα στο logx.optimizely.com πέρα από τη λήψη αρχείου SDK και μηδέν cookies optimizely στο document.cookie. Δεύτερον, η απόρριψη ανάλυσης πρέπει να διατηρεί αυτή την κατάσταση — χωρίς μόνιμο αναγνωριστικό, χωρίς συμβάν απόφασης, χωρίς ανάθεση παραλλαγής δεσμευμένη σε σταθερή εγγραφή. Τρίτον, η αποδοχή ανάλυσης πρέπει να παράγει το αναμενόμενο cookie optimizelyEndUserId και κίνηση συμβάντων απόφασης με σωστά εφαρμοσμένη ανάθεση παραλλαγής. Τέταρτον, η ανάκληση συγκατάθεσης πρέπει να σταματήσει αμέσως περαιτέρω συμβάντα απόφασης, να λήξει τα cookies και να διαδώσει την εξαίρεση σε τυχόν κατάντη αναλυτικές ενσωματώσεις.

Η προσδοκία ελέγχου ιχνηλασιμότητας βάσει των οδηγιών EDPB για banner cookies του 2023 και των ανανεωμένων προτεραιοτήτων ομάδας εργασίας του 2026 είναι ότι ο εκδότης μπορεί να αποδείξει, για οποιαδήποτε συγκεκριμένη πειραματική έκθεση στο έργο Optimizely, ότι ο επισκέπτης είχε δώσει έγκυρη συγκατάθεση κατά τη στιγμή της έκθεσης. Το τυπικό μοτίβο είναι να ορίσετε την έκδοση συγκατάθεσης και τη χρονική σήμανση ως προσαρμοσμένο χαρακτηριστικό στο προφίλ επισκέπτη Optimizely μέσω του attribute API του SDK ώστε κάθε μεμονωμένη έκθεση να είναι ανιχνεύσιμη πίσω σε συγκεκριμένη καταχώρηση αρχείου καταγραφής συγκατάθεσης. Μια σωστά ελεγχόμενη ανάπτυξη, σε συνδυασμό με χειρισμό ανώνυμης λειτουργίας για αποφάσεις απόδοσης πριν από τη συγκατάθεση και μια διαδρομή ανάκλησης που διαδίδεται κατάντη, είναι αυτό που μετατρέπει το Optimizely από μια κρυφή ευθύνη επιπέδου πειραματισμού σε ένα υπερασπίσιμο μέρος του προϊόντος και της στοίβας ανάπτυξης ενός εκδότη.