Skip to main content
Kameleoon Flutter SDK を使用すると、Flutter アプリケーションフレームワークが対象とするすべてのプラットフォームで実験を実行し、機能フラグを有効化できます。SDK をアプリケーションに統合するのは簡単で、メモリやネットワーク使用量の面でもフットプリントは小さいです。 はじめに: 始め方については、開発者ガイドを参照してください。 変更履歴: Flutter SDK の最新バージョン: 3.7.0 変更履歴 SDK メソッド: Flutter SDK メソッドの完全なリファレンスドキュメントについては、リファレンスセクションを参照してください。

開発者ガイド

はじめに

このガイドでは、SDK を統合し、Flutter アプリケーションで実験を実行する方法を説明します。このチュートリアルでは、異なるバリエーションに基づいて推奨商品の数を変更する単純な A/B テストのセットアップについて説明します。

Flutter クライアントのインストール

Kameleoon Flutter クライアントをインストールするには、pubspec.yaml ファイルに依存関係を宣言します。
release モードでは、JS ライブラリは自動的に読み込まれます。ただし、debug モードでは、(Dart Development Compiler により) JS ライブラリのインポート時に問題が発生する可能性があります。潜在的な問題を回避するため、JS ライブラリを明示的にインポートすることを強く推奨します。 index.html<head> セクションに次のスクリプト行を追加してください。

Kameleoon クライアントの初期化

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

機能フラグの有効化

フラグ構成の取得
コード内に機能フラグを実装するには、まず Kameleoon アカウントで 機能フラグ を作成する必要があります。 特定のユーザーに対して機能フラグがアクティブかどうかを判定するには、その構成を取得する必要があります。getFeatureVariationKey() または isFeatureActive() メソッドを使用して、featureKey に基づいて構成を取得します。 複数のバリエーションやターゲティングオプションを持つより複雑な機能フラグとは対照的に、ON または OFF の状態のみを持つ単純な機能フラグの構成を取得したい場合は、isFeatureActive() メソッドを使用してください。 getFeatureVariationKey() メソッドは、複数の機能バリエーションを持つ機能実験の構成を取得します。このメソッドを使用して、必須の引数として visitorCodefeatureKey を指定することにより、特定のユーザーのバリエーションキーを取得できます。 機能フラグには、その動作をカスタマイズするために使用される関連変数を持たせることができます。これらの変数を取得するには、ユーザーの variationKey を取得する必要があるため、getFeatureVariationKey() を呼び出した後に getFeatureVariationVariables() メソッドを使用してください。
機能フラグがアクティブかどうかを確認するには、1 つのメソッドのみを使用すれば十分です。機能フラグがオンかオフかを知りたい場合は isFeatureFlagActive を選択してください。機能の動作を動的に変更するなど、より複雑なシナリオには getFeatureFlagVariables を使用してください。
ユーザーをターゲットしたり、レポート内で訪問をフィルター/分解するためのデータポイントの追加
ユーザーをターゲットするには、機能バリエーションを取得したりフラグがアクティブかどうかを確認したりする前に、関連するデータポイントをそのプロフィールに追加していることを確認してください。これらのデータポイントをユーザーのプロフィールに追加するには addData() メソッドを使用します。 他のデバイスで収集されたデータポイントを取得する、または過去のユーザーデータ (Kameleoon をハイブリッドモードで使用しているときにクライアントサイドで収集) にアクセスするには、getRemoteVisitorData() メソッドを使用します。このメソッドは、サーバーから非同期にデータを取得します。このデータは、機能フラグの特定のバリエーションへのユーザー割り当てに必要となる可能性があるため、バリエーションを取得したり機能フラグがアクティブかどうかを確認したりする前に getRemoteVisitorData() を呼び出してください。 利用可能なターゲティング条件の詳細については、このトピックの詳細記事を参照してください。 さらに、訪問者プロフィールに追加するデータポイントは、実験を分析する際に利用できるため、デバイスやブラウザなどの要素で結果をフィルタリングおよび分解することができます。保存されたデータを Kameleoon サーバーに送信するには、flush() メソッドを呼び出すことを忘れないでください。 自動的に収集されるもの以外の追加データポイントを追跡する必要がある場合は、Kameleoon の カスタムデータ機能を使用できます。カスタムデータを使用すると、実験に関連する特定の情報をキャプチャして分析できます。収集したデータを分析のために Kameleoon サーバーに送信するには、flush() メソッドを呼び出すのを忘れないでください。
フラグの露出とゴールコンバージョンの追跡
Kameleoon は、次のいずれかのメソッドを呼び出すとすぐに、訪問者のフラグへの露出を自動的に追跡します。
  • getFeatureVariationKey()
  • getFeatureVariable()
  • isFeatureActive()
