$30 off During Our Annual Pro Sale. View Details »

メルカリにおける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. 1
    メルカリにおけるA/Bテストワークフローの改善、これま
    でとこれから
    柳沼 慎哉(@yaginuuun)
    2022/1/14, PyData.Tokyo Meetup #25

    View Slide

  2. 2
    Introduction

    View Slide

  3. 3
    自己紹介
    ● Data Analyst @ mercari (2020~)
    ○ Personalization施策の分析支援
    ○ A/Bテスト周りのワークフロー改善
    ● 最近の趣味:
    ○ トレカ収集 @ mercari
    ○ Podcast配信
    柳沼 慎哉
    Twitter: @yaginuuun

    View Slide

  4. 4
    メルカリについて
    国内最大のC2Cマーケットプレイスを運営

    View Slide

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

    View Slide

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

    View Slide

  7. 7
    今日話す内容
    メルカリにおけるA/Bテスト周りのワークフロー改善を中心に話します。
    過去のイベントでは話していなかった、取り組みをどのように広げたかという点にも触れます。
    ● メルカリで用いられているA/Bテスト設計テンプレート
    ● どのように取り組みを広げていったか

    View Slide

  8. 8
    Background

    View Slide

  9. 9
    A/Bテスト(Randomized Controlled Trial)
    ● 世界中で使われている効果検証のゴールドスタンダード
    ● メルカリでもほとんどの変更がA/Bテストによって評価されている。
    Control group
    Treatment group

    View Slide

  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章 実験のプラットフォームと文化

    View Slide

  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章 実験のプラットフォームと文化

    View Slide

  12. 12
    存在していた課題
    A/Bテストは施策効果検証のスタンダードとして実用されていたものの、ワークフローや設計時の検討事項に
    対する課題は小さくなかった。
    ● A/Bテストに必要な考慮事項に対する理解度のばらつき
    ● ワークフローのばらつき

    View Slide

  13. 13
    存在していた課題
    A/Bテストは施策効果検証のスタンダードとして実用されていたものの、ワークフローや設計時の検討事項に
    対する課題は小さくなかった。
    ● A/Bテストに必要な考慮事項に対する理解度のばらつき
    ● ワークフローのばらつき
    効果検証の質に課題

    View Slide

  14. 14
    効果検証の質が低いと起こること
    結果が信頼できなくなってしまう。
    改善しているように見えていても改悪している。またはその逆のパターンもあり得る。
    こっちに進んでいると思っている

    View Slide

  15. 15
    効果検証の質が低いと起こること
    実際にはこっちに進んでいる
    結果が信頼できなくなってしまう。
    改善しているように見えていても改悪している。またはその逆のパターンもあり得る。

    View Slide

  16. 16
    突然のクイズ
    以下のA/Bテスト評価設計に問題はあるでしょうか?
    ● 状況:アプリpush通知の改善
    ● 変更:通知メッセージで訴求する内容を変更(ゴールは同じとする)
    ● 割り当て:user_id, controlとtreatmentに均等に割り当てる
    ● 評価指標:push通知を開いた人のうちCVする人の割合(CVR)
    ○ [CVしたUU] / [Push開封UU]
    ● 検定:母比率の差の検定
    1
    Push送信 Push開封
    2
    CV
    N

    View Slide

  17. 17
    答え:問題がある

    View Slide

  18. 18
    代表的な考慮事項例:Sample Ratio Mismatch (SRM)
    『A/Bテスト実践ガイド』第
    21章 サンプル比率のミスマッチと信用性に関連するガードレールメトリクス
    ● 指標の分母となる数値が variant 間で割り当て比率からズレる現象
    ● 意図せぬバイアスを含んでいることの兆候
    ● 適合度のカイ二乗検定などでチェックする
    ● A/Bテストの様々な段階で発生することが報告されている
    ○ Assignment
    ○ Execution
    ○ Analysis
    ○ …
    ● 今回のケースではこれが発生する可能性が高い

    View Slide

  19. 19
    どういうことか?

    View Slide

  20. 20
    代表的な考慮事項例:Sample Ratio Mismatch (SRM)
    Push文言の変更によって、 CV数と同時にPush開封数も変化する可能性が高い
    下図ではどちらも増えた場合を仮定
    Control
    Treatment
    CV Push Open
    CVは増加 Push openはさらに増加

    View Slide

  21. 21
    代表的な考慮事項例:Sample Ratio Mismatch (SRM)
    Push文言の変更によって、 CV数と同時にPush開封数も変化する可能性が高い
    下図ではどちらも増えた場合を仮定
    Control
    Treatment
    CV Push Open
    CVは増加 Push openはさらに増加
    評価指標の分母となる数値がvariant間で大きく異
    なる = SRMの発生

    View Slide

  22. 22
    代表的な考慮事項例:Sample Ratio Mismatch (SRM)
    そのまま評価を行うと、実際は Push開封の増加に伴いCVも増加しているにもかかわらず指標は悪化して
    見える。
    Control
    Treatment
    (Scaled)
    CV Push open
    CVRは下がって見える!

    View Slide

  23. 23
    [再掲]突然のクイズ
    以下のA/Bテスト評価設計に問題はあるでしょうか?
    ● 状況:アプリpush通知の改善
    ● 変更:通知メッセージで訴求する内容を変更(ゴールは同じとする)
    ● 割り当て:user_id, controlとtreatmentに均等に割り当てる
    ● 評価指標:push通知を開いた人のうちCVする人の割合(CVR)
    ○ [CVしたUU] / [Push開封UU]
    ● 検定:母比率の差の検定
    1
    Push送信 Push開封
    2
    CV
    N

    View Slide

  24. 24
    [再掲]突然のクイズ
    以下のA/Bテスト評価設計に問題はあるでしょうか?
    ● 状況:アプリpush通知の改善
    ● 変更:通知メッセージで訴求する内容を変更(ゴールは同じとする)
    ● 割り当て:user_id, controlとtreatmentに均等に割り当てる
    ● 評価指標:push通知を開いた人のうちCVする人の割合(CVR)
    ○ [CVしたUU] / [Push送信UU]
    ● 検定:母比率の差の検定
    1
    Push送信 Push開封
    2
    CV
    N

    View Slide

  25. 25
    他にも考慮すべき事項は様々...
    ここで取り上げたSRMは一例。他にも様々な検討事項が存在。
    ● 多重比較
    ● Power Analysis(サンプルサイズ設計)
    ● randomization unit != Analysis unit
    ● Cherry picking
    ● 評価指標のSensitivity
    ● …

    View Slide

  26. 26
    他にも考慮すべき事項は様々...
    ここで取り上げたSRMは一例。他にも様々な検討事項が存在。
    ● 多重比較
    ● Power Analysis(サンプルサイズ設計)
    ● randomization unit != Analysis unit
    ● Cherry picking
    ● 評価指標のSensitivity
    ● …
    ではどうするか?

    View Slide

  27. 27
    私たちの取り組み
    Experiment design docを用いたA/Bテスト設計フロー整備

    View Slide

  28. 28
    標準化されたフロー + 検証設計テンプレートの整備
    ● 検証設計テンプレート:A/Bテスト開始前に決めておくべきことを網羅
    ● 標準化されたフロー:
    ○ 事前に評価設計をするフローの浸透
    ○ 上記テンプレートのレビューを通じた検証の質の担保

    View Slide

  29. 29
    標準化されたフロー + 検証設計テンプレートの整備
    ● 検証設計テンプレート:A/Bテスト開始前に決めておくべきことを網羅
    ● 標準化されたフロー:
    ○ 事前に評価設計をするフローの浸透
    ○ 上記テンプレートのレビューを通じた検証の質の担保

    View Slide

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

    View Slide

  31. 31
    Contents:
    ● Background
    ● Test settings
    ● Metrics details
    ● How to evaluate metrics
    ● Action plan

    Experiment design doc (EDD)
    背景や実験設定

    View Slide

  32. 32
    Contents:
    ● Background
    ● Test settings
    ● Metrics details
    ● How to evaluate metrics
    ● Action plan

    Experiment design doc (EDD)
    評価指標、評価方法

    View Slide

  33. 33
    Contents:
    ● Background
    ● Test settings
    ● Metrics details
    ● How to evaluate metrics
    ● Action plan

    Experiment design doc (EDD)
    A/Bテスト終了後のNext Action(各指標の動きに応じていくつか)

    View Slide

  34. 34
    Contents:
    ● Background
    ● Test settings
    ● Metrics details
    ● How to evaluate metrics
    ● Action plan

    Experiment design doc (EDD)
    最もコアなMetrics detailsについてもう少しだけ解説します。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  38. 38
    Experiment design doc - Metrics Details
    三種類の指標を定義
    Goal metrics
    改善を期待する指標
    1
    2
    3
    Guardrail metrics
    UX, ビジネス上重要な棄損したくない指標
    Debugging metrics
    意図通りテストが進んでいるかを確認する指標
    ● 変更内容は適用されているか or どのくらいの認知を得ているのか確認できる
    指標
    ● SRMを基本とした意図しないバイアス混入の確認

    View Slide

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

    View Slide

  40. 40
    (補足) Other metrics
    起こったことの理解を深めるための metrics
    ● Guardrail metricsに置いていたトータルの購買数が下がったとする
    ○ 主にどの経路からの購買が下がっているのか?
    ○ 購買に至るまでのどの段階で棄損が起こっているのか?
    Other metricsとして経路別の購買や購買ファネルの各段階における遷移
    率などを設定することで結果の解釈性を高める

    View Slide

  41. 41
    EDDの詳細が気になる方はこちらの資料もご覧ください
    https://speakerdeck.com/shyaginuma/btesutobiao-zhun-hua-hefalsequ-rizu-mi

    View Slide

  42. 42
    標準化されたフロー + 検証設計テンプレートの整備
    ● 検証設計テンプレート:A/Bテスト開始前に決めておくべきことを網羅
    ● 標準化されたフロー:
    ○ 事前に評価設計をするフローの浸透
    ○ 上記テンプレートのレビューを通じた検証の質の担保

    View Slide

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

    View Slide

  44. 44
    標準化されたフロー + 検証設計テンプレートの整備
    ● 検証設計テンプレート:A/Bテスト開始前に決めておくべきことを網羅
    ● 標準化されたフロー:
    ○ 事前に評価設計をするフローの浸透
    ○ 上記テンプレートのレビューを通じた検証の質の担保
    レビューを取り入れることで、A/Bテストに慣れていないメンバーでも一定の
    質を保った検証を可能に

    View Slide

  45. 45
    ワークフロー(Data Analystの場合)
    最初数回はAnalystのreviewを受けることを推奨。徐々に内部で完結へ。
    Analyst
    PdM
    Project A
    Analyst
    実験設計を詰める review依頼
    Analyst
    PdM
    Project A
    実験設計を詰める
    ここで完結

    View Slide

  46. 46
    取り組みを広げるアプローチ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  52. 52
    [再掲] メルカリの分析チーム(JP Analytics)
    Growth
    Analytics
    Product
    Analytics
    Analytics
    Infra
    Product の改善施策の意思決定を主導する
    (施策の成功指標設計、実験の設計・評価、カスタマーインサイトの導出)
    事業戦略の意思決定を主導する
    (マーケティング予算等グループ全体の成長戦略への提言、グロース施策への提言 )
    分析環境・ノウハウの整備によりデータの民主化を進める
    (KPIの標準化、分析基盤の整備、実験設計の標準化)
    初手として、Product Analytics を中心に浸透を図る

    View Slide

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

    View Slide

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

    View Slide

  55. 55
    本取り組みにおいてフィードバックをもらうことの意義
    意図した目的を達成できているのかの確認
    ● そもそも施策として適切なのかどうかの確認
    ● 目的達成に不十分な箇所の把握
    コストと便益のバランス改善
    ● 新しいdocumentを書くことは基本的にコスト
    ● 現状でコストと便益のバランスがどうなっているのかの把握
    ● さらにコストを下げることや便益を増やすことができないのかの検討

    View Slide

  56. 56
    初期verリリース後、各使用者にインタビューを実施
    主な質問
    ● EDDの導入で効果検証の質は上がったか?
    ● EDDを書く中で最も工数のかかったポイントはどこか? or さらなる改善ポイン

    使用者は比較的少数だったので 1on1でのインタビューを実施

    View Slide

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

    使用者は比較的少数だったので 1on1でのインタビューを実施

    View Slide

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

    使用者は比較的少数だったので 1on1でのインタビューを実施
    施策の方向性としてはズレていないこと、想定していなかったものではありつ
    つも便益を提供できていることの確認

    View Slide

  59. 59
    初期verリリース後、各使用者にインタビューを実施
    主な質問
    ● EDDの導入で効果検証の質は上がったか?
    ● EDDを書く中で最も工数のかかったポイントはどこか? or さらなる改善ポイン

    ○ 想定よりも、EDDのコストに対するネガティブな意見は少なかった
    ○ それよりも、各指標をどのように評価するのが基本的なのかや設計時の検
    討項目を知りたいと言う声が多かった
    使用者は比較的少数だったので 1on1でのインタビューを実施

    View Slide

  60. 60
    初期verリリース後、各使用者にインタビューを実施
    主な質問
    ● EDDの導入で効果検証の質は上がったか?
    ● EDDを書く中で最も工数のかかったポイントはどこか? or さらなる改善ポイン

    ○ 想定よりも、EDDのコストに対するネガティブな意見は少なかった
    ○ それよりも、各指標をどのように評価するのが基本的なのかや設計時の検
    討項目を知りたいと言う声が多かった
    使用者は比較的少数だったので 1on1でのインタビューを実施
    Template自体の改善と言うよりもReferenceへのニーズが高かった

    View Slide

  61. 61
    FBを経ての改善:Referenceの拡充
    ● EDDの各項目に関する説明
    ● Reviewの際のチェックリスト
    元々から存在

    View Slide

  62. 62
    FBを経ての改善:Referenceの拡充
    ● EDDの各項目に関する説明
    ● Reviewの際のチェックリスト
    ● Best Practices
    ○ Goal, Guardrail, Debuggingの指標をどのように評価するのか
    ○ Power analysisの方法
    ○ …
    ● Anti patterns
    ○ この発表の冒頭で述べたようなPitfallを実例を交えて解説
    元々から存在

    View Slide

  63. 63
    取り組みの現在地
    ● プロダクト開発組織を中心に利用が拡大中
    ● Data Analystを中心として様々な職種の方に活用していただいている
    ○ Data Analyst
    ○ SWE
    ○ PdM

    View Slide

  64. 64
    これからの課題

    View Slide

  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章 実験のプラットフォームと文化

    View Slide

  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章 実験のプラットフォームと文化

    View Slide

  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章 実験のプラットフォームと文化

    View Slide

  68. 68
    分析の半自動化は今後必ず必要になる
    ● 各Analystが十分に知識を付けたとしても人手でやる限りは必ずどこかでミスは起こる。リ
    ソースの制約も実際問題として存在。
    ● EDDは単体では Institutional memory の蓄積に向かない
    ○ Institutional memory: 過去に実行されたA/Bテスト結果やリリース判断など
    ■ 組織としての学びの蓄積
    ■ 新メンバーのオンボーディング
    ○ EDDは背景や実験設計を理解するのには役立つが
    結果の集積という観点だと弱い
    『A/Bテスト実践ガイド』第
    8章 インスティテューショナルメモリとメタアナリシス

    View Slide

  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アプリが構築できるライブラリ

    View Slide

  70. 70
    まとめ

    View Slide

  71. 71
    まとめ
    A/Bテストワークフローの改善
    ● Experiment design doc (EDD)
    ○ Goal metrics
    ○ Guardrail metrics
    ○ Debugging metrics
    ● Bottom up型で展開
    ○ フィードバックを通じて価値検証と改善を行いつつ展開
    ● 今後の課題としては分析の自動化があげられる

    View Slide

  72. 72
    End.

    View Slide