Skip to main content
Python SDK を使用すると、バックエンドの Python サーバーで実験を実行し、機能フラグを有効化できます。当社の SDK を Web アプリケーションに統合するのは簡単で、メモリやネットワーク使用量のフットプリントも低く抑えられています。 はじめに: 始め方のヘルプについては、開発者ガイドを参照してください。 変更履歴: Python SDK の最新バージョン: 3.20.0 変更履歴 SDK メソッド: Python SDK の完全なリファレンスドキュメントについては、リファレンスセクションを参照してください。

開発者ガイド

このガイドは、当社の SDK を数分で統合し、Python アプリケーションで実験を開始できるように設計されています。このチュートリアルでは、異なるバリエーションに基づいて推奨商品の数を変更するシンプルな A/B テストの設定について説明します。

はじめに

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

SDK は Python pip パッケージを使用してインストールできます。当社のパッケージは公式の pip リポジトリでホストされているため、次のコマンドを実行するだけです。

追加の設定

Python SDK の認証情報は構成ファイルを介して提供する必要があり、これを使用して SDK の動作をカスタマイズすることもできます。サンプル構成ファイルはこちらから入手できます。このファイルはデフォルトのパス /etc/kameleoon/client-python.yaml にインストールすることを推奨しますが、別の場所に配置して、KameleoonClient() コンストラクタメソッドの引数としてパスを渡すこともできます。現在のバージョンの Python SDK で利用可能なキーは次のとおりです。 あるいは、初期化時にパラメータとして KameleoonClientConfig 型の configuration_object を使用することもできます。これは構成ファイルと同じ引数のリストを持ちます。configuration_object は構成ファイルよりも優先され、その設定を上書きします。

Kameleoon クライアントの初期化

アプリケーションに SDK をインストールし、正しい認証情報を設定し (/etc/kameleoon/client-python.yaml 内)、Kameleoon のバックオフィスでサーバーサイド実験をセットアップしたら、次のステップはアプリケーションコード内で Kameleoon クライアントを作成することです。 右側のコードはわかりやすい例を示しています。KameleoonClient はシングルトンオブジェクトで、アプリケーションと Kameleoon プラットフォームの間のブリッジとして機能します。実験を実行するために必要なすべてのメソッドとプロパティが含まれています。
開発者は、Kameleoon で A/B テストを実装する際にアプリケーションコードの正しいロジックを保証する責任を負います。ベストプラクティスは、訪問者が実験から除外される可能性があると常に想定することです (実験がまだ開始されていない場合)。このプラクティスは実装が簡単で、常に存在すべきデフォルトまたはリファレンスバリエーションのロジックと一致します。次のセクションのコードサンプルは、このアプローチを示しています。

機能フラグの有効化