ユーザーが目的のアクション (たとえば、購入) を完了すると、コンバージョンとしてカウントされます。コンバージョンを追跡するには、trackConversion() メソッドを使用し、visitorCodegoalId パラメータを指定する必要があります。

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

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

ユースケース

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

技術的な詳細

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

技術的要件

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

ターゲティング条件

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

ロギング

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

ログレベル

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

ログのカスタムハンドリング

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

エラーハンドリング

エラーをハンドリングすることは、アプリケーションをより安定させ、技術的な問題を回避するためのベストプラクティスとされています。ほとんどの KameleoonClient メソッドは KameleoonException エラーをスローする可能性があります。 Android クライアント側で SDK のバージョンをパッチするのが難しい場合があるため、その他の致命的なエラーを防ぐために、KameleoonException および Throwable エラータイプをキャッチする try 句で各 SDK メソッドを囲むことを推奨します。 例:

リファレンス

これは Flutter SDK の完全なリファレンスドキュメントです。

初期化

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

create()

SDK を初期化するために、他のどのメソッドよりも先にこのメソッドを呼び出します。このメソッドは KameleoonClientFactory に含まれています。アプリは、このメソッドが作成する KameleoonClient オブジェクトを使用して SDK とのすべてのやり取りを行います。 設定オブジェクトを提供することで、SDK の動作 (たとえば、環境や認証情報など) をカスタマイズできます。それ以外の場合、SDK は設定ファイルを検出して代わりに使用しようとします。
引数
戻り値
スローされる例外

isReadyAsync()

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

runWhenReady()

モバイル SDK の場合、Kameleoon クライアントはすべてのアクティブな機能フラグの現在の構成を取得するためにサーバーコールを実行する必要があるため、すぐには初期化できません。SDK が使用可能になり次第実行されるコールバックを渡すには、KameleoonClient クラスの runWhenReady() メソッドを使用します。タイムアウトも設定できます。 このメソッドの最初の引数として与えられるコールバックは、Function(bool ready) のタイプのインスタンスでなければなりません。readytrue の場合、Kameleoon クライアントは準備完了であり、機能フラグをトリガーしてバリエーションを実装するコードを含む必要があります。それ以外の場合、クライアントが初期化される前に指定されたタイムアウトが発生します。タイムアウトが発生するとユーザーは機能フラグから除外されるため、コールバックにはリファレンスバリエーションを実装するコードを含める必要があります。
引数

機能フラグとバリエーション

isFeatureActive()

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

getVariation()

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

getVariations()

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

getFeatureList()

SDK で現在利用可能な機能フラグキーのリストを返します。
戻り値

getDataFile()

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

setForcedVariation()

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

evaluateAudiences()

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

ゴール

trackConversion()

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

イベント

onUpdateConfiguration()

このメソッドは以前 updateConfigurationHandler と呼ばれていましたが、SDK バージョン 3.0.0 のリリースで削除されました。
onUpdateConfiguration() メソッドを使用すると、構成データが更新されたイベントを処理できます。入力パラメータとして handler を 1 つ取ります。ハンドラーは、リアルタイム構成イベントを使用して構成が更新されたときに呼び出されます。
引数

訪問者データ

getVisitorCode()

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

addData()

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

flush()

  • 📨 Kameleoon にトラッキングデータを送信します
addData() メソッドを介して現在のユーザーに関連付けられたデータは、即座にサーバーに送信されません。これは trackConversion() メソッドによって自動的に送信されるか、flush() メソッドを呼び出すことで手動で送信されるまで保存・蓄積され、データをサーバーにフラッシュするタイミングを正確に制御できます。たとえば、addData() メソッドを 12 回呼び出した場合、各 addData() 呼び出し後にデータをサーバーに送信するのはリソースの浪費になります。最後に 1 回 flush() を呼び出してください。 flush() メソッドは値を返しません。サーバー呼び出しが非同期で行われるため、このメソッドはノンブロッキングです。
スローされる例外

getRemoteData()

このメソッドは以前 retrieveDataFromRemoteSource と呼ばれていましたが、SDK バージョン 3.0.0 のリリースで削除されました。
このメソッドを使用して、アクティブな siteCodekey 引数 (または key が省略された場合はアクティブな visitorCode) に基づいて、Kameleoon リモートサーバーからデータを取得します。visitorCodesiteCodeKameleoonClientFactory.create() で指定されます。Kameleoon Data API を使用すると、データを高度にスケーラブルなリモートサーバーに迅速かつ便利に保存できます。その後、アプリケーションはこのメソッドを使用してデータを取得できます。 サーバー呼び出しが必要なため、このメカニズムは非同期であることに注意してください。
引数
戻り値

getRemoteVisitorData()

getRemoteVisitorData() は、Kameleoon Data API から visitorCode の Kameleoon Visits Data を取得するための非同期メソッドです。このメソッドは、他のメソッドがターゲティングの決定を行う際に使用できるよう、データをストレージに追加します。 このメソッドで取得したデータは、次のような場合に重要な役割を果たします。
  • 他のデバイスから収集されたデータを使用したい場合。
  • 以前の訪問中に収集されたカスタムデータなど、ユーザーの履歴にアクセスしたい場合。
可能なユースケースをより理解するためには、この記事をお読みください。
デフォルトでは、getRemoteVisitorData()scope=Visitor の最新の保存されたカスタムデータを自動的に取得し、addData() を呼び出すことなく訪問者に添付します。これは、複数のデバイス間でのカスタムデータの同期に特に有用です。
引数
戻り値
スローされる例外
getRemoteVisitorData() でのパラメータの使用
getRemoteVisitorData() メソッドは、訪問者のデータを取得する際にさまざまなパラメータを定義できる柔軟性を提供します。ゴール、実験、バリエーションに基づくターゲティングを行う場合、すべてのデータ型に対して同じアプローチが適用されます。 たとえば、ゴール「Order transaction」を完了した訪問者のデータを取得したい場合を考えます。getRemoteVisitorData() メソッド内でパラメータを指定して、ターゲティングを絞り込むことができます。たとえば、最後の 5 回の訪問でゴールに対してコンバージョンしたユーザーのみをターゲットしたい場合、previousVisitAmount パラメータを 5conversionstrue に設定できます。 この例で示される柔軟性はゴールデータに限られません。getRemoteVisitorData() メソッド内のパラメータを使用して、さまざまな訪問者の行動に関するデータを取得できます。
利用可能な RemoteVisitorDataFilter オプションの一覧は次のとおりです。

getVisitorWarehouseAudience()

データウェアハウス内で訪問者に関連付けられたすべてのオーディエンスデータを取得します。任意の warehouseKey パラメータは、通常は内部ユーザー ID です。customDataIndex パラメータは、Kameleoon が訪問者をターゲットするために使用する Kameleoon カスタムデータに対応します。詳細については、ウェアハウスターゲティングドキュメント を参照してください。このメソッドは CustomData オブジェクトとして結果を返し、データが訪問者に追加され、ターゲティングのために利用可能であることを確認します。
サーバー呼び出しが必要なため、このメカニズムは非同期です。
引数
戻り値
スローされる例外

setLegalConsent()

訪問者が個人データの使用に法的同意を提供したかどうかを指定するために、このメソッドを使用する必要があります。consent パラメータを false に設定すると、トラッキングリクエストに含めることができるデータの種類が制限されます。このメソッドは、訪問者データを責任を持って管理しつつ、法律や規制要件に準拠するのに役立ちます。個人データに関する詳細情報は、同意管理ポリシーで確認できます。
引数
スローされる例外
同意取り消し時の動作
これは Flutter Web SDK にのみ適用されます。
setLegalConsent()consent=false で呼び出した場合、SDK は kameleoonVisitorCode Cookie を削除しません。代わりに、Cookie の有効期限の延長を停止し、Cookie が自然に期限切れになるまで保持されるようにします。 コンプライアンス要件によりオプトアウト時に Cookie ファイルの即時削除が必要な場合は、フレームワークのネイティブ Cookie 管理メソッドを使用して手動で削除する必要があります。SDK は自動的にファイルを削除しません。

