あるオンラインショップが、配送料の表示を最終決済画面からカート画面へと移動させたとします。この変更はより透明性が高いように見えますが、購入完了率が上がるのか、ユーザーの想定外のギャップを減らせるのか、それとも早い段階で離脱させてしまうのかは、まだチームにはわかりません。A/Bテストでは、ランダムなグループ分けとあらかじめ計画した結果分析によって、現在の体験と新たなパターンを比較します。

その目的は、不確実性も含めて変更の影響を正確に見極めることです。ダッシュボードの数値が一つ上がったからといって、それは解釈の出発点にすぎず、新バージョンが優れていると判断するにはそれだけでは不十分です。

実験で検証できる問いを設定する

先ほどのショップの例では、主要な指標（プライマリ指標）として「対象ユーザーあたりの購入完了数」が考えられます。また、関連する重要な指標として、売上、決済エラー、キャンセル数なども挙げられるでしょう。これらを実験前に定義しておくことで、後から都合の良い副次的な結果を本来の検証目的にすり替えてしまうのを防げます。

A/Bテストが有効なのは、具体的な施策、測定可能な成果、そして十分なサンプルサイズが揃っている場合です。ユーザーがつまずいている理由がまだ見えていないなら、まずはユーザビリティテストやユーザーインタビューを行って施策の仮説を練るのが有効です。実験は変化の影響を評価するものであり、ユーザーがそう反応した理由のすべてを必ずしも解き明かせるわけではありません。

オンライン実験に関するMicrosoft Researchの解説では、プロダクトのアイデアを評価するうえでの対照実験の役割が述べられています。比較の信頼性は、単に2つのバージョンをAとBと呼ぶことではなく、その設計と実行の質によって決まります。

割り当てと計測の信頼性を保つ

どの単位でバージョンを割り振るかを決めます。ユーザー単位、アカウント単位、あるいはその他の適切な単位です。設計上必要な一貫性を保ちつつ、ユーザー同士が影響を及ぼし合わないかも考慮しましょう。アカウントの共有や共同作業がある場合、一見シンプルに見える個人単位の割り当てが、実際には複雑化することがあります。

両バージョンが意図どおりに読み込まれ、計測イベントが双方で同じ意味を持っているかを確認してください。片方のバージョンで購入イベントが2回発火しているなら、購入完了率が上がったように見えても意味がありません。結果を解釈する前に、グループ間の意図しないサンプル数の偏りや、データの欠落がないかを調査しましょう。

検出すべき効果の大きさ、ベースラインの数値やばらつき、そして選んだ分析手法に合わせて、適切なサンプルサイズと実施期間を計画します。参加者数に万能の基準はありません。発生頻度が低いイベントや小さな変化を捉えるには多くの情報が必要であり、同一ユーザーの複数回のアクションやクラスター単位の割り当てには、その相関を考慮した分析が求められます。

分析手法が前提とする終了ルールを守る

固定サンプル数を前提としたテストでは、数値を繰り返し確認して「有意差が出たから」という理由だけで途中で終了してはいけません。適切に設計された逐次検定法であれば中間判断も可能ですが、それに応じたルールが必要です。プラットフォームの結果を判断材料にする前に、どのような手順が使われているかを理解しておきましょう。

トラッキングの不具合や悪影響の発生を監視することと、単に「勝ち」を見つけようとすることは別物です。実際の実験内容が正しく分析に反映されるよう、重要な中断、除外、変更などはすべて記録しておきましょう。

効果と波及影響を踏まえて判断する

推定された差と信頼区間、そして適用した場合は統計的有意性を合わせて報告します。高精度に測定できてもごくわずかな改善であれば運用コストに見合わないかもしれませんし、不確実性が大きい結果では、有益なメリットや潜在的なリスクを判断しきれないままになる可能性があります。

先ほどのショップの例で言えば、早い段階での情報開示によって購入完了率は上がっても、客単価が下がったりキャンセルが増えたりするかもしれません。そうした波及影響も加味して判断を下す必要があります。また、その結果が新奇性による一時的な反応ではないか、重要な利用サイクルを見落とした期間になっていないかも検討してください。

何を変更し、誰を対象とし、何がまだ不明なままかを記録に残しましょう。テストは根拠のあるリリース判断を後押ししてくれますが、その効果が永続するか、あるいはあらゆる顧客層に当てはまるかまでを保証するものではありません。