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

Slide 1

Slide 1 text

1 メルカリにおけるA/Bテストワークフローの改善、これまでとこれから柳沼慎哉（@yaginuuun） 2022/1/14, PyData.Tokyo Meetup #25

Slide 2

Slide 2 text

2 Introduction

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

8 Background

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17 答え：問題がある

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

19 どういうことか？

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

34 Contents: ● Background ● Test settings ● Metrics details ● How to evaluate metrics ● Action plan  Experiment design doc (EDD) 最もコアなMetrics detailsについてもう少しだけ解説します。

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

64 これからの課題

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

69 分析の半自動化: Experimentation Platform 外資系企業を中心に A/Bテストの分析までをカバーしたプラットフォームをそれぞれ開発、保有している。 ● 企業によって搭載されている機能も異なる ○ Netﬂix: Reimagining Experimentation Analysis at Netﬂix ○ Airbnb: Scaling Airbnb’s Experimentation Platform ○ Uber: Under the Hood of Uber’s Experimentation Platform ● 簡易的にstreamlitによって作成したMVPを部分的にテスト導入するなど始まっている部分もある。 ○ streamlit: pythonで簡単にWebアプリが構築できるライブラリ

Slide 70

Slide 70 text

70 まとめ

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

72 End.