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テストの分析までをカバーしたプラットフォームをそれぞれ開発、保有している。
● 企業によって搭載されている機能も異なる
○ 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アプリが構築できるライブラリ
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.