Skip to main content
Kameleoon Android SDK を使用すると、ネイティブモバイル Android アプリケーション上でフィーチャーフラグを実行できます。Android SDK は Kotlin と Java の両方に対応しています。SDK はアプリケーションへの統合が簡単で、メモリとネットワークの使用量も少ないです。 はじめに: 開始するには、開発者ガイド を参照してください。 変更履歴: Android SDK の最新バージョン: 4.26.0 変更履歴 SDK メソッド: Android SDK メソッドの完全なリファレンスドキュメントについては、リファレンス セクションを参照してください。

開発者ガイド

このセクションに従って、Android アプリに Android SDK をインストールおよび構成し、高度な機能について学びます。

はじめに

以下の手順に従って、アプリケーションに Kameleoon Android SDK をインストールおよび構成します。

インストール

Android アプリの build.gradle ファイルに以下の依存関係を追加することで、Android SDK をインストールできます。

追加の設定

SDK の動作をカスタマイズするには、.properties 設定ファイルを作成します。プロパティファイルの名前と場所は重要です。
  • アプリの assets/ ディレクトリにファイルを作成します。
  • ファイル名は kameleoon-client.properties とします。
サンプル設定ファイル をダウンロードすることもできます。 設定可能なプロパティは次のとおりです。
visitorCode を指定して isUniqueIdentifier パラメータを true に設定した場合、SDK メソッドは visitorCode の値を一意の訪問者識別子として使用します。これは クロスデバイス実験 に便利です。SDK は、フラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。isUniqueIdentifier は、もともと訪問者に割り当てられた匿名の visitorCode にアクセスできないが、セッションマージを通じて匿名訪問者にリンクされた内部 ID にアクセスできる場合など、その他のエッジケースのシナリオでも役立ちます。
activityTrackingIntervalMillisecond の使用
activityTrackingIntervalMillisecond パラメータは、SDK が Data API 上の訪問者のセッションを延長するためにアクティビティイベントを送信する頻度を制御することで、ネットワーク使用量とバッテリー消費を削減するのに役立ちます。デフォルト値および許容される最小値は 60 000 ミリ秒 (60 秒) で、これより低い 0 以外の値は無視され、デフォルト値が適用されます。アプリがバックグラウンドにある間はタイマーが一時停止するため、間隔はアプリがフォアグラウンドにあるときにのみ実質的に進行します。

Kameleoon クライアントの初期化

アプリケーションに SDK をインストールしてアプリプロパティをセットアップした後、Kameleoon クライアントを作成する必要があります。クライアントは、アプリケーションと Kameleoon プラットフォーム間のブリッジとして機能するシングルトンオブジェクトです。フィーチャーフラグを実行するために必要なすべてのメソッドとプロパティが含まれています。
実行中、KameleoonClientFactory.create() メソッドはクライアントを初期化しますが、すぐには使用できる状態にはなりません。この遅延は、Kameleoon クライアントが Kameleoon リモートサーバーからフィーチャーフラグの現在の構成(およびトラフィック分配)を取得する必要があるためです。この取得にはネットワークアクセスが必要ですが、常に利用可能とは限りません。Kameleoon クライアントが完全に準備完了するまで、Kameleoon Android SDK の他のメソッドを実行しようとしないでください。フィーチャーフラグの最初の構成が取得されると、定期的に更新されますが、何らかの理由で更新が失敗した場合でも、Kameleoon クライアントは以前の構成を使用して動作を継続します。 isReady() メソッドを使用して、Kameleoon クライアントの初期化が完了したかどうかを確認できます。 別の方法として、ヘルパーコールバック がフィーチャーフラグの起動とバリエーション実装のロジックをカプセル化できます。最適なアプローチ(isReady() または コールバック)は、好みと具体的なユースケースによって異なります。SDK がまもなく使用可能になる見込みの場合は、isReady() の使用が推奨されます。たとえば、ユーザーがアプリ内のナビゲーション中の最初の数秒または数分はアクセスしない可能性が高いダイアログ上でフィーチャーフラグを実行する場合、isReady() が適切です。SDK がまだ初期化中である可能性が高い場合は、コールバックが推奨されます。たとえば、アプリケーション起動時に画面に表示されるフィーチャーフラグでは、SDK が準備完了するまでまたは指定されたタイムアウトが満了するまでアプリケーションを待機させるコールバックを使用する必要があります。
Kameleoon を使用した A/B テストのコンテキスト内で、アプリケーションコードのロジックが正しいことを保証するのは、アプリ開発者の責任です。良いプラクティスは、Kameleoon クライアントがまだ準備できていないときには、アプリケーションのユーザーが常にフィーチャーフラグから除外される可能性があると想定することです。これはデフォルトまたは参照バリエーションロジックの実装に対応するため、簡単に実装できます。次の段落のコードサンプルは、このアプローチの例を示しています。
これで、フィーチャー管理とフィーチャーフラグを実装する準備ができました。追加メソッドの詳細については、リファレンス セクションを参照してください。

初期化と使用のベストプラクティス

  • 初期化には時間がかかる可能性があるため、アプリケーション開始後にできるだけ早くシングルトンとして KameleoonClient を初期化することが推奨されます。初期化は非同期であるため、アプリケーションの起動プロセスをブロックしたり遅延させたりすることはありません。
  • KameleoonClient を使用する前に、runWhenReady メソッドを呼び出して初期化されているかを確認してください。そうしないと、準備が完了する前にクライアントを使用しようとするとエラーが発生します。
  • ⚠️ 主要なメソッドのほとんどは例外をスローする可能性があるため、適切な例外処理が必要です。使用する各メソッドのドキュメントを必ず確認して、潜在的な例外を理解してください。