ユーザーに一意の ID を割り当てる
ユーザーに一意の ID を割り当てるには、get_visitor_code() メソッドを使用できます。訪問者コードが (リクエストヘッダーのクッキーから) 存在しない場合、メソッドはランダムな一意の ID を生成するか、または生成した default_visitor_code を使用します。ID はその後、レスポンスヘッダーのクッキーに設定されます。 Kameleoon をハイブリッドモードで使用している場合、get_visitor_code() メソッドを呼び出すことで、一意の ID (訪問者コード) がアプリケーションファイル engine.js (以前は kameleoon.js という名前) と SDK の間で共有されることが保証されます。
フラグ構成の取得
コード内に機能フラグを実装するには、まず Kameleoon アカウントで機能フラグを作成する必要があります。 特定のユーザーに対する機能フラグのステータスまたはバリエーションを判定するには、get_variation() または is_feature_active() メソッドを使用して、feature_key に基づいて構成を取得する必要があります。 get_variation() メソッドは、ON/OFF 状態を持つシンプルな機能フラグと、複数のバリエーションを持つより複雑なフラグの両方を処理します。このメソッドは、機能ルールを確認し、バリエーションを割り当て、feature_keyvisitor_code に基づいてバリエーションを返すことで、ユーザーに適切なバリエーションを取得します。 is_feature_active() メソッドは、複数のバリエーションやターゲティングオプションを持つより複雑な機能フラグではなく、ON または OFF 状態のみを持つシンプルな機能フラグの構成を取得したい場合に使用できます。 機能フラグに関連付けられた変数 (各バリエーションに固有の動作など) がある場合、get_variation() を使用すると Variation オブジェクトにアクセスでき、割り当てられたバリエーションとそれに関連する実験の詳細を取得できます。このメソッドは、ユーザーがターゲットになっているかをチェックし、訪問者の割り当てバリエーションを見つけてストレージに保存します。track=True の場合、SDK は次のトラッキングリクエストで指定された実験に露出イベントを送信します。これは SDK の tracking_interval_millisecond に基づいて自動的にトリガーされます。デフォルトでは、この間隔は 1000 ミリ秒 (1 秒) に設定されています。 get_variation() メソッドでは、トラッキングを行うかどうかを制御できます。track=False の場合、SDK は露出イベントを送信しません。これは、SDK 経由のデータトラッキングではなく、たとえば Kameleoon エンジンによって管理されるクライアントサイドのトラッキングに依存することを好む場合に便利です。さらに、track=False の設定は、get_variations() メソッドを使用する場合に役立ちます。この場合、トラッキングイベントをトリガーせずに、すべてのフラグのバリエーションのみが必要かもしれません。トラッキングがどのように動作するかについてさらに詳しく知りたい場合は、この記事を参照してください。
レポートでユーザーをターゲットしたり、訪問をフィルタ/分解するためのデータポイントの追加
ユーザーをターゲットにするには、機能バリエーションを取得したりフラグがアクティブかをチェックする前に、プロファイルに関連するデータポイントを追加してください。これらのデータポイントをユーザーのプロファイルに追加するには、add_data() メソッドを使用します。 他のデバイスで収集されたデータポイントを取得したり、過去のユーザーデータ (Kameleoon をハイブリッドモードで使用する際にクライアントサイドで収集) にアクセスしたりするには、get_remote_visitor_data() メソッドを使用します。このメソッドは、サーバーからデータを非同期的に取得します。このデータは特定のバリエーションへのユーザーの割り当てに必要な可能性があるため、バリエーションを取得したり機能フラグがアクティブかをチェックしたりする前に get_remote_visitor_data() を呼び出すことが重要です。 利用可能なターゲティング条件についての詳細は、こちらの詳細記事を参照してください。 さらに、訪問者プロファイルに追加したデータポイントは、実験を分析する際に使用でき、デバイスやブラウザなどの要因で結果をフィルタリングおよび分解できます。Kameleoon ハイブリッドモードは、クライアントサイドで様々なデータポイントを自動的に収集するため、これらの事前収集されたデータポイントに基づいて簡単に結果を分解できます。完全なリストはこちらをご覧ください。 自動的に収集されるもの以外に追跡したい追加のデータポイントがある場合は、Kameleoon のカスタムデータ機能を使用できます。カスタムデータを使用すると、実験に関連する特定の情報をキャプチャして分析できます。収集したデータを分析のために Kameleoon サーバーに送信するには、flush() メソッドを呼び出すことを忘れないでください。
結果を正確にするためには、UserAgent データタイプを使用してボットをフィルタリングすることをお勧めします。
ゴールコンバージョンのトラッキング
ユーザーが目的のアクションを完了した場合 (購入を行うなど)、それはコンバージョンとして記録されます。コンバージョンをトラッキングするには、track_conversion() メソッドを使用し、必須の visitor_code および goal_id パラメータを指定します。 コンバージョントラッキングリクエストは、SDK が一定間隔 (tracking_interval_millisecond で定義) で送信する次のスケジュールされたトラッキングリクエストと共に送信されます。リクエストを即座に送信したい場合は、instant=True のパラメータを指定して flush() メソッドを使用してください。
分析ソリューションへのイベント送信
コンバージョンをトラッキングし、露出イベントを顧客分析ソリューションに送信するには、まず Kameleoon をハイブリッドモードで実装する必要があります。次に、get_engine_tracking_code() メソッドを使用します。 get_engine_tracking_code() メソッドは、分析ソリューションに露出イベントを送信するために必要な一意のトラッキングコードを取得します。このメソッドを使用すると、イベントを記録し、希望する分析プラットフォームに送信できます。

Django 環境での Kameleoon Python SDK の使用

Django を使用する場合は、Django アプリケーションの apps.py ファイル内でサーバー起動時に Kameleoon クライアントを初期化することをお勧めします。 python manage.py runserver を使用すると、Django は 2 つのプロセスを起動します。1 つは実際の開発サーバー用で、もう 1 つはコードが変更された際にアプリケーションをリロードするためです。 リロードオプションなしでサーバーを起動することもでき、その場合 1 つのプロセスのみが実行されているのが確認できます。プロセスは 1 回のみ実行されます。 python manage.py runserver --noreload ready() メソッド内で RUN_MAIN 環境変数をチェックすることもできます。
これは、python manage.py runserver を使用するローカル開発時にのみ適用されます。本番環境では、ready() 関数内のコードは、アプリケーションが初期化される際に 1 回のみ実行されます。
その後、アプリケーション内で Kameleoon クライアントにアクセスできます。
Django を使用するもう 1 つの利点は、SDK が HTTP リクエスト/レスポンスのクッキーを介して visitor_code を自動的に読み書きすることです。クッキーメカニズムを使用して visitor_code を永続化したい Web 環境で別のフレームワークを使用している場合は、read_cookies() および write_cookies() メソッドの実装を提供する必要があります。

クロスデバイス実験

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

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

