クロスデバイス実験

顧客のジャーニーが単一のデバイスに限定されることはほとんどありません。スマートフォンからタブレット、デスクトップコンピューターまで、ユーザーは定期的にデバイスを切り替えています。 クロスデバイス実験はこの課題に対処します。デバイス間のギャップを埋めることは微妙な課題であり、完璧なソリューションは存在しませんが、信頼できるユーザーIDや慎重なデータ管理といった適切なツールにより、すべてのタッチポイントにわたる訪問者の体験に関するインサイトを得ることができます。

​

Kameleoonのクロスデバイス実験でできること​

• バリエーションの一貫性を確保: ログイン済みユーザーは、使用するデバイスにかかわらず、実験で常に同じバリエーションを表示します。
• 統合されたターゲティングを可能に: デバイスに関係なく、単一のユーザーからのすべての訪問とアクションを考慮します。
• 正確なレポーティングを提供: デバイスをまたいだユニークユーザーを正確にカウントし、行動をより深く理解します。

​

重要なポイントと実践的な洞察​

• クロスデバイストラッキングは、ユーザーの識別に大きく依存します。ユーザーがデバイスをまたいで匿名のままである場合、データのマージは不可能です。どのシステムもこの制限を回避することはできません。
• デバイス間でデータを連携するには、（ログインに紐づくような）信頼できるユーザーIDが不可欠です。信頼できるIDがないと、ブラウジング履歴やアクションのマージは実現できません。
• 匿名状態で行われたアクション（たとえばログインせずにブラウジングするなど）は、ログインが行われるまで識別済みユーザーに紐づけることができません。ログインすると、ユーザーの履歴はマージされますが、それは今後の分のみです。
  • ただし、Web Experimentationでは、カスタムデータが提供されると、ユーザーがまだログインしていなくても、Kameleoonは同じデバイス上のすべての後続訪問でカスタムデータを取得できます。この取得は、ローカルストレージにデータが保存されることによって行われ、Feature Experimentationでは発生しません。
• クロスデバイス実験は多くのユースケースで機能しますが、すべての実験に適しているわけではありません。クロスデバイス実験は、技術スタック、ユーザーのカスタマージャーニー、目標に依存します。

​

アイデンティティの境界を理解する​

クロスデバイス実験の文脈において、アイデンティティの境界とは、異なるセッション、デバイス、識別状態の間でKameleoonがユーザーをどのように認識し、扱うかを指します。これらの境界は、Kameleoonがユーザーデータを体験間で連携できるかどうかを判断するうえで重要です。 Kameleoonは主に2種類のユーザーアイデンティティを区別します。

• 匿名ユーザー: ログインしておらず、一時的なデバイスベースの識別子（visitorCode）で識別されるユーザーです。匿名識別子はデバイスとブラウザに固有であり、デバイス間で永続化されません。
• 識別済みユーザー: ログインして、（ユーザーIDのように）一貫した一意の識別子を提供するユーザーです。この識別子は個々のユーザーに紐づけられており、Kameleoonはデバイスやセッションをまたいで彼らのアクションと履歴をマージできます。

​

クロスデバイス履歴の整合化を有効にする​

クロスデバイス履歴の整合化を使用するには、新しいKameleoon カスタムデータ エントリを作成し、Use this custom data as a unique identifier for cross-device matching オプションを有効にします。有効化されると、Kameleoonはこのカスタムデータを訪問者の一意の識別子として扱い、複数のKameleoon訪問を一意のユーザーにマップします。また、SDKの addData() メソッドや Activation API などの取得方法を使用して、ユーザーIDなどの一意の識別子でカスタムデータの値を設定する必要があります。

​

バリエーション割り当ての一貫性のためのクロスデバイス履歴の整合化​

バリエーション割り当てのためのクロスデバイス履歴の整合化の目的は、実験に割り当てられた訪問者が、ウェブサイトにアクセスするために使用するデバイスに関係なく、一貫して同じバリエーションを見るようにすることです。 ただし、特定のシナリオではこの一貫性を維持することが難しい場合があることに留意することが重要です。たとえば、ユーザーが最初のデバイスでウェブサイトを訪問し、ログインして実験をトリガーした場合、KameleoonはバリエーションV1を割り当てる可能性があります。同じユーザーが別のデバイスでウェブサイトを訪問し、ログインする前に同じ実験をトリガーした場合、システムはバリエーションV2を割り当てるかもしれません。この不一致は、システムがまだデバイスをまたいでユーザーを認識していないために発生します。Kameleoonは、ユーザー体験を妨げないようにするため、単一の訪問中にバリエーション割り当てを意図的に上書きしません。 この問題を緩和し、一貫性を確保するには、ウェブサイトのジャーニー全体を通して訪問者を迅速に識別してください。異なるデバイスからウェブサイトにアクセスしたときに早期に訪問者を識別すると、一貫して同じバリエーションが割り当てられるようになります。このアプローチにより、Kameleoonはシームレスで一貫したテスト体験を提供できます。

​

Kameleoon Web Experimentation​

Kameleoon Web Experimentationソリューションは、主にクライアント側のストレージメカニズムを利用してバリエーション割り当て（バケッティング）を管理します。ユーザーのバリエーション割り当ては、実験に参加すると最初にローカルストレージに保存されます。このストレージにより、お客様が実験のトラフィック割り当てを更新しても、ユーザーが同じデバイスで一貫して同じバリエーションを見ることができます。 同じユーザーが別のデバイスでログインすると、Kameleoonはバックエンドから以前に割り当てられたバリエーション情報を取得します。このステップの後で同じ実験がトリガーされた場合、Kameleoonはユーザーに同じバリエーションを割り当てます。この同期化により、バケッティングを通じて新しいバリエーションを再割り当てすることなく、デバイス間で一貫してバリエーションが適用されます。

​

Feature Experimentationのクロスデバイス実験​

Feature Experimentationは、データがセッションの期間（デフォルトで 30分）メモリに保存される環境で行われるため、有効期限のあるバリエーション割り当てには信頼できないストレージとなります。SDKはランタイムでバリエーションを動的に解決するため、クロスデバイスの一貫性には独自の複雑さが伴います。

​

SDKの役割​

SDKはFeature Experimentationに不可欠であり、以下を行います。

• ターゲティングが発生した時点で、ユーザーアイデンティティ（SDKによってランダムに生成される visitorCode、または独自のユーザーID）に基づいてバリエーション割り当てを動的に解決します。
• アイデンティティ解決を使用して、異なるデバイス間で以前に収集されたデータを取得し、ユーザーがデバイスを切り替えたときに一貫したバリエーション割り当てを保証します。

​

課題と考慮事項​

• ローカルストレージなし: Kameleoon Web Experimentationとは異なり、バリエーションは永続的に保存されません。ユーザーアイデンティティに基づいてランタイムで再計算されます。
• 匿名セッション: ユーザーが匿名として開始し、後でログインする場合に一貫性を確保することは複雑になる場合があります。
• クロスデバイスのアイデンティティ解決: デバイスをまたいだ実験バリエーションの正確な帰属は、堅牢なアイデンティティ解決に依存します。

​

ユースケースの例​

以下のユースケースは、クロスデバイス実験を実装する際に最もよく遭遇するシナリオを示しています。これらの例は、複数のデバイスにわたって一貫したユーザー体験と正確なバリエーション帰属を確保するための典型的な課題と解決策を強調しています。

​

ユースケース1（同じデバイス）​

最初のセッションで、匿名ユーザーが実験のターゲットとなり、その後ログインします。2回目のセッションでは、訪問者はログイン済みで、同じ実験のターゲットになります。

• Web experimentation: Kameleoonはローカルストレージから以前に割り当てられたバリエーションを取得するため、バリエーションは最初のセッションで割り当てられたものと一貫しています。
• Feature experimentation: 匿名訪問者IDをユーザーIDと カスタムデータ で関連付けている場合、匿名IDまたはユーザーIDのいずれかで getVariation() を呼び出すと、同じバリエーションが返されます。ただし、ユーザーIDがメソッドで使用され、ユーザーIDと匿名IDの間にマッピングが存在しない状態で getVariation() を呼び出すと、新しいバリエーションが割り当てられます。

​

ユースケース2（同じデバイス）​

ユーザーがログインし、セッション中に実験のターゲットになります。その後のセッションでは、ユーザーはログアウトして匿名となり、同じ実験のターゲットになります。

• Web experimentation: Kameleoonはローカルストレージから以前に割り当てられたバリエーションを取得するため、バリエーションは最初のセッションで割り当てられたものと一貫しており、セッションをまたいだ継続性が保たれます。
• Feature experimentation:
  • セッション1中にユーザーが匿名状態（anonymous1）から識別済み状態（userId）に移行し、匿名IDがユーザーIDにマッピングされた場合、セッション2では、Kameleoonは anonymous1 を再利用して同じバリエーションでユーザーをバケッティングします。
  • ただし、セッション1で匿名状態が管理されていなかった場合（getVisitorCode() メソッドを呼び出すことによって）、セッション2では新しい visitorCode（anonymous2）が生成され、新しいバリエーション割り当てになります。

​

ユースケース3（異なるデバイス）​

匿名ユーザーが1つのデバイスでログインし、同じセッション中に実験のターゲットになります。後のセッションで別のデバイスで匿名として開始し、同じ実験のターゲットになり、その後ログインします。

• Web experimentation: このシナリオでは、Kameleoonがターゲティングの決定を行うときに2台目のデバイスでユーザーを認識しないため、ユーザーは2つの異なるバリエーションを受け取る可能性があります。2台目のデバイスでのバリエーション割り当てはユーザーがログインする前に行われるため、デバイス間で同期されません。
• Feature experimentation: Web Experimentationと同様に、Kameleoonがターゲティングの決定を行うときに2台目のデバイスでユーザーを認識しないため、ユーザーは2つの異なるバリエーションを受け取る可能性があります。この場合、2台目のデバイスでのバリエーション割り当てはユーザーがログインする前に行われるため、デバイス間で同期されません。

​

ユースケース4（異なるデバイス）​

匿名ユーザーが最初のデバイスでログインし、実験のターゲットになります。後で2台目のデバイスで、同じ実験のターゲットになる前にログインします。

• Web experimentation: バリエーションはデバイス間で一貫しています。実験が再評価される前にユーザーがログインするため、システムは最初のデバイスで割り当てられたバリエーションと一致させます。
• Feature experimentation: Kameleoonは、訪問者用に生成された最新の匿名IDへのユーザーIDのマッピングに基づいてバリエーション割り当てを決定します。
  • デバイス1 では、匿名訪問者（anonymous1）が実験について評価され、バリエーション（var1）を受け取ります。ログイン時に、Kameleoonは userId と anonymous1 の間のマッピングを作成します。
  • デバイス2 で、セッションが userId で直接開始される場合（匿名IDを生成する getVisitorCode() の呼び出しなし）、getRemoteVisitorData(userId) を呼び出すと、Kameleoonは最新の匿名訪問者（anonymous1）のマッピングを取得できます。その結果、実験に対して getRemoteVisitorData() と getVariation() を呼び出すと、ユーザーは anonymous1 に割り当てられたバリエーション（var1）を受け取ります。ただし、セッションが匿名状態で開始される場合、バケッティングが新しく生成されたバケッティングキーを使用するため、新しいバリエーションが割り当てられる可能性があります。

​

ユースケース5（異なるデバイス）​

匿名ユーザーが1つのデバイスで実験のターゲットになり、ログインします。2台目のデバイスでは、ユーザーがログインして同じ実験のターゲットになります。

• Web experimentation: バリエーションはデバイス間で一貫しています。ユーザーがログインすると、システムは同じバリエーションをユーザーに帰属させることができます。
• Feature experimentation: バリエーションは getRemoteVisitorData() を呼び出した場合にのみ一貫します。この呼び出しがないと、システムが2つのセッションを関連付けることができず、デバイスをまたいで異なるバリエーション帰属が発生する可能性があります。

​

ターゲティングのためのクロスデバイス履歴の整合化​

Kameleoonは、新しいセッションが開始されてカスタムデータが値とともに設定されたときに、他のデバイスからの訪問リストを自動的にダウンロードし、現在のデバイスのストレージにこの情報を保存します。ただし、カスタムデータが空の場合、セッション開始時に整合化は実行されません。整合化は、カスタムデータが渡された場合にのみトリガーされ、すべてのアクティブな実験とパーソナライゼーションについてターゲティングが再評価されます。通常、これはユーザーがサイトにログインしてユーザーID、メール、その他の一意の識別子を提供したときに発生します。 カスタムデータが提供されると、ユーザーがまだログインしていなくても、Kameleoonは同じデバイス上のすべての後続訪問でカスタムデータを取得できることに留意することが重要です。整合化は各後続訪問の開始時に発生し、一貫した追跡とターゲティング機能を保証します。

​

クロスデバイス履歴の整合化の影響を受けるデータ​

履歴整合化機能は、現在のデバイスにまだ知られていないすべての以前の訪問のリストを追加します。これには以下のような典型的な情報が含まれます。

• 訪問数とページビュー数
• セッション時間
• 取得チャネルとリファラー
• カスタムデータ（注：訪問者スコープを持つ他のセッションで提供されたカスタムデータは、現在のセッションにマージされます）。

ターゲティングセグメントは通常通り使用でき、期待通りに機能します。たとえば、以前の訪問回数に基づくターゲティング条件はすべての訪問を正確に考慮し、前回の訪問時間に基づく条件も同様です。

​

アナリティクスのためのクロスデバイス履歴の整合化​

履歴整合化は、Kameleoonのレポーティングの 訪問者 ビューにのみ影響を与え、訪問 ビューには影響しません。訪問者モデルでは、標準のKameleoon visitorCode 値（同じデバイス上のリピート訪問者の場合のみ可能）を使用して複数のセッションを単一の訪問者レコードにグループ化する代わりに、システムはカスタムデータ値に基づいてそれらをマージします。カスタムデータが空または提供されていない場合、代わりにvisitorCode値が使用されます。このアプローチにより、ユーザーが顧客システムでまだ識別されていない場合でも、ユニーク訪問者メトリクスが正確に保たれます（ただし、このロジックは同じデバイス上のリピート訪問者にのみ適用されます）。 その結果、訪問者ビューは識別済みユーザーのすべてのデバイスにわたるメトリクスを正しく表示します。たとえば、2台の異なるデバイスで3つのセッションを行う単一の顧客は、1人の訪問者としてカウントされます。履歴整合化がないと、同じ顧客は2人の異なる訪問者（デバイスごとに1人）としてカウントされます。

​

セッションマージのためのカスタムデータの使用​

セッションマージの一意の識別子としてのカスタムデータの使用は、Kameleoonが使用するカスタムデータを識別した後に保存されたセッションでのみ可能です。したがって、Kameleoonは、後で変更することを避けるために、初期インストールと構成時にカスタムデータを選択することを強くお勧めします。 たとえば、Kameleoonが1ヶ月間クロスデバイス履歴の整合化を有効にせずに実行され、2ヶ月目に有効化された場合、2回訪問した（各月に1回ずつ）単一のユーザーは、2人の異なる訪問者としてカウントされます。この不一致は、最初の月のセッションマージがvisitorCodeをキーとして使用するのに対し、2ヶ月目では、ユーザーが両方の訪問で同じデバイスを使用してログインしていても、異なる値のカスタムデータを使用するために発生します。 履歴整合化を担当するカスタムデータ設定への変更は、ユーザーがサイトに戻り認証する頻度に応じて、大多数の訪問者がログインするにつれて、訪問者ベースのメトリクスの精度に一時的に影響を与えます。