フィーチャーフラグの有効化

フラグ構成の取得
コード内でフィーチャーフラグを実装するには、まず Kameleoon アカウントでフィーチャーフラグを作成する必要があります。 特定のユーザーに対するフィーチャーフラグのステータスまたはバリエーションを判断するには、getVariation() または isFeatureActive() メソッドを使用して、featureKey に基づく構成を取得する必要があります。 getVariation() メソッドは、ON/OFF 状態の単純なフィーチャーフラグと、複数のバリエーションを持つより複雑なフラグの両方を処理します。このメソッドは、フィーチャールールをチェックし、バリエーションを割り当て、featureKeyvisitorCode に基づいて返すことで、ユーザーに適切なバリエーションを取得します。 isFeatureActive() メソッドは、複数のバリエーションやターゲティングオプションを持つより複雑なフィーチャーフラグとは対照的に、ON または OFF 状態のみを持つ単純なフィーチャーフラグの構成を取得する場合に使用できます。 フィーチャーフラグに関連する変数 (各バリエーションに関連付けられた特定の動作など) がある場合、getVariation() を使用すると Variation オブジェクトにアクセスできます。これは、割り当てられたバリエーションとそれに関連付けられた実験の詳細を提供します。このメソッドは、ユーザーがターゲットになっているかどうかを確認し、訪問者に割り当てられたバリエーションを見つけて、ストレージに保存します。track=true の場合、SDK は、SDK の tracking_interval_millisecond に基づいて自動的にトリガーされる次のトラッキングリクエスト時に、指定された実験に露出イベントを送信します。デフォルトでは、この間隔は 1000 ミリ秒 (1 秒) に設定されています。 getVariation() メソッドを使用すると、トラッキングを行うかどうかを制御できます。track=false の場合、SDK からは露出イベントは送信されません。これは、SDK 経由でデータを追跡せず、代わりに Kameleoon エンジンによって管理されるクライアントサイドのトラッキングに依存する場合などに便利です。さらに、getVariations() メソッドを使用するとき、トラッキングイベントをトリガーせずにすべてのフラグのバリエーションのみが必要な場合にも、track=false の設定が役立ちます。トラッキングの仕組みについて詳しく知りたい場合は、こちらの記事 をご覧ください。
レポートで訪問をターゲット/フィルター/ブレークダウンするためのデータポイントの追加
ユーザーをターゲットにするには、フィーチャーバリエーションを取得する、またはフラグがアクティブかどうかをチェックする前に、関連するデータポイントをプロファイルに追加していることを確認してください。これらのデータポイントをユーザーのプロファイルに追加するには、addData() メソッドを使用します。 他のデバイスで収集されたデータポイントを取得するには、getRemoteVisitorData() メソッドを使用します。このメソッドはサーバーからデータを非同期的に取得します。このデータはユーザーを特定のバリエーションに割り当てるために必要となる可能性があるため、バリエーションを取得する またはフィーチャーフラグがアクティブかどうかをチェックする getRemoteVisitorData() を呼び出すことが重要です。 利用可能なターゲティング条件について詳しく知るには、この件に関する詳細な記事 を参照してください。 さらに、訪問者プロファイルに追加するデータポイントは、実験を分析する際に利用できるため、デバイスなどの要因で結果をフィルタリングおよびブレークダウンできます。完全なリストは こちら をご覧ください。 自動的に収集されるデータポイント以外に追跡する必要がある場合は、Kameleoon の カスタムデータ機能 を使用できます。カスタムデータを使用すると、実験に関連する特定の情報をキャプチャして分析できます。収集したデータを分析のために Kameleoon サーバーに送信するには、flush() メソッドを呼び出すことを忘れないでください。
目標コンバージョンの追跡
ユーザーが希望するアクション(購入など)を完了すると、それはコンバージョンとして記録されます。コンバージョンを追跡するには、trackConversion() メソッドを使用し、必須の goalId パラメータを提供します。 コンバージョン追跡リクエストは、次のスケジュールされたトラッキングリクエストと一緒に送信されます。これは SDK が定期的な間隔(tracking_interval_millisecond で定義) で送信します(tracking_interval_millisecond)。リクエストを即座に送信したい場合は、instant=true パラメータを指定して flush() メソッドを使用します。

クロスデバイス実験

複数のデバイスからアプリにアクセスする訪問者をサポートするため、Kameleoon は、以前に収集された訪問者データを各訪問者のデバイス間で同期し、クロスデバイス実験を通じてデバイス間で訪問履歴を調整することを可能にします。Kameleoon がデバイス間でどのようにデータを処理するかについてのケーススタディと詳細情報は、クロスデバイス実験の記事 で参照できます。

デバイス間でのカスタムデータの同期

カスタムマッピング同期は、デバイス間で訪問者データを調整するために使用されますが、常に必要というわけではありません。以下は、カスタムマッピング同期が不要な 2 つのシナリオです。 デバイス間で同じユーザー ID すべてのデバイスで同じユーザー ID が一貫して使用される場合、カスタムマッピング同期なしで自動的に同期が処理されます。複数のデバイス間で収集されたデータを同期したい場合は、getRemoteVisitorData() メソッドを呼び出すだけで十分です。 一貫した ID を持つマルチサーバーインスタンス 複数のサーバーが関与する複雑なセットアップ(例: 分散サーバーインスタンス)で、同じユーザー ID が複数のサーバーで利用できる場合、追加のカスタムマッピング同期なしで、サーバー間の同期(getRemoteVisitorData() を使用)で十分です。 追加データが必要なお客様は、詳細なガイダンスについて getRemoteVisitorData() メソッドの説明を参照してください。以下のコードでは、2 つのデバイス間で同じ一意の識別子(この場合は visitorCodeuserId とも呼ばれる)が一貫して使用され、正確なデータ取得が可能であると仮定しています。
収集したデータをリアルタイムで同期したい場合は、カスタムデータのスコープを 訪問者 にする必要があります。
デバイス A
デバイス B

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

クロスデバイス実験 を使用すると、訪問者の履歴を各デバイスで結合できます(履歴の調整)。履歴の調整により、異なる訪問者セッションを 1 つにマージできます。訪問履歴を調整するには、CustomData を使用して訪問者の一意の識別子を提供します。詳細については、専用のドキュメント を参照してください。 クロスデバイスの調整が有効化された後、userId パラメータを指定して getRemoteVisitorData() を呼び出すと、特定のユーザーに対する既知のデータがすべて取得されます。 同じ識別子を持つセッションは、実験において常に同じバリエーションが表示されます。実験結果ページの訪問者ビューでは、これらのセッションは単一の訪問者として表示されます。 SDK 構成は、関連するセッションが常に実験の同じバリエーションを見ることを保証します。ただし、クロスデバイスのバリエーション割り当てにはいくつかの制限があります。これらの制限については こちら で説明されています。 クロスデバイス履歴調整の有効化 ガイドに従って、Kameleoon プラットフォームでカスタムデータをセットアップします。 その後、通常通り SDK を使用できます。セッションマージのコンテキストで役立つ可能性のあるメソッドは次のとおりです。
  • KameleoonClientConfigisUniqueIdentifier=true を渡した getRemoteVisitorData() - リンクされたすべての訪問者のデータを取得します。
  • KameleoonClientConfigisUniqueIdentifier=true を渡した trackConversion() または flush() - 別の訪問者に関連付けられている特定の訪問者のデータを追跡します。
識別子として使用するカスタムデータは 訪問者スコープ に設定する必要があるため、各デバイスで getRemoteVisitorData() メソッドを使用して識別子を取得するには、クロスデバイスカスタムデータ同期 を使用する必要があります。
以下は、セッションマージにカスタムデータを使用する例です。
この例では、アプリケーションにログインページがあります。ログイン時にはユーザー ID が不明であるため、SDK によって自動的に生成された匿名訪問者が使用されます。訪問者コードは getVisitorCode() メソッドで取得できます。ユーザーがログインすると、匿名訪問者はユーザー ID に関連付けられ、訪問者の一意の識別子として使用されます。

カスタムバケッティングキーの使用

デフォルトでは、Kameleoon は一意の匿名訪問者 ID (visitorCode) を使用して、ユーザーをフィーチャーフラグのバリエーションに割り当てます。この ID は通常、ユーザーのデバイス上で生成されて保存されます(クライアントサイドおよびサーバーサイドの SDK ではブラウザクッキー内、モバイル SDK では永続ストレージ内)。ただし、特定のシナリオでは、同じ組織のすべてのユーザーがフィーチャーフラグの同じバリアントを見ることを保証する必要がある場合があります。 カスタムバケッティングキー オプションを使用すると、バケッティングに使用する独自のカスタム識別子を提供することで、このデフォルトの動作を上書きできます。このオーバーライドにより、Kameleoon の割り当てロジックがデフォルトの visitorCode の代わりに指定したキーを使用することが保証されます。

ユースケース

カスタムバケッティングキーを使用することは、特に以下の状況で、フィーチャーフラグの割り当てにおける一貫性と精度を維持するために不可欠です。
  • アカウントレベルまたは組織の実験: B2B 製品または同じ組織のすべてのユーザーを同じバリエーションに割り当てたいシナリオでは、accountId のような識別子を使用できます。チームまたは会社全体に影響を与える機能の A/B テストでは、カスタムバケッティングキーが極めて重要です。
カスタムバケッティングキーを実装することで、実験における一貫性と精度が向上し、信頼性の高い結果とより良いユーザーエクスペリエンスにつながります。

技術的な詳細

フィーチャーフラグにカスタムバケッティングキーを構成する場合、アプリケーションのデータから特定の識別子を Kameleoon に提供します。
  • カスタムキーの提供: addData() メソッドを使用して、カスタム識別子を Kameleoon SDK に提供します。このメソッドでは、選択したカスタムバケッティングキーを CustomData オブジェクトとして渡します。ここで、newVisitorCode は、バケッティングに使用したい識別子(例えば、新しい userId または accountId)を指します。
カスタムバケッティングキーが正しく機能するためには、フラグの作成または編集プロセス中にフィーチャーフラグに対して定義および構成する必要があります。この対応する構成がないと、SDK のバケッティングはカスタムキーを適用しません。Kameleoon でこれをセットアップする詳細な手順については、こちらの 記事 を参照してください。
  • バケッティングロジック: addData() メソッド経由でカスタムバケッティングキーが提供されると、ユーザーをバリエーションに割り当てるためのすべてのハッシュ計算で、デフォルトの visitorCode の代わりにこの newVisitorCode(カスタムキー)が使用されます。newVisitorCode を使用することで、バケッティングの決定がカスタム識別子に紐付けられるため、その識別子が存在する様々なコンテキストで一貫した割り当てが保証されます。
  • データ追跡と分析: newVisitorCode(カスタムキー)はバケッティングの決定に使用される一方、後続のすべてのデータ(例: トラッキングイベントやコンバージョン)は元の visitorCode に関連付けて送信されます。 この分離により、バケッティングが上位レベル(アカウントなど)または複数のデバイス/セッションで実行される場合でも、分析は実験のより広いコンテキスト内での個々のユーザーの旅程やインタラクションを正確に反映します。元の訪問者データは、包括的なレポート用にそのまま保持されます。

