Upgrade to Pro — share decks privately, control downloads, hide ads and more …

リクルートテクノロジーズ新人研修 2020 A/Bテストの話

リクルートテクノロジーズ新人研修 2020 A/Bテストの話

2020年度リクルート新人ブートキャンプ エンジニアコースの講義資料です

Recruit Technologies

August 21, 2020
Tweet

More Decks by Recruit Technologies

Other Decks in Technology

Transcript

  1. 昨今のWeb開発には「不確実」なものが多い • ぶっちゃけ何作ったらいいのかわからんケース ◦ 例:ユーザー体験を改善したい→は? ◦ 俺の考えた最強にCool!が広く受け入れられるかわからない • ユーザー体験や顧客満足を測れるか? ◦

    直接は計測できない。脳に電極さしても無理 ◦ 人間のシミュレーション?かなり限定的な検証 • →実際に使ってもらって確かめる ◦ 人を集めてユーザーインタビュー ◦ 慎重に実験計画をデザインした上でリリースしちゃう
  2. 実際に使って検証の2ケースの大まかな対比 ユーザーインタビュー Online Controlled Experiment メリット • 本格開発前に確認できる • 利用中の思考など深く聞ける

    • 実際にサービス利用するユーザーを対 象にどのくらい行動が変化するかの定 量的な推測ができる • 人を集めるコストが特別にかからない デメリット • 人を集めるコストが高い • 集めた人が実際にどのくらい想定サー ビス利用者を反映しているかわからな い • ↑に関連して実際にどのくらい改善でき るかわからない • 本格開発が必要 • 利用者の行動しかわからず内面まで推 定できない ↑今日はこっちの話をする
  3. しかし現実は • 全く同じ人たちに対して ◦ 全く同じ人は1人しかいない • 新しいhogeが ◦ 絶対評価は困難。既存のものとの相対比較 •

    ユーザー体験やサービスの利益に ◦ 直接測れない場合や影響が間接的な場合がある • 本当に貢献するか ◦ 現実には「ばらつき」がある
  4.  この4点が対応 条件A テスト 条件B 既存 ユーザーを無作為に割当 KPI, KGI を比較。基本、検定する 一般的なA/Bテスト

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

    ?1 ?2 ?3 ?4 1. 全く同じ人たちに対して 2. 新しいhogeが 3. ユーザー体験やサービスの利益に 4. 本当に貢献するか
  6. ユーザーを無作為に割当 • 全く同じ人の集団を作るのは不可能 ◦ そこで、2つの人の集団できる限り似せたい ◦ しかし、人の無数の属性を人手で割り振るのは困難 ▪ 例:年齢、職業、性別、居住地、昨日食べた晩ごはん等等 ▪

    困難というか実質不可能 ◦ 理論的には、その無数の属性と独立な要因で割当を決定 すれば2つの集団の属性の割合は近づく ▪ 集団のサイズが大きくなればなるほど近づく ▪ 無作為(ランダム)は無数の属性と理論的に独立 • ダイスふって決める感じ
  7.  この4点が対応 条件A テスト 条件B 既存 ユーザーを無作為に割当 KPI, KGI を比較。基本、検定する 一般的なA/Bテスト

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

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

    ?1 ?2 ?3 ?4 1. 全く同じ人たちに対して 2. 新しいhogeが 3. ユーザー体験やサービスの利益に 4. 本当に貢献するか
  10. まとめ • 全く同じ人たちに対して ◦ 無作為抽出で同じような集団を作る • 新しいhogeが ◦ 既存条件と対照実験をする •

    ユーザー体験やサービスの利益に ◦ 対応するKGIやKPIを実験前に決める • 本当に貢献するか ◦ 統計的仮説検定を活用する
  11. バンディットアルゴリズム補足 「バンディットアルゴリズムのほうがA/Bテストよりも結果が出るために必要なデータが少 ない」という言及について *バンディットアルゴリズムの手法はたくさんあるが一般的な傾向として ❏ 選択肢が2つしかない場合 ❏ ベイジアンA/Bテストのほうが早い ❏ 選択肢が2つよりも多いとき

    ❏ 筋の悪い選択肢にデータがいかないバンディットアルゴリズムのほうが早い ❏ ただし「筋の悪い」を、例えば火曜日の実験で判定したが実は日曜では有効な施策だった可能性が ある、といった過誤のリスクが高くなる
  12. VS サンプルサイズ問題 だいたい2つのアプローチ 1. 多変量テストの考え方 a. 多変量のモデル(だいたい多重線形回帰)の重み係数の検定を使う b. 計算がちょっと面倒だし、結果の解釈も困難なのであまり推奨しない i.

    多変量モデルをどう作るかにも恣意性あり 2. 交互作用があるかを確認し、交互作用がない場合はまとめて分析 a. 2要因間で「交互作用がない」を帰無仮説にして検定 b. 有意差がなければ、例えば施策 Aの検定をするさいに施策 Bの有無を無視して仮説検定 i. 施策間の割当を無作為に実施しているため、他の施策有無の影響がおなじようにのる c. 有意差があるところだけこまかく見る
  13. MSでも失敗してるよ話 論文紹介 Diagnosing Sample Ratio Mismatch in Online Controlled Experiments:

    A Taxonomy and Rules of Thumb for Practitioner 例えば… • CookieでA/B割当制御してたがCookie名を使いまわしたため昔から使ってるユー ザーに偏った条件ができた • firebaseでテスト条件取得してたが、firabaseの通信失敗時に特定の条件に割り当 てて通信状態の悪いユーザーに偏った条件ができや • 条件間で違うフィルターがかかってる(特定導線到達者VSふつうの訪問者)