開発者ガイド
はじめに
このガイドでは、SDK を統合し、Flutter アプリケーションで実験を実行する方法を説明します。このチュートリアルでは、異なるバリエーションに基づいて推奨商品の数を変更する単純な A/B テストのセットアップについて説明します。Flutter クライアントのインストール
Kameleoon Flutter クライアントをインストールするには、pubspec.yaml ファイルに依存関係を宣言します。
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() メソッドは、複数の機能バリエーションを持つ機能実験の構成を取得します。このメソッドを使用して、必須の引数として visitorCode と featureKey を指定することにより、特定のユーザーのバリエーションキーを取得できます。
機能フラグには、その動作をカスタマイズするために使用される関連変数を持たせることができます。これらの変数を取得するには、ユーザーの variationKey を取得する必要があるため、getFeatureVariationKey() を呼び出した後に getFeatureVariationVariables() メソッドを使用してください。
機能フラグがアクティブかどうかを確認するには、1 つのメソッドのみを使用すれば十分です。機能フラグがオンかオフかを知りたい場合は
isFeatureFlagActive を選択してください。機能の動作を動的に変更するなど、より複雑なシナリオには getFeatureFlagVariables を使用してください。ユーザーをターゲットしたり、レポート内で訪問をフィルター/分解するためのデータポイントの追加
ユーザーをターゲットするには、機能バリエーションを取得したりフラグがアクティブかどうかを確認したりする前に、関連するデータポイントをそのプロフィールに追加していることを確認してください。これらのデータポイントをユーザーのプロフィールに追加するにはaddData() メソッドを使用します。
他のデバイスで収集されたデータポイントを取得する、または過去のユーザーデータ (Kameleoon をハイブリッドモードで使用しているときにクライアントサイドで収集) にアクセスするには、getRemoteVisitorData() メソッドを使用します。このメソッドは、サーバーから非同期にデータを取得します。このデータは、機能フラグの特定のバリエーションへのユーザー割り当てに必要となる可能性があるため、バリエーションを取得したり機能フラグがアクティブかどうかを確認したりする前に getRemoteVisitorData() を呼び出してください。
利用可能なターゲティング条件の詳細については、このトピックの詳細記事を参照してください。
さらに、訪問者プロフィールに追加するデータポイントは、実験を分析する際に利用できるため、デバイスやブラウザなどの要素で結果をフィルタリングおよび分解することができます。保存されたデータを Kameleoon サーバーに送信するには、flush() メソッドを呼び出すことを忘れないでください。
自動的に収集されるもの以外の追加データポイントを追跡する必要がある場合は、Kameleoon の カスタムデータ機能を使用できます。カスタムデータを使用すると、実験に関連する特定の情報をキャプチャして分析できます。収集したデータを分析のために Kameleoon サーバーに送信するには、flush() メソッドを呼び出すのを忘れないでください。
フラグの露出とゴールコンバージョンの追跡
Kameleoon は、次のいずれかのメソッドを呼び出すとすぐに、訪問者のフラグへの露出を自動的に追跡します。getFeatureVariationKey()getFeatureVariable()isFeatureActive()
trackConversion() メソッドを使用し、visitorCode と goalId パラメータを指定する必要があります。
カスタムバケッティングキーの使用
デフォルトでは、Kameleoon は一意の匿名訪問者 ID (visitorCode) を使用して、ユーザーを機能フラグのバリエーションに割り当てます。この ID は通常、ユーザーのデバイス上で生成および保存されます (クライアントサイドおよびサーバーサイド SDK ではブラウザ Cookie に、モバイル SDK では永続ストレージに保存)。ただし、特定のシナリオでは、同じ組織のすべてのユーザーが機能フラグの同じバリアントを見るようにする必要がある場合があります。
カスタムバケッティングキーオプションを使用すると、独自のカスタムバケッティング識別子を提供することで、このデフォルトの動作をオーバーライドできます。このオーバーライドにより、Kameleoon の割り当てロジックがデフォルトの visitorCode ではなく、指定したキーを使用するようになります。
ユースケース
カスタムバケッティングキーの使用は、特に次のような状況において、機能フラグの割り当ての一貫性と正確性を維持するために不可欠です。- アカウントレベルまたは組織レベルの実験: B2B 製品や、同じ組織のすべてのユーザーを同じバリエーションに割り当てたいシナリオでは、
accountIdのような識別子を使用できます。カスタムバケッティングキーは、チームや会社全体に影響を与える機能の A/B テストには不可欠です。
技術的な詳細
機能フラグにカスタムバケッティングキーを設定する際は、アプリケーションのデータから特定の識別子を Kameleoon に提供します。- カスタムキーの提供:
addData()メソッドを使用して、カスタム識別子を Kameleoon SDK に提供します。このメソッドでは、選択したカスタムバケッティングキーをCustomDataオブジェクトとして渡します。ここで、newVisitorCodeは、バケッティングに使用したい識別子 (たとえば、新しいuserIdやaccountId) を指します。
- バケッティングロジック:
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) のタイプのインスタンスでなければなりません。ready が true の場合、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 分後にレポートに表示されます。引数
戻り値
スローされる例外
getVariation()
- 📨 Kameleoon にトラッキングデータを送信します (
trackパラメータによる)
Variation を取得します。
このメソッドは、visitorCode と featureKey を必須の引数として受け取ります。track 引数は任意で、デフォルトは true です。
訪問者に割り当てられた Variation を返します。訪問者が機能フラグルールに関連付けられていない場合、メソッドは指定された機能フラグのデフォルト Variation を返します。
潜在的な例外を管理するための適切なエラーハンドリングをコードに実装してください。
デフォルトバリエーションとは、訪問者が機能フラグの事前定義された配信ルールのいずれにも一致しない場合に割り当てられるバリエーションを指します。言い換えれば、特定のルールでターゲットされていないすべてのユーザーに適用されるフォールバックバリエーションです。これは、管理インターフェースの「その他すべての訪問者に対しては…」セクションのバリエーションとして表されます。
引数
戻り値
スローされる例外
getVariations()
- 📨 Kameleoon にトラッキングデータを送信します (
trackパラメータによる)
Variation オブジェクトのマップを取得します。
このメソッドは、利用可能なすべての機能フラグを反復処理し、指定された訪問者に関連付けられた各フラグに割り当てられた Variation を返します。任意の引数として onlyActive と track を取ります。
onlyActiveがtrueに設定されている場合、getVariations()メソッドは、ユーザーがoffバリエーションにバケッティングされていない限り、機能フラグのバリエーションを返します。trackパラメータは、メソッドがバリエーション割り当てをトラッキングするかどうかを制御します。デフォルトではtrueに設定されています。falseに設定すると、トラッキングは無効化されます。
Variation を値として持ちます。機能フラグにバリエーションが割り当てられていない場合、メソッドはそのフラグのデフォルト Variation を返します。
潜在的な例外を管理するために、適切なエラーハンドリングを実装する必要があります。
デフォルトバリエーションとは、訪問者が機能フラグの事前定義された配信ルールのいずれにも一致しない場合に割り当てられるバリエーションを指します。言い換えれば、特定のルールでターゲットされていないすべてのユーザーに適用されるフォールバックバリエーションです。これは、管理インターフェースの「その他すべての訪問者に対しては…」セクションのバリエーションとして表されます。
引数
戻り値
スローされる例外
getFeatureList()
SDK で現在利用可能な機能フラグキーのリストを返します。戻り値
getDataFile()
現在の SDK 設定をDataFile オブジェクトとして返します。
戻り値
スローされるエラー
setForcedVariation()
このメソッドを使用すると、標準的な評価プロセスをバイパスして、特定のVariation をユーザーにプログラム的に割り当てることができます。これは、通常の評価ロジックが不要、またはスキップする必要がある制御された実験において特に有用です。デバッグやカスタムテストなどのシナリオでも役立ちます。
強制バリエーションが設定されると、Kameleoon のリアルタイム評価ロジックがオーバーライドされます。セグメンテーション、ターゲティング条件、アルゴリズム計算などのプロセスはスキップされます。実験中のセグメンテーションとターゲティング条件を維持するには、代わりに forceTargeting=false を設定してください。
強制バリエーションは、評価されたバリエーションと同様に扱われます。標準的に評価されたバリエーションと同様に分析データに追跡され、ユーザーコンテキストに保存されるため、レポートの一貫性が確保されます。
このメソッドは、特定の条件下 (例: 無効なパラメータ、ユーザーコンテキスト、内部の問題) で例外をスローする可能性があります。アプリケーションが安定して回復力を保つために、適切な例外処理が不可欠です。
引数
スローされるエラー
ほとんどの場合、例で示されているように、基本的なエラー
KameleoonException のみを処理すれば十分です。ただし、異なるタイプのエラーに対して応答が必要な場合は、具体的な要件に基づいてそれぞれを個別に処理してください。さらに、信頼性を高めるために、Exception を含めて一般的な言語エラーを処理することもできます。evaluateAudiences()
- 📨 Kameleoon にトラッキングデータを送信します
evaluateAudiences() は、関連するすべての訪問者データが設定または更新された後、そして機能バリエーションを取得したり機能フラグを確認したりする直前に呼び出す必要があります。このアプローチにより、訪問者が利用可能な最新データに対して評価され、すべての条件に基づいた正確なオーディエンス割り当てが可能になります。
このメソッドを呼び出した後、Audiences Explorer でセグメントパフォーマンスの詳細な分析を実行できます。
スローされるエラー
ほとんどの場合、例で示されているように、基本的なエラー
KameleoonException のみを処理すれば十分です。ただし、異なるタイプのエラーに対して応答が必要な場合は、具体的な要件に基づいてそれぞれを個別に処理してください。さらに、信頼性を高めるために、Exception を含めて一般的な言語エラーを処理することもできます。ゴール
trackConversion()
- 📨 Kameleoon にトラッキングデータを送信します
goalId が必要です。さらに、このメソッドは revenue、metadata、negative 引数も受け取ります。
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() メソッドについても同様です。
引数
例外
flush()
- 📨 Kameleoon にトラッキングデータを送信します
addData() メソッドを介して現在のユーザーに関連付けられたデータは、即座にサーバーに送信されません。これは trackConversion() メソッドによって自動的に送信されるか、flush() メソッドを呼び出すことで手動で送信されるまで保存・蓄積され、データをサーバーにフラッシュするタイミングを正確に制御できます。たとえば、addData() メソッドを 12 回呼び出した場合、各 addData() 呼び出し後にデータをサーバーに送信するのはリソースの浪費になります。最後に 1 回 flush() を呼び出してください。
flush() メソッドは値を返しません。サーバー呼び出しが非同期で行われるため、このメソッドはノンブロッキングです。
スローされる例外
getRemoteData()
このメソッドは以前
retrieveDataFromRemoteSource と呼ばれていましたが、SDK バージョン 3.0.0 のリリースで削除されました。siteCode と key 引数 (または key が省略された場合はアクティブな visitorCode) に基づいて、Kameleoon リモートサーバーからデータを取得します。visitorCode と siteCode は KameleoonClientFactory.create() で指定されます。Kameleoon Data API を使用すると、データを高度にスケーラブルなリモートサーバーに迅速かつ便利に保存できます。その後、アプリケーションはこのメソッドを使用してデータを取得できます。
サーバー呼び出しが必要なため、このメカニズムは非同期であることに注意してください。
引数
戻り値
getRemoteVisitorData()
getRemoteVisitorData() は、Kameleoon Data API から visitorCode の Kameleoon Visits Data を取得するための非同期メソッドです。このメソッドは、他のメソッドがターゲティングの決定を行う際に使用できるよう、データをストレージに追加します。
このメソッドで取得したデータは、次のような場合に重要な役割を果たします。
- 他のデバイスから収集されたデータを使用したい場合。
- 以前の訪問中に収集されたカスタムデータなど、ユーザーの履歴にアクセスしたい場合。
引数
戻り値
スローされる例外
getRemoteVisitorData() でのパラメータの使用
getRemoteVisitorData() メソッドは、訪問者のデータを取得する際にさまざまなパラメータを定義できる柔軟性を提供します。ゴール、実験、バリエーションに基づくターゲティングを行う場合、すべてのデータ型に対して同じアプローチが適用されます。
たとえば、ゴール「Order transaction」を完了した訪問者のデータを取得したい場合を考えます。getRemoteVisitorData() メソッド内でパラメータを指定して、ターゲティングを絞り込むことができます。たとえば、最後の 5 回の訪問でゴールに対してコンバージョンしたユーザーのみをターゲットしたい場合、previousVisitAmount パラメータを 5、conversions を true に設定できます。
この例で示される柔軟性はゴールデータに限られません。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 データセットは、関連付けられている任意のゴールで実験およびパーソナライゼーションレポートをフィルタリングするために使用できます。
CustomData
このデータ型は、モバイル & Web の両方の SDK で利用可能です。
CustomData を使用すると、あらゆる種類のデータを各訪問者に簡単に関連付けることができます。CustomData は、セグメントのターゲティング条件として、または実験レポートのフィルター/分解として使用できます。
カスタムデータについての詳細は、こちらの 記事 を参照してください。
- 各訪問者は、一意の
indexに対して 1 つのCustomDataのみを持つことが許可されています。同じindexで別のCustomDataを追加すると、既存のCustomDataが置き換えられます。 - カスタムデータの
indexは、カスタムデータダッシュボードの「INDEX」列で確認できます。 - プライバシー上の理由から SDK が選択したインデックスのデータを Kameleoon サーバーに送信しないようにするには、カスタムデータの作成時に このデータをターゲティング目的のみでローカルで使用する オプションを有効にしてください。
- SDK インスタンスの設定が最新でない場合や、名前が登録されていない場合に名前で作成された
CustomDataインスタンスを追加すると、データは無視されます。
Device
このデータ型は、モバイル & Web の両方の SDK で利用可能です。
Geolocation
このデータ型は、モバイル & Web の両方の SDK で利用可能です。
Geolocation には、訪問者の地理位置情報の詳細が含まれます。
Browser
このデータ型は Web SDK でのみ利用可能です
Browser データセットは、関連付けられている任意の値で実験およびパーソナライゼーションレポートをフィルタリングするために使用できます。
PageView
このデータ型は Web SDK でのみ利用可能です。
リファラーのインデックス (ID) は、Kameleoon アプリの取得チャネル設定ページで利用可能です。注意: このインデックスは 0 から始まるため、特定のサイトに対して作成する最初の取得チャネルの ID は 1 ではなく 0 になります。
OperatingSystem
このデータ型は Web SDK でのみ利用可能です。
OperatingSystem には、訪問者のデバイス上のオペレーティングシステムに関する情報が含まれます。
Cookie
このデータ型は Web SDK でのみ利用可能です。
Cookie には、訪問者のデバイスに保存された Cookie に関する情報が含まれます。
戻り値の型
DataFile
DataFile には SDK 設定の詳細が含まれます。
クライアントから要求された場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
FeatureFlag
FeatureFlag は、機能フラグ自体を定義する一連のプロパティ — たとえば、その Variations、Rules、環境ステータス、その他関連する詳細 — を表します。
クライアントから要求された場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
Rule
Rule は、ルール自体を定義する一連のプロパティ — たとえば、その Variations — を表します。
クライアントから要求された場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
Variation
Variation には、訪問者に割り当てられたバリエーション (または、特定の割り当てがない場合はデフォルトバリエーション) に関する情報が含まれます。
Variationオブジェクトは割り当てられたバリエーションとその関連実験の詳細を提供する一方、Variableオブジェクトはバリエーション内の各変数に関する具体的な詳細を含みます。- コードが
idまたはexperimentIdがnullとなる可能性に対応していることを確認してください。これはデフォルトバリエーションを示します。 - バリエーションに変数が関連付けられていない場合、
variablesマップが空になる可能性があります。
Variable
Variable には、割り当てられたバリエーションに関連付けられた変数に関する情報が含まれます。
非推奨のメソッド
isReady()
モバイル 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で削除されました。
featureKey と variableKey を必須の引数として受け取ります。
訪問者がこれまで featureKey に関連付けられていない場合、SDK は指定したバリエーションキー (機能フラグルールに従って) に対するランダムに割り当てられた変数値を返します。訪問者がすでにこの機能フラグに登録されている場合、このメソッドは以前に登録されたバリエーションの変数値を返します。ユーザーがどのルールにも一致しない場合、デフォルトの変数値が返されます。
例コードに示されているように、潜在的な例外をキャッチするための適切なエラーハンドリングを設定してください。
引数
戻り値
スローされる例外
getFeatureVariationVariables()
- 代わりに
getVariation()を使用してください。 - このメソッドは以前
getFeatureAllVariablesと呼ばれていましたが、SDK バージョン4.0.0のリリースで削除されました。
featureKey を取ります。Kameleoon アプリで定義された通り、Map<String, Object> 型としてデータを返します。要求された機能が SDK の内部設定で見つからなかった場合は、例外 (FeatureNotFound) をスローします。