メインコンテンツへスキップ
Kameleoon は、従来から（JavaScript エンジンを使用したクライアントレベル、もしくはサーバーサイド SDK を使用したサーバーレベルで）A/B テストの実行を可能にしてきました。しかし、パフォーマンス上の理由から広範なキャッシング戦略が一般的であるため、HTTP リクエストがバックエンドのアプリケーションサーバーに到達しないことがあります。代わりに、フロントの Web サーバーが、要求されたページのキャッシュバージョンを直接返します。このような構成では、訪問者を実験に割り当てるロジックがバックエンドのアプリケーションコードで発生するため、サーバーサイド SDK を使用できません。つまり、ページのキャッシュバージョンが代わりに返されるため、多くのリクエストを処理できなくなります。言い換えれば、実験のバリエーションへのトラフィック分配を実装するコードが実行されません。 この課題を解決するため、Kameleoon の A/B テストモジュールは主要な Web サーバーで利用可能です。これにより、Web サーバーは各訪問者が使用するバリエーションを決定できます。サーバーは正しいバリエーションのキャッシュバージョンで応答できるため、アプリケーションは標準のキャッシング戦略の恩恵を受けることができます。 Web サーバーレベル での Web テストは、フロントエンドとバックエンドの間の中間レベルです。

​
一般的な概念​

Kameleoon Web サーバーモジュールは、低レベルのコンポーネント（最適なパフォーマンスのため C 言語で書かれています）で、HTTP リクエストが A/B 実験をトリガーするたびにバリエーション割り当てを実行します。その後、（内部的に）選択されたバリエーションに対応する別の URL にリクエストをリダイレクトします。 たとえば、訪問者が https://www.shop.com/plasma-tvs.html ページにアクセスし、そのカテゴリページで 3 つのバリエーションを持つ実験が実行されている場合、Web サーバーは HTTP リクエストを内部的に https://www.shop.com/plasma-tvs.html（オリジナル版）、https://www.shop.com/plasma-tvs.html?version=B（最初のバリエーション）、または https://www.shop.com/plasma-tvs.html?version=C（2 番目のバリエーション）のいずれかにリダイレクトします。次に、これらのページのキャッシュバージョンを返します（TTL 値が期限切れになった場合は、新しいページを生成するためアプリケーションサーバーに呼び出しを渡します）。 A/B/C テストはエンドユーザーには完全に透過的です。訪問者はブラウザで正規 URL の https://www.shop.com/plasma-tvs.html のみを目にします。 実験のセットアップと設定（ターゲットおよびリダイレクト URL の設定、たとえば ?version=B パラメーターを追加する等）は Kameleoon プラットフォームで完結します。Web サーバーモジュールは Kameleoon サーバーおよびデータベースから設定を定期的に更新します。A/B テストの計画とデプロイを便利に行うため、テストの開始、一時停止、停止、配信比率の変更、設定の変更など、通常のすべての Kameleoon 機能を利用できます。
Web 上のクライアント・サーバーモデルの技術的制約により、Web サーバーレベルで実験ターゲティングを設定する唯一の方法は、URL 条件を使用することです。同様に、Web サーバーレベルでバリエーションを設定するには、Kameleoon で常に URL リダイレクトを使用してください。フロントエンド（ブラウザ）リダイレクトに関連する負のパフォーマンスおよび SEO への影響は、Web サーバーリダイレクトでは問題になりません。代わりに、Web サーバーの内部リダイレクトは完全に安全で、Web サーバー内部で処理される（高速）ため、検索エンジンクローラーに対して透過的であり、良い実践とみなされます。

​
Web サーバー A/B 実験の運用​

  1. Kameleoon アプリで コードエディター を使用して新しい A/B 実験を作成します。
  2. Kameleoon で、実験に実装したいバリエーションを作成します。各バリエーションについて、URL リダイレクトオプションを選択し、希望する新しい URL を入力します。
  3. 1 つ以上の URL ターゲティング条件を追加して、実験のターゲティングを選択します。Web サーバー上の一致した URL は、リクエストの Web サーバーモジュールをトリガーし、内部リダイレクトを有効化します。モジュールは、一致したリクエストに対して kameleoonVisitorCode という名前の（ファーストパーティ）Cookie を保存します。
Web サーバー実験では、URL リダイレクトオプションのみが考慮されます。グラフィカルエディター経由の JavaScript や CSS コードの変更など、バリエーションへのその他の変更は無視されます。
その後、配信比率を選択し、通常通り実験を開始できます。実験の一時停止または停止も期待通りに動作します。
トラフィック除外 は、Web サーバー A/B 実験では機能しません。実験のオリジナルバージョンの分析には、除外されたバケットの訪問者からのデータが含まれ、それらの訪問者を実験から完全に除外することはできません。
サーバーサイドでの潜在的な処理（トラッキング、バリエーションの実装）を支援するため、Nginx の設定ファイル（kameleoon_headers on;）でオプションが有効化されている場合、Web サーバーは Kameleoon 実験に一致するすべてのリクエストに HTTP ヘッダーを追加します。1 つ目のヘッダーは kameleoon-experiment という名前で、その内容は experimentID=variationID の形式となり、experimentID はトリガーされた実験 ID、variationID は割り当てられたバリエーションの ID を表します。2 つ目のヘッダーは kameleoon-redirection という名前で、その内容は variationID=redirectionURL の形式となり、variationID は割り当てられたバリエーションの ID、redirectionURL はリダイレクトに使用されるパラメーターを表します。

​
サポートされているプラットフォーム​

​
Nginx サーバーモジュール​

このモジュールは Nginx の 1.18.0、1.20.2、1.21.4 をサポートしています。Docker パッケージはこちらから入手できます。 最新バージョンのモジュールは Nginx の 1.27.1 をサポートしています。Docker パッケージはこちらから入手できます。
このモジュールは x86_64 アーキテクチャでテストされています。
Python スクリプトも並行してインストール（CRON ジョブを介して定期的に起動する必要があります。30 分または 60 分間隔を推奨）する必要があります。スクリプトの使用には、Automation API のクレデンシャル（OAuth 2.0 認証用）が必要です。詳細については、API クレデンシャル の記事をご覧ください。

​
Apache HTTPd サーバーモジュール（非推奨）​

Apache httpd モジュールは バージョン 2.4 をサポートしており、x86_64 CPU アーキテクチャの CentOS ディストリビューションでテストされています。
Python スクリプトも並行してインストール（CRON ジョブを介して定期的に起動する必要があります。30 分または 60 分間隔を推奨）する必要があります。このスクリプトは、Kameleoon モジュールに必要な生成済み Nginx 設定ファイルをリフレッシュまたは更新します。スクリプトは設定ファイルのリロードも行います。