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

開発者ガイド

このセクションでは、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 テストを実装する際、開発者はアプリケーションコードの正しいロジックを確保する責任があります。ベストプラクティスとしては、実験がまだ起動されていない場合に訪問者が実験から除外される可能性があると常に想定することです。これはデフォルトまたはリファレンスバリエーションのロジック(常に存在するべきもの)と整合するため、実装は容易です。次のセクションのコードサンプルはこのアプローチを示しています。
Ruby on Rails を使用している場合は、application.rb ファイルでサーバー起動時に Kameleoon クライアントを初期化することをお勧めします。
その後、コントローラ内で Kameleoon クライアントにアクセスできます。

機能フラグの有効化

ユーザーへの一意な 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_keyvisitor_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_codegoal_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) データを追加 - 別の訪問者に関連付けられた特定の訪問者のデータをトラッキングします。
識別子として使用するカスタムデータは Visitor スコープ に設定する必要があるため、クロスデバイスのカスタムデータ同期を使用して、各デバイスで get_remote_visitor_data() メソッドにより識別子を取得する必要があります。
セッションマージのためにカスタムデータを使用する方法の例を以下に示します。
この例では、アプリケーションにログインページがあります。ログイン時点ではユーザー ID が不明なため、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)を指します。
カスタムバケッティングキーが正しく機能するためには、フラグの作成または編集プロセス中に機能フラグに対して定義および設定されている必要があります。対応する設定がない場合、SDK のバケッティングはカスタムキーを適用しません。Kameleoon でこれを設定する詳細な手順については、こちらの記事を参照してください。
  • バケッティングロジック: 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_initfalse を返します。
引数
戻り値

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

feature_active?()

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

get_variation()

  • 📨 Kameleoon にトラッキングデータを送信します(track パラメータに依存)
特定の機能フラグについて、指定された訪問者に割り当てられた Variation を取得します。 このメソッドは、visitor_codefeature_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 を返します。 潜在的な例外を管理するために適切なエラー処理を実装する必要があります。
デフォルトバリエーションとは、訪問者が機能フラグの事前定義された配信ルールのいずれにも一致しない場合に割り当てられるバリエーションを指します。つまり、特定のルールでターゲティングされていないすべてのユーザーに適用されるフォールバックバリエーションです。これは管理画面の「その他のすべてに対して…」セクションのバリエーションとして表されます。
引数
戻り値
スローされる例外

set_forced_variation()

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

evaluate_audiences()

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

get_data_file()

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

訪問者データ

get_visitor_code()

以前は obtain_visitor_code と呼ばれていました - SDK バージョン 3.0.0 以降削除されました。
get_visitor_code ヘルパーメソッドを呼び出して、現在の訪問者の Kameleoon visitor_code を取得します。このメソッドは、ユーザー識別の精度を保証する必要があるフロントエンドとバックエンドの混在環境で Kameleoon を使用する場合に重要です。実装ロジックは以下のとおりです。
  1. 現在の HTTP リクエストに関連付けられた kameleoonVisitorCode クッキーまたはクエリパラメータをチェックします。見つかった場合、これを訪問者識別子として使用します。
  2. クッキーまたはパラメータが見つからない場合、default_visitor_code 引数をチェックします。見つかった場合、これを識別子として使用します。default_visitor_code_ により、顧客が独自の識別子を訪問者コードとして使用したい場合に使用でき、マッチングテーブルでの追加のルックアップなしに、Kameleoon の訪問者と顧客自身のユーザーをマッチングするという追加のメリットがあります。
  3. クッキー、パラメータ、または引数が見つからない場合、一意の識別子をランダムに生成します。
すべての場合において、サーバーサイド(HTTP ヘッダー経由)の kameleoonVisitorCode クッキーがその値で設定されます。後の訪問では、設定した識別子がメソッドが返す値となります。 詳細については、こちらの記事を参照してください。
独自の 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() メソッドでも、実験ルールがトリガーされた場合に同じことが当てはまります。
ほとんどのデータ型については、各訪問者は関連付けられたデータのインスタンスを 1 つしか持てません。ただし、CustomData は例外です。訪問者はインデックスごとに関連付けられた CustomData のインスタンスを 1 つ持つことができます。
引数
例外

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 訪問データを取得する非同期メソッドです。このメソッドは、ターゲティングの判断を行う際に他のメソッドが使用できるようにデータを保存します。 このメソッドを使用して取得したデータは、次のような場合に重要な役割を果たします。
  • 他のデバイスから収集したデータを使用する。
  • 過去の訪問中に訪問したページなど、ユーザーの履歴にアクセスする。
  • データレイヤー変数やフロントエンドでのみ変換するゴールなど、クライアントサイドからのみアクセス可能なデータを使用する。