技術要件

カスタムバケッティングキーを効果的に使用するには:
  • キーは String でなければなりません。
  • バケットしたいエンティティに対して一意でなければなりません(例えば、userId を使用する場合、各ユーザーの ID は一意である必要があります)。
  • フィーチャーフラグの決定がそのユーザーまたはリクエストに対して評価される正確な瞬間に、SDK がキーを利用できる必要があります。

ターゲティング条件

Kameleoon SDK は、キャンペーンでユーザーをターゲットするために使用できる、さまざまな事前定義されたターゲティング条件をサポートしています。この SDK がサポートする条件の一覧については、訪問履歴を使用してユーザーをターゲットする を参照してください。 独自の 外部データを使用してユーザーをターゲットする こともできます。

エラー処理

Kameleoon SDK のすべてのメソッドは、KameleoonException または各メソッドの Exceptions Thrown セクションで一覧されているドキュメント化された継承例外 のみ をスローする可能性があります。 これらの例外は SDK の 予期される動作 です。特定のシナリオを別の方法で処理したい場合は、個別の継承例外をキャッチできます。それ以外の場合、KameleoonException をキャッチするとすべての SDK 関連エラーが処理されます。 ユニットテストおよび統合テスト で SDK が ExceptionRuntimeException決してスローしない ことを確認していますが、Android で SDK のバージョンをパッチするのは困難 であり、RuntimeException をスローする可能性のある サードパーティライブラリ から予期しない問題が発生する可能性があることを理解しています。このようなまれなケースでアプリケーションがクラッシュするのを防ぐために、追加の保護策として Exception(または RuntimeException)もキャッチする ことを推奨します。これは厳密には予防策であり、SDK の予期される動作ではありません 例えば:

ロギング

SDK は、さまざまな内部プロセスと問題を反映するログを生成します。

ログレベル

SDK は、ログレベルによるロギング制限の設定をサポートしています。

ログのカスタム処理

SDK は、デフォルトでログをコンソール出力に書き込みます。この動作はオーバーライドできます。
ログレベルによるロギング制限は、ログ処理ロジックとは別に実行されます。

WebView への訪問者コードの受け渡し

場合によっては、ネイティブアプリケーションから Engine.js または Web の JavaScript または React SDK を使用する WebView に 訪問者コード を渡す必要があります。次の例は、これを実現するための推奨される方法を示しています。

リファレンス

Kameleoon Android SDK の完全なリファレンスドキュメントです。

初期化

アプリケーションに SDK をインストール したら、最初のステップとして Kameleoon を初期化します。実験のトリガーなど、アプリケーションと SDK 間のすべてのインタラクションは、この Kameleoon クライアントオブジェクトを使用して行われます。

create()

SDK を初期化するために、他のメソッドの前にこのメソッドを呼び出します。このメソッドは com.kameleoon.KameleoonClientFactory にあります。アプリは、このメソッドによって作成された結果の KameleoonClient オブジェクトを使用して、SDK とのすべてのインタラクションを行います。 構成オブジェクト を提供することで、SDK の動作(環境、認証情報など)をカスタマイズできます。それ以外の場合、SDK は代わりに構成ファイルを探して使用しようとします。
引数
戻り値
スローされる例外

isReady()

モバイル SDK の場合、Kameleoon クライアントはアクティブなフィーチャーフラグの現在の構成を取得するためにサーバーコールを実行する必要があるため、すぐに初期化することはできません。フィーチャーフラグをトリガーする前に isReady() を呼び出して、SDK の準備が完了しているかを確認するためにこのメソッドを使用します。 または、コールバックを使用することもできます(詳細は runWhenReady() メソッドを参照)。
戻り値

runWhenReady()

  • 🔄 非同期リクエストを実行します(設定が古いまたは欠如している場合)
モバイル SDK では、KameleoonClient はすべてのフィーチャーフラグの現在の構成を取得するためにサーバーコールを実行する必要があるため、すぐに初期化することはできません。クライアントが使用できる状態になるまでの時間を処理するには、runWhenReady() メソッドを使用します。さらに、クライアントが準備完了するまでの最大タイムアウト期間を設定することもできます。 result.getOrThrow()=true の場合、KameleoonClient は初期化されて準備完了であり、フィーチャーフラグはそれぞれのバリエーションでトリガーされます。結果が false であるか、タイムアウトが発生した場合、初期化は正常に完了しません。 タイムアウトが発生した場合、ユーザーはフィーチャーフラグから除外されるため、コールバックまたはコルーチンベースのコードには、参照バリエーションを適用するロジックを含める必要があります。
初期構成にはサーバーコールが必要な場合があるため、このメカニズムは非同期です。したがって、次のいずれかを行ってください。
  • メソッドの引数として completion コールバックを提供し、KameleoonClient が完全に初期化されて使用可能になったときに通知を受け取れるようにします。
  • 非同期操作を処理するためにコルーチンを使用します。
引数

フィーチャーフラグとバリエーション

isFeatureActive()

  • 📨 Kameleoon にトラッキングデータを送信します(track パラメータに依存)
