DSOps #5-2

DSOps  #5. A/B test Practice  1

前半と同様にkohavi本を参照します  2

Experimentation Maturity Models(再)  1. Crawl  a. goal: 基礎的かつ前提となるものを作る   b.
要約統計量を計算して検定とか   c. 小さな成功から次のステージにステップアップする  d. ~10 / years  2. Walk  a. goal: 指標の設計や組織の実験の活性化   b. 実験の信用性のアップ   i. A/A test  ii. Sample Ratio Mismatch (SRM) test   c. ~50 / year  3. Run  a. goal: 実験をスケールさせること  b. 複数の指標のトレードオフを考慮したOECの明文化  c. たくさんの施策の評価に実験を用いている  d. ~250 / year  4. Fly  a. すべての変化を実験で評価  b. 簡単なテストならDSなしでできる  c. 自動化  d. 実験から組織の知見を積み上げていく  e. thousands / year  3 組織が様々な意思決定を実験からデータドリブンにやるようになるまでの4フェーズ  

How do we get from Run to Fly?  • RunとFlyではそれぞれ求められるものや必要なものが変わってくる
  • 求められるもの  ◦ Run : DSチーム内での合意形成  ◦ Fly : 非DSを巻き込んだプロダクトメンバでの合意形成  • 必要なもの  ◦ Run  ▪ DSメンバ内でのA/Bテストの評価，実行を含めたルール形成   ◦ Fly  ▪ プロダクト(or 事業部)内でのA/Bテストの重要性の理解   ▪ 非DSが簡単にA/Bテストを実行，結果を理解できるような実験設定/評価機構の作成   ▪ 「組織の知見」をお金にするためのBizを巻き込んだ戦略策定   4

Dynalystでのとりくみ  • Dynalystでは2年前はRun, 1年前くらいからFlyに行きつつある過程   • この中で取り組んだ施策を紹介   ◦ Run 
▪ 複数指標の考慮, OECの明文化   ▪ 実験ワークフローの策定   ◦ Fly  ▪ クリエイティブ評価基盤プロジェクト   5

Run Phase  6

複数指標の考慮, OECの明文化  7

Single/Multiple Metric  • A/Bテストの結果を判断するのを一つの指標だけでやる場合  ◦ 例: ロジックA VS ロジックBでCTRがいい方を採用  •
しかしオンライン実験では大量の見るべき指標がある  ◦ 売上, CPA, CTR, 原価率, …  • これらをどう優先させるべきか?  ◦ 指標間のトレードオフ  ◦ 例: 3つの指標のうちロジックAが2つの指標で勝ったから採用...? 

指標間のtrade-off  • 例: 売上とCPA  ◦ 売上が上がるがその分CPAが大きく下がる  ◦ 組織によって許容するかどうかが違う  • OECはそれらの指標の重み付け平均とするのがよい 
◦ 複数指標のtradeoffを議論してチームのOECについてのリテラシ向上  ◦ 0 -1にnormalizeしてweightをつけてsumするのがおすすめ(本曰く)  ◦ または複数の指標を使って意思決定する  • 実験ごとに複数指標を考慮してたらスケールしないのでは?  ◦ 組織内での明確なルールの必要性 

合宿  • Dynalystでは配信ロジックに関するA/Bテストに関するMTGを5時間ぶっつづけでやった  ◦ 種々の議題を話し合った  ◦ そこで出た議題を紹介  10

問題1  • ビジネス指標からどうやって予測モデルの優劣を決めるのか?  ◦ 例えば「売上があがってCPAが下がりました」といったケース  ◦ 複数のビジネス指標が全て改善するというケースは稀  ◦ このモデルの適用率を上げるか否か?  •
ここの判断に毎回困るようでは，継続的にA/B testを走らせられない  11

Answer  • A. 結局はプロダクトのいる段階による  ◦ 基本は「CPA > Sales > 利益」の順で大事 
▪ CPAがよくなれば中長期的に売上は拡大する  ▪ 逆に，利益はこの利益を使って投資するわけではないので今は重要ではない  • 上の順序の判断は事業責任者から直接聞いたもの  • 最終的にはA/Bの目的による  ◦ 「このA/Bで何を改善したいのか?」  ◦ この狙いが上手く行っているかをチームとして判断していく  12

問題2  • CTR/CVR予測ではビジネス指標を元に適用率拡大の判断をしていた  • 本当にビジネス指標だけ見ていればいいのか?  ◦ 「このA/Bで何を改善したいのか?」という文脈  • 例 :
CTR予測の精度はオフライン/オンラインで上がっているのにビジネス指標が良くないケース  ◦ この場合はどう判断すべきか?  13

Answer  • CTR/CVR予測モデルなどは「精度指標もちゃんと見る」ことに決定  ◦ これは精度を上げることが目的なので  • 逆に入札戦略や予算ペーシングはビジネス指標を見る  • 精度が良くなる ≠
適用決定  ◦ プロダクトとして適切な方向に進むか? を判断する  ◦ 精度が良くなったけど売上下がった場合も判断  ◦ 例: 動画広告  • 導入したロジックが期待通りのポイントで精度改善しているかを確認  14

実験ワークフローの策定  15

適用率の上げ方  • 新機能ローンチのリスクと付き合うために徐々に適用範囲を増やしていく  ◦ Helthcare.gov はクラッシュが多発するような状態で一度に100%リリースをした  • 適用範囲の増やし方の原則を決め、それを自動化させることが必要  ◦ これが決まっていないと実験のスケールアップが可能にならない 
16

SQR Ramping Framework  • なぜ実験をしたいか? に立ち返る  1. 新機能の100%ローンチ時のKPIを測る  2. 実験時にコストやダメージなどを最小化しておいてリスクを抑える 
3. ユーザの反応を事前に把握したり潜在的なバグの特定のため  • SQR（speed, quality, and risk）のバランスを保った実験をしたい  ◦ もしKPIの計測だけでよければいきなり全体の50%のサンプルサイズをつかえばいい  ◦ 一方リスクがあるので小さく始めたい...   

適用率の上げ方    リスクに備えて小さく始める効果を計測するトラフィック量などスケールさせることによるリスクを和らげる長期的な効果をみる、介入を受けにくいユーザにも考慮

合宿の結果  • CTR予測モデルのSQR  ◦ 適用率でA/B testが食い合うとA/B testをスケーリングさせられない  ◦ とはいえ，急いで適用すると入札で暴発するリスクなどがある  •
予測モデルの適用拡大について厳密にルールを作成  ◦ 1% : ヘルスチェック(CTR: 1日 CVR: 2日)  ◦ 10% : 精度指標 and ビジネス指標の確認(~ 1 week)  ◦ 50% : 最終確認. 日毎にビジネス指標を見る(1day + 1w ~ 2w)  ◦ 100%: 完全適用  19

合宿の結果  • A/Bテストフローチャートを導入  • 厳密に書くことで，チームとしてA/Bをルールを持って推進していくことが可能に  20 実際のフローチャートは非公開

Fly Phase  21

クリエイティブ評価基盤  22

実験を加速させるためには? 23 • どうすれば実験回数を増やせるか? ◦ 実験開始や評価のコストを下げる(実験基盤作成. MLOps) ◦ 実験を開始，評価できる人を増やす(非DSへのeducation) •
上記2つを実践したクリエイティブ評価基盤プロジェクトについて紹介

実験プラットフォームの目的と役割  • Experiment platformの役割  ◦ 実験によるイノベーションの加速  ◦ 確実な意思決定の担保  • Experiment
platformのゴール  ◦ 実験の自動化  ◦ 実験コストを下げつつ確実な実験を遂行する  24

実験プラットフォームの要素  • 実験の定義，セットアップ，管理   • 実験のデプロイ  ◦ 実験対象のアサインなど   •
実験の記録  • 実験結果の分析  25

Experimentation Analytics  run, flyフェーズでは分析の自動化が必要  • チームがアドホックな分析に時間を使うのを避ける  • 分析の方法論を頑健かつ科学的に正しいようにする  26

Experimentation Analytics  • データの前処理  • データからの計算  ◦ OECをチェックする前にまずtrustworthiness checkを  •
可視化  ◦ key metricsやセグメントのハイライト  ◦ すべての実験の指標をモニタリングする  ◦ 何を実験したか + なぜその意思決定をしたか + 成功したか  27

施策前のDynalystのクリエイティブ評価 28 • クリエイティブ評価自体はやっていた ◦ クリエイティブの良し悪し自体は配信実績から判断 ◦ Slackでbotを叩けば評価できるようにした • しかし，以下のデメリットがあった
◦ 要素ごとの比較や実験ができていない ◦ 回している本数が多すぎてそこからの知見が上手く得られていない ◦ 配信量が少なく「確かな差がある」という結果がほぼ得られなかった

クリエイティブ評価の理想 29 • TiktokやGoogleの動画クリエイティブレポートから引用 • 何の要素が何のKPIに効くかを明確にレポートできている ◦ 別の広告クリエイティブにも横転可能

クリエイティブAB基盤プロジェクト 30 • Dynalystとしてクリエイティブの知見を溜めていくことを目指す ◦ クリエイティブチームが実験を自分たちで簡単に回せることを目指す • 要件は以下 ◦ 実験を簡単に,
正しく実行できる ◦ DSの助け無しで結果を解釈できる ◦ 上手くクリエイティブの知見を溜めていける

まず決めたこと 31 • まずビジネス，デザ，DSが集まって以下のことを決めた • 実験のKPIを何にするか? ◦ CTR, ClickCVR, CTVRの3つをまずは見ていく
• 仮説をどのように立案するか? ◦ クリエイティブの上手な仮説はデザが，お金になる知見はBizが持っている ◦ ビジネス，デザ，DSの3者でQごとに決めていく • 溜めた知見をどのようにお金にするか? ◦ ひとまずはDynalystのクリエイティブの質を上げていく ◦ Dynalystのクリエイティブ制作で金を取れるようにする or 代理店に知見を横転して Dynalystの全体のKPIを上げていくか...(ここはまだﬁxしきれてない)

検定の問題 32 • 有意差やp値というのは非DSにとって直感的か? ◦ 「有意差ないというのは差がないというわけでもなくて...」云々 ◦ 評価をデザイナーにやってほしいが，これは直感的ではない • 古典的な検定の問題点
◦ 有意差の概念が直感的ではない ◦ 「何も得られませんでした！」の積み重ねになる可能性 ◦ そもそも有意差がないから棄却できないというのはあまりに保守的(by Manski) • どうするか？ ◦ ベイジアンA/Bテストを採用

ベイジアンA/Bテストの採用 33 • 結局実験を通じて何がわかればいいのか? という落とし所の問題になる • いろいろな話し合いの結果．ベイジアンA/Bテストを用いて「クリエイティブの効果に差がある確率」を出力すればいいのでは? という落とし所に決定 ◦
差があるかないかのゼロイチのoutputからは解放される ◦ 古典的な検定よりかサンプルサイズが小さくて済む ▪ DynaDSの分析によると，古典的な検定よりは2/3くらいらしい

クリエイティブAB基盤 34 • 作成途中のクリエイティブ基盤を紹介 • クリエイティブ評価におけるPDCAを回していくための仕組み

何の実験をするかを決める(Plan) 35 • QごとにBiz & CRチーム & DSで，検証するテーマを決める • 上手く横転できる抽象度のテーマかつインパクトが大きそうなものを選ぶ
• 実験はNotionで管理 Notionは非公開

実験実行前の確認(Do) 36 • Notionで実験前のチェックリストを管理 ◦ 実験前にちゃんと確認することで正しい実験を担保 ◦ 現在改修中実際のリストは非公開

実験実行(Do) 37 • 管理画面上で，実験を簡単に開始できるようにする ◦ 広告主やクリエイティブID，説明をいれるだけ非公開

結果のoutput(Check) 38 • Slackでbotを回すだけで判断できるようにした非公開

結果のoutput(Check) 39 • クリエイティブAとクリエイティブBで，どちらのほうが良いかの確率をbotで出力するように ◦ 「差がない」ばかりで知見がたまらない状態の解消 & 解釈のしやすさ

結果のまとめ(Action) 40 • Checkでの結果を元にクリエイティブチームが考察 • Notionで管理非公開

課題 41 • 評価プラットフォームが実はできていない ◦ botで評価 & notionで管理 ◦ どちらも使いづらく，得られた知見の検索性が低い
◦ 上記を統合した評価プラットフォームを作っていく • 得られた知見を最大限お金にできる方法が実はわかってない ◦ Dynalystでクリエイティブを制作できる広告主しか実験が回せない ◦ 主がせいぜい5件 ◦ 一つの広告主で得られた知見はどれだけgeneralなのか?(外的妥当性)

Question 42 クリエイティブ実験から得られた知見を最大限お金にする方法とは? 加藤くんの第2回講義のお金の流れを思い出してください

DSOps #5-2

DSOps #5-2

More Decks by Yusuke Kaneko

Featured

Transcript