A/B テスト
概要
A/B テストまたはカナリアデプロイメント手法により、開発者はウェブページの複数のバリエーションを試すことができます。バリアントはランダムにユーザーに表示され、統計分析を使用して、特定のビジネス目標に対してどのバリアントのパフォーマンスが優れているかを判断します。たとえば、商品の売り上げを伸ばす目的で、商品ページのUIバリアントをテストできます。
アーキテクチャ上の決定
A/B テストは、技術要件やビジネス要件に応じてさまざまな方法で実装できます。主な技術的決定の1つは、バリアント選択ロジックをクライアント側、エッジサーバー側 (CDNレベル)、またはオリジンサーバー側のどこで実行するかです。
オリジンサーバー側のバリアント選択。この方法では、A/B 選択はウェブアプリケーションをホストしているオリジンサーバー上で直接実行されます。このアプローチは CDN に依存しませんが、CDN キャッシュや静的ファイルホスティングとは互換性がありません。完全に動的なサーバーサイドレンダリングウェブアプリケーション用のオプションです。
Edge サーバー側でのバリアント選択。このアプローチでは、CDN レベルでバリアントの選択を決定します。このアプローチは、アプリケーションの変更を最小限またはまったく必要とせず、CDN キャッシュと互換性があります。CloudFront では、エッジ関数を使用して A/B テストロジックを実装できます。Edge 関数は、外部 A/B テスト API に加えてリクエスト属性 (国、Cookie など) を使用してバリアントの 1 つを選択し、CloudFront にキャッシュから提供させることができます。
クライアント側でのバリアント選択。このアプローチでは、フロントエンドは最初に A/B テスト API にリクエストを行い、配信するバリアントを決定し、その応答に基づいてバリアントをダウンロードし、ブラウザにレンダリングします。このアプローチでは、A/B テストは CDN に依存しませんが、アプリケーションと密接に結びついており、クライアント側での追加手順によりレイテンシーが増加します。静的に生成されたサイト（SSG）のA/Bテストなど、必ずしもオプションではないことにも注意してください。クライアントサイドの A/B テストを実装するには、CloudWatch Evidentlyを使用できます。A/B テスト実験を制御するためのクライアント SDK と UI を提供します。CloudWatch Evidence に関する実践的なチュートリアルについては、このワークショップを検討してください。
Edge のサーバー側の A/B テストに焦点を当てましょう。ビジネスに最適な実装を設計するには、他にも次のような質問を検討してください。
- 固定性は必要ですか（たとえば、同じユーザーが常に同じバリエーションを使用するなど）？ スティッキネスは通常、クッキーを使用して実装されます。
- ユーザーのバリエーションの選択にはどのようなディメンションが使用されますか?国、ユーザー ID など
- どのくらいの頻度で A/B テストを行っていますか？ A/B テストを頻繁に使用し、さまざまなチームが多数の実験を並行して実行する場合、単純で時折行われる A/B テストに比べて、より高度な実装が必要です。
CloudFront のエッジ機能を使用した A/B テストのエッジサービス側実装について学ぶには、このハンズオンワークショップを検討してください。次のセクションでは、前述のワークショップの CloudFront を使用した A/B テストの共通実装を 2 つ紹介します。
Edge サーバーサイドの A/B テストを使用する一般的なユースケース
不定期の A/B テスト
機関ウェブサイトの四半期ごとのデザイン改善など、時折 A/B テストが必要になった場合は、実験期間中に CloudFront Functions ベースのソリューションを検討してください。このソリューションは、A/B テストを実行したいページと一致する Cache ビヘイビアに設定された 2 つの機能に基づいています。
- 受信リクエストのテスト Cookie 値を調べ、それに基づいて URL を選択したページバリアントに書き換えるビューアーリクエスト関数。Cookie が存在しない場合、関数はカスタムロジックに基づいてバリアントを選択します。たとえば、フランスからのリクエストに対してのみ、バリアント A は 60%、バリアント B は 40% と言った具合にです。
- ビューアレスポンス関数。Cookie がまだ存在していない場合に、選択したバリアントに基づいてクライアントに Cookie を設定します。テストクッキーは、ウェブ体験を損なわないように、1人のユーザーに常に同じ種類のページが表示されるようにするために使用されます。
バリアント B の割合を増やすなど、バリアント選択ロジックを変更するには、ビューアイベントのファンクションコードを更新する必要があり、通常数秒で完了します。A/B テストの実験が終わったら、エッジ機能を削除してコストを節約できます。
頻繁な A/B テスト
ウェブサイトの A/B テストを継続的に実施し、日常的に実験を行っている場合は、以前の CloudFront Function ベースのソリューションを引き続き使用できます。ただし、バリアント選択パラメーター (バリアントの重みなど) を関数コードから切り離すことをお勧めします。CloudFront KeyValueStore を使用して、このようなパラメータを関数コードの外部に保存できます。KeyValueStore は、グローバル (すべての PoP)、低レイテンシーの読み取り、
スケール (毎秒数百万リクエスト) のキーバリューデータストアとして理想的です。
ユースケースでは、KeyValueStore のクォータ (最大サイズ (5 MB) や、1 秒間に数回の API コールという変更速度制限など) を尊重する必要があることに注意してください。
高度な A/B テスト
たとえば、KeyValueStore のクォータがユースケースで制限されている場合など、CloudFront 関数ベースのソリューションが A/B テストのニーズを満たさない場合は、Lambda@Edge ベースのソリューションを検討してください。これは、大規模な e コマース Web サイトを運営していて、多くのチームが Web サイトのさまざまな部分で同時に実験を高速で実行している場合に当てはまります。 このシナリオでは、CloudFront Function の代わりに Lambda@Edge を使用し、A/B テストパラメータを保存するための外部データソース (DynamoDB グローバルテーブルなど) を使用します。LaunchDarkly のような機能管理ツールでは、DynamoDB との統合が可能で、A/B テストパラメータを永続化できます。