このメソッドは以前は activateFeature と呼ばれており、SDK バージョン 4.0.0 で削除されました。
フィーチャートグルを有効化するためにこのメソッドを呼び出します。このメソッドは、指定されたフィーチャーが訪問者に対してアクティブになるかどうかをチェックするための必須引数として featureKey を受け取ります。 訪問者がこのフィーチャーフラグに以前関連付けられたことがない場合、このメソッドはランダムなブール値を返します(訪問者にこのフィーチャーを表示する場合は true、それ以外の場合は false)。訪問者がすでにこのフィーチャーフラグに登録されている場合、このメソッドは以前の featureFlag 値を返します。 潜在的な例外をキャッチするために、サンプルコードに示されているようにエラー処理を適切に設定してください。
Kameleoon は、isFeatureActive()getVariation()getVariations() などの特定のメソッドを呼び出す際に、セッションと訪問者をカウントするためにトラッキングを使用します。訪問者をバリエーションに公開し、それらをカウントする必要がある場合は、track パラメータにデフォルトの true 値を使用してください。訪問者を公開する前にこれらのメソッドを呼び出す場合のみ、track パラメータを false に設定してください。例えば、訪問者を公開する前にすべてのバリエーションを取得するために getVariations() を呼び出す場合、track パラメータを false に設定します。この設定により、Kameleoon がセッションを早期にカウントするのを防ぎます。その後、訪問者を明示的に公開する際にトラッキングをトリガーできます。Kameleoon はデフォルトで毎秒トラッキングデータを送信します。トラッキング間隔構成オプションを使用して、この間隔を最大 5 秒まで構成できます。Kameleoon は、イベント間の間隔が 30 分未満であれば、トラッキングイベントを単一のセッションにグループ化します。トラッキングイベント間に 30 分以上経過した場合、Kameleoon はそれらのイベントを別々のセッションとしてカウントします。訪問は、セッション内の最後に記録されたイベントから 30 分後にレポートに表示されます。
isFeatureActive() メソッドは、マスターフラグの状態ではなく、提供されたバリアントを評価します。ルールを除外する場合、メソッドは その他全員に対しては、その後 のデフォルトの状態を使用します。このデフォルトの状態に Off を選択した場合、マスターフィーチャーフラグが On であっても、メソッドは常に false を返します。
引数
戻り値
スローされる例外

getVariation()

  • 📨 Kameleoon にトラッキングデータを送信します(track パラメータに依存)
特定の訪問者に対して、特定のフィーチャーフラグに割り当てられた Variation を取得します。 このメソッドは、必須の引数として visitorCodefeatureKey を受け取ります。track 引数はオプションで、デフォルトは true です。 訪問者に割り当てられた Variation を返します。訪問者がいずれのフィーチャーフラグルールにも関連付けられていない場合、このメソッドは特定のフィーチャーフラグのデフォルトの Variation を返します。 潜在的な例外を管理するため、コード内で適切なエラー処理が実装されていることを確認してください。
デフォルトのバリエーションとは、フィーチャーフラグの事前定義された配信ルールに一致しない場合に訪問者に割り当てられるバリエーションを指します。言い換えると、特定のルールでターゲットにされていないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェースの「その他全員に対しては…」セクションのバリエーションとして表されます。
引数
戻り値
スローされる例外

getVariations()

  • 📨 Kameleoon にトラッキングデータを送信します(track パラメータに依存)
すべてのフィーチャーフラグにわたって特定の訪問者に割り当てられた Variation オブジェクトのマップを取得します。 このメソッドは、利用可能なすべてのフィーチャーフラグを反復処理し、指定された訪問者に関連付けられた各フラグに割り当てられた Variation を返します。onlyActive および track をオプションの引数として受け取ります。
  • onlyActivetrue に設定されている場合、getVariations() メソッドは、ユーザーが off バリエーションでバケットされていない限り、フィーチャーフラグのバリエーションを返します。
  • track パラメータは、メソッドがバリエーションの割り当てを追跡するかどうかを制御します。デフォルトでは true に設定されています。false に設定すると、トラッキングは無効になります。
返されるマップは、フィーチャーフラグのキーをキー、対応する Variation を値として構成されます。フィーチャーフラグに割り当てられたバリエーションがない場合、メソッドはそのフラグのデフォルトの Variation を返します。 潜在的な例外を管理するため、適切なエラー処理が実装されているべきです。
デフォルトのバリエーションとは、フィーチャーフラグの事前定義された配信ルールに一致しない場合に訪問者に割り当てられるバリエーションを指します。言い換えると、特定のルールでターゲットにされていないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェースの「その他全員に対しては…」セクションのバリエーションとして表されます。
引数
戻り値
スローされる例外

setForcedVariation()

このメソッドを使用すると、標準の評価プロセスをバイパスして、特定の Variation をユーザーにプログラム的に割り当てることができます。これは、通常の評価ロジックが不要、またはスキップする必要がある制御された実験で特に貴重です。また、デバッグやカスタムテストなどのシナリオでも役立ちます。 強制 バリエーションが設定されると、Kameleoon のリアルタイム評価ロジックがオーバーライドされます。セグメンテーション、ターゲティング条件、アルゴリズム計算などのプロセスはスキップされます。実験中のセグメンテーションとターゲティング条件を維持するには、代わりに forceTargeting=false を設定します。 強制バリエーションは、評価されたバリエーションと同じように扱われます。標準の評価されたバリエーションと同様に分析で追跡され、ユーザーコンテキストに保存されるため、レポートの一貫性が保証されます。 このメソッドは、特定の条件下(例: 無効なパラメータ、ユーザーコンテキスト、内部の問題)で例外をスローする可能性があります。アプリケーションが安定して回復力があることを保証するため、適切な例外処理が不可欠です。
引数
スローされる例外
ほとんどの場合、例で示すように、基本のエラーである KameleoonException のみを処理すれば十分です。ただし、異なるタイプのエラーに対して応答が必要な場合は、特定の要件に基づいて各々を個別に処理してください。さらに、信頼性を高めるために、一般的な言語エラーを処理するために Exception を含めることもできます。

