本記事は Livesense アドベントカレンダー 2025 の 11 日目の記事です。
はじめに
A/B テストというものは意外と難しいもので、正しく行わなければ施策の効果を正確に評価することができません。本記事ではランダム化にフォーカスして、A/B テストに携わる人に知っておいて欲しいことをまとめました。A/B テストは Web 上で行われることが多いため、とくに Web に関係する注意点についても説明しています。
参考文献
なぜランダム化するのか
A/B テストはユーザーをランダムに 2 グループ (場合によっては 3 グループ以上) に分割することから始まります。よくあるやり方としては、2 グループのうちの片方だけに施策を適用して、一定期間後にグループ間に指標の差が現れるかを見ることで、施策の効果があったかを判定します。
最初のステップをランダム化と呼んでいるのですが、なぜユーザー集合をランダムに分割するのでしょうか。それは、グループ間の偏りを無くすためです。
たとえばあなたは EC サイトを運営していて、購買金額が上がるような施策の効果を A/B テストを通して計測したいとします。つまりユーザーを施策ありグループ (A) と施策なしグループ (B) に分けて、売上の差を計測するようなテストを実施します。
ここで、あろうことか A グループを「直近 3 ヶ月に EC サイトを利用した」ユーザー集合に設定したとしましょう。
| A | B |
|---|---|
| 施策あり | 施策なし |
| 直近 3 ヶ月に EC サイトを利用 | それ以外 |
一定期間後、各グループの一人当たりの売上を比較すると A グループのほうが高いことが分かりました。本来であれば、それは施策の効果であると主張したいところです。しかし A グループは直近に利用歴があるのだから、もともと B グループよりも購買意欲が高かったのではないかと指摘されると、反論できません。
このように、各グループのユーザー属性などに差があると、施策の効果だけをあぶり出すことが難しくなります。そのため、グループ差異を無くすことが重要なのですが、その方法のひとつにランダム化があります。ランダム化を行うことにより、グループ間の偏りを (確率的に) 無くすことができます。
ランダム化単位と分析単位
ここまでユーザー単位にランダム化を行う前提で話をしてきました。例えば新しいボタンデザインを A/B テストを通して検証することを考える場合、ユーザー単位にランダム化を行うというのは、ユーザーが何度サイトに訪れたとしても、毎回同じボタンデザインを提示するということです。
ほかのパターンとしては、アクセス単位にランダム化する方法が考えられます。ユーザーがアクセスするたびに現行デザインと新デザインのどちらを提示するかをランダムに決定するような方法です。
ランダム化単位とセットで考えたいのは分析単位です。分析単位とは、施策の効果を計測するための指標のグルーピングのことです。例えば「ユーザーひとり当たりの売上」を指標としているのなら、分析単位はユーザーということです。
ランダム化単位と分析単位についておさえておきたいのは次です。
ランダム化単位と分析単位は原則揃えよう。とくにユーザー単位にするのが良い。
ランダム化単位よりも分析単位が大きい場合
アクセス単位でランダム化を行い、分析はそれよりも大きいユーザー単位で行うとします。指標としては「ユーザーひとり当たりの売上」のようなものを考えています。
ランダム化はアクセス単位であるため、ユーザーによっては現行デザインと新デザインの両方を見ている可能性があります。そのため、そのようなユーザーの売上は現行デザインと新デザインの両方の効果が合算されていることになります。これでは新デザインの効果だけを取り出すことができません。
ランダム化単位よりも分析単位が小さい場合
上とは逆にユーザー単位でランダム化を行い、分析はそれよりも小さいアクセス単位で行うとします。アクセス単位の指標としては「そのアクセスでボタンをクリックしたかどうか」などが考えられます。
ランダム化はユーザー単位であるため、あるユーザーの 1 回目のアクセスと 2 回目のアクセスでは必ず同一のデザインが提示されます。つまりこの 2 つのアクセスは関連を持つということです。統計学の言葉を使えば、2 つのアクセスは独立でない、と表現できます。各データポイントが独立でない場合でも統計処理を行うことはできますが、分析の難易度が高くなります。もしくは各データポイントが独立であると目をつぶってしまう力技もありますが、それはそれで結果が歪んでしまうため、あまりおすすめしません。
ユーザー識別子
上で見てきたように、ランダム化単位と分析単位の両方をユーザーにするのが良いのですが、とくに Web においてはユーザーという概念があやふやになりがちです。
ログインユーザーに対して A/B テストを行うのであれば、ユーザー ID がユーザーの識別子となりえるでしょう。
一方で必ずしもログインが必要でないサービスもあります。非ログインユーザーに対する A/B テストを行いたい場合、ユーザーはどのように区別すれば良いでしょうか。ひとつの方法が Cookie です。Google Analytics のような分析ツールでも、初回アクセス時に払い出した ID を Cookie に保存することで、ユーザーを識別しています。しかし複数のデバイスからアクセスした場合は異なるユーザーとして扱われてしまう問題があります。
このように、単にユーザーと言ってもその識別方法は複数あります。エンジニアと相談し、ユーザーの識別がうまく行えているか確認することをおすすめします。
毎回異なるランダム性
あなたは先日とあるテスト X を行いました。今回新たにテスト Y を企画しているのですが、手を抜いて、ユーザーの振り分けをテスト X と全く同じものにしようと考えています。つまりテスト X で A グループだったユーザーはテスト Y でも A グループに振り分けられ、B グループでも同様だということです。
このやり方の問題点はどこでしょうか。ランダム化の目的はグループ間の偏りを無くすことでした。もしテスト X を通して A グループのユーザーの購買意欲が大幅に上昇していたとしたら、テスト Y の A グループも購買意欲が高い集団ということになり、テスト Y においてグループ間に偏りが生じてしまいます。つまり、「テスト X でどのグループに振り分けられていたか」という属性が均質化できていないということです。
このようなリスクがあるため、ランダム化のロジックをテストごとに変えなければなりません。
毎回異なるランダム化を行おう
技術的に言えば、乱数シードを毎回変えましょう、ということですね。
これに関連して、ユーザー ID の偶奇でグループの振り分けを行うこともやめておきましょう。一度だけならまだしも、複数回のテストで偶奇による振り分けを行うと、上で述べたのと同じ問題が起きてしまいます。
ランダム化機構の検証
ランダム化機構が正しく動作しているかを確かめる方法として、A/A テストがあります。A/B テストというのは、ランダムに分けた 2 つのユーザーグループそれぞれに、A パターンと B パターンを提示するものですが、A/A テストでは両グループに同一の A パターンを提示する方法です。同じパターンを提示するわけですから、両グループで同じことが起こるはずです。反対に、グループ間に差が生じた場合、ランダム化機構が壊れている可能性があるということです。
着目すべき観点は 2 つです。
グループのサイズに差が無いことを確認しよう
グループ間で指標値に差が無いことを確認しよう
ユーザー単位にランダム化している場合、グループのサイズというのはグループに属するユーザーの人数のことです。正しくランダム化が行えているのならば、大体同じ人数ずつにグループ分けがなされるはずです。
指標値としては A/B テストの評価に用いるものを見れば良いでしょう。
もしこれらに差が生じた場合、エンジニアに相談して原因を突き止めてもらいましょう。
さいごに
A/B テストは意外と難しいのだと冒頭で述べましたが、その意味がご理解いただけたでしょうか。ランダム化に関するところだけでも考えることがたくさんあります。施策を企画する PdM だけでなく、A/B テストを実装するエンジニアのみなさんにも頭に入れておいてほしいです。