Optimizely Web Experimentationが同意を必要とする理由

デフォルトのOptimizely初期化は、ページの最初の描画でいくつかのことを行います。永続的な訪問者識別子を含むoptimizelyEndUserIdの下にファーストパーティCookieを設定し、アクティブな実験に対して訪問者を評価し、optimizelyOptOut名前空間マーカーの下の2番目のCookieにバリアント割り当てを書き込み、logx.optimizely.comに決定イベントを発火させ、レンダリングされたページにバリアントの変更を適用します。オペレーターが分析統合を接続した場合（Google Analytics 4、Adobe Analytics、Amplitude、Mixpanel、Heap、またはOptimizely Data Platform）、SDKは分析レイヤーにバリアント表示イベントも発火させ、それがバリアントを訪問者のより広い分析プロファイルに結び付けます。

これらの活動はそれぞれ別個の同意ゲートを起動します。訪問者識別子の永続化は、EEA、UK、および同じ基準を採用したすべての管轄区域において、事前の、自由に与えられた、特定の、情報に基づいた、明確な同意を必要とするePrivacy指令のArticle 5(3)の下でのストレージおよびアクセス操作です。セッション全体でその識別子に実験的バリアント割り当てを結び付けることは、識別子、IPアドレス、バリアント表示の組み合わせが個人を特定し、実験プログラムとのやり取りを特徴付けるのに十分であるため、GDPRの下での個人データの処理です。バリアントデータのクロスツール伝播（OptimizelyがバリアントをGoogle Analyticsに公開するなど）は、分析ゲートをチェーンに追加します。EDPBの2023年のガイダンスは、永続的な識別を含む実験が分析と同じ同意ルールの対象となると明示しています。CNILはこの点で最も声高な規制当局でしたが、唯一ではありません。

同意前にOptimizelyが書き込むもの——抑制すべきこと

標準のOptimizelyスニペットはJavaScript SDKをページヘッドに直接インストールし、ロード時に即座に初期化します。これは文書化されたクイックスタートであり、最も一般的なコンプライアンス失敗の原因です。SDKはCookieバナーがレンダリングされる前に実行され、optimizelyEndUserId Cookieはミリ秒以内に書き込まれ、バリアント割り当てが行われ、訪問者が後で何を決定するかに関わらず決定イベントが発火します。このパターンについて判断を下したすべてのヨーロッパの規制当局は同じように判断しました。同意前に設定されたCookieは違法であり、同意前にキャプチャされたバリアント割り当ては違法な処理であり、パブリッシャーが責任を負います。

準拠した統合は、関連する同意カテゴリが付与されるまで、OptimizelyによるCookieへの永続的識別子の書き込みと決定イベントの発火を防がなければなりません。Optimizelyはこのために2つのパターンをサポートしています。1つ目は専用の同意属性です。OPTIMIZELY_OPT_OUT=trueをクエリ文字列として渡すか、SDK初期化前にoptimizely.opt_out Cookieを設定することで、SDKをオプトアウトモードに設定します。このモードでは識別子が書き込まれず、イベントも発火しません。2つ目はSDK設定でサポートされる匿名のみモードです。SDKはセッションなしモードで動作し、訪問全体にわたる永続的な識別なしに、セッションローカルな識別のみに基づいてバリアントを割り当てます。匿名モードでは、同意が付与されるまで永続的識別を延期しながら、レンダリング決定のための正当な利益の基礎の下で実験プログラムを実行できます。

Optimizelyが書き込むCookieとストレージ

Optimizely Web Experimentation SDKは初期化時に以下の識別子を書き込みます。これらはすべて非必須であり、同意が必要です。複数年の有効期限を持つ永続的な訪問者識別子を含むoptimizelyEndUserId、オプトアウト状態を追跡するoptimizelyOptOutマーカー、クロスサブドメイン実験のためのoptimizelyDomainTestCookie、オペレーターがクロスドメイン識別を有効にした場合の追加の名前空間Cookie。したがって、同意の撤回はCookieの期限切れと、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の用語ではこれは目的1と組み合わせた目的8にマッピングされます。Consent Modeではanalytics_storageにマッピングされます。
• クロスツール統合（Google Analytics、Amplitude、またはOptimizely Data Platformに伝播されるバリアント表示イベント）は受信ツールから分析ゲートを継承し、そのツールのゲートが付与されていない場合は発火してはなりません。
• 実験の上に構築されたパーソナライゼーションとオーディエンスベースのターゲティングは、実験的測定からユーザーレベルのターゲティングへと移行するため、マーケティングゲートを起動します。

