開発者ガイド
このガイドは、Rust SDK を迅速に統合し、Rust アプリケーションでフィーチャーフラグの評価を開始するのに役立つように設計されています。はじめに
Rust クライアントのインストール
現在のワークスペースで作業している場合、いくつかの SDK メソッドが非同期であるため、SDK をtokio と共にパス依存関係として追加します。
Cargo.toml
追加の構成
認証情報を提供し、SDK の動作をカスタマイズするためのclient-config.json 構成ファイルを作成します。サンプル構成ファイルをダウンロードすることもできます。
このファイルはデフォルトのパス /etc/kameleoon/client-config.json に保存することをお勧めしますが、クラスパス上の任意の場所に client-config.json として保存することもできます。
Rust SDK は、create_with_path() で使用される JSON ファイル、または create_with_config() を使用してコード内で直接 KameleoonClientConfig をビルドすることで構成できます。
次の表は、設定可能な利用可能なプロパティを示しています。
Kameleoon クライアントの初期化
SDK をインストールし、認証情報を構成した後、KameleoonClientFactory を使用して KameleoonClient を作成します。
- 構成ファイル
- コード
KameleoonClient は、フィーチャーフラグの評価、訪問者データの追加、トラッキングリクエストの送信に使用される主要なオブジェクトです。
フィーチャーフラグの有効化
ユーザーへの一意の 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_key と visitor_code に基づいて返すことにより、ユーザーに適したバリエーションを取得します。
is_feature_active() メソッドは、複数のバリエーションやターゲティングオプションを持つより複雑なフィーチャーフラグとは対照的に、ON または OFF 状態のみを持つ単純なフィーチャーフラグの構成を取得したい場合に使用できます。
フィーチャーフラグに関連付けられた変数(各バリエーションに関連付けられた特定の動作など)がある場合、get_variation() を使用すると、割り当てられたバリエーションとその関連実験の詳細を提供する Variation オブジェクトにアクセスすることもできます。このメソッドは、ユーザーがターゲットになっているかどうかを確認し、訪問者の割り当てられたバリエーションを見つけ、それをストレージに保存します。track=true の場合、SDK は次のトラッキングリクエストで指定された実験への露出イベントを送信します。これは、SDK の tracking_interval に基づいて自動的にトリガーされます。デフォルトでは、この間隔は 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 で定義)と共に送信されます。リクエストを即座に送信したい場合は、flush_instant() メソッドを使用してください。
分析ソリューションへのイベント送信
コンバージョンをトラッキングし、露出イベントを顧客分析ソリューションに送信するには、まず Kameleoon を ハイブリッドモード で実装する必要があります。その後、get_engine_tracking_code() メソッドを使用します。
get_engine_tracking_code() メソッドは、露出イベントを分析ソリューションに送信するために必要な一意のトラッキングコードを取得します。このメソッドを使用すると、イベントを記録し、希望の分析プラットフォームに送信できます。
カスタムバケットキーの使用
デフォルトでは、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)を指します。
- バケッティングロジック:
add_data()メソッドを介してカスタムバケットキーが提供されると、ユーザーをバリエーションに割り当てるためのすべてのハッシュ計算は、デフォルトのvisitor_codeではなく、このnew_visitor_code(カスタムキー)を使用します。new_visitor_codeを使用することは、バケッティングの決定がカスタム識別子に紐付けられることを意味し、その識別子が存在するさまざまなコンテキストにわたって一貫した割り当てを保証します。 - データトラッキングと分析:
new_visitor_code(カスタムキー)がバケッティングの決定に使用される一方、その後のすべてのデータ(たとえばトラッキングイベントやコンバージョン)は、元のvisitor_codeと共に送信および関連付けられることに注意することが重要です。この分離により、バケッティングが上位レベル(アカウントなど)で実行されたり、複数のデバイス/セッションにまたがって実行されたりする場合でも、分析が個々のユーザージャーニーと、より広い実験コンテキスト内でのインタラクションを正確に反映するようになります。元の訪問者データは、包括的なレポートのために維持されます。
技術要件
カスタムバケットキーを効果的に使用するには:- キーは
&strでなければなりません。 - バケッティングの対象となるエンティティに対して一意でなければなりません(たとえば、
user_idを使用する場合、各ユーザーの ID は一意である必要があります)。 - フィーチャーフラグの決定がそのユーザーまたはリクエストに対して評価される時点で、キーが SDK で利用可能でなければなりません。
ターゲティング条件
Kameleoon SDK は、キャンペーンでユーザーをターゲットにするために使用できる、さまざまな事前定義されたターゲティング条件をサポートしています。この SDK がサポートする条件の一覧については、訪問履歴を使用してユーザーをターゲットにする を参照してください。 独自の 外部データを使用してユーザーをターゲット にすることもできます。クロスデバイス実験
複数のデバイスからアプリにアクセスする訪問者をサポートするため、Kameleoon ではクロスデバイス実験を通じて、以前に収集された訪問者データを訪問者の各デバイス間で同期し、デバイス間の訪問履歴を統合できます。Kameleoon がデバイス間でデータをどのように扱うかについてのケーススタディと詳細情報は、クロスデバイス実験に関する記事 で入手できます。デバイス間でのカスタムデータの同期
カスタムマッピング同期はデバイス間で訪問者データを揃えるために使用されますが、常に必要なわけではありません。以下は、カスタムマッピング同期が不要な 2 つのシナリオです。 デバイス間で同じユーザー ID すべてのデバイスで同じユーザー ID が一貫して使用されている場合、カスタムマッピング同期なしに同期が自動的に処理されます。複数のデバイス間で収集されたデータを同期したい場合は、get_remote_visitor_data() メソッドを呼び出すだけで十分です。
一貫した ID を持つマルチサーバーインスタンス
複数のサーバー(たとえば、分散サーバーインスタンス)を含む複雑な設定で、サーバー間で同じユーザー ID が利用可能な場合、サーバー間の同期(get_remote_visitor_data() を使用)で十分で、追加のカスタムマッピング同期は不要です。
追加データが必要なお客様は、詳細なガイダンスについて get_remote_visitor_data() メソッドの説明を参照してください。以下のコードでは、正確なデータ取得のために、2 つのデバイス間で同じ一意の識別子(この場合は visitor_code、userId とも呼ばれます)が一貫して使用されていることを前提としています。
収集したデータをリアルタイムで同期したい場合は、カスタムデータのスコープに Visitor を選択する必要があります。
Device A
Device B
セッションマージのためのカスタムデータの使用
クロスデバイス実験 を使用すると、訪問者の履歴を各デバイス間で結合できます(履歴の統合)。履歴の統合により、異なる訪問者セッションを 1 つにマージできます。訪問履歴を統合するには、CustomData を使用して訪問者の一意の識別子を提供します。詳細については、専用のドキュメント を参照してください。
クロスデバイス統合が有効になった後、パラメータ userId を指定して get_remote_visitor_data() を呼び出すと、特定のユーザーに対するすべての既知のデータが取得されます。
同じ識別子を持つセッションは、実験において常に同じバリエーションが表示されます。実験結果ページの Visitor ビューでは、これらのセッションは単一の訪問者として表示されます。
SDK 構成により、関連するセッションは常に実験の同じバリエーションを参照することが保証されます。ただし、クロスデバイスのバリエーション割り当てに関するいくつかの制限があります。これらの制限の概要は、こちら に記載されています。
Kameleoon プラットフォームでカスタムデータを設定するには、クロスデバイス履歴統合の有効化 ガイドに従ってください。
その後、SDK を通常通り使用できます。次のメソッドはセッションマージのコンテキストで役立つ可能性があります:
UniqueIdentifier(true)を追加したget_remote_visitor_data()- リンクされたすべての訪問者のデータを取得します。UniqueIdentifier(true)データを追加したtrack_conversion()またはflush()- 別の訪問者に関連付けられた特定の訪問者のデータを追跡します。
get_visitor_code() メソッドによって生成された匿名訪問者識別子が使用されます。ユーザーがログインした後、匿名訪問者はユーザー ID に関連付けられ、訪問者の一意の識別子として使用されます。
ロギング
SDK は、さまざまな内部プロセスや問題を反映するログを生成します。ログレベル
SDK は、ログレベルによるロギングの制限の構成をサポートしています。ログのカスタムハンドリング
SDK はデフォルトでログをコンソール出力に書き込みます。この動作はオーバーライドできます。ログレベルによるロギング制限は、ログハンドリングロジックとは別に実行されます。
リファレンス
これは Rust SDK の完全なリファレンスドキュメントです。初期化
create()
SDK を使用するには、KameleoonClientFactory::create_with_config()/KameleoonClientFactory::create_with_file() を使用して KameleoonClientConfig インスタンスから KameleoonClient を作成します。
- create_with_config()
- create_with_file()
引数
戻り値
エラー
initialize()
Kameleoon クライアントの初期化を待ち、構成されたdefault_timeout または提供された timeout を使用します。このメソッドは、さらに操作を実行する前にクライアントが完全に初期化されていることを保証します。
引数
戻り値
エラー
is_ready()
クライアントが初期化されているかどうかを確認します。戻り値
forget()
指定されたsite_code に関連付けられたキャッシュされた SDK クライアントを削除します。
引数
戻り値
フィーチャーフラグとバリエーション
is_feature_active()
- 📨 Kameleoon にトラッキングデータを送信します(
trackオプションに応じて)
Kameleoon は、
is_feature_active()、get_variation() または get_variations() などの特定のメソッドを呼び出すときに、トラッキングを使用してセッションと訪問者をカウントします。訪問者をバリエーションに公開し、それらをカウントする必要がある場合は、track パラメータにデフォルトの true 値を使用してください。訪問者を公開する前にこれらのメソッドを呼び出す場合のみ、track パラメータを false に設定してください。たとえば、訪問者を公開する前にすべてのバリエーションを取得するために get_variations() を呼び出す場合、track パラメータを false に設定してください。この設定により、Kameleoon がセッションを早期にカウントするのを防ぎます。後で訪問者を明示的に公開するときにトラッキングをトリガーできます。Kameleoon はデフォルトで毎秒トラッキングデータを送信します。tracking interval 構成オプションを使用して、この間隔を最大 5 秒まで設定できます。Kameleoon は、イベント間の間隔が 30 分未満である限り、トラッキングイベントを単一セッションにグループ化します。トラッキングイベント間に 30 分以上経過した場合、Kameleoon はイベントを別々のセッションとしてカウントします。訪問はセッションで最後に記録されたイベントから 30 分後にレポートに表示されます。引数
戻り値
エラー
get_variation()
- 📨 Kameleoon にトラッキングデータを送信します(
trackパラメータに応じて)
Variation を取得します。
このメソッドは、visitor_code と feature_key を必須引数として受け取ります。track 引数はオプションで、デフォルトは true です。
訪問者に割り当てられた Variation を返します。訪問者がどのフィーチャーフラグルールにも関連付けられていない場合、メソッドは指定されたフィーチャーフラグのデフォルト Variation を返します。
潜在的な例外を管理するため、コード内で適切なエラー処理を実装してください。
デフォルトバリエーションとは、訪問者がフィーチャーフラグの事前定義された配信ルールのいずれにも一致しない場合に割り当てられるバリエーションのことです。言い換えると、特定のルールでターゲット指定されていないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェイスの「その他すべてのユーザーには…」セクションのバリエーションとして表されます。
引数
戻り値
エラー
get_variations()
- 📨 Kameleoon にトラッキングデータを送信します(
trackパラメータに応じて)
Variation オブジェクトのマップを取得します。
このメソッドは、利用可能なすべてのフィーチャーフラグを反復処理し、指定された訪問者に関連付けられた各フラグに割り当てられた Variation を返します。必須引数として visitor_code を取り、only_active と track はオプションです。
only_activeがtrueに設定されている場合、get_variations()メソッドは、ユーザーがoffバリエーションでバケッティングされていないことを条件に、フィーチャーフラグのバリエーションを返します。trackパラメータは、メソッドがバリエーション割り当てを追跡するかどうかを制御します。デフォルトではtrueに設定されています。falseに設定すると、トラッキングが無効になります。
Variation を値として構成されています。フィーチャーフラグにバリエーションが割り当てられていない場合、メソッドはそのフラグのデフォルト Variation を返します。
潜在的な例外を管理するため、適切なエラー処理を実装する必要があります。
デフォルトバリエーションとは、訪問者がフィーチャーフラグの事前定義された配信ルールのいずれにも一致しない場合に割り当てられるバリエーションのことです。言い換えると、特定のルールでターゲット指定されていないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェイスの「その他すべてのユーザーには…」セクションのバリエーションとして表されます。
引数
戻り値
エラー
set_forced_variation()
このメソッドを使用すると、標準の評価プロセスをバイパスして、特定のVariation をユーザーにプログラム的に割り当てることができます。これは、通常の評価ロジックが不要であるか、スキップする必要がある制御された実験で特に役立ちます。デバッグやカスタムテストなどのシナリオでも役立ちます。
強制バリエーションが設定されると、Kameleoon のリアルタイム評価ロジックがオーバーライドされます。セグメンテーション、ターゲティング条件、アルゴリズム計算などのプロセスはスキップされます。実験中にセグメンテーションとターゲティング条件を保持するには、代わりに force_targeting=false を設定してください。
シミュレートされたバリエーションは、実行順序で常に優先されます。シミュレートされたバリエーション計算がトリガーされると、それが完全に処理され、最初に完了します。
引数
戻り値
エラー
evaluate_audiences()
- 📨 Kameleoon にトラッキングデータを送信します
evaluate_audiences() は、関連するすべての訪問者データが設定または更新された後、フィーチャーバリエーションを取得したりフィーチャーフラグをチェックしたりする 直前 に呼び出す必要があります。このアプローチにより、訪問者は利用可能な最新のデータに対して評価され、すべての基準に基づいて正確なオーディエンス割り当てが可能になります。
このメソッドを呼び出した後、Audiences Explorer でセグメントパフォーマンスの詳細な分析を実行できます。
引数
戻り値
エラー
get_datafile()
現在の SDK 構成をDataFile オブジェクトとして返します。
戻り値
エラー
訪問者データ
get_visitor_code()
get_visitor_code() を使用して、現在の訪問者の Kameleoon visitor_code を取得します。このメソッドは、CookieAccessor トレイトを実装する任意のクッキーストアで動作します。
実装ロジックは次のとおりです:
- SDK は、提供されたアクセサを通じて
kameleoonVisitorCodeクッキーがすでに利用可能かどうかを確認します。 - クッキーが存在しない場合、SDK は提供された場合に
default_visitor_codeを使用します。 - それ以外の場合、SDK は新しい訪問者コードを生成し、アクセサを介して保存します。
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 コンポーネントとしてエンコードする必要があります。- Custom
- Axum
- Actix
引数
戻り値
add_data()
add_data() メソッドは、ターゲティングデータ をストレージに追加し、他のメソッドがデータを使用して現在の訪問者をターゲットにするかどうかを決定できるようにします。
add_data() メソッドは値を返さず、Kameleoon バックエンドサーバーとは独自に対話しません。代わりに、宣言されたすべてのデータは、flush() メソッドを使用して将来の送信のために保存されます。このアプローチでは、データは通常 flush() によってトリガーされる単一のサーバー呼び出しにグループ化されるため、サーバー呼び出しの数を減らすことができます。
track_conversion() メソッドも、flush() と同様に、以前に関連付けられたデータを送信します。これは、実験ルールがトリガーされた場合の get_variation() および get_variations() メソッドにも同様に当てはまります。
引数
戻り値
エラー
flush()
- 📨 Kameleoon にトラッキングデータを送信します
flush() メソッドは、訪問者に関連付けられたすべての Kameleoon データを集約し、トラッキングリクエストをサーバーに送信します。このリクエストには、他のトラッキングメカニズム(詳細については参照されたメソッドを参照)を通じてまだ送信されていない、add_data メソッドを介して以前に追加されたデータが含まれます。サーバー呼び出しは非同期で実行されるため、flush() 操作はノンブロッキングです。
このメソッドは、特定の visitor_code に関連付けられたデータがいつ送信されるかを制御します。たとえば、add_data() が複数回呼び出された場合、各呼び出し後にリクエストを送信するのは非効率的です。代わりに、これらの更新をバッチ処理し、flush() を 1 回呼び出して、すべての蓄積されたデータを単一のリクエストで送信できます。
flush() メソッドは、提供された visitor_code を一意の訪問者識別子として使用します。
引数
戻り値
エラー
get_remote_data()
get_remote_data() メソッドを使用すると、指定された key に対して Kameleoon サーバーに保存されているリモートデータを取得できます。ほとんどのセットアップでは、このデータは Kameleoon Data API を介して書き込まれ、追加のアプリケーションコンテキストが必要なときに後で Rust サービスによってフェッチされます。
このメソッドは、Kameleoon のリモートインフラストラクチャ上に構造化された情報を保持し、別個の取得メカニズムを維持することなくバックエンドから再利用したい場合に役立ちます。
引数
戻り値
エラー
get_remote_visitor_data()
get_remote_visitor_data() は、提供された visitor_code に対して Kameleoon 訪問データを取得するための非同期メソッドです。このメソッドはローカル訪問者ストレージにデータを追加し、他の SDK メソッドがターゲティングの決定にそれを使用できるようにします。
このメソッドを使用して取得したデータは、特に次の場合に役立ちます:
- 他のデバイスから収集されたデータを使用する。
- 過去の訪問から以前に表示されたページなど、訪問者の履歴にアクセスする。
- データレイヤー変数やフロントエンドの目標コンバージョンなど、クライアント側でのみ利用可能なデータを使用する。
引数
戻り値
エラー
get_remote_visitor_data() でのパラメータの使用
get_remote_visitor_data() メソッドを使用すると、訪問者に対してどのデータが取得されるかを制御できます。同じフィルタリングアプローチが、目標、実験、バリエーション、その他の訪問者データにわたって機能します。
たとえば、過去 5 回の訪問で目標にコンバージョンしたユーザーをターゲットにしたい場合、previous_visit_amount を 5 に、conversions を true に設定できます。
この例で示される柔軟性は、目標データに限定されません。フィルタを使用して、さまざまな訪問者の行動を取得し、Rust アプリケーションのターゲティングとレポーティングロジックで利用できるようにすることができます。
RemoteVisitorDataFilter フィールド
get_visitor_warehouse_audience()
このメソッドは、指定されたvisitor_code と、オプションで warehouse_key を使用して、ウェアハウス統合内の訪問者に関連付けられたオーディエンスデータを取得します。warehouse_key は通常、内部ユーザー ID です。custom_data_index パラメータは、Kameleoon が訪問者をターゲットにするために使用する Kameleoon カスタムデータに対応します。
呼び出しが成功すると、SDK は返されたオーディエンスリストを CustomData に変換し、訪問者にローカルに追加し、ターゲティング目的で利用可能にします。詳細については、ウェアハウスターゲティングのドキュメント を参照してください。
引数
戻り値
エラー
set_legal_consent()
このメソッドを使用して、訪問者が個人データの使用について法的同意を提供したかどうかを指定する必要があります。legal_consent を false に設定すると、トラッキングリクエストに含めることができるデータの種類が制限されます。これにより、訪問者データを責任を持って管理しながら、法的および規制要件を遵守できます。詳細については、同意管理ポリシー を参照してください。
クッキーアクセサを提供すると、SDK は同意ステータスに応じて訪問者のクッキーも更新します。
引数
戻り値
エラー
同意撤回時の動作
legal_consent=false で set_legal_consent() を呼び出した場合、SDK は kameleoonVisitorCode クッキーを削除しません。代わりに、クッキーの有効期限を延長することを停止し、クッキーが自然に期限切れになるまで保持されるようにします。
コンプライアンス要件によりオプトアウト時にクッキーファイルを直ちに削除する必要がある場合は、フレームワークのネイティブクッキー管理メソッドを使用して手動で削除する必要があります。SDK はファイルを自動的に削除しません。
目標とサードパーティ分析
track_conversion()
- 📨 Kameleoon にトラッキングデータを送信します
visitor_code と goal_id が必要です。さらに、このメソッドはオプションの revenue、negative、metadata 引数も受け入れます。visitor_code は通常、実験をトリガーしたときに使用したものと同じです。
引数
メタデータ値は 生データのエクスポート および 結果ページ からアクセスできます。
metadata パラメータが提供された場合、Kameleoon は add_data() メソッドを使用して以前に収集された値ではなく、これらの指定された値を現在のコンバージョンに使用します。パラメータが省略されると、Kameleoon はコンバージョン前および同じ訪問内のそれらの CustomData に対して最後にトラッキングされた値を使用します。Kameleoon は、track_conversion() メソッドにパラメータとして明示的に渡されたメタデータ値のみを考慮します。以下の例では、Kameleoon はパラメータとして明示的に提供されたカスタムデータ値(ここでは: 値 ‘Amex Credit Card’ のインデックス 5)のみをコンバージョンに関連付けます。戻り値
エラー
get_engine_tracking_code()
Kameleoon は、Mixpanel、Google Analytics 4、Segment など、いくつかの分析ソリューションと統合しています。サーバーサイド実験を正しくトラッキングするには、訪問者が実験をトリガーした後にget_engine_tracking_code() メソッドを呼び出します。SDK は、訪問者が過去 5 秒間にトリガーした実験の JavaScript キューコマンドを返します。このコードをページに挿入すると、Engine.js がコマンドを処理し、アクティブな分析統合を介して露出イベントを送信します。
このメソッドの実装に関する詳細は、ハイブリッド実験 を参照してください。
- この機能を使用するには、Rust 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 が返されたトラッキングコード内でこれらの値を生成します。引数
戻り値
エラー
イベント
on_datafile_update()
on_datafile_update() メソッドを使用すると、データファイル更新イベントを処理できます。これは、polling または streaming のデータファイル更新イベントを介して構成が更新されるたびに呼び出される単一のパラメータ handler を受け入れます。
引数
データ型
このセクションでは、SDK がkameleoon_client::data で再エクスポートする Rust データ型を一覧表示します。
ApplicationVersion
ApplicationVersion は、アプリケーションのセマンティックバージョン番号を表します。
Browser
ここに保存されているBrowser データセットは、関連付けられた任意の値で実験やパーソナライゼーションレポートをフィルタリングするために使用できます。
Conversion
ここに保存されているConversion データセットは、関連付けられた任意の目標で実験やパーソナライゼーションレポートをフィルタリングするために使用できます。
Cookie
Cookie には、訪問者のデバイスに保存されているクッキーに関する情報が含まれています。
CustomData
CustomData を使用すると、各訪問者にあらゆる種類のデータを関連付けることができ、セグメント のターゲティング条件のための効果的なツールとなります。さらに、実験レポートのフィルタやブレークダウンとして使用できます。カスタムデータの詳細については、この 記事 を参照してください。
Kameleoon アプリまたは Data API でカスタムデータ型を定義し、SDK から使用します。
-
各訪問者は、各一意の
index(name)に対して 1 つのCustomDataのみを許可されます。同じindex(name)を持つ別のCustomDataを追加すると、既存のものが置き換えられます。 - カスタムデータの「インデックス」は、Custom Data ダッシュボード の「INDEX」列で確認できます。
- プライバシー上の理由から、選択されたインデックスを持つデータが SDK から Kameleoon サーバーに送信されるのを防ぐには、カスタムデータの作成時に このデータをローカルでターゲティング目的にのみ使用する オプションを有効にします。
-
SDK インスタンスが初期化されていないか、名前が登録されていない場合に名前で作成された
CustomDataインスタンスを追加すると、データは無視されます。
Device
デバイスデータを使用して、関連付けられた任意の値で実験やパーソナライゼーションレポートをフィルタリングできます。Geolocation
Geolocation には、訪問者の地理位置情報の詳細が含まれています。
OperatingSystem
OperatingSystem には、訪問者のデバイスのオペレーティングシステムに関する情報が含まれています。
PageView
ページビューイベントを保存します。リファラインデックスは、Kameleoon アプリの 取得チャネル構成 ページで利用できます。注意: インデックスは
0 から始まるため、作成した最初の取得チャネルの ID は 1 ではなく 0 です。UniqueIdentifier
訪問者にUniqueIdentifier を追加しない場合、visitor_code が一意の訪問者識別子として使用され、クロスデバイス実験 に役立ちます。UniqueIdentifier(true) を追加すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
これは、訪問者に元々割り当てられた匿名の visitor_code にアクセスできないが、セッションマージを通じてその訪問者に接続された内部識別子にアクセスできる状況で役立ちます。
UserAgent
サーバーサイド実験は、クライアントサイド実験よりもボットトラフィックの影響を受けやすくなっています。Kameleoon は IAB/ABC International Spiders and Bots List を使用して既知のボットとスパイダーを認識し、UserAgent フィールドを使用してコンバージョン指標を歪める可能性のあるその他の不要なトラフィックをフィルタリングします。詳細については、ボットフィルタリング に関するヘルプ記事を参照してください。
内部ボットを使用している場合は、分析から除外するためにユーザーエージェント値 curl/8.0 を送信することをお勧めします。
返却される型
DataFile
DataFile には、SDK 構成の詳細が含まれています。
クライアントの要件に応じて追加情報で拡張できます。詳細が必要な場合は、Customer Success Manager にお問い合わせください。
FeatureFlag
FeatureFlag は、フィーチャーフラグ自体を定義する一連のプロパティ — たとえば、その Variations、Rules、環境ステータス、その他の関連する詳細 — を表します。
クライアントの要件に応じて追加情報で拡張できます。詳細が必要な場合は、Customer Success Manager にお問い合わせください。
Rule
Rule は、ルール自体を定義する一連のプロパティ — たとえば、その Variations — を表します。
クライアントの要件に応じて追加情報で拡張できます。詳細が必要な場合は、Customer Success Manager にお問い合わせください。
Variation
Variation には、訪問者の割り当てられたバリエーションに関する情報、または特定の割り当てが存在しない場合のデフォルトバリエーションが含まれています。
Variationは割り当てられたまたはデフォルトのバリエーションを記述し、Variableには各個別の変数の詳細が含まれます。idとexperiment_idはNoneにすることができ、これは特定の実験割り当てに紐付けられていないデフォルトバリエーションを示します。
Variable
Variable には、割り当てられたバリエーションに関連付けられた変数に関する情報が含まれています。
JsonValue
JsonValue は、Rust におけるバリエーション変数の値を表します。