開発者ガイド
このセクションでは、SDK を統合し、Ruby アプリケーションで実験を開始する方法を説明します。このチュートリアルに従って、異なるバリエーションに基づいて推奨製品の数を変更する簡単な A/B テストを設定します。はじめに
SDK のインストール
SDK は、公式の RubyGems リポジトリでホストされている標準的な gem パッケージを使用してインストールします。インストールするには、次のコマンドを実行します。クライアントの設定
Ruby SDK の認証情報は設定ファイルで提供します。このファイルを使用して SDK の動作をカスタマイズすることもできます。サンプル設定ファイルから始めることができます。このファイルはデフォルトのパス/etc/kameleoon/client-ruby.yaml に追加することを推奨します。別の場所を使用する場合は、初期化中に Kameleoon::KameleoonClientFactory.Create() メソッドへの引数としてパスを渡す必要があります。最新の SDK で使用可能なキーは以下のとおりです。
Kameleoon Ruby SDK は Automation API を使用し、OAuth 2.0 のクライアントクレデンシャルフローに従います。
クライアントの初期化
SDK をアプリケーションにインストールし、正しい認証情報(/etc/kameleoon/client-ruby.yaml または Kameleoon::KameleoonClientConfig 内)を設定したら、Kameleoon アプリでサーバーサイドの実験を設定する必要があります。
次のステップは、アプリケーションコード内で Kameleoon クライアントを作成することです。以下のコードは Kameleoon クライアントの作成例です。Kameleoon::KameleoonClient は、アプリケーションと Kameleoon の間のブリッジとして機能するシングルトンオブジェクトです。実験を実行するために必要なすべてのメソッドとプロパティが含まれています。
Kameleoon で A/B テストを実装する際、開発者はアプリケーションコードの正しいロジックを確保する責任があります。ベストプラクティスとしては、実験がまだ起動されていない場合に訪問者が実験から除外される可能性があると常に想定することです。これはデフォルトまたはリファレンスバリエーションのロジック(常に存在するべきもの)と整合するため、実装は容易です。次のセクションのコードサンプルはこのアプローチを示しています。
機能フラグの有効化
ユーザーへの一意な ID の割り当て
ユーザーに一意な ID を割り当てるには、get_visitor_code() メソッドを使用できます。visitor code が存在しない場合(リクエストヘッダーのクッキーから)、メソッドはランダムな一意の ID を生成するか、あなたが生成した default_visitor_code を使用します。その後、ID はレスポンスヘッダーのクッキーに設定されます。
Kameleoon をハイブリッドモードで使用している場合、get_visitor_code() メソッドを呼び出すと、一意の ID(visitor code)がアプリケーションファイルの engine.js(以前は kameleoon.js という名前でした)と SDK の間で共有されます。
フラグ設定の取得
コードに機能フラグを実装するには、まず Kameleoon アカウントで機能フラグを作成する必要があります。 特定のユーザーに対する機能フラグのステータスまたはバリエーションを判定するには、get_variation() または feature_active?() メソッドを使用して、feature_key に基づいて設定を取得します。
get_variation() メソッドは、ON/OFF 状態のシンプルな機能フラグと、複数のバリエーションを持つより複雑なフラグの両方を処理します。このメソッドは、機能ルールをチェックし、バリエーションを割り当て、feature_key と visitor_code に基づいて適切なバリエーションをユーザーに対して返します。
feature_active?() メソッドは、複数のバリエーションやターゲティングオプションを持つより複雑な機能フラグではなく、ON または OFF 状態のみを持つシンプルな機能フラグの設定を取得したい場合に使用できます。
機能フラグに関連付けられた変数がある(各バリエーションに紐づく特定の動作など)場合、get_variation() を使用すると、Variation オブジェクトにもアクセスでき、割り当てられたバリエーションとそれに関連する実験の詳細を提供します。このメソッドは、ユーザーがターゲットされているかどうかをチェックし、訪問者に割り当てられたバリエーションを見つけ、ストレージに保存します。track=true の場合、SDK は SDK の tracking_interval_millisecond に基づいて自動的にトリガーされる次のトラッキングリクエストで、指定された実験への露出イベントを送信します。デフォルトでは、この間隔は 1000 ミリ秒(1 秒)に設定されています。
get_variation() メソッドでは、トラッキングを行うかどうかを制御できます。track=false の場合、SDK は露出イベントを送信しません。これは、SDK を介してデータをトラッキングしたくない場合や、たとえば Kameleoon エンジンによって管理されるクライアントサイドのトラッキングに依存したい場合に便利です。さらに、get_variations() メソッドを使用する際、トラッキングイベントをトリガーせずにすべてのフラグのバリエーションのみが必要な場合に、track=false の設定が役立ちます。トラッキングの仕組みについて詳しく知りたい場合は、こちらの記事をご覧ください。
レポート内でユーザーをターゲティング、または訪問をフィルター/ブレークダウンするためのデータポイントの追加
ユーザーをターゲティングするには、機能バリエーションを取得する、またはフラグがアクティブかどうかを確認する前に、プロファイルに関連するデータポイントを追加しておく必要があります。これらのデータポイントをユーザープロファイルに追加するには、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() メソッドは、分析ソリューションに露出イベントを送信するために必要な一意のトラッキングコードを取得します。このメソッドを使用すると、イベントを記録し、希望の分析プラットフォームに送信できます。
クロスデバイス実験
複数のデバイスからアプリにアクセスする訪問者をサポートするために、Kameleoon はクロスデバイス実験を通じて、訪問者の各デバイス間で以前に収集された訪問者データを同期し、デバイス間で訪問履歴を統合できるようにします。Kameleoon がデバイス間でデータを処理する方法に関するケーススタディと詳細な情報は、クロスデバイス実験に関する記事で確認できます。デバイス間でのカスタムデータの同期
カスタムマッピングの同期は、デバイス間で訪問者データを整合させるために使用されますが、必ずしも必要ではありません。以下にカスタムマッピングの同期が必要ない 2 つのシナリオを示します。 デバイス間で同一のユーザー ID すべてのデバイスで同じユーザー ID が一貫して使用されている場合、カスタムマッピングの同期なしで同期が自動的に処理されます。複数のデバイス間で収集されたデータを同期したいときにget_remote_visitor_data() メソッドを呼び出すだけで十分です。
一貫した ID を持つマルチサーバーインスタンス
複数のサーバー(例: 分散サーバーインスタンス)を含む複雑な設定では、サーバー間で同じユーザー ID が利用可能な場合、追加のカスタムマッピング同期なしにサーバー間の同期(get_remote_visitor_data() を使用)で十分です。
追加のデータが必要なお客様は、get_remote_visitor_data() メソッドの説明を参照して詳細なガイダンスを得てください。以下のコードでは、正確なデータ取得のために、2 つのデバイス間で同じ一意の識別子(この場合、userId とも呼ばれる visitor_code)が一貫して使用されていることを前提としています。
収集したデータをリアルタイムで同期したい場合、カスタムデータのスコープに Visitor を選択する必要があります。
Device A
Device B
セッションマージのためのカスタムデータの使用
クロスデバイス実験を使用すると、訪問者の履歴を各デバイスで結合することができます(履歴の整合)。履歴の整合は、異なる訪問者セッションを 1 つにマージすることを可能にします。訪問履歴を整合するには、CustomData を使用して訪問者の一意の識別子を提供します。詳細は、専用のドキュメントを参照してください。
クロスデバイス整合が有効化されると、userId パラメータを使用して get_remote_visitor_data() を呼び出すことで、特定のユーザーの既知のすべてのデータを取得できます。
同じ識別子を持つセッションは、実験で常に同じバリエーションが表示されます。実験結果ページのビジター ビューでは、これらのセッションは単一の訪問者として表示されます。
SDK の構成により、関連付けられたセッションが常に同じ実験のバリエーションを表示することが保証されます。ただし、クロスデバイスのバリエーション割り当てに関するいくつかの制限事項があります。これらの制限はこちらで説明されています。
クロスデバイスの履歴整合の有効化ガイドに従って、Kameleoon プラットフォームでカスタムデータを設定してください。
その後、SDK を通常どおりに使用できます。セッションマージの文脈で役立つメソッドは次のとおりです。
get_remote_visitor_data()にUniqueIdentifier(true)を追加 - すべてのリンクされた訪問者のデータを取得します。track_conversion()またはflush()にUniqueIdentifier(true)データを追加 - 別の訪問者に関連付けられた特定の訪問者のデータをトラッキングします。
get_visitor_code() メソッドによって生成された匿名の訪問者識別子が使用されます。ユーザーがログインすると、匿名の訪問者がユーザー ID に関連付けられ、訪問者の一意の識別子として使用されます。
カスタムバケッティングキーの使用
デフォルトでは、Kameleoon は一意の匿名訪問者 ID(visitor_code)を使用して、ユーザーを機能フラグのバリエーションに割り当てます。この ID は通常、ユーザーのデバイス上で生成および保存されます(クライアントサイドおよびサーバーサイド SDK ではブラウザ クッキーに、モバイル SDK では永続ストレージに)。しかし、特定のシナリオでは、同じ組織のすべてのユーザーに機能フラグの同じバリアントを表示させたい場合があります。
カスタムバケッティングキー オプションを使用すると、バケッティングに独自のカスタム識別子を提供することで、このデフォルトの動作を上書きできます。この上書きにより、Kameleoon の割り当てロジックがデフォルトの visitor_code の代わりに、指定したキーを使用するようになります。
ユースケース
カスタムバケッティングキーの使用は、機能フラグの割り当てにおいて整合性と精度を維持するために、特に以下の状況で不可欠です。- アカウントレベルまたは組織の実験: B2B 製品や、同じ組織のすべてのユーザーを同じバリエーションに割り当てたいシナリオでは、
accountIdなどの識別子を使用できます。チームや会社全体に影響を与える機能を A/B テストする際に、カスタムバケッティングキーは極めて重要です。
技術的な詳細
機能フラグにカスタムバケッティングキーを設定すると、アプリケーションのデータから特定の識別子を Kameleoon に提供することになります。- カスタムキーの提供:
add_data()メソッドを使用して、選択したカスタム識別子を Kameleoon SDK に提供します。このメソッドでは、選択したカスタムバケッティングキーをCustomDataオブジェクトとして渡します。ここで、newVisitorCodeは、バケッティングに使用したい識別子(たとえば、新しいuserIdまたはaccountId)を指します。
- バケッティングロジック:
add_data()メソッドを通じてカスタムバケッティングキーが提供されると、ユーザーをバリエーションに割り当てるためのすべてのハッシュ計算では、デフォルトのvisitor_codeの代わりにこのnewVisitorCode(カスタムキー)が使用されます。newVisitorCodeを使用することで、バケッティングの決定がカスタム識別子に紐付けられ、その識別子が存在するさまざまなコンテキストで一貫した割り当てが保証されます。 - データトラッキングと分析: 重要な点として、
newVisitorCode(カスタムキー)はバケッティングの判断に使用されますが、それ以降のすべてのデータ(トラッキングイベントやコンバージョンなど)は、元のvisitor_codeで送信および関連付けられます。 この分離により、(アカウントなどの)より高いレベルや、複数のデバイス/セッション間でバケッティングが実行される場合でも、分析が実験のより広いコンテキスト内で個々のユーザージャーニーとインタラクションを正確に反映します。元の訪問者データは、包括的なレポートのためにそのまま保持されます。
技術的要件
カスタムバケッティングキーを効果的に使用するには:- キーは
Stringでなければなりません。 - バケッティング対象のエンティティに対して一意である必要があります(たとえば、
userIdを使用する場合、各ユーザーの ID は一意でなければなりません)。 - そのユーザーまたはリクエストに対して機能フラグの判断が評価される正確な瞬間に、SDK でキーが利用可能でなければなりません。
ターゲティング条件
Kameleoon SDK は、キャンペーンでユーザーをターゲティングするために使用できるさまざまな事前定義済みターゲティング条件をサポートしています。この SDK がサポートする条件のリストについては、訪問履歴を使用してユーザーをターゲティングするを参照してください。 ユーザーをターゲティングするための独自の外部データを使用することもできます。ロギング
SDK は、さまざまな内部プロセスや問題を反映したログを生成します。ログレベル
SDK は、ログレベルによるログ出力の制限の設定をサポートしています。ログのカスタムハンドリング
SDK はデフォルトでログをコンソール出力に書き込みます。この動作は上書き可能です。ログレベルによるログ出力の制限は、ログ処理ロジックとは別に実行されます。
リファレンス
Ruby SDK の完全なリファレンスドキュメントです。初期化
create()
SDK の使用を開始するには、初期化のステップから始めます。SDK とのすべてのやり取りは、Kameleoon::KameleoonClient という名前のオブジェクトを介して行われるため、このオブジェクトを作成する必要があります。引数
スローされる例外
wait_init()
wait_init は Kameleoon クライアントの初期化を待機します。このメソッドを使用すると、他の操作に進む前にクライアントが正常に初期化されたかどうかを確認できます。
クライアントが初期化されると、wait_init は直ちに戻ります。初期構成の取得が失敗した場合、クライアントはバックグラウンドで再試行を続けるため、wait_init はいずれかの取得が成功した時点で戻ります。待機は常にタイムアウトによって制限されるため、無期限にブロックすることはありません。構成が読み込まれる前にタイムアウトが経過した場合、wait_init は false を返します。
引数
戻り値
機能フラグとバリエーション
feature_active?()
- 📨 Kameleoon にトラッキングデータを送信します(
trackパラメータに依存)
以前は
activate_feature と呼ばれていました - SDK バージョン 3.0.0 以降削除されました。visitor_code を指定すると、feature_active? メソッドは visitor_code を一意の訪問者識別子として使用します。これはクロスデバイス実験で便利です。visitor_code を指定し、is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
is_unique_identifier パラメータは非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名の visitorCode にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続された内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。引数
戻り値
スローされる例外
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 を設定します。
シミュレート されたバリエーションは、実行順序で常に優先されます。シミュレート バリエーション計算がトリガーされた場合、それが最初に完全に処理され完了します。
引数
スローされる例外
ほとんどの場合、例に示すように基本的なエラーである
KameleoonError のみを処理する必要があります。ただし、異なる種類のエラーに対応する必要がある場合は、特定の要件に基づいて個別に処理してください。さらに、信頼性を高めるためには、StandardError を含めることで一般的な言語エラーを処理できます。evaluate_audiences()
- 📨 Kameleoon にトラッキングデータを送信します
evaluate_audiences() は、関連するすべての訪問者データが設定または更新された後、かつ機能バリエーションを取得する、または機能フラグをチェックする直前に呼び出す必要があります。このアプローチにより、訪問者が利用可能な最新のデータに対して評価され、すべての基準に基づいた正確なオーディエンス割り当てが可能になります。
このメソッドを呼び出した後、Audiences Explorer でセグメントのパフォーマンスを詳細に分析できます。
引数
スローされる例外
ほとんどの場合、例に示すように基本的なエラーである
KameleoonError のみを処理する必要があります。ただし、異なる種類のエラーに対応する必要がある場合は、特定の要件に基づいて個別に処理してください。さらに、信頼性を高めるためには、StandardError を含めることで一般的な言語エラーを処理できます。get_data_file()
現在の SDK 設定をDataFile オブジェクトとして返します。
戻り値
訪問者データ
get_visitor_code()
以前は
obtain_visitor_code と呼ばれていました - SDK バージョン 3.0.0 以降削除されました。get_visitor_code ヘルパーメソッドを呼び出して、現在の訪問者の Kameleoon visitor_code を取得します。このメソッドは、ユーザー識別の精度を保証する必要があるフロントエンドとバックエンドの混在環境で Kameleoon を使用する場合に重要です。実装ロジックは以下のとおりです。
- 現在の HTTP リクエストに関連付けられた kameleoonVisitorCode クッキーまたはクエリパラメータをチェックします。見つかった場合、これを訪問者識別子として使用します。
- クッキーまたはパラメータが見つからない場合、default_visitor_code 引数をチェックします。見つかった場合、これを識別子として使用します。
default_visitor_code_により、顧客が独自の識別子を訪問者コードとして使用したい場合に使用でき、マッチングテーブルでの追加のルックアップなしに、Kameleoon の訪問者と顧客自身のユーザーをマッチングするという追加のメリットがあります。 - クッキー、パラメータ、または引数が見つからない場合、一意の識別子をランダムに生成します。
独自の
visitor_code を提供する場合、その一意性を保証する必要があります(SDK は確認できません)。また、visitor_code の長さは 255 文字に制限されていることに注意してください。それを超える文字は例外をスローします。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に対するデフォルトバリエーション(Then, for everyone else in Production, serve セクションで定義)をシミュレートします。
encodeURIComponent のようなメソッドを使用して URI コンポーネントとしてエンコードする必要があります。引数
戻り値
add_data()
add_data() メソッドは、他のメソッドが現在の訪問者をターゲットするかどうかを判断するために使用できるよう、ターゲティングデータをストレージに追加します。
add_data() メソッドは値を返さず、独立して Kameleoon バックエンドサーバーと通信することもありません。代わりに、宣言されたすべてのデータは、後で flush() メソッドを使用して送信するために保存されます。このアプローチは、データが通常 flush() でトリガーされる単一のサーバー呼び出しにまとめられるため、サーバー呼び出しの数を削減します。
track_conversion() メソッドも、flush() と同様に、以前に関連付けられたデータを送信します。get_variation() および get_variations() メソッドでも、実験ルールがトリガーされた場合に同じことが当てはまります。
引数
例外
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 は、もともと訪問者に割り当てられた匿名の visitorCode にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続された内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。引数
get_remote_data()
以前は
retrieve_data_from_remote_source と呼ばれていました - SDK バージョン 3.0.0 以降削除されました。get_remote_data() メソッドを使用すると、リモート Kameleoon サーバーに保存されている指定された siteCode(Kameleoon::KameleoonClientFactory.create() で指定)について、引数として渡された key に基づいてデータを取得できます。通常、データは Data API を使用してリモートサーバーに保存されます。このメソッドは、この目的のために高度にスケーラブルなサーバーが利用可能であることと相まって、訪問者/ユーザーごとに取得できる大量のデータを保存する便利な方法を提供します。
引数
戻り値
スローされる例外
get_remote_visitor_data()
get_remote_visitor_data() は、Kameleoon Data API から visitor_code の Kameleoon 訪問データを取得する非同期メソッドです。このメソッドは、ターゲティングの判断を行う際に他のメソッドが使用できるようにデータを保存します。
このメソッドを使用して取得したデータは、次のような場合に重要な役割を果たします。
- 他のデバイスから収集したデータを使用する。
- 過去の訪問中に訪問したページなど、ユーザーの履歴にアクセスする。
- データレイヤー変数やフロントエンドでのみ変換するゴールなど、クライアントサイドからのみアクセス可能なデータを使用する。
is_unique_identifier パラメータは非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名の visitorCode にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続された内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。引数
戻り値
get_remote_visitor_data() でのパラメータの使用
get_remote_visitor_data() メソッドは、訪問者データを取得する際にさまざまなパラメータを定義することで柔軟性を提供します。ゴール、実験、バリエーションに基づいてターゲティングする場合でも、すべてのデータ型に同じアプローチが適用されます。
たとえば、「注文取引」というゴールを完了した訪問者のデータを取得したいとします。get_remote_visitor_data() メソッド内でパラメータを指定することで、ターゲティングを絞り込めます。たとえば、過去 5 回の訪問でこのゴールを変換したユーザーのみをターゲットにしたい場合、previous_visit_amount パラメータを 5 に設定し、conversions を true に設定できます。
この例で示される柔軟性はゴールデータに限定されません。get_remote_visitor_data() メソッド内のパラメータを使用して、さまざまな訪問者の行動に関するデータを取得できます。
利用可能な
Kameleoon::Types::RemoteVisitorDataFilter のオプションのリストは以下のとおりです。get_visitor_warehouse_audience()
指定されたvisitor_code および warehouse_key を使用して、データウェアハウス内の訪問者に関連付けられたすべてのオーディエンスデータを取得します。warehouse_key は通常、内部ユーザー ID です。custom_data_index パラメータは、Kameleoon が訪問者をターゲットするために使用する Kameleoon カスタムデータに対応します。詳細については、ウェアハウスターゲティングのドキュメントを参照してください。このメソッドは CustomData オブジェクトを返し、データが訪問者に追加され、ターゲティングの目的で使用可能であることを確認します。
引数
戻り値
スローされる例外
set_legal_consent()
このメソッドを使用して、訪問者が個人データの使用について法的同意を与えたかどうかを指定する必要があります。consent パラメータを false に設定すると、トラッキングリクエストに含められるデータの種類が制限されます。このメソッドは、訪問者データを責任を持って管理しながら、法的要件や規制要件を遵守するのに役立ちます。個人データの詳細については、同意管理ポリシーを参照してください。
引数
スローされる例外
同意取り消し時の動作
consent=false で set_legal_consent() を呼び出すと、SDK は kameleoonVisitorCode クッキーを削除しません。代わりに、クッキーの有効期限の延長を停止し、自然に期限切れになるまでクッキーが保持されることを許可します。
コンプライアンス要件によりオプトアウト時にクッキーファイルを即座に削除する必要がある場合は、フレームワークのネイティブクッキー管理メソッドを使用して手動で削除する必要があります。SDK は自動的にファイルを削除しません。
ゴールとサードパーティ分析
track_conversion()
- 📨 Kameleoon にトラッキングデータを送信します
visitor_code と goal_id を必要とします。さらに、このメソッドはオプションの revenue、negative、metadata 引数も受け入れます。visitor_code は通常、実験をトリガーする際に使用したものと同じです。
track_conversion() メソッドは値を返しません。このメソッドはサーバー呼び出しが非同期で実行されるため、非ブロッキングです。
isUniqueIdentifier パラメータは非推奨です。代わりに UniqueIdentifier を使用してください。isUniqueIdentifier は、もともと訪問者に割り当てられた匿名の visitor_code にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続された内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。引数
metadata の値には、生データのエクスポートおよび結果ページを通じてアクセスできます。
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 がコマンドを処理し、アクティブな分析統合を通じて露出イベントを送信します。
このメソッドの実装に関する詳細については、ハイブリッド実験を参照してください。
- この機能を使用するには、Ruby SDK と Kameleoon の Engine.js の両方を実装します。このフローでは Engine.js はトラッキングにのみ使用されるため、非同期タグを
</body>の終了タグ直前にインストールできます。 - Kameleoon でのみ実験をトラッキングしたく、サードパーティの分析ツールに露出イベントを送信する必要がない場合は、JavaScript / TypeScript SDK を使用してください。このオプションはサーバーレスエッジコンピュートプラットフォームに適しています。JavaScript / TypeScript SDK は、
getVisitorCodeを呼び出すと、対応する実験割り当てをwindow.kameleoonQueueに追加する限り、バリエーションを自動的にトラッキングします。 - 返されたトラッキングコードは、HTML の
<script>タグに直接挿入できます。
123456 と 234567 は実験 ID で、7890 と 8901 はバリエーション ID です。実装では、SDK が返されるトラッキングコード内でこれらの値を生成します。引数
戻り値
イベント
on_update_configuration()
on_update_configuration() メソッドを使用すると、設定にデータの更新があった際のイベントを処理できます。1 つの入力パラメータ handler を受け取ります。リアルタイム設定イベントを使用して設定が更新されたときに呼び出されるハンドラです。
引数
データ型
Browser
ここに保存されているBrowser データセットは、関連付けられた任意の値で実験およびパーソナライゼーションレポートをフィルタリングするために使用できます。
PageView
リファラーのインデックス (ID) は、バックオフィスの取得チャネル設定ページで確認できます。注意: このインデックスは 0 から始まるため、サイトに対して最初に作成した取得チャネルの ID は 1 ではなく 0 になります。
Conversion
ここに保存されているConversion データセットは、関連付けられた任意のゴールで実験およびパーソナライゼーションレポートをフィルタリングするために使用できます。
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 は、もともと訪問者に割り当てられた匿名の visitorCode にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続された内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。
OperatingSystem
OperatingSystem には訪問者のオペレーティングシステムに関する情報が含まれます。
各訪問者は、
OperatingSystem を 1 つしか持つことができません。2 つ目の OperatingSystem を追加すると、最初のものが上書きされます。Cookie
Cookie には、訪問者のデバイスに保存されているクッキーに関する情報が含まれます。
各訪問者は、
Cookie を 1 つしか持つことができません。2 つ目の Cookie を追加すると、最初のものが上書きされます。Geolocation
Geolocation には訪問者のジオロケーション詳細が含まれます。
ApplicationVersion
ApplicationVersion は、アプリケーションのセマンティックバージョン番号を表します。
戻り値の型
DataFile
DataFile には SDK 設定の詳細が含まれます。
顧客が必要とする場合、追加情報で拡張できます。さらに詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
FeatureFlag
FeatureFlag は、機能フラグ自体を定義する一連のプロパティを表します。たとえば、その Variations、Rules、環境ステータス、その他の関連する詳細などです。
顧客が必要とする場合、追加情報で拡張できます。さらに詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
Rule
Rule は、ルール自体を定義する一連のプロパティを表します。たとえば、その Variations などです。
顧客が必要とする場合、追加情報で拡張できます。さらに詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
Variation
Variation には、訪問者に割り当てられたバリエーション(または、特定の割り当てが存在しない場合はデフォルトバリエーション)に関する情報が含まれます。
Variationオブジェクトは、割り当てられたバリエーションとそれに関連する実験に関する詳細を提供しますが、Variableオブジェクトには、バリエーション内の各変数に関する具体的な詳細が含まれます。idまたはexperiment_idがnilの場合(デフォルトバリエーションを示す)を、コードが処理することを確認してください。- バリエーションに変数が関連付けられていない場合、
variablesハッシュは空になる可能性があります。
Variable
Variable には、割り当てられたバリエーションに関連付けられた変数に関する情報が含まれます。
非推奨のメソッド
get_feature_variation_key()
- 📨 Kameleoon にトラッキングデータを送信します
代わりに
get_variation() を使用してください。get_feature_variation_key メソッドを呼び出します。
このメソッドは、visitor_code と feature_key を必須引数として受け取り、ユーザーのバリエーションキーを取得します。
そのようなユーザーがこの機能フラグに関連付けられたことがない場合、SDK はバリエーションキーをランダムに返します(機能フラグのルールに従って)。指定された visitor_code のユーザーがこの機能フラグで既に登録されている場合、以前の variation key 値を検出します。ユーザーがどのルールにも一致しない場合は、顧客のアカウントで定義できるデフォルト値が返されます。
潜在的な例外をキャッチするために、右の例に示すようにコードに適切なエラー処理が設定されていることを確認する必要があります。
visitor_code を指定すると、get_feature_variation_key メソッドは visitor_code を一意の訪問者識別子として使用します。これはクロスデバイス実験に便利です。visitor_code を指定し、is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
is_unique_identifier パラメータは非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名の visitorCode にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続された内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。引数
戻り値
スローされる例外
get_active_feature_list_for_visitor()
代わりに
get_active_features() を使用してください。visitorCode のみを受け取ります。結果には、指定された訪問者に対してアクティブな機能フラグのみが含まれます。
引数
戻り値
スローされる例外
get_active_features()
get_active_features メソッドは、指定された訪問者コードで利用可能なアクティブな機能フラグに関する情報を取得します。
このメソッドは非推奨であり、SDK バージョン
4.0.0 で削除されます。代わりに get_variations() を使用してください。引数
戻り値
スローされる例外
get_feature_variable()
- 📨 Kameleoon にトラッキングデータを送信します
代わりに
get_variation() を使用してください。以前は
obtain_feature_variable と呼ばれていました - SDK バージョン 2.1.0 以降非推奨で、将来のリリースで削除されます。get_feature_variable メソッドを呼び出します。
このメソッドは、visitor_code、feature_key、および variable_name を必須引数として受け取り、指定されたユーザーのバリエーションキーの変数を取得します。
そのようなユーザーがこの機能フラグに関連付けられたことがない場合、SDK はバリエーションキーの変数値をランダムに返します(機能フラグのルールに従って)。指定された visitor_code のユーザーがこの機能フラグで既に登録されている場合、以前に関連付けられた variation の variable 値を検出します。ユーザーがどのルールにも一致しない場合、デフォルトの変数が返されます。
潜在的な例外をキャッチするために、右の例に示すようにコードに適切なエラー処理が設定されていることを確認する必要があります。
visitor_code を指定すると、get_feature_variable メソッドは visitor_code を一意の訪問者識別子として使用します。これはクロスデバイス実験に便利です。visitor_code を指定し、is_unique_identifier パラメータを true に設定すると、SDK はフラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。
is_unique_identifier パラメータは非推奨です。代わりに UniqueIdentifier を使用してください。is_unique_identifier は、もともと訪問者に割り当てられた匿名の visitorCode にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続された内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。引数
戻り値
スローされる例外
get_feature_variation_variables()
代わりに
get_variation() を使用してください。get_feature_variation_variables メソッドを呼び出します。機能変数は Web アプリケーションを使用して変更できます。
このメソッドは、feature_key と variation_key を必須引数として受け取ります。Web インターフェイスで定義されたオブジェクト型のデータを返します。リクエストされた機能フラグが SDK のクライアント設定で見つからない場合、エラー (FeatureNotFound) をスローします。バリエーションキーが見つからない場合、メソッドは (FeatureVariationNotFound) エラーをスローします。