evaluateAudiences()

  • 📨 Kameleoon にトラッキングデータを送信します
このメソッドは、利用可能なすべての Audiences Explorer セグメントに対して訪問者を評価し、一致する訪問者を追跡します。 evaluateAudiences()関連するすべての訪問者データがセットまたは更新された後、フィーチャーバリエーションを取得するかフィーチャーフラグをチェックする 直前 に呼び出される必要があります。このアプローチにより、訪問者が利用可能な最新のデータに対して評価されることが保証され、すべての基準に基づいて正確なオーディエンス割り当てが可能になります。 このメソッドを呼び出した後、Audiences Explorer でセグメントのパフォーマンスを詳細に分析できます。
スローされる例外
ほとんどの場合、例で示すように、基本のエラーである KameleoonException のみを処理すれば十分です。ただし、異なるタイプのエラーに対して応答が必要な場合は、特定の要件に基づいて各々を個別に処理してください。さらに、信頼性を高めるために、一般的な言語エラーを処理するために Exception を含めることもできます。

getDataFile()

すべてのフィーチャーフラグを評価するには、getVariations() を使用します。このメソッドは、DataFile を呼び出して getVariation() でフラグを反復処理するよりも効率的です。
現在の SDK 構成を DataFile オブジェクトとして返します。
戻り値
スローされるエラー

目標

trackConversion()

  • 📨 Kameleoon にトラッキングデータを送信します
コンバージョンを追跡するためにこのメソッドを使用します。このメソッドは、この特定の 目標 でコンバージョンを追跡するために goalId を必要とします。さらに、このメソッドは revenuemetadatanegative 引数も受け取ります。 trackConversion() メソッドは値を返しません。このメソッドは、サーバーコールが非同期で行われるため非ブロッキングです。
引数
メタデータの値は、生データのエクスポート および 結果ページ からアクセスできます。metadata パラメータが指定されている場合、Kameleoon は addData() メソッドを使用して以前に収集されたものではなく、現在のコンバージョンにこれらの指定された値を使用します。パラメータが省略された場合、Kameleoon は、コンバージョン前および同じ訪問内で最後に追跡された CustomData の値を使用します。Kameleoon は、trackConversion() メソッドにパラメータとして明示的に渡されたメタデータ値のみを考慮します。以下の例では、Kameleoon は、パラメータとして明示的に提供されたカスタムデータ値(ここではインデックス 5、値 ‘Amex Credit Card’) のみとコンバージョンを関連付けます。

イベント

onUpdateConfiguration()

このメソッドは以前は updateConfigurationHandler と呼ばれており、SDK バージョン 4.0.0 リリースで削除されました。
onUpdateConfiguration() メソッドを使用すると、構成がデータを更新したときのイベントを処理できます。1 つの入力パラメータ completion を受け取ります。リアルタイム構成イベントを使用して構成が更新されたときに呼び出される completion です。
このハンドラは、SDK が ストリーミングモード (サーバー送信イベント) で実行されている場合にのみ起動します。デフォルトのポーリングモード (refreshIntervalMinute) で実行される設定の更新では 呼び出されません
引数

訪問者データ

getVisitorCode()

SDK で使用される一意の訪問者コードを返します。
戻り値

addData()

addData() メソッドは、ターゲティングデータ をストレージに追加し、他のメソッドがこのデータを使用して現在の訪問者をターゲットにするかどうかを判断できるようにします。 addData() メソッドは値を返さず、それ自体では Kameleoon バックエンドサーバーと対話しません。代わりに、すべての宣言されたデータは flush() メソッドを使用した将来の送信のために保存されます。このアプローチは、データが通常、flush() でトリガーされる単一のサーバーコールにグループ化されるため、サーバーコールの数を削減します。 trackConversion() メソッドも、flush() と同様に、以前に関連付けられたデータを送信します。実験ルールがトリガーされた場合、getVariation() および getVariations() メソッドにも同じことが当てはまります。
ほとんどのデータタイプについて、各訪問者は関連付けられたデータのインスタンスを 1 つしか持てません。ただし、CustomData は例外です。訪問者はインデックスごとに 1 つの関連付けられた CustomData インスタンスを持つことができます。
引数

flush()

  • 📨 Kameleoon にトラッキングデータを送信します
flush() は、訪問者に関連付けられた Kameleoon データを受け取り、まだ送信されていない addData() メソッドを使用して以前に追加されたすべてのデータとともにトラッキングリクエストを送信します。これらのメソッドのいずれかを呼び出す際に(こちらのメソッド で確認できます)。flush() は、サーバーコールが非同期で行われるため非ブロッキングです。 flush() は、訪問者に関連付けられたデータがいつサーバーに送信されるかを制御します。たとえば、addData() が 12 回呼び出される場合、各 addData() 呼び出し後にデータをサーバーに送信するのは非効率です。最後に一度 flush() を呼び出します。 flush() メソッドは、visitorCode を一意の訪問者識別子として使用します。これは クロスデバイス実験 に役立ちます。isUniqueIdentifier 構成パラメータを true に設定すると、SDK は、フラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
引数

getRemoteData()

  • 🔄 非同期リクエストを実行します
