メインコンテンツへスキップ
Web アプリで Kameleoon を使用する際の同意管理ポリシーの設定方法については、ユーザーガイドを参照してください。
Kameleoon は同意管理プラットフォームとのネイティブな組み込みインテグレーションを提供しています。

同意ポリシー

特定の訪問者について、Kameleoon の利用に関する法的同意は、付与済み拒否済み、または 不明(同意が定義されていない特殊な状態で、訪問者がまだ付与も拒否もしていない状態)のいずれかとして扱われます。最初に、Kameleoon が法的同意をどのように扱うかを選択する必要があります。
  • 同意不要:このポリシーでは、本ウェブサイトおよびモジュールに対して明示的な同意を必要としません。Kameleoon は同意が自動的に付与されていると見なし、即座にフル機能モードで動作を開始します。
  • 同意必須:このポリシーでは、訪問者から明示的に同意を取得する必要があります。同意が付与されるまで、法的同意は「不明」と見なされ、Kameleoon は通常どおりには動作しません。
法的同意が取得されたことを Kameleoon に通知するには、カスタム JS コードの実装が必要な Kameleoon Activation API メソッドを使用するか、フィーチャーフラグを実行している場合はいずれかの SDK を使用する必要があります。このトピックの詳細については、ユーザーガイドを参照してください。
あらゆるユースケースをカバーするため、同意が不明と見なされる場合やユーザーが拒否した場合の Kameleoon Web Experimentation の挙動はさらにカスタマイズできます。利用可能なオプションの詳細については、同意が不明な場合の挙動に関する記事をご覧ください。

訪問者の現在の同意状態の読み取り

このセクションは Kameleoon Web Experimentation ソリューションにのみ適用されます。
訪問者の現在の法的同意状態を取得(読み取り)するには、Kameleoon.API.Visitor オブジェクトを使用します。
  • Kameleoon.API.Visitor.experimentLegalConsent: 状態が不明(同意が必要だがまだ付与も拒否もされていない)場合は truefalse、または null を返します。
  • Kameleoon.API.Visitor.personalizationLegalConsent: 状態が不明(同意が必要だがまだ付与も拒否もされていない)場合は truefalse、または null を返します。
Kameleoon.API.Core.enableLegalConsent() および Kameleoon.API.Core.disableLegalConsent() メソッドは訪問者の法的同意ステータスを変更(書き込み)するために使用されますが、現在の状態の取得(読み取り)は Kameleoon.API.Visitor を介して行われます。
同意不要ポリシーを選択している場合、法的同意は決して不明な状態にはなりません。Kameleoon.API.Visitor.experimentLegalConsent または Kameleoon.API.Visitor.personalizationLegalConsent は既定で常に true を返し、Kameleoon.API.Core.disableLegalConsent() メソッドが呼び出された場合にのみ false に設定されます。

Kameleoon Web Experimentation エンジンの動作モード

このセクションは Kameleoon Web Experimentation ソリューションにのみ適用されます。
Kameleoon エンジンは動作モードに応じて異なる動作をします。動作モードを決定するために、Kameleoon は Kameleoon.API.Visitor.experimentLegalConsent および Kameleoon.API.Visitor.personalizationLegalConsent の現在の値を考慮します。値が null(不明な状態)または false の場合、Kameleoon はプロジェクト設定同意が不明な場合の挙動 または オプトアウト時の挙動 に対応する設定値を考慮します。 以下のセクションでは、エンジンで使用可能なすべてのモードについて説明します。

アクティブモード

これは通常の動作モードです。Kameleoon は必要に応じてトラッキングサーバーにデータを送信し、デバイスにデータを書き込みます。訪問者は Kameleoon の利用に同意していると見なされます。 このモードは、Kameleoon.API.Visitor.experimentLegalConsent または Kameleoon.API.Visitor.personalizationLegalConsenttrue の場合に動作します。

無効モード

このモードでは、Kameleoon は一切何も行いません。データはリモートサーバーに送信されず、ローカルデバイスにも書き込まれません。実験やパーソナライゼーションは決して表示されません。要するに、特定の訪問者にとって Kameleoon が存在しないかのような状態となります。 このモードは以下の場合に動作します。
  • Kameleoon.API.Visitor.experimentLegalConsent または Kameleoon.API.Visitor.personalizationLegalConsentnull で、同意が不明な場合に「Kameleoon を完全にブロックする」オプションを選択した場合。
  • Kameleoon.API.Visitor.experimentLegalConsent または Kameleoon.API.Visitor.personalizationLegalConsentfalse で、お客様がオプトアウト挙動で「Kameleoon を完全にブロックする」を選択した場合。

遅延モード

