リクルートテクノロジーズ新人 研修 2020 A/Bテストの話 2020/04/24：大杉直也

昨今のWeb開発には「不確実」なものが多い ● ぶっちゃけ何作ったらいいのかわからんケース ○ 例：ユーザー体験を改善したい→は？ ○ 俺の考えた最強にCool！が広く受け入れられるかわからない ● ユーザー体験や顧客満足を測れるか？ ○ 直接は計測できない。脳に電極さしても無理 ○ 人間のシミュレーション？かなり限定的な検証 ● →実際に使ってもらって確かめる ○ 人を集めてユーザーインタビュー ○ 慎重に実験計画をデザインした上でリリースしちゃう

実際に使って検証の２ケースの大まかな対比 ユーザーインタビュー Online Controlled Experiment メリット ● 本格開発前に確認できる ● 利用中の思考など深く聞ける ● 実際にサービス利用するユーザーを対 象にどのくらい行動が変化するかの定 量的な推測ができる ● 人を集めるコストが特別にかからない デメリット ● 人を集めるコストが高い ● 集めた人が実際にどのくらい想定サー ビス利用者を反映しているかわからな い ● ↑に関連して実際にどのくらい改善でき るかわからない ● 本格開発が必要 ● 利用者の行動しかわからず内面まで推 定できない ↑今日はこっちの話をする

Online Controlled Experiment (OCE) 単にA/Bテストとよばれることが多い（厳密にはA/BテストはOCEの一部） 実際にリリース Web上で実施 計画的に制御して 実際に確かめる 条件A テスト 条件B 既存 ユーザーを無作為に割当 KPI, KGI を比較。基本、検定する 一般的なA/Bテスト

A/Bテストで本当にやりたいことは ● 全く同じ人たちに対して ● 新しいhogeが ● ユーザー体験やサービスの利益に ● 本当に貢献するか をテストしたい

しかし現実は ● 全く同じ人たちに対して ○ 全く同じ人は１人しかいない ● 新しいhogeが ○ 絶対評価は困難。既存のものとの相対比較 ● ユーザー体験やサービスの利益に ○ 直接測れない場合や影響が間接的な場合がある ● 本当に貢献するか ○ 現実には「ばらつき」がある

　この４点が対応 条件A テスト 条件B 既存 ユーザーを無作為に割当 KPI, KGI を比較。基本、検定する 一般的なA/Bテスト ？1 ？2 ？3 ？4 1. 全く同じ人たちに対して 2. 新しいhogeが 3. ユーザー体験やサービスの利益に 4. 本当に貢献するか

　この４点が対応 条件A テスト 条件B 既存 ユーザーを無作為に割当 KPI, KGI を比較。基本、検定する 一般的なA/Bテスト ？1 ？2 ？3 ？4 1. 全く同じ人たちに対して 2. 新しいhogeが 3. ユーザー体験やサービスの利益に 4. 本当に貢献するか

ユーザーを無作為に割当 ● 全く同じ人の集団を作るのは不可能 ○ そこで、２つの人の集団できる限り似せたい ○ しかし、人の無数の属性を人手で割り振るのは困難 ■ 例：年齢、職業、性別、居住地、昨日食べた晩ごはん等等 ■ 困難というか実質不可能 ○ 理論的には、その無数の属性と独立な要因で割当を決定 すれば2つの集団の属性の割合は近づく ■ 集団のサイズが大きくなればなるほど近づく ■ 無作為（ランダム）は無数の属性と理論的に独立 ● ダイスふって決める感じ

　この４点が対応 条件A テスト 条件B 既存 ユーザーを無作為に割当 KPI, KGI を比較。基本、検定する 一般的なA/Bテスト ？1 ？2 ？3 ？4 1. 全く同じ人たちに対して 2. 新しいhogeが 3. ユーザー体験やサービスの利益に 4. 本当に貢献するか

テスト条件とコントロール条件 ● 画面デザイン、レコメンドアルゴリズム、新機能などなど試したい対象は多岐にわた る ● テスト条件をひとつだけではなく、複数同時に実験（ABCテスト）や、複数の対照実 験を同時に実施するテストなどのパターンあり ○ 同時に複数のA/Bテストを実施する場合は対照実験の数だけダイスふる ○ 複数のA/Bテスト間で独立性を仮定できない場合、多変量テストが用いられる（後述）

　この４点が対応 条件A テスト 条件B 既存 ユーザーを無作為に割当 KPI, KGI を比較。基本、検定する 一般的なA/Bテスト ？1 ？2 ？3 ？4 1. 全く同じ人たちに対して 2. 新しいhogeが 3. ユーザー体験やサービスの利益に 4. 本当に貢献するか

