Skip to main content

​
フィーチャーフラグの設定とバケッティング

フィーチャーフラグの設定が更新されたり、オン/オフが切り替えられたりすると、SDK は polling または streaming のいずれかを使用して、Cloudflare Content Delivery Network (CDN) から更新された設定を取得できます。ポーリングはデフォルトのオプションで、ストリーミングはプレミアムオプションです。 Kameleoon SDK は zero latency policy に準拠するよう設計されています。これは、SDK がユーザーをフィーチャーフラグでアクティブ化およびバケット化するために追加のリモートサーバー呼び出しを必要としないことを意味します。最速のリモートサーバー呼び出しでも、アプリケーションに最低 20 ms のレイテンシが追加され、いくつかの要因によりこの遅延は数百ミリ秒に増加したり、エンドユーザーの Web アプリケーションの読み込みを完全にブロックする可能性があります。この追加レイテンシを防ぐため、Kameleoon SDK は訪問者をローカルで実験に割り当てます。
ユーザーのデバイスで動作するクライアントサイド SDK の場合、アプリはセッション開始時にアクティブなフィーチャーフラグ設定を取得する必要があります。これには関連するコールバックを伴うリモート呼び出しが必要で、SDK を使用するアプリケーションコードは、このコールバックの実行が完了するまで実験を実行したりフィーチャーフラグを適用したりできないことを意味します。

​
ポーリング（デフォルト）

このモードでは、SDK は定期的な間隔（デフォルトでは 60 分ごと）に CDN にリクエストを送信し、最新の設定を取得します。この間隔は SDK 設定で refresh_interval_minute（または refresh_interval）パラメーターを使用してカスタマイズできます。
間隔が適度に開けられている場合、設定の更新は非常に少ないメモリとネットワークリソースしか消費しません。
Web クライアントサイド SDK の場合、ポーリング戦略にはローカルキャッシングロジックが含まれます：
  1. 初期ロード: Web ページが開かれると、SDK はまずキャッシュ（利用可能な場合）から設定をロードしようとします。
  2. バックグラウンド更新: refresh_interval が経過した場合、SDK は設定を更新するためにバックグラウンドリクエストを実行し、キャッシュをリフレッシュします。
  3. キャッシュの有効性: キャッシュされた設定は、最後の正常な更新から 1.5 時間 有効と見なされます。訪問者がこの 1.5 時間以内にページを開く場合、キャッシュされたバージョンが使用されます。それ以外の場合、キャッシュは無視され、すぐに新しいリクエストが行われます。
このキャッシング戦略により、ページ読み込みが高速化され、ネットワーク使用量が最小限に抑えられる一方で、設定は適度に新鮮に保たれます。たとえば、refresh_interval が 15 分に設定されており、ユーザーがフィーチャーフラグに公開されているとします。フィーチャーフラグが 10 分後 にオフにされ、同じユーザーが 20 分後に Web サイトに戻った場合：
  • SDK はまず キャッシュから設定をロード します（依然としてフラグがアクティブとして表示されます）。
  • 同時に バックグラウンドリクエスト を行って、更新された設定を取得しキャッシュをリフレッシュします。
  • この設計は パフォーマンス を優先し、ページの素早い読み込みを保証しながら、最新の設定と非同期に同期します。
したがって、ユーザーが古い設定を見る可能性のある短い期間があるとしても（間隔次第）、SDK はバックグラウンドで素早く更新します。更新された設定は、訪問者が次にページを開いたときに適用されます。

​
新しく開始された実験やフィーチャーフラグへの影響

dataFileCacheTtl と dataFileRefreshInterval は、新しく開始された実験やフィーチャーフラグの設定に基づいて訪問者がどれだけ早く評価されるかを共に決定します。キャッシュされたデータファイルがすでに dataFileCacheTtl を超えて古くなっている訪問者、またはまだキャッシュされたデータファイルを持たない訪問者は、initialize() が最新のデータファイルの到着を待つため、すぐに新しい設定を受け取ります。キャッシュされたデータファイルがまだ dataFileCacheTtl の範囲内にある訪問者は、そのキャッシュが dataFileCacheTtl を超えて古くなるか、バックグラウンドの更新が完了して別のページを読み込むまで、以前の設定で評価され続けます。 その結果、デフォルトの dataFileCacheTtl（90 分）では、新しく開始された実験へのトラフィックは、すぐに全量に達するのではなく段階的に増加します。たとえば、新しく開始された実験では、十分な数の訪問者のキャッシュされたデータファイルがこの 90 分のウィンドウを経過すると、開始後 1 時間で最終的な対象ユーザーの約 40%、2 時間目までに約 57%、3 時間目までに 95% 以上に達することがあります。実験から永久に除外される訪問者はいません。各訪問者は、デバイスが更新された設定を取得し次第、実験に参加します。
Kameleoon の露出数をキャンペーン開始直後に他の分析ツールと比較する場合、露出数が安定して対象ユーザーと一致するまでに dataFileCacheTtl 分（デフォルトは 90 分）程度の増加期間があることを想定してください。この期間中の露出訪問者数が少ないことは、訪問者が失われている、またはターゲティングが誤っていることを意味しません。より速い立ち上がりが必要な場合は、dataFileCacheTtl を小さくするか（ページ読み込みへの不要なブロッキングリクエストを避けるため dataFileRefreshInterval より大きい値に保ってください）、Kameleoon サポートに連絡して SDK データファイルのこのキャッシュモデルを完全に回避するストリーミングオプションについて相談してください。
サーバーサイドまたはエッジ SDK を getEngineTrackingCode() と Engine.js トラッキングスクリプトを組み合わせて使用する構成でも、Engine.js 自体の個別のブラウザキャッシュが原因で、トラッキングされた結果に同様の段階的な増加が見られることがあります。詳細は Engine.js のキャッシュ動作を参照してください。