機能する統合パターン

参照デプロイメントには4つの部分があります。リアルタイムの同意変更イベントを公開するCMP、オプトアウトが有効または匿名モードがアクティブな状態でOptimizely SDKを初期化する遅延ブートストラップ、分析ゲートが開いたときにSDKをオプトアウトから切り替えて永続的識別を開始する同意リスナー、SDKをオプトアウトモードに戻し、document.cookieを通じてoptimizely Cookieの期限を切り、ダウンストリームの分析統合に撤回を伝播するウィズドロウパス。

遅延ブートストラップを使用したWeb実装

Webでは、SDK初期化前にwindow.optimizelyOptOut = trueを設定してOptimizelyスニペットをロードするのが最もクリーンなパターンです。CMPの同意変更イベントをサブスクライブしてください。分析カテゴリがtrueに遷移したら、window.optimizely.push({ type: 'user', attributes: { opt_out: false } })を呼び出し、SDKを通常通り初期化させます。ゲートが撤回されたら、オプトアウト属性をtrueに戻し、optimizelyEndUserId Cookieの期限を切り、それぞれの同意APIを通じて統合された分析プラットフォームに変更を伝播してください。

Decision Serviceを通じたサーバーサイド実験

OptimizelyはDecision Service APIを通じたサーバーサイド実験もサポートしています。サーバーサイドの決定は同意から免除されません。法的根拠はデータに従います。ただし、サーバーサイドの実行により、パブリッシャーはどの識別子が伝播されるかについて完全な制御を持つことができます。機能するパターンは、分析ゲートが閉じているときにDecision Serviceにエフェメラルなセッション識別子を渡し、ゲートが開いているときにのみ永続的識別子に切り替えることです。Decision Serviceが返すバリアント割り当ては引き続きレンダリングされたページに適用できます。変わるのは、それらが安定した訪問者レコードに結び付けられているかどうかです。

統合と監査証跡の検証

検証ステップは規制当局が確認するものであり、パブリッシャーが実験ツールで最もよくスキップするものです。正しく統合されたOptimizelyデプロイメントは4つのテストを順番にパスしなければなりません。第1に、バナーは表示されているが選択がされていない清潔なブラウザセッションは、SDKファイルフェッチを超えたlogx.optimizely.comへのリクエストをゼロ、document.cookieのoptimizely CookieもゼロにするDIO必要があります。第2に、分析を拒否するとその状態を維持する必要があります。永続的識別子なし、決定イベントなし、安定したレコードに結び付けられたバリアント割り当てなし。第3に、分析を受け入れると期待されるoptimizelyEndUserId Cookieと決定イベントトラフィックが生成され、バリアント割り当てが正しく適用されるはずです。第4に、同意の撤回はそれ以上の決定イベントを直ちに停止させ、Cookieの期限を切り、ダウンストリームの分析統合にオプトアウトを伝播する必要があります。

EDPBの2023年のCookieバナーガイドラインと2026年の更新されたタスクフォースの優先事項の下での監査証跡の期待は、パブリッシャーがOptimizelyプロジェクトの特定の実験的表示について、訪問者が表示時点で有効な同意を提供していたことを証明できるということです。標準的なパターンは、SDKのattribute APIを通じてOptimizely訪問者プロファイルの同意バージョンとタイムスタンプをカスタム属性として設定することで、個々の表示が特定の同意ログエントリまで追跡可能になります。適切にゲーティングされたデプロイメントに、同意前のレンダリング決定のための匿名モード処理とダウンストリームに伝播するウィズドロウパスを組み合わせることで、Optimizelyは隠れた実験層の負債からパブリッシャーの製品と成長スタックの守れる部分へと変わります。