このメソッドは以前 retrieveDataFromRemoteSource と呼ばれており、SDK バージョン 4.0.0 で削除されました。
アクティブな siteCodekey 引数(または key が省略された場合はアクティブな visitorCode)に基づいて、リモートの Kameleoon サーバーからデータを取得するためにこのメソッドを使用します。visitorCode および siteCodeKameleoonClientFactory.create() で指定されます。Kameleoon Data API を使用して、データを非常にスケーラブルなリモートサーバーに迅速かつ便利に保存できます。アプリケーションは、このメソッドを使用してデータを取得できます。
サーバーコールが必要なため、このメカニズムは非同期です。したがって、次のいずれかを行ってください。
  • メソッドの引数として completion コールバックを提供し、データが正常に取得されたときに通知を受け取れるようにします。
  • 非同期処理のためにコルーチンを使用します。
引数

getRemoteVisitorData()

  • 🔄 非同期リクエストを実行します
getRemoteVisitorData() は、Kameleoon Data API から訪問者の Kameleoon 訪問データを取得する非同期メソッドです。このメソッドは、他のメソッドがターゲティング決定を行う際に使用するデータをストレージに追加します。 このメソッドで取得したデータは、次のような場合に重要な役割を果たします。
  • 他のデバイスから収集されたデータを使用する場合。
  • 前回の訪問中に収集されたカスタムデータなど、ユーザーの履歴にアクセスする場合。
可能なユースケースの理解を深めるには、この記事 を参照してください。
デフォルトでは、getRemoteVisitorData() は、scope=Visitor で最新に保存されたカスタムデータを自動的に取得し、addData() メソッドを呼び出すことなく訪問者にアタッチします。これは特に 複数のデバイス間でカスタムデータを同期する のに役立ちます。失敗した結果のみを確認することが推奨されます。ただし、必要に応じて、データが訪問者に追加され、ターゲティング目的(またはデバッグ用、ただしデバッグには ロギング を使用する方が良いです)で利用できることを確認できます。さらに、shouldAddData=false パラメータが渡された場合、データを手動で管理できます。
サーバーコールが必要なため、このメカニズムは非同期です。したがって、次のいずれかを行ってください。
  • メソッドの引数として completion コールバックを提供し、データが正常に取得されて訪問者に追加されたときに通知を受け取れるようにします。
  • 非同期処理のためにコルーチンを使用します。
引数
RemoteVisitorDataFilter のパラメータの使用
getRemoteVisitorData() メソッドは、訪問者のデータを取得する際にさまざまなパラメータを定義できる柔軟性を提供します。目標、実験、またはバリエーションに基づいてターゲティングする場合でも、同じアプローチがすべてのデータタイプに適用されます。 たとえば、「注文取引」という目標を完了した訪問者のデータを取得したいとします。getRemoteVisitorData() メソッド内でパラメータを指定して、ターゲティングを絞り込むことができます。例えば、最近の 5 回の訪問で目標に変換したユーザーのみをターゲットにしたい場合は、previousVisitAmount パラメータを 5 に、conversionstrue に設定できます。 この例で示される柔軟性は、目標データに限定されません。getRemoteVisitorData() メソッド内のパラメータを使用して、さまざまな訪問者の行動に関するデータを取得できます。
利用可能な RemoteVisitorDataFilter オプションの一覧は次のとおりです。

getVisitorWarehouseAudience()

  • 🔄 非同期リクエストを実行します
データウェアハウスで訪問者に関連付けられているすべてのオーディエンスデータを取得します。オプションの warehouseKey パラメータは通常、内部のユーザー ID です。customDataIndex パラメータは、Kameleoon が訪問者をターゲットにするために使用する Kameleoon カスタムデータに対応しています。詳細については、ウェアハウスターゲティングドキュメント を参照してください。
サーバーコールが必要なため、このメカニズムは非同期です。したがって、次のいずれかを行ってください。
  • メソッドの引数として completion コールバックを提供し、データが正常に取得されて訪問者に追加されたときに通知を受け取れるようにします。
  • 非同期処理のためにコルーチンを使用します。
失敗した結果のみを確認することが推奨されます。ただし、必要に応じて、データが訪問者に追加され、ターゲティング目的(またはデバッグ用、ただしデバッグには ロギング を使用する方が良いです)で利用できることを確認できます。
引数

setLegalConsent()

訪問者が個人データの使用について法的同意を提供したかどうかを指定するために、このメソッドを使用する必要があります。legalConsent パラメータを false に設定すると、トラッキングリクエストに含めることができるデータタイプが制限されます。このメソッドは、訪問者データを責任を持って管理しながら、法的および規制要件に準拠するのに役立ちます。個人データの詳細については、同意管理ポリシー を参照してください。
引数

データタイプ

このセクションでは、Kameleoon でサポートされている com.Kameleoon.Data 型を一覧表示します。複数の標準データタイプと、カスタムデータタイプを定義するための CustomData タイプが提供されています。

Conversion

ここに保存される Conversion データセットは、それに関連付けられた任意の目標で実験およびパーソナライゼーションレポートをフィルタリングするために使用できます。
  • 各訪問者は複数の Conversion オブジェクトを持つことができます。
  • goalId は Kameleoon アプリで見つけることができます。

Device

Android SDK 4.13.0 以降、Deviceandroid.content.Context に基づいて自動的に検出されます。ただし、必要に応じて手動でオーバーライドすることもできます。
ユーザーのデバイスに関する情報を保存します。

Geolocation

Geolocation には訪問者のジオロケーション詳細が含まれます。
  • 各訪問者は Geolocation を 1 つしか持てません。2 つ目の Geolocation を追加すると、最初のものが上書きされます。

