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

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

yaginuuun
January 14, 2022

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

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

yaginuuun

January 14, 2022
Tweet

More Decks by yaginuuun

Other Decks in Technology

Transcript

  1. 3 自己紹介 • Data Analyst @ mercari (2020~) ◦ Personalization施策の分析支援

    ◦ A/Bテスト周りのワークフロー改善 • 最近の趣味: ◦ トレカ収集 @ mercari ◦ Podcast配信 柳沼 慎哉 Twitter: @yaginuuun
  2. 5 メルカリの分析チーム(JP Analytics) Growth Analytics Product Analytics Analytics Infra Product

    の改善施策の意思決定を主導する (施策の成功指標設計、実験の設計・評価、カスタマーインサイトの導出) 事業戦略の意思決定を主導する (マーケティング予算等グループ全体の成長戦略への提言、グロース施策への提言 ) 分析環境・ノウハウの整備によりデータの民主化を進める (KPIの標準化、分析基盤の整備、実験設計の標準化) 大きく3つのサブチームに分かれている
  3. 6 メルカリの分析チーム(JP Analytics) Growth Analytics Product Analytics Analytics Infra Product

    の改善施策の意思決定を主導する (施策の成功指標設計、実験の設計・評価、カスタマーインサイトの導出) 事業戦略の意思決定を主導する (マーケティング予算等グループ全体の成長戦略への提言、グロース施策への提言 ) 分析環境・ノウハウの整備によりデータの民主化を進める (KPIの標準化、分析基盤の整備、実験設計の標準化) 今日は Analytics Infra team における取り組みの話
  4. 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章 実験のプラットフォームと文化
  5. 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章 実験のプラットフォームと文化
  6. 18 代表的な考慮事項例:Sample Ratio Mismatch (SRM) 『A/Bテスト実践ガイド』第 21章 サンプル比率のミスマッチと信用性に関連するガードレールメトリクス • 指標の分母となる数値が

    variant 間で割り当て比率からズレる現象 • 意図せぬバイアスを含んでいることの兆候 • 適合度のカイ二乗検定などでチェックする • A/Bテストの様々な段階で発生することが報告されている ◦ Assignment ◦ Execution ◦ Analysis ◦ … • 今回のケースではこれが発生する可能性が高い
  7. 30 Contents: • Background • Test settings • Metrics details

    • How to evaluate metrics • Action plan Experiment design doc (EDD) A/Bテストの設計項目をテンプレート化
  8. 31 Contents: • Background • Test settings • Metrics details

    • How to evaluate metrics • Action plan
 Experiment design doc (EDD) 背景や実験設定
  9. 32 Contents: • Background • Test settings • Metrics details

    • How to evaluate metrics • Action plan
 Experiment design doc (EDD) 評価指標、評価方法
  10. 33 Contents: • Background • Test settings • Metrics details

    • How to evaluate metrics • Action plan
 Experiment design doc (EDD) A/Bテスト終了後のNext Action(各指標の動きに応じていくつか)
  11. 34 Contents: • Background • Test settings • Metrics details

    • How to evaluate metrics • Action plan
 Experiment design doc (EDD) 最もコアなMetrics detailsについてもう少しだけ解説します。
  12. 35 Experiment design doc - Metrics Details 三種類の指標を定義 Goal metrics

    改善を期待する指標 1 2 3 Guardrail metrics UX, ビジネス上重要な棄損したくない指標 Debugging metrics 意図通りテストが進んでいるかを確認する指標
  13. 36 Experiment design doc - Metrics Details 三種類の指標を定義 Goal metrics

    改善を期待する指標 1 2 3 Guardrail metrics UX, ビジネス上重要な棄損したくない指標 Debugging metrics 意図通りテストが進んでいるかを確認する指標 • 仮説によって設定するものが変わるので、 A/Bテストによって異なること が多い • 指標設計の大部分はここが占める
  14. 37 Experiment design doc - Metrics Details 三種類の指標を定義 Goal metrics

    改善を期待する指標 1 2 3 Guardrail metrics UX, ビジネス上重要な棄損したくない指標 Debugging metrics 意図通りテストが進んでいるかを確認する指標 • 監視的な役割が強くなるのでA/Bテスト共通で設定されることが多い。 • 棄損があった時にクリティカルなものを設定。(アクションが変わらないものは基 本的に設定しない)
  15. 38 Experiment design doc - Metrics Details 三種類の指標を定義 Goal metrics

    改善を期待する指標 1 2 3 Guardrail metrics UX, ビジネス上重要な棄損したくない指標 Debugging metrics 意図通りテストが進んでいるかを確認する指標 • 変更内容は適用されているか or どのくらいの認知を得ているのか確認できる 指標 • SRMを基本とした意図しないバイアス混入の確認
  16. 39 (補足) Other metrics 起こったことの理解を深めるための metrics • Guardrail metricsに置いていたトータルの購買数が下がったとする ◦

    主にどの経路からの購買が下がっているのか? ◦ 購買に至るまでのどの段階で棄損が起こっているのか?
  17. 40 (補足) Other metrics 起こったことの理解を深めるための metrics • Guardrail metricsに置いていたトータルの購買数が下がったとする ◦

    主にどの経路からの購買が下がっているのか? ◦ 購買に至るまでのどの段階で棄損が起こっているのか? Other metricsとして経路別の購買や購買ファネルの各段階における遷移 率などを設定することで結果の解釈性を高める
  18. 43 標準化されたフロー + 検証設計テンプレートの整備 • 検証設計テンプレート:A/Bテスト開始前に決めておくべきことを網羅 • 標準化されたフロー: ◦ 事前に評価設計をするフローの浸透

    ◦ 上記テンプレートのレビューを通じた検証の質の担保 EDDを事前に書くフローを浸透させることで後から過度に思考錯誤してしま うことを防止
  19. 44 標準化されたフロー + 検証設計テンプレートの整備 • 検証設計テンプレート:A/Bテスト開始前に決めておくべきことを網羅 • 標準化されたフロー: ◦ 事前に評価設計をするフローの浸透

    ◦ 上記テンプレートのレビューを通じた検証の質の担保 レビューを取り入れることで、A/Bテストに慣れていないメンバーでも一定の 質を保った検証を可能に
  20. 47 取り組みを広げるアプローチ 一般に大きく2種類のアプローチが考えられる。 Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros: 強制力を働かせるため浸透速度が早い

    • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れるので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
  21. 48 取り組みを広げるアプローチ 私たちは Bottom up なアプローチを採用 Top down - ルールとして決めてしまい、強制的に浸透させる。

    • Pros: 強制力を働かせるため浸透速度が早い • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れるので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
  22. 49 取り組みを広げるアプローチ いきなりTop downで進めてしまうリスクを重く見た。 Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros:

    強制力を働かせるため浸透速度が早い • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れるので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
  23. 50 取り組みを広げるアプローチ Bottom upであれば改善を重ねつつ取り組みを広げることができる。 Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros:

    強制力を働かせるため浸透速度が早い • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れる ので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
  24. 51 取り組みを広げるアプローチ どこから取り組みを広げるのか? Top down - ルールとして決めてしまい、強制的に浸透させる。 • Pros: 強制力を働かせるため浸透速度が早い

    • Cons: 不十分な状態だと形骸化、最悪コストだけが増える結果になるリスクも Bottom up - 小さな範囲から徐々に広げていく • Pros: イテレーションを重ねながら浸透を図れるので長期的な定着の可能性が高い • Cons: 浸透速度が遅い
  25. 52 [再掲] メルカリの分析チーム(JP Analytics) Growth Analytics Product Analytics Analytics Infra

    Product の改善施策の意思決定を主導する (施策の成功指標設計、実験の設計・評価、カスタマーインサイトの導出) 事業戦略の意思決定を主導する (マーケティング予算等グループ全体の成長戦略への提言、グロース施策への提言 ) 分析環境・ノウハウの整備によりデータの民主化を進める (KPIの標準化、分析基盤の整備、実験設計の標準化) 初手として、Product Analytics を中心に浸透を図る
  26. 53 Product Analyticsの選定理由 最も対象ユーザー層に近い • PdMと二人三脚で仮説構築、検証を行う • 職務上A/Bテストの設計、評価に関わる機会が圧倒的に多い 組織的な距離が近い •

    定期的にサブチームをまたぐSyncを行っており、互いにやっていることが把握しやすい • フィードバックが受けやすい 二つのポイント
  27. 54 Product Analyticsの選定理由 最も対象ユーザー層に近い • PdMと二人三脚で仮説構築、検証を行う • 職務上A/Bテストの設計、評価に関わる機会が圧倒的に多い 組織的な距離が近い •

    定期的にサブチームをまたぐSyncを行っており、互いにやっていることが把握しやすい • フィードバックが受けやすい フィードバックが受けやすい = Bottom upな進め方の利点を活かしやすい
  28. 57 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか? ◦ 検証の質が上がった ◦ 検証の質は変わらないがコミュニケーションがスムーズになった •

    EDDを書く中で最も工数のかかったポイントはどこか? or さらなる改善ポイン ト 使用者は比較的少数だったので 1on1でのインタビューを実施
  29. 58 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか? ◦ 検証の質が上がった ◦ 検証の質は変わらないがコミュニケーションがスムーズになった •

    EDDを書く中で最も工数のかかったポイントはどこか? or さらなる改善ポイン ト 使用者は比較的少数だったので 1on1でのインタビューを実施 施策の方向性としてはズレていないこと、想定していなかったものではありつ つも便益を提供できていることの確認
  30. 59 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか? • EDDを書く中で最も工数のかかったポイントはどこか? or さらなる改善ポイン ト

    ◦ 想定よりも、EDDのコストに対するネガティブな意見は少なかった ◦ それよりも、各指標をどのように評価するのが基本的なのかや設計時の検 討項目を知りたいと言う声が多かった 使用者は比較的少数だったので 1on1でのインタビューを実施
  31. 60 初期verリリース後、各使用者にインタビューを実施 主な質問 • EDDの導入で効果検証の質は上がったか? • EDDを書く中で最も工数のかかったポイントはどこか? or さらなる改善ポイン ト

    ◦ 想定よりも、EDDのコストに対するネガティブな意見は少なかった ◦ それよりも、各指標をどのように評価するのが基本的なのかや設計時の検 討項目を知りたいと言う声が多かった 使用者は比較的少数だったので 1on1でのインタビューを実施 Template自体の改善と言うよりもReferenceへのニーズが高かった
  32. 62 FBを経ての改善:Referenceの拡充 • EDDの各項目に関する説明 • Reviewの際のチェックリスト • Best Practices ◦

    Goal, Guardrail, Debuggingの指標をどのように評価するのか ◦ Power analysisの方法 ◦ … • Anti patterns ◦ この発表の冒頭で述べたようなPitfallを実例を交えて解説 元々から存在
  33. 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章 実験のプラットフォームと文化
  34. 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章 実験のプラットフォームと文化
  35. 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章 実験のプラットフォームと文化
  36. 68 分析の半自動化は今後必ず必要になる • 各Analystが十分に知識を付けたとしても人手でやる限りは必ずどこかでミスは起こる。リ ソースの制約も実際問題として存在。 • EDDは単体では Institutional memory の蓄積に向かない

    ◦ Institutional memory: 過去に実行されたA/Bテスト結果やリリース判断など ▪ 組織としての学びの蓄積 ▪ 新メンバーのオンボーディング ◦ EDDは背景や実験設計を理解するのには役立つが 結果の集積という観点だと弱い 『A/Bテスト実践ガイド』第 8章 インスティテューショナルメモリとメタアナリシス
  37. 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アプリが構築できるライブラリ
  38. 71 まとめ A/Bテストワークフローの改善 • Experiment design doc (EDD) ◦ Goal

    metrics ◦ Guardrail metrics ◦ Debugging metrics • Bottom up型で展開 ◦ フィードバックを通じて価値検証と改善を行いつつ展開 • 今後の課題としては分析の自動化があげられる