メルカリにおけるA/Bテストワークフローの改善 これまでとこれから

2022/01/14開催 [Online] PyData.Tokyo Meetup #25 ABテストの実践における発表資料
https://pydatatokyo.connpass.com/event/235205/

Transcript

1. 1 メルカリにおけるA/Bテストワークフローの改善、これま でとこれから 柳沼 慎哉（@yaginuuun） 2022/1/14, PyData.Tokyo Meetup #25
2. 2 Introduction
3. 3 自己紹介 • Data Analyst @ mercari (2020~) ◦ Personalization施策の分析支援 ◦ A/Bテスト周りのワークフロー改善 • 最近の趣味： ◦ トレカ収集 @ mercari ◦ Podcast配信 柳沼 慎哉 Twitter: @yaginuuun
4. 4 メルカリについて 国内最大のC2Cマーケットプレイスを運営
5. 5 メルカリの分析チーム（JP Analytics） Growth Analytics Product Analytics Analytics Infra Product の改善施策の意思決定を主導する （施策の成功指標設計、実験の設計・評価、カスタマーインサイトの導出） 事業戦略の意思決定を主導する （マーケティング予算等グループ全体の成長戦略への提言、グロース施策への提言 ) 分析環境・ノウハウの整備によりデータの民主化を進める （KPIの標準化、分析基盤の整備、実験設計の標準化） 大きく３つのサブチームに分かれている
6. 6 メルカリの分析チーム（JP Analytics） Growth Analytics Product Analytics Analytics Infra Product の改善施策の意思決定を主導する （施策の成功指標設計、実験の設計・評価、カスタマーインサイトの導出） 事業戦略の意思決定を主導する （マーケティング予算等グループ全体の成長戦略への提言、グロース施策への提言 ) 分析環境・ノウハウの整備によりデータの民主化を進める （KPIの標準化、分析基盤の整備、実験設計の標準化） 今日は Analytics Infra team における取り組みの話
7. 7 今日話す内容 メルカリにおけるA/Bテスト周りのワークフロー改善を中心に話します。 過去のイベントでは話していなかった、取り組みをどのように広げたかという点にも触れます。 • メルカリで用いられているA/Bテスト設計テンプレート • どのように取り組みを広げていったか
8. 8 Background
9. 9 A/Bテスト（Randomized Controlled Trial） • 世界中で使われている効果検証のゴールドスタンダード • メルカリでもほとんどの変更がA/Bテストによって評価されている。 Control group Treatment group
10. 10 前提：A/Bテストは既に実用されていた Experimentation Maturity Models（成熟モデル） Fly 04 • 1000~ tests / year • テスト集計が自動化されている • ほぼ全ての変更時に A/Bテストが行われている Run 03 • ~250 tests / year • 包括的なmetrics setの定義、OECの設定 • ほとんどの変更時に A/Bテストを行う Walk 02 • ~50 tests / year • 標準的な指標の定義 • SRM check, A/Aテスト実施などによる A/Bテスト結 果の信頼性向上 Crawl 01 • ~10 tests / year • 統計値を計算できる基盤が整っている。 『A/Bテスト実践ガイド』第 4章 実験のプラットフォームと文化
11. 11 前提：A/Bテストは既に実用されていた 既に Crawl Phase は超えていた Fly 04 • 1000~ tests / year • テスト集計が自動化されている • ほぼ全ての変更時に A/Bテストが行われている Run 03 • ~250 tests / year • 包括的なmetrics setの定義、OECの設定 • ほとんどの変更時に A/Bテストを行う Walk 02 • ~50 tests / year • 標準的な指標の定義 • SRM check, A/Aテスト実施などによる A/Bテスト結 果の信頼性向上 Crawl 01 • ~10 tests / year • 統計値を計算できる基盤が整っている。 『A/Bテスト実践ガイド』第 4章 実験のプラットフォームと文化
12. 12 存在していた課題 A/Bテストは施策効果検証のスタンダードとして実用されていたものの、ワークフローや設計時の検討事項に 対する課題は小さくなかった。 • A/Bテストに必要な考慮事項に対する理解度のばらつき • ワークフローのばらつき
13. 13 存在していた課題 A/Bテストは施策効果検証のスタンダードとして実用されていたものの、ワークフローや設計時の検討事項に 対する課題は小さくなかった。 • A/Bテストに必要な考慮事項に対する理解度のばらつき • ワークフローのばらつき 効果検証の質に課題
14. 14 効果検証の質が低いと起こること 結果が信頼できなくなってしまう。 改善しているように見えていても改悪している。またはその逆のパターンもあり得る。 こっちに進んでいると思っている
15. 15 効果検証の質が低いと起こること 実際にはこっちに進んでいる 結果が信頼できなくなってしまう。 改善しているように見えていても改悪している。またはその逆のパターンもあり得る。
16. 16 突然のクイズ 以下のA/Bテスト評価設計に問題はあるでしょうか？ • 状況：アプリpush通知の改善 • 変更：通知メッセージで訴求する内容を変更（ゴールは同じとする） • 割り当て：user_id, controlとtreatmentに均等に割り当てる • 評価指標：push通知を開いた人のうちCVする人の割合（CVR） ◦ [CVしたUU] / [Push開封UU] • 検定：母比率の差の検定 1 Push送信 Push開封 2 CV N
17. 17 答え：問題がある
18. 18 代表的な考慮事項例：Sample Ratio Mismatch (SRM) 『A/Bテスト実践ガイド』第 21章 サンプル比率のミスマッチと信用性に関連するガードレールメトリクス • 指標の分母となる数値が variant 間で割り当て比率からズレる現象 • 意図せぬバイアスを含んでいることの兆候 • 適合度のカイ二乗検定などでチェックする • A/Bテストの様々な段階で発生することが報告されている ◦ Assignment ◦ Execution ◦ Analysis ◦ … • 今回のケースではこれが発生する可能性が高い
19. 19 どういうことか？
20. 20 代表的な考慮事項例：Sample Ratio Mismatch (SRM) Push文言の変更によって、 CV数と同時にPush開封数も変化する可能性が高い 下図ではどちらも増えた場合を仮定 Control Treatment CV Push Open CVは増加 Push openはさらに増加
21. 21 代表的な考慮事項例：Sample Ratio Mismatch (SRM) Push文言の変更によって、 CV数と同時にPush開封数も変化する可能性が高い 下図ではどちらも増えた場合を仮定 Control Treatment CV Push Open CVは増加 Push openはさらに増加 評価指標の分母となる数値がvariant間で大きく異 なる = SRMの発生
22. 22 代表的な考慮事項例：Sample Ratio Mismatch (SRM) そのまま評価を行うと、実際は Push開封の増加に伴いCVも増加しているにもかかわらず指標は悪化して 見える。 Control Treatment (Scaled) CV Push open CVRは下がって見える！
23. 23 [再掲]突然のクイズ 以下のA/Bテスト評価設計に問題はあるでしょうか？ • 状況：アプリpush通知の改善 • 変更：通知メッセージで訴求する内容を変更（ゴールは同じとする） • 割り当て：user_id, controlとtreatmentに均等に割り当てる • 評価指標：push通知を開いた人のうちCVする人の割合（CVR） ◦ [CVしたUU] / [Push開封UU] • 検定：母比率の差の検定 1 Push送信 Push開封 2 CV N
24. 24 [再掲]突然のクイズ 以下のA/Bテスト評価設計に問題はあるでしょうか？ • 状況：アプリpush通知の改善 • 変更：通知メッセージで訴求する内容を変更（ゴールは同じとする） • 割り当て：user_id, controlとtreatmentに均等に割り当てる • 評価指標：push通知を開いた人のうちCVする人の割合（CVR） ◦ [CVしたUU] / [Push送信UU] • 検定：母比率の差の検定 1 Push送信 Push開封 2 CV N
25. 25 他にも考慮すべき事項は様々... ここで取り上げたSRMは一例。他にも様々な検討事項が存在。 • 多重比較 • Power Analysis（サンプルサイズ設計） • randomization unit != Analysis unit • Cherry picking • 評価指標のSensitivity • …
26. 26 他にも考慮すべき事項は様々... ここで取り上げたSRMは一例。他にも様々な検討事項が存在。 • 多重比較 • Power Analysis（サンプルサイズ設計） • randomization unit != Analysis unit • Cherry picking • 評価指標のSensitivity • … ではどうするか？
27. 27 私たちの取り組み Experiment design docを用いたA/Bテスト設計フロー整備
28. 28 標準化されたフロー + 検証設計テンプレートの整備 • 検証設計テンプレート：A/Bテスト開始前に決めておくべきことを網羅 • 標準化されたフロー： ◦ 事前に評価設計をするフローの浸透 ◦ 上記テンプレートのレビューを通じた検証の質の担保
29. 29 標準化されたフロー + 検証設計テンプレートの整備 • 検証設計テンプレート：A/Bテスト開始前に決めておくべきことを網羅 • 標準化されたフロー： ◦ 事前に評価設計をするフローの浸透 ◦ 上記テンプレートのレビューを通じた検証の質の担保
30. 30 Contents: • Background • Test settings • Metrics details • How to evaluate metrics • Action plan Experiment design doc (EDD) A/Bテストの設計項目をテンプレート化
31. 31 Contents: • Background • Test settings • Metrics details • How to evaluate metrics • Action plan
 Experiment design doc (EDD) 背景や実験設定