このモードでは、Kameleoon はトラッキングサーバーへのデータ送信もデバイスへの書き込みも行いません。ただし、訪問者が関連するセグメントをトリガーした場合、実験(またはパーソナライゼーション)は通常どおり表示されます。 加えて、書き込むべきデータやリモートサーバーに送信すべきデータはすべてメモリに保持されます。後に Kameleoon がアクティブモードに切り替わった場合(通常はある時点で同意が付与されたため)、これまで(本ページのコンテキストで)収集されたすべてのデータが一括して書き込み・送信されます。これが「遅延」と呼ばれる所以です。最終的に完全な同意が取得された場合、Kameleoon はほぼアクティブモードと同じように動作した結果となります。 このモードは、Kameleoon.API.Visitor.experimentLegalConsent / Kameleoon.API.Visitor.personalizationLegalConsentnull で、同意が不明な場合に「Kameleoon をブロックしない」オプションを選択した場合に動作します。

制限モード

このモードでは、Kameleoon はトラッキングサーバーへのデータ送信もデバイスへの書き込みも行いません。ただし、Kameleoon で「テクニカル」タグが付けられた実験(またはパーソナライゼーション)は引き続き表示されます。それ以外の実験 / パーソナライゼーションは表示されません。 これは非常に有用なモードであり、訪問者が同意の付与を望まない場合に Kameleoon のほとんどの動作を無効化できる一方で、その訪問者に対して重要な実験やパーソナライゼーションを実行することを可能にします。Kameleoon は、本番環境にバグ修正や小さな改善を素早く展開する手段としてよく利用されます。このような特定の文脈では、GDPR などのデータプライバシー規制は明示的に適用されず、そのようなユースケースでは同意なしで Kameleoon を使用できます。 制限モードは遅延モードと同等ですが、より制限が強くなります。最終的な法的同意の選択(拒否)の結果として選択され得るため、この場合データが書き込まれたり送信されたりすることはまずないと想定されます(一方、遅延モードは通常「遷移的」なモードに過ぎません)。 このモードは以下の場合に動作します。
  • Kameleoon.API.Visitor.experimentLegalConsent または Kameleoon.API.Visitor.personalizationLegalConsentnull で、同意が不明な場合に「Kameleoon を部分的にブロックする」オプションを選択した場合。
  • Kameleoon.API.Visitor.experimentLegalConsent または Kameleoon.API.Visitor.personalizationLegalConsentfalse で、オプトアウト挙動に「Kameleoon を部分的にブロックする」オプションを選択した場合。
Kameleoon の AB 実験とパーソナライゼーションで異なる動作モードが適用される可能性は十分にあります。その場合、すべてが期待どおりに動作します。たとえば、実験は表示されデータがトラッキングされる一方で、パーソナライゼーションでは何も行われない、といった具合です。

高度な考慮事項

AB テストの文脈で明示的な同意ポリシーを実装することを選択すると、通常複雑な問題が発生し、理想的な解決策は存在しません。ここでは主に 2 つの問題について説明します。 考慮すべき第一の点は、同意が不明な場合に厳格な動作(無効モード)を選択した場合、まったく新しい訪問者の最初のページビューの文脈で実験 / パーソナライゼーションが「遅れて」トリガーされるということです。この設定では、法的同意が取得された後(通常は数秒後)にしか表示できないためです。残念ながら、この挙動は基盤となる実験やパーソナライゼーションによっては深刻な UX 上の問題を引き起こす可能性があり、考慮する必要があります。 遅延モードはこの問題を軽減できます。表示は即時に行われ、書き込みのみが遅延されるためです。しかし、訪問者が法的同意ステータスが不明なまま複数ページにわたって「滞在」する場合に第二の問題が生じます。Kameleoon はデバイスに一切データを書き込まず、Kameleoon の visitorCode 識別子すら書き込まないため、最終的な同意が確定するまでページごとにランダムに(再)生成され続けます。これは、実験についてバリエーション割り当てが新しいページビューごとに発生し、それらの割り当てに整合性が保証されないことを意味します。したがって、この状況が発生しないように対策を講じることが重要です。複数のオプションが考えられます(ブロッキング型の同意バナー、X 秒後に自動的に同意を拒否するなど)が、訪問者が法的同意不明の状態に永遠に留まることは決してあってはなりません。同意は付与されるか拒否されるかのいずれかです。
同じ技術的理由(バリエーションの永続的な再割り当て)により、オプトアウト挙動として 制限モード を選択する場合、特定のバリエーションへの 100% のトラフィック配分を持つパーソナライゼーションまたは実験のみに「テクニカル」タグを付けることが期待されます。そうしないと、拒否したユーザーのナビゲーション体験を大きく損なう可能性があります。同じセッション内で複数の異なるバリエーションにさらされる可能性があるためです。