​
ストリーミング（プレミアムオプション）

リアルタイムストリーミングモードにより、SDK は遅延なしで新しい設定を自動的に適用できます。ストリーミングが有効になっている場合、Kameleoon SDK は server-sent events (SSE) のおかげで、設定への変更をリアルタイムで通知されます。 主な利点：
  • 設定を即座に更新します（次のポーリングサイクルを待つ必要がありません）。
  • 短い間隔でのポーリングよりもネットワークトラフィックが少なくなります。ストリーミングは定期的なリクエストを送信しません。接続を一度開き、それを永続的に開いた状態に保ち、データを受信する準備が整います。
利用可能性：
  • これはサブスクリプションが必要なプレミアムオプションです。Kameleoon アカウントでリアルタイムストリーミングをアクティブ化するには、カスタマーサクセスマネージャーに連絡するか、support@kameleoon.com にメールしてください。
  • PHP SDK は技術的な制約のためストリーミングをサポートしていません。PHP SDK は現在、リクエスト間で永続化されないため、ノンブロッキング方式で設定の更新をリッスンできません。各リクエストは、応答を受け取るとすぐに自己破棄する新しい SDK インスタンスを作成します。
  • リアルタイムストリーミングモードは現在、サーバーレスエッジコンピューティングプラットフォーム と互換性がありません。
  • その他の言語については、SDK 互換性マトリックス で希望する言語の最小サポートバージョンをご確認ください。

​
データストレージ

Kameleoon の SDK は、最適なパフォーマンスとユーザーエクスペリエンスのために設計されています。これを実現するため、SDK はリモートソースから取得する代わりに、訪問者データをサーバー上またはデバイス上で直接ローカルに管理します。 Kameleoon の実験およびフィーチャーフラグに関連するすべての訪問者データ（実験割り当て、セグメントデータ、addData() のようなメソッドで追加されたカスタムデータ、または getRemoteVisitorData() でサーバーから取得されたデータを含む）はローカルに保存されます。このデータが保存される方法と寿命は、サーバーサイド SDK またはクライアントサイド SDK のどちらが使用されるかによって異なります。

​
サーバーサイド SDK

サーバーサイド SDK の場合、訪問者データはサーバーの揮発性メモリ（RAM）に保存され、実験およびフィーチャーフラグの評価に高速アクセスを提供します。データは、一意の visitorCode 値をキーとするマップとして整理されます。
  • セッションベースのストレージ: データは、ユーザーのアクティブセッションの間のみメモリに保持されます。これはデフォルトでは、30 分間アクティビティ（ページビュー、クリックなど）がないと終了します。セッション中に収集されたすべてのデータは同時に期限切れになります。
    • session_duration パラメーター: セッション期間は、SDK 設定で session_duration パラメーターを使用して調整できます。このパラメーターにより、Kameleoon セッションをアプリケーションのサーバーサイド管理と整合させることができます。
session_duration を増やすと、増加した訪問者データを保存するために SDK がより多くの RAM を割り当てる必要があります
  • サーバー再起動時のデータ損失: データは RAM に保存されるため、アプリケーションサーバーが再起動すると失われます。通常、重要な訪問者データ（ユーザー ID や属性など）は永続データベースから取得され、新しいリクエスト時に訪問者に再割り当てされるため、データ損失は懸念事項ではありません。
  • 以前の訪問からのデータ取得: getRemoteVisitorData() メソッドを使用すると、訪問者の以前の訪問中に収集されたカスタムデータを取得できます。このメソッドは訪問者の最新のデータエントリを自動的に関連付けるため、addData() を再度呼び出す必要がありません。

​
クライアントサイド SDK

サーバーサイド SDK とは対照的に、クライアントサイド SDK はユーザーのデバイスにある永続的なローカルストレージを利用します。 このメカニズムにより、訪問者データはブラウザセッション、アプリの再起動、さらにはデバイスの再起動を通じて保持されます。具体的なストレージメカニズムはプラットフォームによって異なります：
  • iOS: UserDefaults
  • Android: SharedPreferences
  • JavaScript/TypeScript: LocalStorage
    • JS SDK 向けの注意: kameleoonVisitorCode は、Kameleoon アプリケーションファイル（engine.js）とのシームレスなデータ継続性と通信を保証するため、Cookie 経由でも共有されます。
  • React Native: MMKV Storage