A/Bテストの測定。KPI、KGI KGI（Key Goal Indicator）とはビジネスの最終目標を定量的に評価できる指標です。重要目標達成指標とも呼ばれます。売上高や 成約数、利益率などがそれに当てはまります。 ＊ただしリクルートのWebではゴール指標まで距離が遠く、KGIを置かなかったりCVを仮置したりするケースがほとんど KPI（Key Performance Indicator）とはKGIを達成するための各プロセスが適切に実施されているかどうか定量的に評価するための 指標です。重要業績評価指標とも呼ばれています。セッション数やクリック数など指標は無数にありますが、その中で適切な指標を 設定することが重要です。 https://growthhackjournal.com/article/words/the-difference-kgi-kpi/　からコピペ 今回のテスト内容で影響（良い方向だけでなく悪い方向も）出そうな KPIは観測する 実験前に「意思決定」に使う KGI/KPIの優先順位を基準を決めておく

　この４点が対応 条件A テスト 条件B 既存 ユーザーを無作為に割当 KPI, KGI を比較。基本、検定する 一般的なA/Bテスト ？1 ？2 ？3 ？4 1. 全く同じ人たちに対して 2. 新しいhogeが 3. ユーザー体験やサービスの利益に 4. 本当に貢献するか

検定する。統計的仮説検定とは 観測されたKGI/KPIが「実験間」で違うことの基準に使われる考え方 結構、面倒くさい論理なので、次ページから丁寧に解説します

統計的仮説検定　帰無仮説をたてる 統計的仮説検定は背理法の一種 まず、本当は否定したい仮説をたてる 「条件Aで観測されたKPIは、条件Bで観測されたKPIと同一」 →帰無仮説と呼ばれる ただし、現実の測定にはばらつきがあるので同一になることは（ほぼ）ない なので、ばらつきまで含めて同一の判定を行う

統計的仮説検定　ばらつきを扱う その観測された値の性質から分布を仮定する 例えば、「クリック率」なら、クリックするかしないかなので、コイントスで表裏の確率で使 う二項分布を仮定する 厳密には毎回同じコインを投げてるわけでないがよく使う仮定 二項分布を仮定した場合 条件AのKPIが理論値と同一かを検証（ばらつきが片方）→二項検定 条件Aと条件Bの指標が同一か検証（ばらつきが両方）→χ2乗独立性の検定

分布を仮定して今回の計測値が得られる確率を計算 条件Aと条件BのKPIが同一だと仮定した場合、AとBの実際のKPI差が生じる確率を計 算 この確率が十分小さいとき→AとBに差がないとは考えにくい→AとBに差がある という論理。十分小ささは有意水準とよばれ、1%や5%が慣習的によく使われる この差があるという結論を「有意差がでた」と表現される 【注意】この確率が十分に小さくない、「AとBに差がない」を意味しない その場合、差があるかないかを今の観測結果から結論できない、が正しい

まとめ ● 全く同じ人たちに対して ○ 無作為抽出で同じような集団を作る ● 新しいhogeが ○ 既存条件と対照実験をする ● ユーザー体験やサービスの利益に ○ 対応するKGIやKPIを実験前に決める ● 本当に貢献するか ○ 統計的仮説検定を活用する

絶対覚えてほしいA/Aテスト A/Bテストをまったく同じ条件で実施するテスト まったく同じ条件なのでKPIに違いがあったらバグってる←これをテストできる また、偶然のばらつきがどの程度なのかを推定するのにも使える 新しい仕組みでA/Bテストするさいは、必ず実施すること！

ここからはA/B テストtips

統計的仮説検定以外の手法 Bayesian A/B testing という手法があります 統計仮説検定の代わりにベイズ推定を使うといったものらしい（4の部分） メリット： ❏ 検出力が高く、より少ないサンプルでも結果が出る ❏ テスト計画や指標設計が複雑でも計算できる デメリット： ❏ 計算が重く、ExcelやSQLでの実行が困難

バンディットアルゴリズムとの違い A/Bテストと似たような存在にバンディットアルゴリズムがある A/Bテストもバンディットアルゴリズムも「複数の選択肢のうちどれを選択すればよいの か？」問題を答える この２つの比較メリデメの話ではない。そもそも解きたい問題が違う ❏ バンディットアルゴリズムの場合 ❏ 実験期間内での利得を最大化する ❏ A/Bテストの場合 ❏ 本当に一番良い選択肢をみつける 一般的に、選択肢がすぐ陳腐化する広告などはバンディット、Web画面のようにしばらく 最良の選択肢が変わらないと思われるものはA/Bテストが良い

バンディットアルゴリズム補足 「バンディットアルゴリズムのほうがA/Bテストよりも結果が出るために必要なデータが少 ない」という言及について ＊バンディットアルゴリズムの手法はたくさんあるが一般的な傾向として ❏ 選択肢が2つしかない場合 ❏ ベイジアンA/Bテストのほうが早い ❏ 選択肢が２つよりも多いとき ❏ 筋の悪い選択肢にデータがいかないバンディットアルゴリズムのほうが早い ❏ ただし「筋の悪い」を、例えば火曜日の実験で判定したが実は日曜では有効な施策だった可能性が ある、といった過誤のリスクが高くなる

同時に複数施策のA/Bテスト よく聞く話「複数同時に施策のテストしたら結果が濁る」 たしかに、複数施策の間で交互作用がある場合はよくある 交互作用がある→正解 交互作用があるから、同時にテストしてはならない→？？？

施策間に交互作用があった場合 同時にテストしたら→A:False, B:True の最高の施策にたどり着ける バラバラにテストしたら→？？？（考えてみよう） Ture False True 良い 最高！ False ふつう 全然ダメ IS　施策A IS　施策B

施策間に交互作用があった場合 同時にテストしたら→A:False, B:True の最高の施策にたどり着ける バラバラにテストしたら→答え：AとBのどちらを先にするかで結果が変わる Ture False True 良い 最高！ False ふつう 全然ダメ IS　施策A IS　施策B

同時に複数施策のA/Bテスト よく聞く話「複数同時に施策のテストしたら結果が濁る」 たしかに、複数施策の間で交互作用がある場合はよくある 交互作用がある→正解 交互作用があるから、同時にテストしてはならない→逆。交互作用を見ないとダメ

同時に複数施策のA/Bテスト 施策間に独立に無作為抽出でテスト条件の割当を行うのが大前提 その上で全組み合わせ毎に統計検定をかければOKか？ 問題2つ。多重検定の罠、サンプルサイズが足りず検出力が下がる ❏ 多重検定の罠とは？ ❏ 本当に帰無仮説が正しいときでも有意水準５％での検定を独立な実験で 20回やれば、1つくらいは 有意差でてしまう問題 ❏ サンプルサイズが足りず検出力が下がるとは？ ❏ 要するにデータ不足でうまく統計的仮説検定できない。「 Nが不足」とも表現

VS 多重検定の罠 有意差が出にくくするために補正をかける 実用上、便利なのはボンフェローニ法。 有意水準5%で20回テストするときは、有意差の基準を 0.05/20 = 0.0025 の確率以下 のときから帰無仮説を棄却する補正方法 ただし、この20の部分が莫大な数になると向いてない 莫大なデータ数と試行回数の場合は統計的仮説検定がそもそも向いてない

VS サンプルサイズ問題 だいたい２つのアプローチ 1. 多変量テストの考え方 a. 多変量のモデル（だいたい多重線形回帰）の重み係数の検定を使う b. 計算がちょっと面倒だし、結果の解釈も困難なのであまり推奨しない i. 多変量モデルをどう作るかにも恣意性あり 2. 交互作用があるかを確認し、交互作用がない場合はまとめて分析 a. 2要因間で「交互作用がない」を帰無仮説にして検定 b. 有意差がなければ、例えば施策 Aの検定をするさいに施策 Bの有無を無視して仮説検定 i. 施策間の割当を無作為に実施しているため、他の施策有無の影響がおなじようにのる c. 有意差があるところだけこまかく見る

同時に複数施策のA/Bテスト まとめると ❏ 可能な限り交互作用を確認するために同時にテストしたほうが良い ❏ 多重検定の補正をかける（ボンフェローニ補正） ❏ 交互作用の有無を検定し、無い場合は他の施策の影響を気にせずに分析

A/Bテストよくある失敗例 論文紹介 Puzzling Outcomes 5つの失敗事例が紹介 ❏ KPI設定ミス ❏ ブラウザ間挙動の違いとビーコン ❏ ご祝儀効果 ❏ 実験期間と検出力 ❏ 実験後の残存効果

MSでも失敗してるよ話 論文紹介 Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioner 例えば… ● CookieでA/B割当制御してたがCookie名を使いまわしたため昔から使ってるユー ザーに偏った条件ができた ● firebaseでテスト条件取得してたが、firabaseの通信失敗時に特定の条件に割り当 てて通信状態の悪いユーザーに偏った条件ができや ● 条件間で違うフィルターがかかってる（特定導線到達者VSふつうの訪問者）

p-hacking 有意差をだすためのハック行為の総称 許されざる行為。悪意もって実施は許されない行為 テクニックはいろいろとあるが、下の２つは要注意 1. 毎日累積で有意差確認して有意差でたら実験終了 2. 多重検定を考慮せずにたくさんA/Bテスト a. A/Aテストしてるだけでも偶然有意差がでたプラスだけ積み上がるので効果は積み上がる