Skip to main content

概要

Kameleoon の SDK を使用すると、Web およびモバイルアプリケーションでユーザーエクスペリエンスを向上させるための実験を実施できます。下の図に基づき、Kameleoon SDK で実験を実装するには、初期化、ユーザー識別と属性割り当て、バリエーション割り当てとトラッキング の 3 つの段階があります。本記事ではこれら各段階について詳しく説明します。
SDK Flow
以下の各ステップで説明されているメソッド(およびその名称)は、特定の SDK 言語の慣習に基づき、異なる構文を持ちます。

1. 初期化

初期化時に、SDK は Cloudflare の Content Delivery Network を介して、更新されたフィーチャーフラグ設定を取得します。取得方法には次の 2 つがあります。デフォルトオプションの Polling では、SDK が定期的に CDN に要求を送信し(デフォルト間隔は 60 分毎)、最新の設定を取得します。プレミアムオプションの Streaming では、Kameleoon SDK は server-sent events (SSE) を介して設定のリアルタイムな変更を通知されます。設定が取得されると、SDK はバリエーションおよびターゲティングプロセスとともに、訪問者コードの割り当てを開始します。詳細については、技術的考慮事項 をご覧ください。
図に示されているように、Streaming 中、on_configuration_update メソッド(名称は SDK ごとに異なります)を使用すると、設定にデータ更新があった際のイベントを処理できます。このメソッドは 1 つの入力パラメーター handler を受け取ります。handler は、リアルタイム設定イベントによって設定が更新されたときに呼び出されます。詳細については、各 Web および Mobile SDK をご参照ください。

2. ユーザー識別と属性割り当て

この段階では、バリエーションを計算するため、訪問者コードが割り当てられ、ユーザー属性 が組み込まれます。
  • 1. 訪問者コードの割り当て: 初期化時に、訪問者に一意の ID を割り当てるオプションがあります。Web SDK では、getVisitorCode() メソッドが要求ヘッダーの Cookie から訪問者コードを取得します。訪問者コードが存在しない場合、メソッドはランダムな訪問者コードを生成し、応答ヘッダー Cookie に保存します。モバイル SDK では、訪問者コードはモバイルデバイスのメモリから取得されます。
  • 2. ターゲティング目的のユーザー属性の追加: Kameleoon のターゲティング条件により、ユーザー属性 に基づいてフィーチャーフラグをアクティブ化できます。これらの条件を効果的に使用するには、addData() メソッドで値を設定したり、getRemoteVisitorData() を使用して 特定の条件 を取得して使用します。ユーザー属性はその後、サーバーサイド SDK ではサーバーメモリ、クライアントサイド SDK ではブラウザのローカルストレージ、モバイル SDK ではデバイスメモリに保存されます。詳細については、データストレージに関する記事 をご覧ください。
  • 3. ターゲティング目的の外部データの追加: ユーザーの好みや CRM データなどの外部データは、Data API(REST API)の POST エンドポイント を介して保存できます。このデータは、getRemoteData() メソッドを使用して SDK で取得します。

3. バリエーション割り当てとトラッキング

Kameleoon SDK では、getVariation()(isFeatureFlagActive() / getVariations())メソッドは、複数のバリエーションを含むフィーチャー実験の設定を取得します。特定のユーザーに割り当てられたバリエーションキーを取得するために使用できます。 訪問者がフィーチャーフラグのすべてのターゲティング条件と公開ルールを満たすと、Kameleoon はハッシュ関数を使用して訪問者をバリエーションに割り当て、トラッキングサービスに実験イベントを送信します。訪問者が条件を満たさない場合、ユーザーが Web またはモバイルアプリでアクティブであることを示すアクティビティイベントが送信されます。さらに、flush() メソッドを使用して、その他の保存されているデータをトラッキングサービスに送信できます。

4. 関連ドキュメント

言語固有の連携については、Web SDK および Mobile SDK の記事をご参照ください。 Web SDK Mobile SDK 追加リソース

FAQ

一般的に、flush メソッドを手動で呼び出す必要はありません。他の SDK メソッド を呼び出すと、蓄積されたデータも同時に送信されるからです。ただし、フィーチャーフラグの訪問者をトリガーせずに Data API へデータを送信する必要がある場合は、flush メソッドを使用してください。
デフォルトでは、SDK は複数のイベントをまとめて、設定可能な間隔で分析用のトラッキングリクエストを Kameleoon のサーバーに送信します。この方法により効率が向上し、サーバーの負荷が軽減されます。SDK は次のタイミングでトラッキングリクエストを送信します:
  • 定期的: デフォルトでは、SDK は 1000 ms(1 秒) ごとにリクエストを送信します。tracking interval の値を設定すると、この間隔を変更できます。
  • オンデマンド: コードが flush(instant=true) のようなメソッドを呼び出すと、即座に送信されます。
具体的には、次のメソッドのいずれかを間隔が切れる前に呼び出すと、トラッキングリクエストがトリガーされます:
  • getVariation(track を true に設定した場合)。
  • getVariations(track を true に設定した場合)。
  • isFeatureFlagActive(track を true に設定した場合)。
  • trackConversion
  • flush(instant=true の有無にかかわらず)
クライアントサイド SDK は、他のアクティビティがない場合、デフォルトで 60 秒 ごとにもトラッキングリクエストを送信し、訪問者のセッションを維持します。この既定値は、SDK 設定の activityTrackingIntervalMillisecond(または activity_tracking_interval_millisecond)パラメーターを設定して変更できます。サーバーサイド SDK では、イベントのバッチ処理が特に有用です。各トラッキングリクエストが、複数の訪問者のデータを 1 つのリクエストにまとめられるからです。この方法では、影響を受けるすべての訪問者の情報が集約され、間隔ごとに 1 回送信されるため、効率が向上し、サーバーの負荷が軽減されます。
トラッキングリクエストは Data API のレート制限 の対象となります。クライアントサイド SDK の場合、同じネットワークを共有する複数の訪問者(例: オフィス内)が同じ IP アドレスから発信しているように見えることがあります。その結果、レート制限を超え、429 - Too Many Requests エラーが発生する可能性があります。
異なる SDK では、言語の特性により、メソッド名が異なる場合があります。
HTTP リクエストを行う SDK メソッドの一覧は次のとおりです:
  • isFeatureFlagActive / getVariation / trackConversion / flush
    • 非同期のメソッドは、訪問者に関するすべての情報(訪問者が受け取ったバリエーションを含む)を保存するために、Data API へ非同期リクエストを行います。Kameleoon はこの情報を使用して、app.kameleoon.com で統計を表示します。
  • getRemoteData / getRemoteVisitorData / getVisitorWarehouseAudience
    • getRemoteData / getRemoteVisitorData / getVisitorWarehouseAudience は、訪問者に関する情報を取得するために Data API へリクエストを行います。JavaScript SDK では非同期のため、結果を使用する前に await で待つ必要があります。
  • さらに、SDK は内部処理に必要な設定を取得するために非同期リクエストを行います。
訪問者が受け取った正確なバリエーションを知る必要はなく、フラグが有効かどうかだけを知りたい場合は、isFeatureFlagActive を呼び出してください。実験ルールを使用する場合は、off 以外のバリエーションが 2 つ以上あるときに getVariation を呼び出す方が適しています。