グローバルな session_duration を使用するサーバーサイド SDK とは異なり、クライアントサイド SDK はすべてのデータに対してセッションベースの有効期限で動作しません。代わりに、targetingDataCleanupInterval または data_expiration_interval_minute を使用して、個々のデータの保存期間を制御します。
  • targetingDataCleanupInterval/data_expiration_interval_minute: これらのパラメーターは、特定の各データエントリの個別の寿命を決定します。デフォルトでは、訪問間で一貫したユーザーエクスペリエンスを保証するため、データは無期限に保存されます（明示的にクリアされるまで）。個々のデータポイントを特定の時間後に有効期限切れにする必要がある場合は、このパラメーターを特定の分数に設定できます。
  • データの永続性: この根本的な違いは、ユーザーがブラウザタブを閉じたり、サイトから離れたり、モバイルアプリケーションを閉じたりしても、データが永続することを意味します。
  • 命名規則の根拠: パラメーター用語の違い（session_duration 対 data_expiration_interval_minute）は、根本的なストレージの哲学を直接反映しています。session_duration は、サーバーサイドセッション内のすべてのデータの全体的な寿命を管理します。data_expiration_interval_minute は、クライアントに永続的に保存される特定の各データの寿命をきめ細かく制御できます。

​
エッジ SDK

サーバーレスエッジコンピュートスターターキットを通じてデプロイされるエッジ SDK は、サーバーサイド SDK やクライアントサイド SDK のようにはリクエスト間で訪問者データを保持しません。エッジプラットフォームはいつでもワーカーインスタンスを破棄して再作成できるため、session_duration の設定には適用できる永続的なメモリがなく、エッジワーカーには同じ訪問者からの後続のリクエストを見られる保証がありません。 このため、フィーチャーフラグや実験を評価する前に、統合がリクエストごとにエッジワーカーで訪問者データを利用できるようにする責任があります。通常はクッキーとして渡し、addData() を呼び出します。完全な説明とコード例については、エッジターゲティングの制約を参照してください。

​
ドメインリスト

Kameleoon SDK は、SDK に特定のサービスを提供する一連の URI へのアクセスを必要とします。アクセスを制限していて、ドメインを明示的にホワイトリスト化する必要がある場合は、当社の SDK が以下のドメインに到達できるようにしてください： Content-Security-Policy (CSP) ヘッダーでこれらのドメインを許可する方法については、Kameleoon で許可が必要なドメイン を参照してください。このページには、Kameleoon の製品が使用するすべてのドメインが記載されています。
Kameleoon スクリプトのドメインはプロジェクトごとに異なる場合があります。プロジェクトは作成日に応じて kameleoon.eu または kameleoon.io のいずれかでホストされている場合があります。Kameleoon App のプロジェクトに表示されているドメインを使用していることを確認してください。

​
FAQ

Kameleoon は初期化中に CDN サーバーを使用します。SDK が設定を受信してキャッシュすると、取得と更新は迅速に行われ、通常 50〜70 ms です(最も近い CDN からのサーバーのレイテンシーによります)。
設定を取得する方法は 2 つあります：Polling と Streaming です。
ストリーミングでは、server-sent events(SSE または EventSource)プロトコルを使用します。
フィーチャーフラグの設定(例: バリエーション、トラフィックの露出、ターゲティング)を更新するたびに、または 24 時間ごとに、Kameleoon は CDN をパージします。
各サーバーインスタンスは、収集した訪問者データを独自のメモリに保存します。同じ訪問者からのリクエストは、同じサーバーインスタンスに振り分けてください。そうしない場合は、各トラッキングリクエストの前に addData() で訪問者データを完全に追加するか、getRemoteVisitorData メソッドを使用して読み込んでください。異なるサーバーインスタンスが同時に異なる SDK の設定を適用する場合は、Streaming オプションを使用して、各インスタンスが設定の変更をリアルタイムで受け取るようにしてください。
レイテンシーを排除するため、すべての評価はローカルで行われます。その後、トラッキングリクエストは非同期に Kameleoon Data API サーバーへ送信されます。
訪問者を実験のバリエーションに割り当てるために、Kameleoon はまず、訪問者コード、実験 ID、および再プール時の追加要素を使用して識別子を構築します。次に、ハッシュ関数 SHA-256 の同期的な実装によって、この識別子のハッシュを計算します。ハッシュ化によって得られた整数は、0 から 1 の間の浮動小数点数にマッピングされ、実験のバリエーションに割り当てられます。SHA-256 関数は決定論的であるため、割り当ての再計算を明示的に要求しない限り、同じユーザー(同じ訪問者コードを持つ)は常に同じ実験のバリエーションを受け取ります。
Add a new rollout rule の記事では、考えられるすべてのケースについて説明しています。
サーバーサイド SDK は、訪問者データを訪問者セッションの間メモリに保持します。訪問者セッションは、デフォルトで 30 分間続きます。クライアントサイド SDK は、データをデバイスのローカルストレージに保存します。データは、消去するか、設定された有効期限が経過するまで保持されます。詳細については、データストレージ を参照してください。