可能なユースケースをより理解するために、こちらの記事をお読みください。
デフォルトでは、get_remote_visitor_data()scope=Visitor で最新の保存済みカスタムデータを自動的に取得し、add_data() メソッドを呼び出さずに訪問者に添付します。これは、複数のデバイス間でカスタムデータを同期する場合に特に便利です。
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 オブジェクトを返し、データが訪問者に追加され、ターゲティングの目的で使用可能であることを確認します。
引数
戻り値
スローされる例外
このメソッドを使用して、訪問者が個人データの使用について法的同意を与えたかどうかを指定する必要があります。consent パラメータを false に設定すると、トラッキングリクエストに含められるデータの種類が制限されます。このメソッドは、訪問者データを責任を持って管理しながら、法的要件や規制要件を遵守するのに役立ちます。個人データの詳細については、同意管理ポリシーを参照してください。
引数
スローされる例外
同意取り消し時の動作
consent=falseset_legal_consent() を呼び出すと、SDK は kameleoonVisitorCode クッキーを削除しません。代わりに、クッキーの有効期限の延長を停止し、自然に期限切れになるまでクッキーが保持されることを許可します。 コンプライアンス要件によりオプトアウト時にクッキーファイルを即座に削除する必要がある場合は、フレームワークのネイティブクッキー管理メソッドを使用して手動で削除する必要があります。SDK は自動的にファイルを削除しません。

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

track_conversion()

  • 📨 Kameleoon にトラッキングデータを送信します
このメソッドを使用して、特定のゴールとユーザーのコンバージョンをトラッキングします。このメソッドは visitor_codegoal_id を必要とします。さらに、このメソッドはオプションの revenuenegativemetadata 引数も受け入れます。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> タグに直接挿入できます。
この例では、123456234567 は実験 ID で、78908901 はバリエーション ID です。実装では、SDK が返されるトラッキングコード内でこれらの値を生成します。
引数
戻り値

イベント

on_update_configuration()

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

データ型

Browser

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

PageView

リファラーのインデックス (ID) は、バックオフィスの取得チャネル設定ページで確認できます。注意: このインデックスは 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 は、もともと訪問者に割り当てられた匿名の visitorCode にアクセスできないが、セッションマージ機能を使用して匿名訪問者と接続された内部 ID にアクセスできる場合など、他のエッジケースシナリオでも役立ちます。

OperatingSystem

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

Geolocation

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

ApplicationVersion

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

戻り値の型

DataFile

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

FeatureFlag

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

Rule

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

Variation

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

Variable

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

非推奨のメソッド

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

get_feature_variation_key()

  • 📨 Kameleoon にトラッキングデータを送信します
代わりに get_variation() を使用してください。
機能バリエーションキーを取得するには、get_feature_variation_key メソッドを呼び出します。 このメソッドは、visitor_codefeature_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_codefeature_key、および variable_name を必須引数として受け取り、指定されたユーザーのバリエーションキーの変数を取得します。 そのようなユーザーがこの機能フラグに関連付けられたことがない場合、SDK はバリエーションキーの変数値をランダムに返します(機能フラグのルールに従って)。指定された visitor_code のユーザーがこの機能フラグで既に登録されている場合、以前に関連付けられた variationvariable 値を検出します。ユーザーがどのルールにも一致しない場合、デフォルトの変数が返されます。 潜在的な例外をキャッチするために、右の例に示すようにコードに適切なエラー処理が設定されていることを確認する必要があります。 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_keyvariation_key を必須引数として受け取ります。Web インターフェイスで定義されたオブジェクト型のデータを返します。リクエストされた機能フラグが SDK のクライアント設定で見つからない場合、エラー (FeatureNotFound) をスローします。バリエーションキーが見つからない場合、メソッドは (FeatureVariationNotFound) エラーをスローします。
引数
戻り値
スローされる例外

get_feature_list()

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