CustomData

Kameleoon アプリまたは Data API で独自のカスタムデータタイプを定義し、SDK から使用します。
  • カスタムデータのインデックスは、Kameleoon アプリの カスタムデータ構成 ページで利用可能です。注意: このインデックスは 0 から始まるため、特定のサイトで作成する最初のカスタムデータのインデックスは 1 ではなく 0 になります。
  • SDK インスタンス構成が最新でない、または名前が登録されていない場合に、名前で作成された CustomData インスタンスを追加すると、データは無視されます。

戻り値型

DataFile

DataFile には SDK 構成の詳細が含まれています。 クライアントが必要とする場合は、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。

FeatureFlag

FeatureFlag は、フィーチャーフラグ自体を定義するプロパティのセットを表します。例えば、その VariationsRules、環境ステータス、その他の関連詳細などです。 クライアントが必要とする場合は、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。

Rule

Rule は、ルール自体を定義するプロパティのセットを表します。例えば、その Variations です。 クライアントが必要とする場合は、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。

Variation

Variation には、訪問者に割り当てられたバリエーション(または特定の割り当てが存在しない場合はデフォルトのバリエーション)に関する情報が含まれています。
  • Variation オブジェクトは、割り当てられたバリエーションとその関連実験に関する詳細を提供し、Variable オブジェクトはバリエーション内の各変数に関する特定の詳細を含みます。
  • id または experimentIdnull である場合(これはデフォルトのバリエーションを示します)をコードで処理することを確認してください。
  • バリエーションに変数が関連付けられていない場合、variables マップは空である可能性があります。

Variable

Variable には、割り当てられたバリエーションに関連付けられた変数に関する情報が含まれています。

非推奨のメソッド

これらのメソッドは非推奨で、SDK バージョン 5.0.0 で削除されます。

getFeatureVariationKey()

  • 📨 Kameleoon にトラッキングデータを送信します
代わりに getVariation() を使用してください。
訪問者のフィーチャーバリエーションキーを取得するには、このメソッドを使用します。このメソッドは、指定されたユーザーのバリエーションキーを取得するために、必須引数として featureKey を受け取ります。 訪問者がこのフィーチャーフラグに以前関連付けられたことがない場合、SDK は(フィーチャーフラグルールに従って)ランダムに割り当てられたバリエーションキーを返します。訪問者がすでにこのフィーチャーフラグに登録されている場合、このメソッドは以前のバリエーションキーを返します。ユーザーがどのルールにも一致しない場合は、お客様のアカウントで定義されているデフォルト値が返されます。 潜在的な例外をキャッチするために、サンプルコードに示されているようにエラー処理を適切に設定してください。

getFeatureVariationKey()

  • 📨 Kameleoon にトラッキングデータを送信します
代わりに getVariation() を使用してください。
訪問者のフィーチャーバリエーションキーを取得するには、このメソッドを使用します。このメソッドは、指定されたユーザーのバリエーションキーを取得するために、必須引数として featureKey を受け取ります。 訪問者がこのフィーチャーフラグに以前関連付けられたことがない場合、SDK は(フィーチャーフラグルールに従って)ランダムに割り当てられたバリエーションキーを返します。訪問者がすでにこのフィーチャーフラグに登録されている場合、このメソッドは以前のバリエーションキーを返します。ユーザーがどのルールにも一致しない場合は、お客様のアカウントで定義されているデフォルト値が返されます。 潜在的な例外をキャッチするために、サンプルコードに示されているようにエラー処理を適切に設定してください。

getActiveFeatures()

  • 代わりに getVariations() を使用してください。
  • 以前は getFeatureListForVisitorCode と呼ばれていました。これは SDK バージョン 4.0.0 リリースで削除されました。
getActiveFeatures メソッドは、訪問者に利用可能なアクティブなフィーチャーフラグに関する情報を取得します。
戻り値

getFeatureVariable()

  • 📨 Kameleoon にトラッキングデータを送信します
代わりに getVariation() を使用してください。
このメソッドは、特定のユーザーのバリエーションキーの変数値を取得します。featureKey および variableKey を必須引数として受け取ります。 訪問者が featureKey に以前関連付けられたことがない場合、SDK は(フィーチャーフラグルールに従って)指定されたバリエーションキーに対してランダムに割り当てられた変数値を返します。訪問者がすでにこのフィーチャーフラグに登録されている場合、このメソッドは以前に登録されたバリエーションの変数値を返します。ユーザーがどのルールにも一致しない場合は、デフォルトの変数値が返されます。 潜在的な例外をキャッチするために、サンプルコードに示されているようにエラー処理を適切に設定してください。
引数
戻り値
スローされる例外

getFeatureVariationVariables()

  • 代わりに getVariation() を使用してください。
  • このメソッドは以前 getFeatureAllVariables と呼ばれており、SDK バージョン 4.0.0 リリースで削除されました。
フィーチャーのすべての変数を取得するには、このメソッドを呼び出します。Kameleoon アプリでフィーチャー変数を変更できます。 このメソッドは 1 つの入力パラメータ: featureKey を受け取ります。Kameleoon アプリで定義されているとおり、Map<String, Object> 型としてデータを返します。リクエストされたフィーチャーが SDK の内部構成で見つからなかった場合、例外 (FeatureNotFound) をスローします。
引数
戻り値
スローされる例外

getFeatureList()

すべてのフィーチャーフラグを反復処理して各々に対して getVariation() を呼び出したい場合は、代わりに getVariations() メソッドを使用してください。
SDK で現在利用可能なフィーチャーフラグキーのリストを返します。
戻り値