A/B テスト（スプリットテストとも呼びます）は、Web 開発でよく使う手法です。チームはこれを繰り返し適用し、デジタル体験を改善します。A/B テストでは、Web ページやアプリ機能の 2 つの版を比べ、コンバージョン、エンゲージメント、ユーザー満足度など、あらかじめ決めた目標に対してどちらが優れるかを調べます。
通常は、コントロール（A）とバリアント（B）の 2 つを用意します。両者は、テスト対象の要素以外は同じです。対象は見出し、ボタンの色、レイアウト、そのほかの UI / UX コンポーネントです。たとえば、コールトゥアクションボタンの色を 2 通り試し、どちらがより多くクリックされるかを見ます。
バリアントの準備ができたら、ユーザーへランダムに見せます。ランダム化により、性能の差をユーザー属性や行動などの外部要因ではなく、テストした変更に帰着しやすくします。
ユーザーが各バリアントを使うあいだ、行動を追跡して、あらかじめ決めた目標に対する性能を測ります。クリック率、コンバージョン率、直帰率、エンゲージメントなどの指標を見て、望ましい結果により近いバリアントを判断します。
A/B テストは、主観や推測ではなく、実際のユーザー反応に基づいて判断するための手段です。サイトやアプリケーションの要素を体系的に試し、改善することで、ユーザー満足度とコンバージョンを高め、競争の激しいオンライン環境で事業目標に近づけます。
Cloudflare の低レイテンシなフルサーバーレスコンピュート基盤である Workers は、サーバーサイド実装による A/B テストを実現できます。Workers KV を使うと、この仕組みをコードデプロイから切り離して柔軟に設定できます。
このアーキテクチャは、同一 URL の A/B テストエンドポイントを示します。ロジックと設定はサーバーサイドに置くため、クライアント側の変更は不要です。
- クライアント: サーバーへリクエストを送ります。デスクトップやモバイルのブラウザー、ネイティブアプリ、モバイルアプリなどです。
- 設定: Workers で受信リクエストを処理します。KV の
get()で現在の設定を読みます。これにより、A/B サービスの設定をコードデプロイから切り離して更新できます。 - オリジンリクエスト: リクエストヘッダーに既存の Cookie があるか確認します。グループ割り当て用の Cookie がなければ、グループをランダムに割り当てます。Cookie がある場合は、Cookie ヘッダーから割り当て済みグループを取り出します。設定と割り当てグループに応じて、コントロールエンドポイント（A）またはバリアントエンドポイント（B）へリクエストを送ります。
- レスポンス: オリジンからのレスポンスを返します。加えて、以前 Cookie が設定されていなければ、セッション親和性のために割り当てグループを Cookie に設定します。
Workers と Workers KV で異なるオリジン Web サーバーへリクエストを振り分けるコード例は、Workers KV の Web サーバー間のルーティング を参照してください。