カスタムマッピング同期はデバイス間で訪問者データを揃えるために使用されますが、必ずしも必要というわけではありません。以下は、カスタムマッピング同期が必要ない 2 つのシナリオです。 デバイス間で同じユーザー ID すべてのデバイスで同じユーザー ID が一貫して使用されている場合、同期はカスタムマッピング同期なしで自動的に処理されます。複数のデバイス間で収集されたデータを同期したい場合は、get_remote_visitor_data() メソッドを呼び出すだけで十分です。 一貫した ID を持つマルチサーバーインスタンス 複数のサーバー (たとえば、分散型サーバーインスタンス) を含む複雑なセットアップで、同じユーザー ID がサーバー間で利用可能な場合、サーバー間の同期 (get_remote_visitor_data() を使用) で十分であり、追加のカスタムマッピング同期は必要ありません。 追加のデータが必要な顧客は、詳細なガイダンスのために get_remote_visitor_data() メソッドの説明を参照してください。以下のコードでは、正確なデータ取得のために、同じ一意の識別子 (この場合は visitor_codeuserId とも呼ばれる可能性があります) が 2 つのデバイス間で一貫して使用されていることを前提としています。
収集したデータをリアルタイムで同期したい場合は、カスタムデータに対してスコープを Visitor に選択する必要があります。
Device A
Device B

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

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

カスタムバケットキーの使用

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

ユースケース

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

技術詳細

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

技術要件

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

ターゲティング条件

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

ロギング

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

ログレベル

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

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

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

リファレンス

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

create()

SDK の使用を開始するには、初期化を完了する必要があります。SDK とのすべてのやり取りは Kameleoon::KameleoonClient というオブジェクトを介して完了するため、最初にすべきことはこのオブジェクトを作成することです。
引数
スローされる例外

wait_init_async()

wait_init_async は Kameleoon クライアントの初期化を非同期で待機します。このメソッドを使用すると、他の操作を進める前に、クライアントが正常に初期化されたかを確認できます。
戻り値

wait_init()

wait_init は Kameleoon クライアントの初期化を同期で待機します。このメソッドを使用すると、他の操作を進める前に、クライアントが正常に初期化されたかを確認できます。
戻り値

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

is_feature_active()

  • 📨 トラッキングデータを Kameleoon に送信します (track パラメータに依存)
以前は activate_feature と呼ばれていました。SDK バージョン 2.1.0 以降非推奨であり、今後のリリースで削除されます。
訪問者に対して機能フラグがアクティブかどうかを確認するには、is_feature_active() メソッドを呼び出します。 このメソッドは、指定したユーザーに対して機能がアクティブになるかを確認するために、visitor_code および feature_key を必須引数として受け取ります。 そのようなユーザーがこの機能フラグに関連付けられたことがない場合、SDK はランダムにブール値を返します (機能がユーザーに対してアクティブになる場合は true、そうでない場合は false)。指定された visitor_code を持つユーザーが既にこの機能フラグに登録されている場合、以前の機能フラグの値を検出します。 右側の例に示すように、潜在的な例外をキャッチするために、コードに適切なエラー処理が設定されていることを確認する必要があります。 visitor_code を指定すると、is_feature_active() メソッドは visitor_code を一意の訪問者識別子として使用します。これはクロスデバイス実験に便利です。visitor_code を指定して is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
パラメータ is_unique_identifier は非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
Kameleoon は、is_feature_active()get_variation()get_variations() などの特定のメソッドを呼び出す際にセッションと訪問者をカウントするためにトラッキングを使用します。訪問者をバリエーションに公開してカウントする必要がある場合は、track パラメータにデフォルトの True 値を使用します。訪問者を公開する前にこれらのメソッドを呼び出す場合のみ、track パラメータを False に設定してください。たとえば、訪問者を公開する前にすべてのバリエーションを取得するために get_variations() を呼び出す場合は、track パラメータを False に設定します。この設定により、Kameleoon がセッションを早期にカウントすることを防ぎます。その後、訪問者を明示的に公開するときにトラッキングをトリガーできます。Kameleoon はデフォルトでトラッキングデータを毎秒送信します。トラッキング間隔の構成オプションを使用して、この間隔を最大 5 秒まで構成できます。Kameleoon は、イベント間の間隔が 30 分未満である限り、トラッキングイベントを 1 つのセッションにグループ化します。トラッキングイベント間で 30 分以上経過すると、Kameleoon はイベントを別のセッションとしてカウントします。セッションの最後に記録されたイベントから 30 分後にレポートに訪問が表示されます。
is_feature_active() メソッドは、マスターフラグの状態ではなく、提供されたバリアントを評価します。ルールを除外する場合、メソッドはそれ以外のすべての人に対しては、〇〇を提供するデフォルトの状態を使用します。このデフォルトの状態に対して Off を選択する場合、マスター機能フラグが On であっても、メソッドは常に false を返します。
引数
戻り値
スローされる例外

get_variation()

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

get_variations()

  • 📨 トラッキングデータを Kameleoon に送信します (track パラメータに依存)
すべての機能フラグにわたって指定された訪問者に割り当てられた Variation オブジェクトのマップを取得します。 このメソッドは利用可能なすべての機能フラグを反復処理し、指定された訪問者に関連付けられた各フラグに割り当てられた Variation を返します。visitor_code を必須引数として受け取り、only_activetrack はオプションです。
  • only_activeTrue に設定されている場合、get_variations() メソッドは、ユーザーが off バリエーションにバケットされていないことを条件に、機能フラグのバリエーションを返します。
  • track パラメータは、メソッドがバリエーションの割り当てをトラッキングするかどうかを制御します。デフォルトでは True に設定されています。False に設定されている場合、トラッキングは無効になります。
返されるマップは、キーとして機能フラグキー、値として対応する Variation で構成されます。機能フラグにバリエーションが割り当てられていない場合、メソッドはそのフラグのデフォルト Variation を返します。 潜在的な例外を管理するために適切なエラー処理を実装する必要があります。
デフォルトバリエーションは、訪問者が機能フラグの事前定義された配信ルールに一致しない場合に割り当てられるバリエーションを指します。つまり、特定のルールでターゲットされていないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェースでは「それ以外のすべての人に対しては…」セクションのバリエーションとして表示されます。
引数
戻り値
スローされる例外

get_data_file()

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

set_forced_variation()

このメソッドを使用すると、標準の評価プロセスをバイパスして、特定の Variation をユーザーにプログラム的に割り当てることができます。これは特に、通常の評価ロジックが不要またはスキップする必要がある制御された実験で価値があります。また、デバッグやカスタムテストなどのシナリオでも役立ちます。 強制バリエーションが設定されると、Kameleoon のリアルタイム評価ロジックを上書きします。セグメンテーション、ターゲティング条件、アルゴリズム計算などのプロセスはスキップされます。実験中にセグメンテーションとターゲティング条件を保持するには、代わりに force_targeting=False を設定します。
シミュレートされたバリエーションは、実行順序で常に優先されます。シミュレートされたバリエーションの計算がトリガーされた場合、最初に完全に処理されて完了します。
強制バリエーションは、評価されたバリエーションと同様に扱われます。分析でトラッキングされ、ユーザーコンテキストに保存され、標準の評価されたバリエーションと同様に、レポーティングの一貫性が保たれます。 このメソッドは、特定の条件下で例外をスローする場合があります (たとえば、無効なパラメータ、ユーザーコンテキスト、または内部の問題)。適切な例外処理は、アプリケーションが安定し、堅牢であることを保証するために不可欠です。
強制バリエーションと シミュレートされた バリエーションを区別することが重要です:
  • 強制バリエーション: 個々の実験に固有です。
  • シミュレートされたバリエーション: 全体的な機能フラグの結果に影響します。
引数
スローされる例外
ほとんどの場合、例で示されているように、基本的なエラーである KameleoonError のみを処理すればよいです。ただし、異なる種類のエラーに対応する必要がある場合は、それぞれを特定の要件に基づいて個別に処理してください。さらに、信頼性を高めるために、Exception を含めることで一般的な言語エラーも処理できます。

evaluate_audiences()

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

訪問者データ

get_visitor_code()

このメソッドは以前 obtain_visitor_code と呼ばれていました。これは SDK バージョン 3.0.0 で削除されました。
get_visitor_code() ヘルパーメソッドは、現在の訪問者の Kameleoon visitor_code を取得するために呼び出すべきです。このメソッドは、Kameleoon をフロントエンドとバックエンドの混合環境で使用する際に特に重要であり、ユーザー識別の一貫性を保証する必要があります。実装ロジックは以下のように記述されています。
  1. 最初に、現在の HTTP リクエストに関連する kameleoonVisitorCode クッキーまたはクエリパラメータが見つかるかをチェックします。見つかった場合、これを訪問者識別子として使用します。
  2. 現在のリクエストでクッキー/パラメータが見つからない場合、新しい識別子をランダムに生成するか、渡された場合は default_visitor_code 引数を識別子として使用します。これにより、顧客が独自の識別子を訪問者コードとして使用することができ、マッチングテーブルでの追加検索なしに、Kameleoon 訪問者と独自のユーザーをマッチさせるという追加の利点があります。
  3. いずれの場合も、サーバーサイド (HTTP ヘッダー経由) で kameleoonVisitorCode クッキーに値が設定されます。その後、この識別子の値が最終的にメソッドによって返されます。
独自の visitor_code を提供する場合は、その一意性を保証する必要があります。SDK は引数として渡される値を検証しません。また、visitor_code の長さは 255 文字に制限されていることに注意してください。この制限を超えると VisitorCodeInvalid 例外が発生します。
get_visitor_code() メソッドを使用すると、訪問者にシミュレートされたバリエーションを設定できます。クッキー (リクエストまたはドキュメントから) にキー kameleoonSimulationFFData が含まれている場合、標準の評価プロセスはバイパスされます。代わりに、メソッドは提供されたデータに基づいて直接 Variation を返します。シミュレーションは 2 つの方法で適用できます。
  • 自動的に (推奨): Kameleoon Web Experimentation または SDK を ハイブリッドモード で使用している場合、シミュレーションパネル を使用してバリアントの表示をシミュレートする際に、クッキーが自動的に作成されます。
  • 手動で: kameleoonSimulationFFData クッキーを手動で設定します。
シミュレートされたバリエーションと 強制 バリエーションを区別することが重要です:
  • シミュレートされたバリエーション: 全体的な機能フラグの結果に影響します。
  • 強制バリエーション: 個々の実験に固有です。
⚙️ 手動セットアップkameleoonSimulationFFData クッキーが次の形式に従っていることを確認してください。
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: 指定された featureKey に対して、実験 expId のバリエーション varId をシミュレートします。
  • kameleoonSimulationFFData={"featureKey":{"expId":0}}: 指定された featureKey に対して、デフォルトバリエーション (それ以外のすべての人に対しては、本番環境で〇〇を提供するセクションで定義) をシミュレートします。
⚠️ 適切な機能を確保するために、クッキー値は encodeURIComponent などのメソッドを使用して URI コンポーネントとしてエンコードする必要があります。
引数
戻り値
スローされる例外

add_data()

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

flush()

  • 📨 トラッキングデータを Kameleoon に送信します
flush() は訪問者に関連付けられた Kameleoon データと、これらのメソッドのいずれかを呼び出したときにまだ送信されていない、以前に add_data メソッドを使用して追加されたすべてのデータを取得し、トラッキングリクエストを送信します。flush() は非ブロッキングであり、サーバー呼び出しは非同期で行われます。 flush() を使用すると、指定された visitor_code に関連付けられたデータがサーバーに送信されるタイミングを制御できます。たとえば、add_data() を 12 回呼び出す場合、add_data() が呼び出されるたびにサーバーにデータを送信するのは非効率なので、最後に flush() を 1 回だけ呼び出せばよいのです。 visitor_code を指定すると、flush() メソッドはそれを一意の訪問者識別子として使用します。これはクロスデバイス実験に便利です。visitor_code を指定して is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
パラメータ is_unique_identifier は非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
引数

get_remote_data()

  • 以前は retrieve_data_from_remote_source と呼ばれていました。これは SDK バージョン 3.0.0 で削除されました。
  • データを非同期で取得したい場合は、代わりに get_remote_data_async メソッドを使用してください (バージョン 2.3.0 以降で利用可能)。
get_remote_data メソッドは、リモート Kameleoon サーバーに保存されている指定された site_code (KameleoonClient.__init__ で指定) に対して、引数として渡された キー に従って、データを同期的に取得します。データは通常、当社の Data API を介してリモートサーバーに保存されます。このメソッドと、この目的のための高スケーラブルなサーバーの可用性が、訪問者/ユーザーごとに取得できる大量のデータを保存するための便利な方法を提供します。
引数
戻り値

get_remote_data_async()

get_remote_data_async メソッドを使用すると、リモート Kameleoon サーバーに保存されている指定された site_code (KameleoonClient.__init__ で指定) に対して、引数として渡された キー に従って、データを非同期で取得できます。データは通常、当社の Data API を介してリモートサーバーに保存されます。このメソッドと、この目的のための高スケーラブルなサーバーの可用性が、訪問者/ユーザーごとに取得できる大量のデータを保存するための便利な方法を提供します。
引数
戻り値

get_remote_visitor_data()

get_remote_visitor_data() は、Kameleoon Data API から visitor_code の Kameleoon Visits Data を取得する非同期メソッドです。このメソッドはデータをストレージに追加し、ターゲティングの決定を行う際に他のメソッドが使用できるようにします。 このメソッドで取得したデータは、次のような場合に重要な役割を果たします。
  • 他のデバイスから収集されたデータを使用する場合。
  • ユーザーの履歴 (過去の訪問中に閲覧したページなど) にアクセスする場合。
  • データレイヤー変数やフロントエンドでのみコンバージョンするゴールなど、クライアントサイドでのみアクセス可能なデータを使用する場合。
可能なユースケースをよりよく理解するには、この記事を読んでください。
デフォルトでは、get_remote_visitor_data()scope=visitor の最新の保存済みカスタムデータを自動的に取得し、add_data() メソッドを呼び出すことなく訪問者に追加します。これは複数のデバイス間でカスタムデータを同期する場合に特に便利です。
パラメータ is_unique_identifier は非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
引数
get_remote_visitor_data() でのパラメータの使用
get_remote_visitor_data() メソッドは、訪問者に関するデータを取得する際にさまざまなパラメータを定義できるという柔軟性を提供します。ゴール、実験、またはバリエーションに基づいてターゲットを設定する場合でも、同じアプローチがすべてのデータタイプに適用されます。 たとえば、「Order transaction」というゴールを完了した訪問者のデータを取得したいとします。get_remote_visitor_data() メソッド内でパラメータを指定して、ターゲティングを絞り込むことができます。たとえば、過去 5 回の訪問でゴールを達成したユーザーのみをターゲットにしたい場合は、previous_visit_amount パラメータを 5 に、conversions を true に設定できます。 この例で示されている柔軟性は、ゴールデータに限定されていません。get_remote_visitor_data() メソッド内でパラメータを使用して、さまざまな訪問者の行動に関するデータを取得できます。
戻り値
利用可能な Kameleoon::Configuration::RemoteVisitorDataFilter オプションのリストは次のとおりです。

get_remote_visitor_data_async()

get_remote_visitor_data_async メソッドは、リモート Kameleoon サーバーに保存されている訪問者 (visitor_code 引数で指定) のカスタムデータを非同期で取得します。add_dataTrue の場合、このメソッドは取得したデータを訪問者に自動的に追加し、別途 add_data を呼び出す必要はありません。 以前に当社のリモートサーバーに保存されたデータが必要です。これは、SDK の次のトラッキング呼び出しのいずれかで追加できます。
  • flush
  • get_feature_variation_key
  • get_feature_variable
  • is_feature_active
get_remote_visitor_data メソッドを当社の高スケーラブルなサーバーの可用性と一緒に使用すると、訪問者のすべてのデバイス間で大量のデータにアクセスして同期する便利な方法が提供されます。 visitor_code を指定すると、get_remote_visitor_data_async メソッドは visitor_code を一意の訪問者識別子として使用します。これはクロスデバイス実験に便利です。visitor_code を指定して is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
パラメータ is_unique_identifier は非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
引数
戻り値
get_remote_visitor_data_async() でのパラメータの使用
get_remote_visitor_data_async() メソッドは、訪問者に関するデータを取得する際にさまざまなパラメータを定義できるという柔軟性を提供します。ゴール、実験、またはバリエーションに基づいてターゲットを設定する場合でも、同じアプローチがすべてのデータタイプに適用されます。 たとえば、「Order transaction」というゴールを完了した訪問者のデータを取得したいとします。get_remote_visitor_data_async() メソッド内でパラメータを指定して、ターゲティングを絞り込むことができます。たとえば、過去 5 回の訪問でゴールを達成したユーザーのみをターゲットにしたい場合は、previous_visit_amount パラメータを 5 に、conversions を true に設定できます。 この例で示されている柔軟性は、ゴールデータに限定されていません。get_remote_visitor_data_async() メソッド内でパラメータを使用して、さまざまな訪問者の行動に関するデータを取得できます。
利用可能な Kameleoon::Configuration::RemoteVisitorDataFilter オプションのリストは次のとおりです。

get_visitor_warehouse_audience()

指定された visitor_code および warehouse_key を使用して、データウェアハウス内の訪問者に関連付けられたすべてのオーディエンスデータを同期的に取得します。warehouse_key は通常、内部ユーザー ID です。custom_data_index パラメータは、Kameleoon が訪問者をターゲットにするために使用する Kameleoon カスタムデータに対応します。追加の詳細については、ウェアハウスターゲティングドキュメントを参照してください。メソッドは CustomData オブジェクトを返し、データが訪問者に追加され、ターゲティング目的で利用可能であることを確認します。
データを非同期で取得したい場合は、代わりに get_visitor_warehouse_audience_async メソッドを使用してください。
引数
戻り値
スローされる例外

get_visitor_warehouse_audience_async()

指定された visitor_code および warehouse_key を使用して、データウェアハウス内の訪問者に関連付けられたすべてのオーディエンスデータを非同期で取得します。warehouse_key は通常、内部ユーザー ID です。custom_data_index パラメータは、Kameleoon が訪問者をターゲットにするために使用する Kameleoon カスタムデータに対応します。追加の詳細については、ウェアハウスターゲティングドキュメントを参照してください。メソッドは CustomData オブジェクトを返し、データが訪問者に追加され、ターゲティング目的で利用可能であることを確認します。
引数
戻り値
スローされる例外
このメソッドを使用して、訪問者が個人データの使用に法的同意を与えているかを指定する必要があります。consent パラメータを False に設定すると、トラッキングリクエストに含めることができるデータタイプが制限されます。このメソッドは、訪問者データを責任を持って管理しながら法的および規制要件を遵守するのに役立ちます。個人データに関する詳細は、同意管理ポリシーを参照してください。
同意の取り消し動作
consent=Falseset_legal_consent() を呼び出した場合、SDK は kameleoonVisitorCode クッキーを削除しません。代わりに、クッキーの有効期限を延長することを停止し、クッキーが自然に期限切れになるまで保持されます。 コンプライアンス要件でオプトアウト時にクッキーファイルを即座に削除する必要がある場合は、フレームワークのネイティブクッキー管理メソッドを使用して手動で削除する必要があります。SDK はファイルを自動的に削除しません。
引数
スローされる例外