データ型

このセクションでは、Kameleoon でサポートされる Data 型をリストします。いくつかの標準データ型が提供されているほか、カスタムデータ型を定義するための CustomData 型もあります。

Conversion

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

CustomData

このデータ型は、モバイル & Web の両方の SDK で利用可能です。
CustomData を使用すると、あらゆる種類のデータを各訪問者に簡単に関連付けることができます。CustomData は、セグメントのターゲティング条件として、または実験レポートのフィルター/分解として使用できます。 カスタムデータについての詳細は、こちらの 記事 を参照してください。
  • 各訪問者は、一意の index に対して 1 つの CustomData のみを持つことが許可されています。同じ index で別の CustomData を追加すると、既存の CustomData が置き換えられます。
  • カスタムデータの index は、カスタムデータダッシュボードの「INDEX」列で確認できます。
  • プライバシー上の理由から SDK が選択したインデックスのデータを Kameleoon サーバーに送信しないようにするには、カスタムデータの作成時に このデータをターゲティング目的のみでローカルで使用する オプションを有効にしてください。
  • SDK インスタンスの設定が最新でない場合や、名前が登録されていない場合に名前で作成された CustomData インスタンスを追加すると、データは無視されます。

Device

このデータ型は、モバイル & Web の両方の SDK で利用可能です。
ユーザーのデバイスに関する情報を保存します。

Geolocation

このデータ型は、モバイル & Web の両方の SDK で利用可能です。
Geolocation には、訪問者の地理位置情報の詳細が含まれます。
  • 各訪問者は、Geolocation を 1 つだけ持つことができます。2 つ目の Geolocation を追加すると、最初のものが上書きされます。

Browser

このデータ型は Web SDK でのみ利用可能です
ここに保存される Browser データセットは、関連付けられている任意の値で実験およびパーソナライゼーションレポートをフィルタリングするために使用できます。

PageView

このデータ型は Web SDK でのみ利用可能です。
リファラーのインデックス (ID) は、Kameleoon アプリの取得チャネル設定ページで利用可能です。注意: このインデックスは 0 から始まるため、特定のサイトに対して作成する最初の取得チャネルの ID は 1 ではなく 0 になります。

OperatingSystem

このデータ型は Web SDK でのみ利用可能です。
OperatingSystem には、訪問者のデバイス上のオペレーティングシステムに関する情報が含まれます。
各訪問者は、OperatingSystem を 1 つだけ持つことができます。2 つ目の OperatingSystem を追加すると、最初のものが上書きされます。
このデータ型は Web SDK でのみ利用可能です。
Cookie には、訪問者のデバイスに保存された Cookie に関する情報が含まれます。
各訪問者は、Cookie を 1 つだけ持つことができます。2 つ目の Cookie を追加すると、最初のものが上書きされます。

戻り値の型

DataFile

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

FeatureFlag

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

Rule

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

Variation

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

Variable

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

非推奨のメソッド

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

isReady()

代わりに isReadyAsync() を使用してください。iOS と Android では、isReady() は、SDK が defaultDataFile で初期化されている場合でも、誤った (false) 結果を返す可能性があります。
モバイル SDK の場合、Kameleoon クライアントはアクティブな機能フラグの現在の構成を取得するためにサーバーコールを実行する必要があるため、すぐには初期化できません。機能フラグをトリガーする前にこのメソッドを呼び出して、SDK の準備ができているかどうかを確認するには、isReady() を使用します。 または、コールバックを使用することもできます (詳細は runWhenReady() メソッドを参照してください)。
戻り値

getFeatureVariationKey()

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

getActiveFeatures()

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

getFeatureVariable()

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

getFeatureVariationVariables()

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