0.8.5。リリースノートについては C++ SDK 変更履歴 を、すべての SDK については SDK 変更履歴インデックス を参照してください。
SDK メソッド: C++ SDK の完全なリファレンスドキュメントについては、リファレンスセクションを参照してください。
開発者ガイド
このガイドは、C++ SDK を迅速に統合し、C++ アプリケーションでフィーチャーフラグの評価を開始できるように設計されています。はじめに
C++ クライアントのインストール
C++ SDK は、Kameleoon SDK Core の上に構築された C++17 ライブラリです。SDK Core は、SDK の動作を実装する Rust 製のネイティブ共有ライブラリ(libkameleoon_ffi)です。アプリケーションは C++ ライブラリを静的にリンクし、コアライブラリを実行時にロードします。
要件:
- C++17 コンパイラ(GCC、Clang、または MSVC)と CMake 3.16 以降。
- SDK Core ライブラリ(Linux では
libkameleoon_ffi.so、macOS ではlibkameleoon_ffi.dylib、Windows ではインポートライブラリkameleoon_ffi.dll.libを伴うkameleoon_ffi.dll)をビルドするための Rust 1.91 以降、Cargo、およびcbindgen。
add_subdirectory() で cpp/client ディレクトリを追加し、Kameleoon::CppClient ターゲットをリンクします。KAMELEOON_FFI_LIBRARY をビルドしたコアライブラリに向けてください。C ヘッダーは cbindgen で生成されますが、既存のヘッダーを KAMELEOON_FFI_HEADER で渡すこともできます:
CMakeLists.txt
libkameleoon_ffiは実行時にロードされます。標準のライブラリ配置場所にインストールするか、実行ファイルの隣に配置してください。Linux および macOS では、実行ファイルの隣に配置する場合、$ORIGINまたは@loader_pathの RPATH が必要です(たとえば、set_target_properties(my_app PROPERTIES INSTALL_RPATH "$ORIGIN"))。Windows では、kameleoon_ffi.dllをバイナリの隣にコピーします。- クライアントを作成すると、SDK はロードされた
libkameleoon_ffiがビルド時のバージョンと一致するかどうかを確認し、一致しない場合はErrorCode::Internalを伴うKameleoonExceptionをスローします。C++ ライブラリとコアライブラリは常に一緒にアップグレードしてください。 - すべての公開 SDK 型は
kameleoon名前空間にあります。公開 API 全体を取得するにはkameleoon/kameleoon.hppをインクルードしてください。
追加の構成
認証情報を提供し、SDK の動作をカスタマイズするために、JSON 構成ファイル(たとえば、client-cpp.json)を作成します。サンプル構成ファイル をダウンロードすることもできます。
C++ SDK は、パスを KameleoonClientFactory::create() に渡す JSON ファイル、またはコード内で直接 KameleoonClientConfig 構造体に値を設定することで構成できます。
次の表は、設定可能なプロパティを示しています:
Kameleoon クライアントの初期化
SDK をインストールし、認証情報を構成したら、KameleoonClientFactory を使用して KameleoonClient を作成します。
- 構成ファイル
- コード
このページの例では、SDK の構成、オプション、およびデータ構造体に値を設定するために、C++20 の 指示付き初期化子(
GetVariationOptions{.track = false})を使用しています。C++17 コンパイラの場合は、構造体を宣言し、フィールドを 1 つずつ設定してください。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_millis に基づいて自動的にトリガーされます。デフォルトでは、この間隔は 1000 ミリ秒(1 秒)に設定されています。
get_variation() メソッドを使用すると、SDK が訪問者をトラッキングするかどうかを制御できます。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_millis で定義)と共に送信されます。リクエストを即座に送信したい場合は、flush_instant() メソッドを使用してください。
分析ソリューションへのイベント送信
コンバージョンをトラッキングし、露出イベントを顧客分析ソリューションに送信するには、まず Kameleoon を ハイブリッドモード で実装する必要があります。その後、get_engine_tracking_code() メソッドを使用します。
get_engine_tracking_code() メソッドは、露出イベントを分析ソリューションに送信するために必要な一意のトラッキングコードを取得します。このメソッドを使用すると、イベントを記録し、希望の分析プラットフォームに送信できます。
エラー処理
SDK が発生させるすべてのエラーはKameleoonException であるため、この型に対する単一のハンドラーで SDK のすべての失敗をキャッチできます。アプリケーションが特定の失敗に対応する必要がある場合は、特定のエラータイプを処理してください。たとえば、フィーチャーフラグが構成に含まれていない場合や SDK がまだ初期化されていない場合に、デフォルトの動作にフォールバックするなどです。各メソッドのリファレンスセクションに、発生する可能性のあるエラーが一覧表示されています。
KameleoonException は std::runtime_error から派生しています。エラーを区別する ErrorCode を取得するには code() を、メッセージを取得するには what() を呼び出します。
SDK に渡す文字列は有効な UTF-8 でなければなりません。SDK に提供するコールバック(
CookieAccessor のオーバーライド、イベントハンドラー、ロガー)は例外をスローしてはいけません。コールバックから脱出した例外は SDK の境界でキャッチされ、破棄されます。SDK のエラーはクラッシュではなく、想定された動作です。まだアクティブ化されていないフィーチャーフラグ、構成をまだロード中の SDK、ネットワークの失敗はすべて正常な状態です。フィーチャー評価が失敗した場合は、エラーをログに記録し、訪問者が引き続き正常な体験を得られるようにデフォルトの動作にフォールバックしてください。
非同期操作
ネットワークに依存する操作(initialize()、flush_instant()、get_remote_data()、get_remote_visitor_data()、および get_visitor_warehouse_audience())は、SDK 独自のワーカースレッドで実行されます。それぞれ 3 つの形式があり、呼び出し元のスレッドに合ったものを選択できます:
Completion<void>(std::function<void(std::exception_ptr)>)、または値を返す操作の場合は Completion<T>(std::function<void(std::exception_ptr, T)>)です。SDK はこれを正確に 1 回呼び出します。コンプリーションを省略して、操作をファイアアンドフォーゲットで実行することもできます。その場合、失敗は SDK のログにのみ記録されます。
C++20 には組み込みのコルーチンタスク型がないため、
co_await は、プロミス型が SDK の Awaitable<T> を受け入れるコルーチン内でのみ機能します(コルーチンが利用可能な場合、KAMELEOON_HAS_COROUTINES が kameleoon/async.hpp によって定義されます)。デフォルトでは、コルーチンは SDK のワーカースレッドで再開されます。代わりに独自のイベントループで再開するには、アウェイタブルの .via(executor) を呼び出します。Boost.Asio などの独自のコルーチン型を持つフレームワークでは、コンプリーション形式の周りに小さなアダプターが必要です。SDK に同梱されているサーバー例を参照してください。get_visitor_code()、get_variation()、get_variations()、is_feature_active()、add_data()、track_conversion()、および flush())は同期的なインメモリ呼び出しであり、これらは一切不要です。
カスタムバケットキーの使用
デフォルトでは、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と共に送信および関連付けられることに注意することが重要です。この分離により、バケッティングが上位レベル(アカウントなど)で実行されたり、複数のデバイス/セッションにまたがって実行されたりする場合でも、分析が個々のユーザージャーニーと、より広い実験コンテキスト内でのインタラクションを正確に反映するようになります。元の訪問者データは、包括的なレポートのために維持されます。
技術要件
カスタムバケットキーを効果的に使用するには:- キーは
std::stringでなければなりません。 - バケッティングの対象となるエンティティに対して一意でなければなりません(たとえば、
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 はデフォルトでログをコンソール出力に書き込みます。この動作はオーバーライドできます。ログレベルによるロギング制限は、ログハンドリングロジックとは別に実行されます。
リファレンス
これは C++ SDK の完全なリファレンスドキュメントです。初期化
create()
SDK を使用するには、KameleoonClientFactory::create() を使用して、KameleoonClientConfig 構造体または JSON 構成ファイルから KameleoonClient を作成します。
クライアントはサイトコードと環境ごとにキャッシュされます。同じサイトコードと環境で create() を繰り返し呼び出すと、同じ基盤 SDK インスタンス上のクライアントが返され、最初の呼び出しの構成が優先されます。
- create(config struct)
- create(config file)
パラメーター
戻り値
例外
initialize()
アプリケーションがフィーチャーフラグを評価する前に Kameleoon クライアントの初期化完了を待つ必要がある場合は、initialize() を使用します。
この呼び出しは構成フェッチの結果を返します。クライアントの初期化が完了すると正常に完了し、クライアントが準備できる前に初回の構成フェッチが失敗すると失敗します。その最初の失敗の後も、バックグラウンドでの再試行は継続されます。再試行が成功すると、以降の呼び出しは成功した結果を返します。タイムアウトが切れる前に初期化結果が得られない場合、呼び出しは失敗します。timeout 値を提供しない場合、SDK は default_timeout_millis のデフォルトタイムアウトを使用します。
パラメーター
戻り値
例外
is_ready()
is_ready() は、SDK が使用可能な状態、つまり構成が正常にロードされているかどうかを確認します。initialize() とは異なり、このメソッドはブロックやスローをせずに即座に戻ります。
戻り値
forget()
指定されたsite_code に関連付けられたキャッシュされた SDK クライアントを削除し、同じサイトコードと環境での次の create() 呼び出しで新しいクライアントが作成されるようにします。
forget() はファクトリの参照を破棄するだけです。そのサイトコード用に作成されたすべての KameleoonClient は、破棄されるまで基盤となる SDK インスタンス(およびそのワーカースレッド、ポーリング、トラッキング)を保持し、未完了の非同期操作は、そのコンプリーションが完了するまでインスタンスを保持します。バックグラウンドリソースを解放するには、forget() を呼び出し、そのサイトコードのすべての KameleoonClient インスタンスを破棄してください。
パラメーター
フィーチャーフラグとバリエーション
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 を返します。
潜在的な例外を管理するため、コード内で適切なエラー処理を実装してください。
デフォルトバリエーションとは、訪問者がフィーチャーフラグの事前定義された配信ルールのいずれにも一致しない場合に割り当てられるバリエーションのことです。言い換えると、特定のルールでターゲット指定されていないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェイスの「その他すべてのユーザーには…」セクションのバリエーションとして表されます。
パラメーター
オプションの
track パラメータは、GetVariationOptions 構造体の track フィールドとして渡されます。戻り値
例外
get_variations()
- 📨 Kameleoon にトラッキングデータを送信します(
trackパラメータに依存)
Variation オブジェクトのマップを取得します。
このメソッドは、利用可能なすべてのフィーチャーフラグを反復処理し、指定された訪問者に関連付けられた各フラグに割り当てられた Variation を返します。visitor_code を必須引数として受け取り、only_active と track は任意です。
only_activeをtrueに設定すると、get_variations()メソッドは、訪問者がoffバリエーションにバケット化されていない場合にのみフィーチャーフラグのバリエーションを返します。trackパラメータは、メソッドがバリエーションの割り当てをトラッキングするかどうかを制御します。デフォルトではtrueです。falseの場合、メソッドはバリエーションの割り当てをトラッキングしません。
Variation を値として構成されます。SDK がフィーチャーフラグにバリエーションを割り当てない場合、メソッドはそのフラグのデフォルトの Variation を返します。
潜在的な例外を管理するために、適切なエラー処理を実装してください。
デフォルトバリエーションとは、フィーチャーフラグの事前定義された配信ルールのいずれにも一致しない訪問者に割り当てられるバリエーションを指します。言い換えれば、特定のルールの対象にならないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェースの「Then, for everyone else…」セクションのバリエーションとして表されます。
パラメーター
オプションの
only_active および track パラメータは、GetVariationsOptions 構造体のフィールドとして渡されます。戻り値
例外
set_forced_variation()
このメソッドを使用すると、標準の評価プロセスをバイパスして、特定のVariation をユーザーにプログラムで割り当てることができます。このメソッドは、通常の評価ロジックが不要な場合やスキップする必要がある制御された実験で特に役立ちます。また、デバッグやカスタムテストのようなシナリオでも役立ちます。
強制バリエーションを設定すると、Kameleoon のリアルタイム評価ロジックがオーバーライドされます。SDK は、セグメンテーション、ターゲティング条件、アルゴリズム計算などのプロセスをスキップします。実験中にセグメンテーションとターゲティング条件を保持するには、代わりに force_targeting=false を設定してください。
シミュレートされたバリエーションは、実行順序において常に優先されます。シミュレートされたバリエーションの計算が開始されると、SDK はまずそれを完全に処理して完了させます。
パラメーター
オプションの
force_targeting パラメータは、SetForcedVariationOptions 構造体の force_targeting フィールドとして渡されます。例外
evaluate_audiences()
- 📨 Kameleoon にトラッキングデータを送信します
evaluate_audiences() は、関連するすべての訪問者データを設定または更新した後、かつフィーチャーバリエーションの取得やフィーチャーフラグのチェックの直前に呼び出してください。このアプローチにより、Kameleoon は利用可能な最新のデータに対して訪問者を評価し、すべての基準に基づいた正確なオーディエンス割り当てが可能になります。
このメソッドを呼び出した後、Audiences Explorer でセグメントのパフォーマンスの詳細な分析を実行できます。
パラメーター
例外
ほとんどの場合、例に示すように、基本的なエラーである
KameleoonException を処理するだけで十分です。ただし、異なる種類のエラーに対応が必要な場合は、特定の要件に基づいてそれぞれを個別に処理してください。さらに、信頼性を高めるために、std::exception を含めることで一般的な言語エラーを処理できます。get_datafile()
現在の SDK 構成をDataFile オブジェクトとして返します。
返される DataFile は現在の構成のコピーです。SDK が構成を更新しても変更されません。
戻り値
例外
訪問者データ
get_visitor_code()
get_visitor_code() を使用して、現在の訪問者の Kameleoon visitor_code を取得します。このメソッドは、CookieAccessor インターフェースを実装する任意の Cookie ストアで動作します。
実装ロジックは次のとおりです:
- SDK は、提供されたアクセサを通じて
kameleoonVisitorCodeCookie がすでに利用可能かどうかを確認します。 - Cookie が存在しない場合、
default_visitor_codeを提供していれば、SDK はそれを使用します。 - それ以外の場合、SDK は新しい訪問者コードを生成し、アクセサを通じて保存します。
get_visitor_code() メソッドを使用すると、訪問者にシミュレートされたバリエーションを設定できます。Cookie(リクエストまたはドキュメントから)にキー kameleoonSimulationFFData が含まれている場合、メソッドは Cookie を読み取り、その訪問者のシミュレートされたバリエーションを保存します。戻り値は変わりません。その後、get_variation() や is_feature_active() などのその訪問者に対するフィーチャー評価は、標準の評価プロセスをバイパスし、提供されたデータに基づいてシミュレートされた Variation を返します。シミュレーションは 2 つの方法で適用できます:- 自動(推奨): Kameleoon Web Experimentation またはハイブリッドモードで SDK を使用している場合、シミュレーションパネルを使用してバリアントの表示をシミュレートすると、Kameleoon は自動的に Cookie を作成します。
- 手動:
kameleoonSimulationFFDataCookie を手動で設定します。
- シミュレートされたバリエーション: フィーチャーフラグ全体の結果に影響します。
- 強制バリエーション: 個々の実験に固有です。
kameleoonSimulationFFData Cookie が次の形式に従っていることを確認してください:kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: 指定されたfeatureKeyに対して、実験expIdのvarIdのバリエーションをシミュレートします。kameleoonSimulationFFData={"featureKey":{"expId":0}}: 指定されたfeatureKeyに対して、デフォルトバリエーション(Then, for everyone else in Production, serve セクションで定義)をシミュレートします。
encodeURIComponent などのメソッドを使用して URI コンポーネントとしてエンコードしてください。CookieAccessor インターフェース
kameleoon::CookieAccessor を実装して、SDK の Cookie の読み取りと書き込みを HTTP フレームワークに橋渡しします:
get()は、同じ名前のリクエスト Cookie よりも、レスポンスでset()を通じてすでに書き込まれた Cookie を優先して返す必要があります。SDK は呼び出し間で Cookie の状態を保持しないため、これにより、同じリクエスト内での 2 回目のget_visitor_code()呼び出しが、新しいコードを生成するのではなく、1 回目の呼び出しで書き込まれたコードを返すようになります。- オーバーライドは SDK 内部から呼び出されるため、例外をスローしてはいけません。
get()から漏れた例外は、Cookie が存在しないものとして扱われます。Cookie 値は有効な UTF-8 である必要があります。
- Custom
- Drogon
パラメーター
戻り値
例外
add_data()
add_data() メソッドは、ターゲティングデータをストレージに追加し、他のメソッドがそのデータを使用して現在の訪問者をターゲットにするかどうかを判断できるようにします。
add_data() メソッドは値を返さず、単独では Kameleoon のバックエンドサーバーとやり取りしません。代わりに、SDK は宣言されたすべてのデータを flush() メソッドを使用した将来の送信のために保存します。このアプローチにより、データは通常、flush() によってトリガーされる単一のサーバー呼び出しにグループ化されるため、サーバー呼び出しの回数が削減されます。
track_conversion() メソッドも、flush() と同様に、以前に関連付けられたデータをすべて送信します。実験ルールがトリガーされた場合、get_variation() および get_variations() メソッドについても同様です。
data パラメータは std::vector<Data> です。ここで、Data はすべてのデータ型の std::variant です。各データ型は暗黙的に Data に変換されるため、波括弧で囲んだデータオブジェクトのリストを渡すことができます。
パラメーター
例外
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 を通じて書き込まれ、追加のアプリコンテキストが必要になったときに C++ サービスから後で取得できます。
このメソッドは、構造化された情報を Kameleoon のリモートインフラストラクチャに保持し、別個の取得メカニズムを維持することなくバックエンドから再利用したい場合に便利です。
パラメーター
戻り値
例外
get_remote_visitor_data()
get_remote_visitor_data() は、提供された visitor_code の Kameleoon 訪問データを取得します。このメソッドはデータをローカルの訪問者ストレージに追加し、他の SDK メソッドがターゲティングの判断に使用できるようにします。
このメソッドを使用して取得したデータは、次のような場合に特に役立ちます:
- 他のデバイスから収集したデータを使用する。
- 過去の訪問で以前に表示されたページなど、訪問者の履歴にアクセスする。
- datalayer 変数やフロントエンドの目標コンバージョンなど、クライアント側でのみ利用可能なデータを使用する。
パラメーター
例外
get_remote_visitor_data() でのパラメータの使用
get_remote_visitor_data() メソッドを使用すると、訪問者に対してどのデータを取得するかを制御できます。同じフィルタリングアプローチが、目標、実験、バリエーション、およびその他の訪問者データ全体で機能します。
たとえば、直近 5 回の訪問中に目標でコンバージョンしたユーザーをターゲットにしたい場合、previous_visit_amount を 5 に、conversions を true に設定できます。
この例で示した柔軟性は、目標データに限定されません。フィルターを使用して、さまざまな訪問者の行動を取得し、C++ アプリのターゲティングおよびレポートロジックで利用できるようにすることができます。
RemoteVisitorDataFilter フィールド
get_visitor_warehouse_audience()
このメソッドは、指定されたvisitor_code と、オプションで warehouse_key を使用して、ウェアハウス統合内で訪問者に関連付けられたオーディエンスデータを取得します。warehouse_key は通常、内部のユーザー ID です。custom_data_index パラメータは、Kameleoon が訪問者のターゲティングに使用する Kameleoon カスタムデータに対応します。
呼び出しが成功すると、SDK は返されたオーディエンスリストを CustomData に変換し、訪問者にローカルで追加して、ターゲティングの目的で利用できるようにします。背景の詳細については、ウェアハウスターゲティングのドキュメントを参照してください。
パラメーター
例外
set_legal_consent()
訪問者が個人データの使用に法的同意を与えたかどうかを指定するには、このメソッドを使用する必要があります。consent を false に設定すると、トラッキングリクエストに含めることができるデータの種類が制限されます。これにより、訪問者データを責任を持って管理しながら、法的および規制上の要件を遵守できます。詳細については、同意管理ポリシーを参照してください。
CookieAccessor を渡すと、SDK は同意ステータスに従って訪問者の Cookie も更新します。
パラメーター
例外
同意撤回時の動作
consent=false で set_legal_consent() を呼び出した場合、SDK は kameleoonVisitorCode Cookie を削除しません。代わりに、Cookie の有効期限の延長を停止し、Cookie が自然に期限切れになるまで保持されるようにします。
コンプライアンス要件により、オプトアウト時に Cookie ファイルの即時削除が求められる場合は、フレームワークのネイティブな Cookie 管理メソッドを使用して手動で削除する必要があります。SDK はファイルを自動的に削除しません。
目標とサードパーティ分析
track_conversion()
- 📨 Kameleoon にトラッキングデータを送信します
visitor_code と goal_id が必要です。さらに、このメソッドはオプションの revenue、negative、metadata 引数も受け取ります。visitor_code は通常、実験をトリガーしたときに使用したものと同一です。
パラメーター
オプションの
revenue、negative、metadata パラメータは、TrackConversionOptions 構造体のフィールドとして渡されます。メタデータの値には、生データエクスポートと結果ページからアクセスできます。
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 がコマンドを処理し、アクティブな分析統合を通じてエクスポージャーイベントを送信します。
このメソッドの実装の詳細については、ハイブリッド実験を参照してください。
- この機能を使用するには、C++ SDK と Kameleoon Engine.js の両方を実装してください。このフローは Engine.js をトラッキングのみに使用するため、非同期タグは閉じタグ
</body>の前にインストールできます。 - Kameleoon でのみ実験をトラッキングし、サードパーティの分析ツールにエクスポージャーイベントを送信する必要がない場合は、JavaScript / TypeScript SDK を使用してください。このオプションは、サーバーレスエッジコンピューティングプラットフォームに適しています。対応する実験の割り当てを
window.kameleoonQueueに追加している限り、JavaScript / TypeScript SDK はgetVisitorCodeを呼び出すと自動的にバリエーションをトラッキングします。 - 返されたトラッキングコードは、HTML の
<script>タグに直接挿入できます。
123456 と 234567 は実験 ID、7890 と 8901 はバリエーション ID です。実装では、SDK が返されるトラッキングコード内にこれらの値を生成します。パラメーター
戻り値
例外
イベント
set_event_handler()
このメソッドを使用して、SDK イベントのハンドラーを登録します。選択したイベントが発生すると、SDK はハンドラーを呼び出します。クライアントは、イベントタイプごとに最大 1 つのハンドラーを保持します。同じイベントタイプに新しいハンドラーを登録すると、以前のハンドラーが置き換えられます。 使用するEventHandler コンストラクタ(EventHandler::datafile_update() または EventHandler::http_request())がイベントタイプを選択するため、ハンドラーとそれが受け取るイベントが同期しなくなることはありません。空の std::function({})を渡すと、選択したイベントタイプの現在のハンドラーが削除されます。
- datafile_update
- http_request
ハンドラーは SDK の単一のワーカースレッド上で同期的に呼び出されるため、ブロックしてはいけません。ハンドラー内で費やされた時間は、データファイルのポーリングとトラッキングのフラッシュを遅延させます。ハンドラーはスレッドセーフであり、例外をスローしてはいけません。ハンドラーから漏れた例外はキャッチされて破棄され、SDK の動作に影響を与えることはありません。ハンドラーからブロッキングする SDK 操作を呼び出さないでください。代わりに
*_async 形式を使用し、アプリケーションスレッドで作業を完了させてください。すでに進行中の呼び出しは、ハンドラーをクリアした後やクライアントを破棄した後に完了する場合があり、ハンドラー(およびそのキャプチャ)は、使用されなくなった時点で SDK スレッド上で破棄されます。キャプチャされたオブジェクトは、それに応じて存続させ、スレッドセーフに保ってください。ハンドラーは自分自身をクリアまたは置き換えることができます。同じサイトコードと環境に対して作成されたすべての KameleoonClient インスタンスは、イベントタイプごとに 1 つのハンドラーを共有します。最後に設定されたハンドラーが優先され、それらのインスタンスのいずれかを破棄するとクリアされます。サイトコードと環境ごとに単一のクライアントインスタンスを保持してください。パラメーター
データ型
このセクションでは、SDK がkameleoon 名前空間(kameleoon/data/*.hpp)で宣言する C++ データ型を一覧します。これらはすべて、add_data() に渡すプレーンな構造体です。
ApplicationVersion
ApplicationVersion は、アプリケーションのセマンティックバージョン番号を表します。
Browser
ここに保存されたBrowser データセットを使用して、それに関連付けられた任意の値で実験およびパーソナライゼーションのレポートをフィルタリングできます。
Conversion
ここに保存されたConversion データセットを使用して、それに関連付けられた任意の目標で実験およびパーソナライゼーションのレポートをフィルタリングできます。
Cookie
Cookie には、訪問者のデバイスに保存されている Cookie に関する情報が含まれます。
CustomData
CustomData を使用すると、あらゆる種類のデータを各訪問者に関連付けることができ、セグメントのターゲティング条件の効果的なツールになります。さらに、実験レポートのフィルターやブレークダウンとしても使用できます。カスタムデータの詳細については、こちらの記事を参照してください。
Kameleoon アプリまたは Data API でカスタムデータの型を定義し、SDK から使用します。
CustomData には 2 つのコンストラクタがあります。1 つはカスタムデータを id(インデックス)で識別し、もう 1 つは name で識別します。
-
各訪問者は、一意の
id(name)ごとに 1 つのCustomDataしか持てません。同じid(name)を持つ別のCustomDataを追加すると、既存のものが置き換えられます。 - カスタムデータの「インデックス」は、カスタムデータダッシュボードの「INDEX」列で確認できます。
- プライバシー上の理由から、SDK が選択したインデックスのデータを Kameleoon サーバーに送信しないようにするには、カスタムデータの作成時に Use this data only locally for targeting purposes オプションを有効にしてください。
-
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 フィールドを使用して、コンバージョン指標を歪める可能性のあるその他の不要なトラフィックを除外します。詳細については、ボットフィルタリングに関するヘルプ記事を参照してください。
内部ボットを使用している場合は、user-agent 値 curl/8.0 を送信して分析から除外してください。
返される型
DataFile
DataFile には、SDK 構成の詳細が含まれます。
クライアントが必要とする場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
FeatureFlag
FeatureFlag は、フィーチャーフラグ自体を定義するプロパティのセット(たとえば、その Variations、Rules、環境ステータス、およびその他の関連する詳細)を表します。
クライアントが必要とする場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
Rule
Rule は、ルール自体を定義するプロパティのセット(たとえば、その Variations)を表します。
クライアントが必要とする場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
Variation
Variation には、訪問者に割り当てられたバリエーション、または特定の割り当てが存在しない場合はデフォルトバリエーションに関する情報が含まれます。
Variationは割り当てられたバリエーションまたはデフォルトバリエーションを記述し、Variableは個々の変数の詳細を含みます。idとexperiment_idはstd::nulloptになる場合があり、これは特定の実験の割り当てに紐付いていないデフォルトバリエーションを示します。
Variable
Variable には、割り当てられたバリエーションに関連付けられた変数に関する情報が含まれます。
JsonValue
JsonValue は、C++ におけるバリエーション変数の値を表します。kind フィールドは、文字列を保持する種類を区別します。value は std::variant<bool, double, std::string> です。
型付きアクセサは、値が別の種類の場合に
std::nullopt を返します: