Skip to main content
SDK をアプリケーションに統合するのは簡単で、フットプリント(メモリおよびネットワーク使用量)も小さく抑えられています。 はじめに: 入門ガイドについては、開発者ガイドを参照してください。 最新バージョン: 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++ ライブラリを静的にリンクし、コアライブラリを実行時にロードします。
Kameleoon SDK Core は、ターゲットのプラットフォームおよびアーキテクチャに合わせてソースからコンパイルされます。Rust と Cargo がインストールされ、システムの PATH で利用可能であることを確認し、コアライブラリの C ヘッダーを生成する cbindgen をインストールしてください:
Rust と Cargo のインストール: https://rust-lang.org/tools/install将来のリリースでは、インストールを簡素化するために、一般的なプラットフォーム向けのビルド済みコアライブラリが提供される予定です。ソースからビルドしたいユーザー向けに、ローカルコンパイルは引き続き利用可能です。
要件:
  • 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。
C++ SDK リポジトリ をクローンしてコアライブラリをビルドし、その後それに対して C++ ライブラリをビルドします:
SDK を独自の CMake プロジェクトに統合するには、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 は、フィーチャーフラグの評価、訪問者データの追加、トラッキングリクエストの送信に使用される主要なオブジェクトです。
  • KameleoonClient はアプリケーションと Kameleoon プラットフォームの間のブリッジとして機能するため、シングルトンオブジェクトとして使用することをお勧めします。実験を効率的に実行するために必要なすべてのメソッドとプロパティを公開しています。KameleoonClient はムーブ専用です。1 か所に保持し、参照で渡してください。
  • C++ SDK は非同期で初期化されます。本番コードでフィーチャー評価に依存する前に、initialize() を呼び出す必要があります。
  • SDK のすべての失敗は KameleoonException として報告されます。SDK 呼び出しは try/catch ブロックでラップしてください。

フィーチャーフラグの有効化

ユーザーへの一意の 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 のログにのみ記録されます。
コンプリーションとイベントハンドラーは通常 SDK のワーカースレッドで実行されますが、コンプリーションは、*_async の呼び出しが戻る前に、呼び出し元のスレッドで実行されることもあります。たとえば、SDK が即座に失敗する場合(クライアントが準備できていない、訪問者コードが無効)や、すでに初期化されたクライアントで initialize_async() が呼び出された場合です。コンプリーションが特定のスレッドで、または呼び出しが戻った後に実行されると想定しないでください。また、コンプリーションも取得するロックを呼び出しをまたいで保持しないでください。コンプリーションとイベントハンドラーはブロックしてはならず、例外をスローしてはならず、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)を指します。
カスタムバケットキーが正しく機能するためには、フラグの作成または編集プロセス中に、フィーチャーフラグに対しても定義および構成される必要があります。これに対応する設定がないと、SDK のバケッティングはカスタムキーを適用しません。Kameleoon でこれを設定する方法の詳細については、この 記事 を参照してください。
  • バケッティングロジック: 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() - 別の訪問者に関連付けられた特定の訪問者のデータを追跡します。
識別子として使用するカスタムデータは Visitor スコープ に設定する必要があるため、各デバイスで get_remote_visitor_data() メソッドを使用して識別子を取得するには、クロスデバイスカスタムデータ同期 を使用する必要があります。
以下に、セッションマージのためのカスタムデータの使用例を示します。
この例では、アプリケーションにログインページがあります。ログイン時点ではユーザー ID が不明であるため、get_visitor_code() メソッドによって生成された匿名訪問者識別子が使用されます。ユーザーがログインした後、匿名訪問者はユーザー ID に関連付けられ、訪問者の一意の識別子として使用されます。

ロギング

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

ログレベル

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

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

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

リファレンス

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

初期化

create()

SDK を使用するには、KameleoonClientFactory::create() を使用して、KameleoonClientConfig 構造体または JSON 構成ファイルから KameleoonClient を作成します。 クライアントはサイトコードと環境ごとにキャッシュされます。同じサイトコードと環境で create() を繰り返し呼び出すと、同じ基盤 SDK インスタンス上のクライアントが返され、最初の呼び出しの構成が優先されます。
パラメーター
戻り値
例外

initialize()

アプリケーションがフィーチャーフラグを評価する前に Kameleoon クライアントの初期化完了を待つ必要がある場合は、initialize() を使用します。 この呼び出しは構成フェッチの結果を返します。クライアントの初期化が完了すると正常に完了し、クライアントが準備できる前に初回の構成フェッチが失敗すると失敗します。その最初の失敗の後も、バックグラウンドでの再試行は継続されます。再試行が成功すると、以降の呼び出しは成功した結果を返します。タイムアウトが切れる前に初期化結果が得られない場合、呼び出しは失敗します。timeout 値を提供しない場合、SDK は default_timeout_millis のデフォルトタイムアウトを使用します。
アプリケーションの起動時に initialize() を 1 回呼び出し、SDK が構成をロードするかタイムアウトが切れるまで待機します。各受信リクエストでは、フィーチャーフラグを評価する前のノンブロッキングなガードとして is_ready() を使用してください。initialize() が失敗しても、SDK はバックグラウンドで構成のフェッチを再試行し続けるため、再試行が成功すると is_ready() は true を返すようになります。
パラメーター
戻り値
例外

is_ready()

is_ready() は、SDK が使用可能な状態、つまり構成が正常にロードされているかどうかを確認します。initialize() とは異なり、このメソッドはブロックやスローをせずに即座に戻ります。
  • SDK は一度準備が完了すると、その状態を維持します。その後の構成リフレッシュが失敗しても、SDK は以前にダウンロードした構成を使用し続け、未準備の状態に戻ることはありません。
  • アプリケーションの起動時に initialize() を 1 回呼び出し、SDK が構成をロードするかタイムアウトが切れるまで待機します。各受信リクエストでは、フィーチャーフラグを評価する前のノンブロッキングなガードとして is_ready() を使用してください。initialize() が失敗しても、SDK はバックグラウンドで構成のフェッチを再試行し続けるため、再試行が成功すると is_ready() は true を返すようになります。
戻り値

forget()

指定された site_code に関連付けられたキャッシュされた SDK クライアントを削除し、同じサイトコードと環境での次の create() 呼び出しで新しいクライアントが作成されるようにします。 forget() はファクトリの参照を破棄するだけです。そのサイトコード用に作成されたすべての KameleoonClient は、破棄されるまで基盤となる SDK インスタンス(およびそのワーカースレッド、ポーリング、トラッキング)を保持し、未完了の非同期操作は、そのコンプリーションが完了するまでインスタンスを保持します。バックグラウンドリソースを解放するには、forget() を呼び出し、そのサイトコードのすべての KameleoonClient インスタンスを破棄してください。
パラメーター

フィーチャーフラグとバリエーション

is_feature_active()

  • 📨 Kameleoon にトラッキングデータを送信します(track オプションに応じて)
特定のユーザーに対してフィーチャーフラグがアクティブかどうかを判断します。 訪問者がこのフィーチャーフラグに対してまだ評価されていない場合、SDK はターゲティングルールを評価して結果を返します。訪問者がすでに保存された評価を持っている場合、SDK は一貫性を確保するために既存の結果を再利用します。
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 分後にレポートに表示されます。
is_feature_active() メソッドは、マスターフラグ状態ではなく、提供されたバリアントを評価します。ルールを除外した場合、メソッドは その他すべてに対して提供する デフォルト状態を使用します。このデフォルト状態に Off を選択した場合、マスターフィーチャーフラグが On であってもメソッドは常に false を返します。
パラメーター
戻り値
例外

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 はまずそれを完全に処理して完了させます。
Kameleoon は、強制バリエーションを評価されたバリエーションと同じように扱います。標準的な評価済みバリエーションと同様に、分析でトラッキングされ、ユーザーコンテキストに保存されるため、レポートの一貫性が確保されます。 このメソッドは、特定の条件下(たとえば、無効なパラメータ、ユーザーコンテキスト、または内部の問題)で例外をスローする場合があります。アプリの安定性と回復力を確保するために、適切な例外処理が不可欠です。
強制バリエーションと シミュレート されたバリエーションを区別することが重要です:
  • 強制バリエーション: 個々の実験に固有です。
  • シミュレートされたバリエーション: フィーチャーフラグ全体の結果に影響します。
パラメーター
オプションの force_targeting パラメータは、SetForcedVariationOptions 構造体の force_targeting フィールドとして渡されます。
例外

evaluate_audiences()

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

get_datafile()

すべてのフィーチャーフラグを評価するには、get_variations() を使用してください。このメソッドは、DataFile を呼び出して get_variation() でフラグを反復処理するよりも効率的です。
現在の SDK 構成を DataFile オブジェクトとして返します。 返される DataFile は現在の構成のコピーです。SDK が構成を更新しても変更されません。
戻り値
例外

訪問者データ

get_visitor_code()

get_visitor_code() を使用して、現在の訪問者の Kameleoon visitor_code を取得します。このメソッドは、CookieAccessor インターフェースを実装する任意の Cookie ストアで動作します。 実装ロジックは次のとおりです:
  1. SDK は、提供されたアクセサを通じて kameleoonVisitorCode Cookie がすでに利用可能かどうかを確認します。
  2. Cookie が存在しない場合、default_visitor_code を提供していれば、SDK はそれを使用します。
  3. それ以外の場合、SDK は新しい訪問者コードを生成し、アクセサを通じて保存します。
詳細については、ハイブリッド実験を参照してください。
独自の visitor_code を提供する場合、その一意性はお客様側で保証する必要があります。また、visitor_code の長さは 255 文字に制限されていることに注意してください。
get_visitor_code() メソッドを使用すると、訪問者にシミュレートされたバリエーションを設定できます。Cookie(リクエストまたはドキュメントから)にキー kameleoonSimulationFFData が含まれている場合、メソッドは Cookie を読み取り、その訪問者のシミュレートされたバリエーションを保存します。戻り値は変わりません。その後、get_variation() や is_feature_active() などのその訪問者に対するフィーチャー評価は、標準の評価プロセスをバイパスし、提供されたデータに基づいてシミュレートされた Variation を返します。シミュレーションは 2 つの方法で適用できます:
  • 自動(推奨): Kameleoon Web Experimentation またはハイブリッドモードで SDK を使用している場合、シミュレーションパネルを使用してバリアントの表示をシミュレートすると、Kameleoon は自動的に Cookie を作成します。
  • 手動: kameleoonSimulationFFData Cookie を手動で設定します。
シミュレートされたバリエーションと**強制**バリエーションを区別することが重要です:
  • シミュレートされたバリエーション: フィーチャーフラグ全体の結果に影響します。
  • 強制バリエーション: 個々の実験に固有です。
⚙️ 手動設定kameleoonSimulationFFData Cookie が次の形式に従っていることを確認してください:
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: 指定された featureKey に対して、実験 expId の varId のバリエーションをシミュレートします。
  • kameleoonSimulationFFData={"featureKey":{"expId":0}}: 指定された featureKey に対して、デフォルトバリエーション(Then, for everyone else in Production, serve セクションで定義)をシミュレートします。
⚠️ Cookie 値が正しく機能するようにするには、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 である必要があります。
パラメーター
戻り値
例外

add_data()

add_data() メソッドは、ターゲティングデータをストレージに追加し、他のメソッドがそのデータを使用して現在の訪問者をターゲットにするかどうかを判断できるようにします。 add_data() メソッドは値を返さず、単独では Kameleoon のバックエンドサーバーとやり取りしません。代わりに、SDK は宣言されたすべてのデータを flush() メソッドを使用した将来の送信のために保存します。このアプローチにより、データは通常、flush() によってトリガーされる単一のサーバー呼び出しにグループ化されるため、サーバー呼び出しの回数が削減されます。 track_conversion() メソッドも、flush() と同様に、以前に関連付けられたデータをすべて送信します。実験ルールがトリガーされた場合、get_variation() および get_variations() メソッドについても同様です。
ほとんどのデータ型では、各訪問者は関連付けられたデータのインスタンスを 1 つしか持てません。ただし、CustomData は例外です。訪問者は、インデックスごとに 1 つの関連付けられた CustomData インスタンスを持つことができます。
data パラメータは std::vector<Data> です。ここで、Data はすべてのデータ型の std::variant です。各データ型は暗黙的に Data に変換されるため、波括弧で囲んだデータオブジェクトのリストを渡すことができます。
パラメーター
例外

flush()

  • 📨 Kameleoon にトラッキングデータを送信します
flush() メソッドは、訪問者に関連付けられたすべての Kameleoon データを集約し、サーバーにトラッキングリクエストを送信します。このリクエストには、add_data メソッドで以前に追加され、他のトラッキングメカニズムを通じてまだ送信されていないデータが含まれます(詳細は参照先のメソッドを参照してください)。サーバー呼び出しは非同期で実行されるため、flush() 操作はノンブロッキングです。 このメソッドにより、特定の visitor_code にリンクされたデータがいつ送信されるかを制御できます。たとえば、add_data() が複数回呼び出された場合、呼び出しごとにリクエストを送信するのは非効率的です。代わりに、これらの更新をバッチ処理し、flush() を 1 回呼び出すことで、蓄積されたすべてのデータを単一のリクエストで送信できます。 flush() メソッドは、提供された visitor_code を一意の訪問者識別子として使用します。
  • flush(): 構成されたトラッキング間隔に従ってフラッシュ操作をキューに入れます。
  • flush_instant(): 間隔を待たずに、トラッキングデータをただちに送信します。
パラメーター
例外

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() は scope=Visitor の最新の保存済みカスタムデータを自動的に取得し、add_data() を呼び出すことなく訪問者にアタッチします。これは、複数のデバイス間でのカスタムデータの同期に特に役立ちます。
パラメーター
例外
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 に変換し、訪問者にローカルで追加して、ターゲティングの目的で利用できるようにします。背景の詳細については、ウェアハウスターゲティングのドキュメントを参照してください。
パラメーター
例外
訪問者が個人データの使用に法的同意を与えたかどうかを指定するには、このメソッドを使用する必要があります。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 は通常、実験をトリガーしたときに使用したものと同一です。
SDK はサーバー呼び出しを非同期で行うため、このメソッドはノンブロッキングです。
パラメーター
オプションの 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({})を渡すと、選択したイベントタイプの現在のハンドラーが削除されます。
DataFileUpdateEvent には、SDK データファイルの更新に関する情報が含まれます。
ハンドラーは SDK の単一のワーカースレッド上で同期的に呼び出されるため、ブロックしてはいけません。ハンドラー内で費やされた時間は、データファイルのポーリングとトラッキングのフラッシュを遅延させます。ハンドラーはスレッドセーフであり、例外をスローしてはいけません。ハンドラーから漏れた例外はキャッチされて破棄され、SDK の動作に影響を与えることはありません。ハンドラーからブロッキングする SDK 操作を呼び出さないでください。代わりに *_async 形式を使用し、アプリケーションスレッドで作業を完了させてください。すでに進行中の呼び出しは、ハンドラーをクリアした後やクライアントを破棄した後に完了する場合があり、ハンドラー(およびそのキャプチャ)は、使用されなくなった時点で SDK スレッド上で破棄されます。キャプチャされたオブジェクトは、それに応じて存続させ、スレッドセーフに保ってください。ハンドラーは自分自身をクリアまたは置き換えることができます。同じサイトコードと環境に対して作成されたすべての KameleoonClient インスタンスは、イベントタイプごとに 1 つのハンドラーを共有します。最後に設定されたハンドラーが優先され、それらのインスタンスのいずれかを破棄するとクリアされます。サイトコードと環境ごとに単一のクライアントインスタンスを保持してください。
パラメーター

データ型

このセクションでは、SDK が kameleoon 名前空間(kameleoon/data/*.hpp)で宣言する C++ データ型を一覧します。これらはすべて、add_data() に渡すプレーンな構造体です。

ApplicationVersion

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

Browser

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

Conversion

ここに保存された Conversion データセットを使用して、それに関連付けられた任意の目標で実験およびパーソナライゼーションのレポートをフィルタリングできます。
  • 各訪問者は複数の Conversion オブジェクトを持つことができます。
  • goal_id は Kameleoon アプリで確認できます。
Cookie には、訪問者のデバイスに保存されている Cookie に関する情報が含まれます。
各訪問者は 1 つの Cookie しか持てません。2 つ目の 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 には、訪問者の位置情報の詳細が含まれます。
  • 各訪問者は 1 つの Geolocation しか持てません。2 つ目の Geolocation を追加すると、最初のものが上書きされます。

OperatingSystem

OperatingSystem には、訪問者のデバイスのオペレーティングシステムに関する情報が含まれます。
各訪問者は 1 つの OperatingSystem しか持てません。2 つ目の 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 を返します: