Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
いまさら聞けない ABテスト入門
Search
木村彩恵(skmr2348)
October 01, 2025
Technology
0
120
いまさら聞けない ABテスト入門
DeNA+GO AI関連勉強会の発表資料を一部編集したものになります。
ABテストの手順や実施するにあたって個人的に気をつけたいと感じているポイントをまとめました。
木村彩恵(skmr2348)
October 01, 2025
Tweet
Share
More Decks by 木村彩恵(skmr2348)
See All by 木村彩恵(skmr2348)
ダイナミックプライシング とその実例
skmr2348
3
770
Other Decks in Technology
See All in Technology
「技術負債にならない・間違えない」 権限管理の設計と実装
naro143
30
9k
Goを使ってTDDを体験しよう!
chiroruxx
1
200
Goのビルドシステムの変遷 / The history of Go's build system
ymotongpoo
12
3.3k
AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ?
kinosuke01
4
3.5k
High performance GIF playback/iOSDC25
noppefoxwolf
1
190
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
170
Why React!?? Next.jsそしてReactを改めてイチから選ぶ
ypresto
8
3k
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
9k
日経が挑戦するデータ民主化 ~ セルフサービス基盤がもたらす利点と苦悩~/nikkei-tech-talk-37
nikkei_engineer_recruiting
0
210
2重リクエスト完全攻略HANDBOOK / Double Request Handbook
shoheimitani
5
6.7k
そのグラフに「魂」は宿っているか? ~生成AI全盛期におけるデータ可視化手法とライブラリ比較~
negi111111
2
780
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
joker1007
19
8.5k
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.7k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
600
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Into the Great Unknown - MozCon
thekraken
40
2.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Agile that works and the tools we love
rasmusluckow
330
21k
Why Our Code Smells
bkeepers
PRO
339
57k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.6k
Transcript
AI 2025.07.17 GO株式会社 木村 彩恵 いまさら聞けない ABテスト入門
AI 2 ▪ 主に以下の3つ ▪ ログ分析 ▪ コストがかからない ▪ 未知のシナリオでの施策評価が難しい
▪ シミュレーション ▪ 未知のシナリオでも施策の効果を検証できる ▪ モデルの精度が悪いと、結果が信頼できない ▪ ABテスト ▪ 施策効果を実際に計測できる ▪ コストがかかる 業務でよく使う施策の評価方法
AI 3 ▪ ABテストは施策の効果を直接計測できて非常に強力! ▪ 過去に実施したABテストを振り返ると・・・ ▪ 判断できなかったケース ▪ 判断が誤っていたケース
▪ やり直したケース 本日の発表の動機 適切なABテストの やり方を知って、 正しい意思決定が できるようになりたい
AI 4 ▪ A/Bテスト実践ガイド ▪ pythonで学ぶ効果検証入門 ▪ Lyftブログ ▪ https://eng.lyft.com/challenges-in
-experimentation-be9ab98a7ef4 ▪ ChatGPTによる調査 今回の発表の参考文献
AI 5 ▪ ターゲットをランダムに複数のグループに分けて、グループ間でKPIを比較す ることで施策に効果があるかどうかを判断する方法 ▪ 現状のグループをControl群、施策を適用したグループをTreatment群と 呼ぶ ▪ 施策に効果があるかどうかは統計検定で「Control群とTreatment群の
KPIに有意な差がない」という帰無仮説を棄却できるかどうかで判断する ▪ p値(ControlとTreatmentが同じ母集団の場合に、偶然差が出る 確率)が有意水準以下、or ▪ ControlとTreatmentの差の信頼区間が0をまたがない そもそもABテストとは?
AI 6 ▪ ABテストは主に以下の手順に沿って実施される ▪ Step1. KPI設計 ▪ Step2. テスト設計
▪ Step3. テスト実装・実施 ▪ Step4. データ収集・モニタリング ▪ Step5. 分析 ABテストの手順 各手順の内容や気を付けるべきポイントを共有します
AI 7 ▪ やること ▪ 解決したい課題と課題を解決する仮説を明確化 ▪ 仮説を裏付けるKPIを設計する ▪ 課題:ECサイトにおいてCVR(=全セッションのうち、購入完了
セッションの割合)が低く、売り上げが伸び悩んでいる ▪ 仮説:購入ボタンを大きくするとCVRが上がるはず →KPI:CVR・決済ページ到達率などを計測する ▪ 気を付けること ▪ 施策の副作用も可能な限り考慮しKPIを設計する ▪ 購入ボタンを大きくすることでCVRは改善したが、購入後キャンセ ル率も上がってしまった →キャンセル率もKPIでケアすべきだった Step1. KPI設計
AI 8 ▪ ゴールメトリクス ▪ 施策が成功したかどうかを判定するメトリクス ▪ 前ページの例では:CVR ▪ ドライバーメトリクス
▪ ゴールに影響を主要な行動をモニタリングするメトリクス ▪ 前ページの例では:カート到達率、決済ページ到達率 ▪ ガードレールメトリクス ▪ 副作用を監視するメトリクス ▪ 前ページの例では:購入後キャンセル率 KPIの分類
AI 9 ▪ やること ▪ テストに関わる項目を決定する ▪ ランダム化単位(割り付け方法) ▪ テスト期間
▪ 分析時の検定手法 ▪ オフラインAAにより品質をチェックする ▪ 気を付けること ▪ ランダム化単位は互いに干渉を受けないか ▪ テスト期間は十分か Step.2 テスト設計
AI 10 ▪ 基本的には、施策がどの単位で影響を受けるかによって決める ▪ KPIが定義されている単位を採用する ▪ 干渉が起こる場合は、KPIの単位よりも大きい単位とする場合もある ▪ Step1のECサイトの場合、KPIがCVRであるため、セッション単位とするのが
自然 ▪ ただし、同一ユーザーが複数の群にまたがるのが問題となる施策であれ ばユーザー単位としたほうが良い ▪ サイトの見た目が変わるような施策の場合、Treatment群を一度経 験した後にControl群とすると影響が出るかもしれない ランダム化単位の考え方(基本)
AI 11 ▪ セッションやユーザー単位で干渉が起きる場合は、時間単位や地域単位とす ることも考える ▪ 例えば、モバイルオーダーのようなマッチング問題の場合、 ユーザー単位でマッチングを変えると、他のペアにも影響を及ぼす ランダム化単位の考え方(ユーザー単位で干渉する場合) Control
Control Treatment Control Treatmentのアルゴリズムを変えるとControlにも影響が出る例 時間かかる ならキャン セル
AI 12 ▪ 一方で時間単位とした場合、以下のような問題が起きる ▪ 外部要因(時間・曜日・天候やイベント)の影響を受けやすい ▪ ControlとTreatmentで同じ時間帯を同じ回数実施する ▪ 1日目の10:00-10:30はControl、2日目の10:00-10:30は
Treatment ▪ 共変量コントロール等で外部要因の影響を排除する(後述) ▪ 切り替わった瞬間にKPIの急変動が起きる ▪ 切り替え後の一定期間(ウォッシュアウト期間)のデータを破棄 ランダム化単位の考え方(時間単位の問題点) 10:00- Control 10:30- Treatment 11:00- Control 11:30- Treatment 10:00- Treatment 10:30- Control 11:00- Treatment 11:30- Control 1日目 2日目
AI 13 ▪ サンプルサイズは、有意水準と検出力が一定の水準を満たすように設計する ▪ 有意水準α:ControlとTreatmentが差がない場合に、偶然差があると判 定される確率(0.05以下) ▪ 検出力1-β:ControlとTreatmentに差がある場合に正しく差があると判 定される確率(0.8以上)
テスト期間の考え方(有意水準と検出力) 検定の結果 差がある 差がない Controlと Treatmentの 真の分布 差がある 1-β: 検出力 β: 第二種の過誤 差がない α:第一種の過誤 (=有意水準) 1-α
AI 14 ▪ サンプルサイズは有意水準αと検出力1-βに加え、効果量(検出したい差)も 影響する ▪ 正規分布に従う場合のサンプルサイズ ▪ 効果量が小さいほど、必要となるサンプルも増える テスト期間の考え方(サンプルサイズ定式化)
効果量小 検出力 有意水準 効果量大
AI 15 ▪ 効果量の定義はサンプルサイズを計算する対象のKPIによって変わる ▪ 比率の差(例えばCVR):Cohen’s h ▪ Control群の比率 pC
とTreatment群の比率 pT の効果量h ▪ 連続値の差(例えば単価):Cohen’s d ▪ Control群の平均 μC とTreatment群の平均 μT の効果量d テスト期間導出例(効果量の定式化)
AI 16 ▪ cohen’s hはstatsmodelsの 関数で計算可能 テスト期間導出例(python実装例)
AI 17 ▪ 過去のログを用いて、以下の手順の繰り返しにより計算したp値の分布が一様 かどうかを確認する ▪ ABテストと同じロジックでランダム化 ▪ KPIを集計、統計検定によりp値を計算 テスト設計の品質チェック(オフラインAAテスト)
ControlとTreatmentで同じ 分布の場合 ControlとTreatmentで異な る分布の場合
AI 18 ▪ p値が一様になっていない場合、以下の点で問題がないかをチェックする ▪ 割り付け ▪ 同じユーザーがControlとTreatment両方に入っていないか ▪ セグメント
▪ KPIに相関がありそうな属性(新規/既存や性別、年齢別)で偏りが ないか ▪ 分析 ▪ クエリのミスがないか オフラインAAで問題が見つかった場合の対応
AI 19 ▪ やること ▪ テスト実装 ▪ 気を付けること ▪ 施策以外の部分に差がでないかを確認する
▪ 例えばECサイト上で実施するABの場合、ページ表示速度など ▪ オンラインAAを実施するのも有効 ▪ 深夜や週末に発火するABは避ける ▪ 不測の事態に対応できるように、対応しやすい時間でまずは開始 Step3. テスト実装
AI 20 ▪ やること ▪ KPIのモニタリング ▪ 外部要因に注意する(ECサイトの場合、セールがあった等) ▪ 気を付けること
▪ 途中解析をすると多重検定の問題が発生する ▪ 多重検定の問題:第一種の過誤の発生確率が高まる ▪ どうしても途中解析したい場合は以下のような方法がある ▪ α spending(後述) ▪ ベイジアンAB ▪ ABテストの結果を確率分布として推定する Step4. データ収集、モニタリング
AI 21 ▪ 途中解析することを前提に、解析時に使用するαを定める方法 ▪ 分析するタイミングを決める(例えば、25%, 50%, 75%, 100%のデー タを取得したタイミング)
▪ 各タイミングで使用するαを決定する ▪ Pocock型:均等割する(α/4 = 1.25%) ▪ O’Brien-Fleming型:最初は保守的に、最後は緩和する方法 ▪ 各タイミングで検定する ▪ p値<αとなったら帰無仮説を棄却してデータ収集を終了する α spending
AI 22 ▪ やること ▪ 帰無仮説が棄却できるかどうかを統計検定により判定する ▪ 気を付けること ▪ KPIが正規分布かどうかを意識する
▪ 分布の可視化 ▪ 正規性検定 ▪ Q-Qプロット Step5. 分析
AI 23 ▪ データの分布が正規分布ではないor外れ値がある場合に、T検定やZ検定を 用いると検出力が下がってしまい、母集団に差がある場合であっても見過ご されてしまうことがある ▪ ヒストグラム等で分布をみるのが重要 データの分布の可視化 例えば単価データは右図のような
対数正規分布となることが多い グラフでは明らかに分布が異なるが、 T検定では以下のように有意差なしと の結果になる • p値: 0.2429 • 平均差: 283.71 • 95%信頼区間: ◦ [-195.83, 763.2731]
AI 24 ▪ ヒストグラムで可視化する以外にも、正規性検定やQ-Qプロットなどにより 正規分布かどうか判断できる ▪ 正規性の検定(Shapiro-Wilk検定) ▪ Control、Treatmentそれぞれで検定、p値が有意水準以下の場合は 正規性を棄却
▪ 前述の例の場合はControl、Treatmentいずれもp値=0となった 正規性の確認(Shapiro-Wilk検定)
AI 25 ▪ ヒストグラムで可視化する以外にも、正規性検定やQ-Qプロットなどにより 正規分布かどうか判断できる ▪ Q-Qプロット ▪ X軸に理論分布の分位点、Y軸に実データの分位点をプロット ▪
正規分布でない場合に直線にならない 正規性の確認(Q-Qプロット)
AI 26 ▪ ブートストラップCI ▪ データを何度も抽出して統計 分布を作ることで、信頼区間 を推定する方法 ▪ 先の単価データの場合、信頼
区間が[51.6350, 524.4042] となり有意差ありと判定 正規分布でない場合の対処法(ブートストラップCI)
AI 27 ▪ 検定する場合も2つのアプローチがある ▪ WelchのT検定(Z検定) ▪ 分散が異なっていてもよい ▪ 回帰分析(OLS)を使う方法
▪ ControlとTreatmentで分散が異なる場合、係数のp値や信頼区間が 不正確になる可能性がある ▪ 頑健SEで等分散性の緩和可能 ▪ 共変量コントロールなどにより、外部要因の除去がしやすい 検定のアプローチ
AI 28 ▪ 以下のようにControlとTreatmentで分散が異なるケースを考える ▪ Control:クリック率20%、サンプル数50 ▪ Treatment:クリック率30%、サンプル数200 ▪ 各手法で求めたCIは以下の通り。
▪ 頑健SEの方が信頼区間がZ検定やブートストラップCIと近い 頑健SEによる等分散性の緩和 Lower CI Upper CI Welch Z検定 0.039 0.28 ブートストラップCI 0.035 0.275 OLS(標準SE) 0.02 0.30 OLS(頑健SE) 0.039 0.281 HC1を指定すると頑健SE
AI 29 ▪ 共変量コントロール ▪ KPIに影響を与える既知の要因がある場合、モデルに含める ▪ 例えばクリック率が過去のクリック傾向に依存する場合 外部要因の除去(共変量コントロール) 共変量あり
共変量なし
AI 30 ▪ DID(差分の差分法) ▪ Control群とTreatment群で施策前後の差を比較することで施策の効果 を推定する方法 ▪ 平行トレンド仮定が成り立つ必要がある ▪
平行トレンド仮定:施策以外の外部要因がControlとTreatmentで 共通である 外部要因の除去(DID) 時間経過による変化 施策による変化 施策前 施策後 Control Treatment
AI 31 ▪ 今回の発表ではABテストの手順や各手順で気を付けたいことをまとめました ▪ 実際に施策効果を測定可能である一方、設計や実施後の分析を適当にすると 結果が変わり、誤った結論につながります ▪ ABテストについてはまだまだ勉強中なので、役に立つTipsがあれば、 コメントでぜひ教えてください!
まとめ