forget()

forget メソッドは、指定された site_code を持つ KameleoonClient インスタンスを KameleoonClientFactory から削除し、KameleoonClient インスタンスが使用するリソースを解放します。forget メソッドを呼び出した後は、KameleoonClient インスタンスを使用してはなりません。 visitor_code を指定すると、track_conversion メソッドは visitor_code を一意の訪問者識別子として使用します。これはクロスデバイス実験に便利です。visitor_code を指定して is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
is_unique_identifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
引数

ゴールとサードパーティ分析

get_engine_tracking_code()

Kameleoon は、Mixpanel、Google Analytics 4、Segment などのいくつかの分析ソリューションと統合されています。サーバーサイド実験を正しくトラッキングするには、訪問者が実験をトリガーした後に get_engine_tracking_code() メソッドを呼び出します。SDK は、過去 5 秒間に訪問者がトリガーした実験の JavaScript キューコマンドを返します。このコードをページに挿入すると、Engine.js はコマンドを処理し、アクティブな分析統合を介して露出イベントを送信します。 このメソッドの実装に関する詳細については、ハイブリッド実験を参照してください。
  • この機能を使用するには、Python SDK と Kameleoon Engine.js の両方を実装します。Engine.js はこのフローでトラッキングにのみ使用されるため、閉じる </body> タグの前に非同期タグをインストールできます。
  • Kameleoon で実験のみをトラッキングし、サードパーティの分析ツールに露出イベントを送信する必要がない場合は、JavaScript / TypeScript SDK を使用します。このオプションは、サーバーレスエッジコンピューティングプラットフォームに適しています。JavaScript / TypeScript SDK は、対応する実験割り当てを window.kameleoonQueue に追加する限り、getVisitorCode を呼び出すとバリエーションを自動的にトラッキングします。
  • 返されたトラッキングコードを HTML の <script> タグに直接挿入できます。
この例では、123456 および 234567 は実験 ID、7890 および 8901 はバリエーション ID です。実装では、SDK は返されたトラッキングコード内でこれらの値を生成します。
引数
戻り値

track_conversion()

  • 📨 トラッキングデータを Kameleoon に送信します
このメソッドを使用して、特定のゴールとユーザーのコンバージョンをトラッキングします。このメソッドには visitor_codegoal_id が必要です。さらに、このメソッドはオプションの revenuenegativemetadata 引数も受け取ります。visitor_code は通常、実験をトリガーする際に使用されたものと同じです。 track_conversion() メソッドは値を返しません。サーバー呼び出しは非同期で行われるため、このメソッドは非ブロッキングです。
パラメータ is_unique_identifier は非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
引数
メタデータ値は、生データのエクスポートおよび結果ページからアクセスできます。metadata パラメータが提供されている場合、Kameleoon はこれらの指定された値を現在のコンバージョンに使用し、以前 add_data() メソッドを使用して収集された値を使用しません。パラメータが省略された場合、Kameleoon はコンバージョンの前および同じ訪問内でそれらの CustomData に対してトラッキングされた最後の値を使用します。Kameleoon は、track_conversion() メソッドにパラメータとして明示的に渡されたメタデータ値のみを考慮します。以下の例では、Kameleoon はパラメータとして明示的に提供されたカスタムデータ値 (ここではインデックス 5 と値「Amex Credit Card」) にのみコンバージョンを関連付けます。
例外

イベント

on_update_configuration()

on_update_configuration() メソッドを使用すると、構成がデータを更新したイベントを処理できます。入力パラメータとして handler を 1 つ受け取ります。リアルタイム構成イベントを使用して構成が更新されたときに呼び出されるハンドラです。
引数

データタイプ

Browser

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

PageView

リファラーのインデックス (ID) は、バックオフィスの Acquisition channel 構成ページで確認できます。注意: このインデックスは 0 から始まるため、特定のサイトに対して作成した最初のアクイジションチャネルの ID は 1 ではなく 0 になります。

Conversion

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

CustomData

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

Device

UserAgent

訪問者のユーザーエージェントに関する情報を保存します。サーバーサイド実験は、クライアントサイド実験よりもボットトラフィックに脆弱です。これに対処するため、Kameleoon は IAB/ABC International Spiders and Bots List を使用して既知のボットおよびスパイダーを識別します。Kameleoon はまた、UserAgent フィールドを使用して、コンバージョンメトリクスを歪める可能性のあるボットやその他の不要なトラフィックをフィルタリングします。詳細については、ボットフィルタリングのヘルプ記事を参照してください。 内部ボットを使用している場合は、それらを分析から除外するために userAgent の値 curl/8.0 を渡すことをお勧めします。