32. 32 Contents: • Background • Test settings • Metrics details • How to evaluate metrics • Action plan
 Experiment design doc (EDD) 評価指標、評価方法
33. 33 Contents: • Background • Test settings • Metrics details • How to evaluate metrics • Action plan
 Experiment design doc (EDD) A/Bテスト終了後のNext Action（各指標の動きに応じていくつか）
34. 34 Contents: • Background • Test settings • Metrics details • How to evaluate metrics • Action plan
 Experiment design doc (EDD) 最もコアなMetrics detailsについてもう少しだけ解説します。
35. 35 Experiment design doc - Metrics Details 三種類の指標を定義 Goal metrics 改善を期待する指標 1 2 3 Guardrail metrics UX, ビジネス上重要な棄損したくない指標 Debugging metrics 意図通りテストが進んでいるかを確認する指標
36. 36 Experiment design doc - Metrics Details 三種類の指標を定義 Goal metrics 改善を期待する指標 1 2 3 Guardrail metrics UX, ビジネス上重要な棄損したくない指標 Debugging metrics 意図通りテストが進んでいるかを確認する指標 • 仮説によって設定するものが変わるので、 A/Bテストによって異なること が多い • 指標設計の大部分はここが占める
37. 37 Experiment design doc - Metrics Details 三種類の指標を定義 Goal metrics 改善を期待する指標 1 2 3 Guardrail metrics UX, ビジネス上重要な棄損したくない指標 Debugging metrics 意図通りテストが進んでいるかを確認する指標 • 監視的な役割が強くなるのでA/Bテスト共通で設定されることが多い。 • 棄損があった時にクリティカルなものを設定。（アクションが変わらないものは基 本的に設定しない）
38. 38 Experiment design doc - Metrics Details 三種類の指標を定義 Goal metrics 改善を期待する指標 1 2 3 Guardrail metrics UX, ビジネス上重要な棄損したくない指標 Debugging metrics 意図通りテストが進んでいるかを確認する指標 • 変更内容は適用されているか or どのくらいの認知を得ているのか確認できる 指標 • SRMを基本とした意図しないバイアス混入の確認
39. 39 (補足) Other metrics 起こったことの理解を深めるための metrics • Guardrail metricsに置いていたトータルの購買数が下がったとする ◦ 主にどの経路からの購買が下がっているのか？ ◦ 購買に至るまでのどの段階で棄損が起こっているのか？
40. 40 (補足) Other metrics 起こったことの理解を深めるための metrics • Guardrail metricsに置いていたトータルの購買数が下がったとする ◦ 主にどの経路からの購買が下がっているのか？ ◦ 購買に至るまでのどの段階で棄損が起こっているのか？ Other metricsとして経路別の購買や購買ファネルの各段階における遷移 率などを設定することで結果の解釈性を高める
41. 41 EDDの詳細が気になる方はこちらの資料もご覧ください https://speakerdeck.com/shyaginuma/btesutobiao-zhun-hua-hefalsequ-rizu-mi
42. 42 標準化されたフロー + 検証設計テンプレートの整備 • 検証設計テンプレート：A/Bテスト開始前に決めておくべきことを網羅 • 標準化されたフロー： ◦ 事前に評価設計をするフローの浸透 ◦ 上記テンプレートのレビューを通じた検証の質の担保
43. 43 標準化されたフロー + 検証設計テンプレートの整備 • 検証設計テンプレート：A/Bテスト開始前に決めておくべきことを網羅 • 標準化されたフロー： ◦ 事前に評価設計をするフローの浸透 ◦ 上記テンプレートのレビューを通じた検証の質の担保 EDDを事前に書くフローを浸透させることで後から過度に思考錯誤してしま うことを防止
44. 44 標準化されたフロー + 検証設計テンプレートの整備 • 検証設計テンプレート：A/Bテスト開始前に決めておくべきことを網羅 • 標準化されたフロー： ◦ 事前に評価設計をするフローの浸透 ◦ 上記テンプレートのレビューを通じた検証の質の担保 レビューを取り入れることで、A/Bテストに慣れていないメンバーでも一定の 質を保った検証を可能に
45. 45 ワークフロー（Data Analystの場合） 最初数回はAnalystのreviewを受けることを推奨。徐々に内部で完結へ。 Analyst PdM Project A Analyst 実験設計を詰める review依頼 Analyst PdM Project A 実験設計を詰める ここで完結
46. 46 取り組みを広げるアプローチ
47. 47 取り組みを広げるアプローチ 一般に大きく2種類のアプローチが考えられる。 Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros: 強制力を働かせるため浸透速度が早い • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れるので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
48. 48 取り組みを広げるアプローチ 私たちは Bottom up なアプローチを採用 Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros: 強制力を働かせるため浸透速度が早い • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れるので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
49. 49 取り組みを広げるアプローチ いきなりTop downで進めてしまうリスクを重く見た。 Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros: 強制力を働かせるため浸透速度が早い • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れるので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
50. 50 取り組みを広げるアプローチ Bottom upであれば改善を重ねつつ取り組みを広げることができる。 Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros: 強制力を働かせるため浸透速度が早い • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れる ので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
51. 51 取り組みを広げるアプローチ どこから取り組みを広げるのか？ Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros: 強制力を働かせるため浸透速度が早い • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れるので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
52. 52 [再掲] メルカリの分析チーム（JP Analytics） Growth Analytics Product Analytics Analytics Infra Product の改善施策の意思決定を主導する （施策の成功指標設計、実験の設計・評価、カスタマーインサイトの導出） 事業戦略の意思決定を主導する （マーケティング予算等グループ全体の成長戦略への提言、グロース施策への提言 ) 分析環境・ノウハウの整備によりデータの民主化を進める （KPIの標準化、分析基盤の整備、実験設計の標準化） 初手として、Product Analytics を中心に浸透を図る
53. 53 Product Analyticsの選定理由 最も対象ユーザー層に近い • PdMと二人三脚で仮説構築、検証を行う • 職務上A/Bテストの設計、評価に関わる機会が圧倒的に多い 組織的な距離が近い • 定期的にサブチームをまたぐSyncを行っており、互いにやっていることが把握しやすい • フィードバックが受けやすい 二つのポイント
54. 54 Product Analyticsの選定理由 最も対象ユーザー層に近い • PdMと二人三脚で仮説構築、検証を行う • 職務上A/Bテストの設計、評価に関わる機会が圧倒的に多い 組織的な距離が近い • 定期的にサブチームをまたぐSyncを行っており、互いにやっていることが把握しやすい • フィードバックが受けやすい フィードバックが受けやすい = Bottom upな進め方の利点を活かしやすい
55. 55 本取り組みにおいてフィードバックをもらうことの意義 意図した目的を達成できているのかの確認 • そもそも施策として適切なのかどうかの確認 • 目的達成に不十分な箇所の把握 コストと便益のバランス改善 • 新しいdocumentを書くことは基本的にコスト • 現状でコストと便益のバランスがどうなっているのかの把握 • さらにコストを下げることや便益を増やすことができないのかの検討
56. 56 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか？ • EDDを書く中で最も工数のかかったポイントはどこか？ or さらなる改善ポイン ト 使用者は比較的少数だったので 1on1でのインタビューを実施
57. 57 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか？ ◦ 検証の質が上がった ◦ 検証の質は変わらないがコミュニケーションがスムーズになった • EDDを書く中で最も工数のかかったポイントはどこか？ or さらなる改善ポイン ト 使用者は比較的少数だったので 1on1でのインタビューを実施
58. 58 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか？ ◦ 検証の質が上がった ◦ 検証の質は変わらないがコミュニケーションがスムーズになった • EDDを書く中で最も工数のかかったポイントはどこか？ or さらなる改善ポイン ト 使用者は比較的少数だったので 1on1でのインタビューを実施 施策の方向性としてはズレていないこと、想定していなかったものではありつ つも便益を提供できていることの確認
59. 59 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか？ • EDDを書く中で最も工数のかかったポイントはどこか？ or さらなる改善ポイン ト ◦ 想定よりも、EDDのコストに対するネガティブな意見は少なかった ◦ それよりも、各指標をどのように評価するのが基本的なのかや設計時の検 討項目を知りたいと言う声が多かった 使用者は比較的少数だったので 1on1でのインタビューを実施
60. 60 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか？ • EDDを書く中で最も工数のかかったポイントはどこか？ or さらなる改善ポイン ト ◦ 想定よりも、EDDのコストに対するネガティブな意見は少なかった ◦ それよりも、各指標をどのように評価するのが基本的なのかや設計時の検 討項目を知りたいと言う声が多かった 使用者は比較的少数だったので 1on1でのインタビューを実施 Template自体の改善と言うよりもReferenceへのニーズが高かった
61. 61 FBを経ての改善：Referenceの拡充 • EDDの各項目に関する説明 • Reviewの際のチェックリスト 元々から存在
62. 62 FBを経ての改善：Referenceの拡充 • EDDの各項目に関する説明 • Reviewの際のチェックリスト • Best Practices ◦ Goal, Guardrail, Debuggingの指標をどのように評価するのか ◦ Power analysisの方法 ◦ … • Anti patterns ◦ この発表の冒頭で述べたようなPitfallを実例を交えて解説 元々から存在
63. 63 取り組みの現在地 • プロダクト開発組織を中心に利用が拡大中 • Data Analystを中心として様々な職種の方に活用していただいている ◦ Data Analyst ◦ SWE ◦ PdM
64. 64 これからの課題
65. 65 [再掲] Experimentation Maturity models 今メルカリは Walk ~ Run 辺りのフェーズ Fly 04 • 1000~ tests / year • テスト集計が自動化されている • ほぼ全ての変更時に A/Bテストが行われている Run 03 • ~250 tests / year • 包括的なmetrics setの定義、OECの設定 • ほとんどの変更時に A/Bテストを行う Walk 02 • ~50 tests / year • 標準的な指標の定義 • SRM check, A/Aテスト実施などによる A/Bテスト結 果の信頼性向上 Crawl 01 • ~10 tests / year • 統計値を計算できる基盤が整っている。 『A/Bテスト実践ガイド』第 4章 実験のプラットフォームと文化
66. 66 [再掲] Experimentation Maturity models これからFlyフェーズに入っていく Fly 04 • 1000~ tests / year • テスト集計が自動化されている • ほぼ全ての変更時に A/Bテストが行われている Run 03 • ~250 tests / year • 包括的なmetrics setの定義、OECの設定 • ほとんどの変更時に A/Bテストを行う Walk 02 • ~50 tests / year • 標準的な指標の定義 • SRM check, A/Aテスト実施などによる A/Bテスト結 果の信頼性向上 Crawl 01 • ~10 tests / year • 統計値を計算できる基盤が整っている。 『A/Bテスト実践ガイド』第 4章 実験のプラットフォームと文化
67. 67 [再掲] Experimentation Maturity models テスト集計の自動化 Fly 04 • 1000~ tests / year • テスト集計が自動化されている • ほぼ全ての変更時に A/Bテストが行われている Run 03 • ~250 tests / year • 包括的なmetrics setの定義、OECの設定 • ほとんどの変更時に A/Bテストを行う Walk 02 • ~50 tests / year • 標準的な指標の定義 • SRM check, A/Aテスト実施などによる A/Bテスト結 果の信頼性向上 Crawl 01 • ~10 tests / year • 統計値を計算できる基盤が整っている。 『A/Bテスト実践ガイド』第 4章 実験のプラットフォームと文化
68. 68 分析の半自動化は今後必ず必要になる • 各Analystが十分に知識を付けたとしても人手でやる限りは必ずどこかでミスは起こる。リ ソースの制約も実際問題として存在。 • EDDは単体では Institutional memory の蓄積に向かない ◦ Institutional memory: 過去に実行されたA/Bテスト結果やリリース判断など ▪ 組織としての学びの蓄積 ▪ 新メンバーのオンボーディング ◦ EDDは背景や実験設計を理解するのには役立つが 結果の集積という観点だと弱い 『A/Bテスト実践ガイド』第 8章 インスティテューショナルメモリとメタアナリシス
69. 69 分析の半自動化: Experimentation Platform 外資系企業を中心に A/Bテストの分析までをカバーしたプラットフォームをそれぞれ開発、保有している。 • 企業によって搭載されている機能も異なる ◦ Netflix: Reimagining Experimentation Analysis at Netflix ◦ Airbnb: Scaling Airbnb’s Experimentation Platform ◦ Uber: Under the Hood of Uber’s Experimentation Platform • 簡易的にstreamlitによって作成したMVPを部分的にテスト導入するなど始まっている部 分もある。 ◦ streamlit: pythonで簡単にWebアプリが構築できるライブラリ
70. 70 まとめ
71. 71 まとめ A/Bテストワークフローの改善 • Experiment design doc (EDD) ◦ Goal metrics ◦ Guardrail metrics ◦ Debugging metrics • Bottom up型で展開 ◦ フィードバックを通じて価値検証と改善を行いつつ展開 • 今後の課題としては分析の自動化があげられる
72. 72 End.