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