UniqueIdentifier

訪問者に対して UniqueIdentifier を追加しない場合、visitor_code が一意の訪問者識別子として使用されます。これはクロスデバイス実験に便利です。訪問者に対して UniqueIdentifier を追加すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。 UniqueIdentifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。

OperatingSystem

OperatingSystem には、訪問者のデバイス上のオペレーティングシステムに関する情報が含まれます。
各訪問者は 1 つの OperatingSystem のみを持つことができます。2 つ目の OperatingSystem を追加すると、最初のものが上書きされます。
Cookie には、訪問者のデバイスに保存されているクッキーに関する情報が含まれます。
各訪問者は 1 つの Cookie のみを持つことができます。2 つ目の Cookie を追加すると、最初のものが上書きされます。

Geolocation

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

ApplicationVersion

ApplicationVersion は、アプリケーションのセマンティックバージョン番号を表します。
訪問者は 1 つの ApplicationVersion のみを持つことができます。2 つ目のインスタンスを追加すると、最初のものが上書きされます。

戻り値の型

DataFile

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

FeatureFlag

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

Variation

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

Variable

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

非推奨のメソッド

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

get_feature_variation_key()

  • 📨 トラッキングデータを Kameleoon に送信します
代わりに get_variation() を使用してください。
機能バリエーションキーを取得するには、get_feature_variation_key メソッドを呼び出します。 このメソッドは、指定されたユーザーのバリエーションキーを取得するための必須引数として visitor_code および feature_key を受け取ります。 そのようなユーザーがこの機能フラグに関連付けられたことがない場合、SDK はバリエーションキーをランダムに返します (機能フラグルールに従って)。指定された visitor_code を持つユーザーが既にこの機能フラグに登録されている場合、以前のバリエーションキーの値を検出します。ユーザーがどのルールにも一致しない場合、デフォルト値が返されます。これは顧客のアカウントで定義できます。 右側の例に示すように、潜在的な例外をキャッチするために、コードに適切なエラー処理が設定されていることを確認する必要があります。 visitor_code を指定すると、get_feature_variation_key メソッドは visitor_code を一意の訪問者識別子として使用します。これはクロスデバイス実験に便利です。visitor_code を指定して is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
パラメータ is_unique_identifier は非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
引数
戻り値
スローされる例外

get_active_features()

代わりに get_variations() を使用してください。
このメソッドは入力パラメータ visitorCode のみを受け取ります。結果には、指定された訪問者のアクティブな機能のみが含まれます。
引数
戻り値
スローされる例外

get_active_feature_list_for_visitor()

代わりに get_variation() を使用してください。
このメソッドは入力パラメータ visitorCode のみを受け取ります。結果には、指定された訪問者のアクティブな機能フラグのみが含まれます。
引数
戻り値

get_feature_variable()

  • 📨 トラッキングデータを Kameleoon に送信します
代わりに get_variation() を使用してください。
以前は obtain_feature_variable と呼ばれていました。これは SDK バージョン 3.0.0 で削除されました。
ユーザーに関連付けられたバリエーションキーの変数を取得するには、get_feature_variable メソッドを呼び出します。 このメソッドは、必須引数として visitor_codefeature_keyvariable_key を受け取ります。 ユーザーがこの機能フラグに関連付けられたことがない場合、SDK は変数値をランダムに返します (機能フラグルールに従って)。指定された visitor_code を持つユーザーが既にこの機能フラグに登録されている場合、関連するバリエーション変数値を検出します。ユーザーがどのルールにも一致しない場合、デフォルトの変数が返されます。 右側の例に示すように、潜在的な例外をキャッチするために、コードに適切なエラー処理が設定されていることを確認する必要があります。 visitor_code を指定すると、get_feature_variable メソッドは visitor_code を一意の訪問者識別子として使用します。これはクロスデバイス実験に便利です。visitor_code を指定して is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
パラメータ is_unique_identifier は非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名 visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続されている内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
引数
戻り値
スローされる例外

get_feature_variation_variables()

代わりに get_variation() を使用してください。
以前は get_feature_all_variables と呼ばれていました。これは SDK バージョン 3.0.0 で削除されました。
すべての機能変数を取得するには、get_feature_variation_variables メソッドを呼び出します。機能変数は、当社の Web アプリケーションを介して簡単に変更できます。 このメソッドは feature_key 入力パラメータを受け取ります。Web インターフェイスで定義された Dict[str,Any] 型のデータを返します。要求された機能が SDK の内部構成で見つからない場合、例外 (FeatureNotFound) をスローします。
引数
戻り値
スローされる例外

get_feature_list()

以前は obtain_feature_list と呼ばれていました。これは SDK バージョン 3.0.0 で削除されました。
現在 SDK で利用可能な機能フラグキーのリストを返します。
戻り値