去年買って読んでいないビジネス書の読書感想文5「A / Bテスト実践ガイド」
目次
第I部 すべての人向けの導入的トピック
第1章 導入と動機付け
ABテストの基本概念
A群とB群を比較してどちらが良かったのか確認する
用語の紹介
- ABテスト(=スプリットランテスト、コントロール実験)
- OEC(Overall Evaluation Criterion)総合評価基準
- パラメーター
- 実験群(A/B/C)
実験の重要性
因果関係を高い確率で確立する最高の科学的な方法である。
信用性の確立方法
- 実験単位があり、異なる実験対象に干渉しない
- 充分な実験単位が存在する
- OEC(目標と評価方法)が明確
効果的な実験の実行原則
- OECが明確
- 組織的にABテストの重要性を理解している
- 組織がアイディアの価値を評価することが苦手だと自覚している
オンライン環境での実験例
- Bingの広告キャッチコピー位置の変更(年間150億円の価値)*
- Googleのリンク文字色の変更*
- Amazonにおける適切なタイミングでのクレジットカード登録オファー
戦略と戦術の関係性
- 事業戦略があり、充分な実験単位があり、プロダクトがあるケースは最適化手法としてマッチ
- リーン戦略にもマッチ。プロダクトと戦略をABテストの結果で変更・改善する
第2章 実験の実行と分析 ~一連の流れの例~
実験のセットアップ方法*
お買い物カゴにクーポンコードを含めるテストを行う場合は以下の様にユーザーを絞って実験することがベストである。
- サイトを訪問した全てのユーザー:◯
- 購入プロセスを完了したユーザー:×
- 購入プロセスを開始したユーザー:◎
仮説検定のプロセス*
- 統計的にはp値が0.05未満であれば有意(検出力95%以上)
- 検出力80-90%で設計することが一般的
- 実用上重要な指標について、巨大サイトでは0.2%のCV向上でも意味がある
- 一方スタートアップでは10%以上のCV率向上が必要かもしれない
- 目安としてユーザー1人あたりの収益が1%以上増加するなら有意的だとする。
実験デザインの考慮点
- ランダム化単位(例:ユーザー)
- ターゲットにしたいランダム化単位の母集団(例:購入確認ページに訪れたユーザー)
- 実験に必要な標本の大きさ(例:収益1%以上の変化に80%以上の検出力を持たせる)
- どのくらいの期間実験を実施するのか(例:3つのコントロール群を4日間実施)
データ収集と分析
ABテストツール(APOLLO Optimizeなど)を使用
結果の解釈と意思決定への応用
前提のチェック
- コントロール群と介入群のサンプルサイズが同じか
- レイテンシなどに影響がないか
結果のチェック
- テスト毎のCV率・CV数・ユーザー単価・P値を比較
結果の判断*
- 統計的に実質的にも有意ではない:×
- 統計的にも実質的にも有意:◎
- 統計的に有意だが、実質的(コスト要因)には有意でない:×
- 統計的に中立で、実質的には判断不能:追加実験
- 統計的に無為で、実質的に有意(恣意的解釈可能)に見える:追加実験
- 統計的に有意で、実質的に有意である可能性が高い:◎or追加実験
第3章 トワイマンの法則と実験の信用性
統計結果の誤解釈
- p値が0.05の場合、帰無仮説が真である確率5%しかないとみなす誤解
- p値が0.05より大きい場合、2つの群に違いがないとみなす
- p値が0.05は、帰無仮説の下で、数ある試行の5%しか発生しないデータが観測されたことを意味するという誤解
- p値0.05は帰無仮説を棄却した場合、偽陽性の確率が5%であるという誤解
信頼区間の理解
95%の信頼区間を使用する場合、同じ実験を100回繰り返した場合、推定された信頼区間に真の値が95回含まれることを期待できるということ。
内的妥当性への脅威
- SUTVAの違反(独立性や一貫性が担保されない)
- 生存者バイアス(戦闘機の装甲の例)
- Intention to Treat(元の割当からイレギュラーが発生)
- サンプル比率のミスマッチ(リダイレクト/ 計測の通信欠損 / バグの繰越 / 不適切なランダム化ハッシュ / トリガー / 時間対効果 / データパイプラインがABテストから影響を受ける)
外部妥当性の扱い*
- プライマシー効果(ユーザーは古い機能になれており、新しい機能学習に時間がかかる)
- ノベルティ効果(新規性効果)
セグメントの違い
セグメントによってより深いインサイトが得られる場合がある。
- 市場または国
- デバイス又はプラットフォーム
- 時間帯や曜日
- ユーザーのタイプ(新規と既存)
- ユーザーアカウントの特徴(アカウントタイプ)
セグメントビューは以下2つ
- 実験に依存しないメトリクス(OS…デバイス別など)
- 介入効果のあるメトリクス(UIの変更はブラウザ別で違う相関をもたらす)
セグメント別の分析はミスリードを起こすこともあるので注意が必要。
シンプソンのパラドックス
テストの結果が逆説を示す可能性は以下の場合。
- サンプリング
- 複数の国で実験されている
- 全体にテストを行うものの、価値の高い顧客群が1%程度しかいない場合
健全な懐疑主義の推奨*
常に懐疑主義的であるべきだとういこと。
第4章 実験のプラットフォームと文化
実験成熟度モデルの紹介
ABテストツールの利用で事足る為、割愛。
実験に必要なインフラストラクチャーとツール
- UIの変更機能
- 割当機能
- 結果の集計機能(統計エンジン)
※基本的にABテストツールを利用。
第II部 すべての人を対象にした選択的トピック
第5章 スピードの重要さを示すケーススタディ
ウェブサイトのパフォーマンス測定
検索エンジンなどにおいて、速度差がどのように影響をもたらすかを試す。
スローダウン実験の設計
表示速度を遅くすることで、ウェブサイトのパフォーマンスを測る方法論。
ページ要素の影響
要素によっては読み込みが遅くても問題がない箇所がある。
- 最初の結果の表示までの時間
- Above the fold timeの時間
- スピードインデックス
- ページフェーズ時間とユーザー待機時間
などのKPIの影響を測る。
極端な結果の分析
- Google検索結果を30件にしたことで収益が20%下降(表示に1.5倍時間がかかった)*
- 速度が早すぎて「やってる感」がなく、プログレスバーを設置して遅延させることで上手くいった例も(占いなど)
第6章 組織を運用するためのメトリクス
メトリクスの分類
- ゴールメトリクス
- ドライバーメトリクス*
- ガードレールメトリクス
メトリクスを定式化するための原理とテクニック
- ゴールメトリクス…単純・安定
- ドライバーメトリクス…ゴールとの整合性・操作可能・敏感に反応・ゲーム化に耐性
その他*
- バウンス率をドライバーメトリクスとして利用
- バウンスの高いクリックは悪いクリックとして定義
- Netflixはパケット化された視聴時間をドライバーメトリクスとして計測
- ネガティブな現象をドライバーメトリクスとして利用
メトリクスの評価
- 他のデータソースとの整合性
- 観察データの分析(レコーディングデータ)*
- 他者事例の検証
- メトリクスの評価を目的とした実験の実施
- 過去の実験コーパスを利用
メトリクスの進化
変更するケース。
- ビジネスが進化した場合
- 環境の進化
- 実験主体者のノウハウの進化
ガードレールメトリクス
いくつかのおすすめを列記。
- ページ当たりのhtmlのレスポンシブサイズ
- ページ当たりのJavascriptエラー数
- 1ユーザー当たりの収益
- 1ユーザー当たりのページ数
- クライアントのクラッシュ
ゲーム化のしやすさ
注意すべき、ゲーミフィケーション。
- ロシアの重量挙げの例(1gでも増えればインセンティブ)
- 鶏肉の廃棄率(行列が発生しレストランは廃業)
- 救急病院にて、患者登録から主治医診察時間を測定(患者は救急車の中に据え置かれた)
- 在庫を少なく維持することでボトルネックが発生
- フランス支配下のハノイでは、ネズミの駆除に賞金(しかしこれは養殖に繋がった)*
- ニューデリーでのコブラも同様
- カナダは孤児一人に70セント。精神疾患一人に2.25ドルを支給。教会は孤児を精神疾患と偽って登録
- 火災発生件数に応じて消防署に資金を提供すると、火災予防施策を抑制する
第7章 実験のためのメトリクスとOEC
ビジネスメトリクスから実験用メトリクスへの変換
- 測定可能
- 紐づけ可能
- 俊敏かつ即時的(短期測定可能)
その他
- ゴールやドライバーを補完するサロゲートメトリクスを設定
- ページのCTRを要素のCTRとして分解
- 信用性ガードレールの追加
- デバッグのメトリクスを追加
OEC(Overall Evaluation Criterion)の例と応用*
- 全ての主要メトリクスがフラットで、少なくとも1つのメトリクスがポジティブである場合はローンチ
- 全ての主要メトリクスがフラット又はネガティブで、少なくとも1つのメトリクスがネガティブである場合はローンチしない
- 主要なメトリクスが全てフラットの場合は、実験を継続するか、失敗と判断
- いくつかの主要なメトリクスがポジティブで、いくつかの主要なメトリクスがネガティブであるならば、心の中のトレードオフモデルに基づいて決定。この蓄積が以後主要メトリクスに重要度の係数を与えることを可能に。
Amazonのメールの例では、メルマガの数に応じてクリック数は増え、短期的に収益は増えたが、メールの量が長大になると、メルマガの解約も増えLTVに悪い影響を。最適なメール間隔を導いた。
Bingの検索エンジンの例では、介入群に非常に劣悪な検索結果が表示されたことで、30%の広告収益が増加し、10%のクエリシェアが拡大した。しかしこれは検索エンジンとして正しい動きではない。
グッドハートの法則*
ある指標を目標にすると、その目標達成の為の行動は必ずしも本質的な改善につながらないことがある。
キャンベルの法則*
KPIは腐敗する(腐敗圧力の対象となる)。
ルーカスの批判
歴史的データは、構造的、因果関係ががあるとは考えられないというもの。
第8章 インスティチューショナルメモリとメタアナリシス
組織の知識蓄積(インスティチューショナルメモリ)とは?
ABテストを通じた、メタデータ分析のノウハウが蓄積することは当然ながら重要である。
インスティチューショナルメモリが有用な理由
#1 実験文化が醸成される。メタアナリシスの問いの例。
- 実験がより広範な組織目標の成長にどのように貢献してきたのか
- 大きな、あるいは驚くべき影響を与えた実験の特定
- どのくらいの実験がメトリクスにポジティブな影響を与えたのか、ネガティブな影響を与えたのか
- ローンチされた機能のうち、実験された機能の割合
- 最も多くの実験を行ったチームの特定
#2 実験のベストプラクティス
社内慣習や、政治的意思ではなく、成果の為の選択と投資を行うことができる。
#3 未来のイノベーション
実験結果の蓄積を後進に渡せること。
#4 メトリクス(KPI)の扱いに足ける
- メトリクスの分析感度
- 関連するメトリクスの特定
- ベイズ的アプローチのてまの確率的な定理
#5 実証研究データとなる
第9章 コントロール実験の倫理
実験の倫理的背景*
Facebookとコーネル大学の研究において、否定的なコンテンツの受信者は、1週間以内に、否定的なコンテンツを投稿する傾向が明らかに(逆もしかりであった)。
上記の例の良し悪しはさておき、実験が倫理的であるかを問いかけることは重要。
- 人々を尊重すること
- 有益性(害から人々を守ること)利益とはリスクを最小化し、実験参加者への利益を最大化すること
- 正義(実験参加者が搾取されないように)
データ収集の倫理
- ユーザーがデータ収集について理解しているか(少なくとも利用規約で公開されているか)
- データが個人特定につながらないか
- 何の目的で収集し何に利用するのか
- データ収集のリスクは何か
- プライバシーの機密性は保証されているか
文化とプロセス
- 文化的規範と教育プロセスを確立
- 機関審査委員会の設置
- 収集データの種類に限らずアクセスできる人間を限定
- 問題発生時のプロセス(エスカレーションパス)の設定
個人特定の問題
- 個人特定データはNG
- 匿名データでも同意が必要
第III部 コントロール実験の補完または代替となる手法
第10章 オンラインでのコントロール実験の補完手法(*章全体を参考にする)
補完手法の概要
- アイディア
- メトリクス
- 仮説の支持・反論の為の証拠
補完手法(*mosueflow的分析による補完)
- ログデータの分析
- 人手による評価手法
- ユーザー体験の調査研究
- フォーカスグループ
- サーベイ
- 外部データ
ログデータ分析
- 直感を養う
- 直感により潜在的なメトリクスを探索
- データからABテストのアイディア探索
- 自然実験(バグなど)の発見
- 観察的因果研究(レコーディング)
人手による評価手法
- バイアスがかかる
- エンドユーザーと同じ属性ではない
為に限界はある。
一方で、デバッグにはとても役立つ。
ユーザー体験の調査研究
- アイトラッキングデータなどを収集
- 日記データ(定性データ)を収集
フォーカスグループ
=グループディスカッション
サーベイ
アイディアを得るために有効な手段であるが、
- 質問文によって意図がズレてしまう
- 匿名なので真実とは限らない
- 応答バイアスがあり母集団が偏りやすい(ファンやクレーマーなどエクストリームユーザーほど反応しやすい)
コントロール実験の結果と因果関係があるとは言えない。
外部データ
- mouseflowなどのレコーディングデータ
- どこどこjpなどのユーザーセグメントデータ
- マクロミルなどにサーベイ依頼
- 論文
- その他公開情報
第11章 観察的因果関係研究
コントロール実験が不可能な場合
- テスト対象の因果関係のある行動がコントロール下にない
- 実験単位が少なすぎる
- 介入を受けないコントロール群を確立する際にあまりにも大きな機会費用が発生
- 変化のコストが実験のリターンと比べて高価な場合
- 実験単位を適切にランダム化できない場合
- 実験が内容が倫理に反する又は違法
観察的因果関係研究の計画
上記の様な理由でコントロール実験ができない場合観察的因果関係の研究を行う。
ポイントは2つ。
- 比較の為のコントロール群と介入群をどうつくるか
- コントロール群と介入群への影響をどのようにモデル化するか
#1 分割時系列分析
時系列を分けて実施。
#2 インターリープ実験
検索エンジンで、同じ母集団に対して、アルゴリズムを混在させて表示させる手法。
※限りなくコントロール実験に近い。
#3 回帰不連続デザイン
しきいち付近のユーザーだけでデータを比較。
#4 操作変数と自然実験
自然に発生する実験(バグなど)を用いる。
#5 傾向スコアマッチング
治療を受けたグループと、治療を受けなかったグループそれぞれの属性を調べる方法論。
#6 差分の差分法
時系列を分けて分析することとほぼ同じ意味。
落とし穴
- 見落とした他の変数による結果差(たまたまテレビで取材された)
- 代表性ヒューリスティックの少数の法則など
反証された観察的因果関係研究
ABテストの方が基本的には良い。
第IV部 【発展的内容】実験のプラットフォームの開発
第12章 クライアントサイドの実験
サーバーサイドとクライアントサイドの違い
- リリースプロセスの時間差
- データの収集方法
実験に関連する事項*
- 変更箇所を早期に予測し、パラメータ化(ローンチの準備)しておく
- ロギングの遅延と実験が有効な期間を予測
- オフライン又は実験開始時のフェイルセーフの仕組みを作る(キャッシュ)
- 実験割当をトリガーにした分析のために、どの実験群に割り当てられたかをクライアントサイドでトラッキングする仕組みを作る(ABテストで実装)
- デバイスとアプリの健全性を保つために重要なガードレールをトラッキング(APOLLO Optimizeで計測。JSエラーはMouseflowで測定)
- 準実験的手法を用いて、アプリ全体でのリリースを監視
- 複数のデバイスプラットフォームとそれらの間の相互作用に注意
第13章 計測装置
クライアントサイドとサーバーサイドの計測装置の違い
クライアントサイド
- ユーザーの行動
- パフォーマンス
- エラーとクラッシュ(JSエラーなど)
システムサイド
- パフォーマンス
- システムの応答時間
- システム情報(キャッシュビット率など)
クライアントサイドの計測の懸念事項
- CPUサイクルやネットワーク帯域幅を大幅に消費
- JavaScriptの計測装置は欠損(読み込み前にリロード / リダイレクト)
ログ処理
理想は下記様々なソースからのアクセスも共通の識別子をもたせること
- 複数ブラウザやモバイルからのログ
- 複数サーバーからのログ
- 同じユーザーがオプトインオプトアウトなど複数の状態を持つ場合
計画装置のための文化
- 文化的規範の確立
- 開発中の計測装置のテストに投資
- 生ログの品質を監視
第14章 ランダム化単位の選択
- ページレベル・セッションレベル・ユーザーレベルの違いを把握
- 複数ページにまたがる機能変更ならユーザーレベルで分析
ランダム化単位と分析単位
- ページレベル…ここのページ単位で分析したい場合
- ユーザーレベル…複数ページにまたがった機能で分析したい場合
ユーザーレベルのランダム化
- サインインID
- クッキー
- デバイスID
第15章 実験対象の拡大 ~スピードと品質とリスクのトレードオフ~
実験対象の拡大(Ramping)の概念
リスクを下げながら実験を行う為に、最初は割当を少ない状況から始めることもある。
SQRフレームワーク
- 100%適用した場合の介入の影響とROIを測定
- 実験時にユーザーやビジネスへの被害やコストを最小限に抑えることによるリスク軽減
- 理想的にはユーザーセグメントごとのユーザー反応を学習する
拡大プロセス
- MPR前(徐々に実行・自動で割当増加・ガードレールをチェック)
- MPR(A:B=50:50実験を実行)
- MPR後(運用上の懸念に基づいて慣らし運転)
- 長期ホールドアウトまたは実験の複製(長期運用が影響を及ぼしそうな場合。念のため実験)
第16章 実験の分析のスケール
データ処理
- データのソートとグループ化(セグメント)
- データクレンジング(主にはセグメントで実現)
- データのリッチ化(別のデータを例えばmouseflowなどから追加)
計算*
- ユーザーごとの統計(OECはコンバージョン数だけではない)
- ユーザーごとのメトリクス計算
結果の要約と可視化
レポート作成の要諦は以下。
- SRMなどの主要なテストを強調表示し、決kが信用できるかどうか明示
- OECと重要なメトリクスを強調
- ガードレール、品質などのメトリクスも表示
- メトリクスの想定的な変化を提示。結果が統計的に有意であるかを示す(色分けしフィルターを有効にするなど)
プラットフォームにあるべきもの(インスティチューショナルメモリの為に)
- チームメンバーが気になるメトリクスを購読できる
- マイナスな影響が想定出来る場合、実験担当者と、データ所有者の会話を強制化する
- メトリクスの分類し実験結果を整理
- 多重検定
- 興味のあるメトリクス
- 関連するメトリクス
第V部 【発展的内容】実験の分析のより深い理解に向けて
第17章 コントロール実験を支える統計学
2標本t検定
2つのグループ(例えば、クラスAとクラスBの生徒)の平均(例えば、テストスコアの平均)が、本当に違うかどうかを調べる方法。
P値と信頼区間
ある現象がたまたま起こったのか、それとも本当に意味のあることなのかを判断する方法。
正規性の仮定
データがある特定の形(正規分布)に従っているという仮定。
偽陽性/偽陰性
- 偽陽性…本当は陰性なのに陽性だとご検出されるケース
- 偽陰性…本当は陽性なのに陰性だとご検出されるケース
バイアス
偏りのこと。
多重検定
たくさんの異なるテストや比較を同時に行うこと。注意が必要。
メタアナリシス
たくさんの小さな研究を一つにまとめて、全体としてどういう傾向があるかを見る方法。
第18章 分散の推定と分析感度の向上 ~その落とし穴と解決方法~
よくある落とし穴
- 差分 vs %の差分
- 比率の指標。分析単位が実験単位と異なる場合
- 外れ値
実験感度の向上
- 似たような情報を取り込みつつ、より分散の小さい評価用のメトリクスを作成
- キャッピング・2値化・対数変換によりメトリクスを変換
- トリガー分析の使用
- 層別化・コントロール変数又はCUPEDを使用
分散にまつわるその他の統計学
割愛。
第19章 A/Aテスト
なぜA/Aを実施するのか
- 偽陽性の発生確率んお合っくニン
- メトリクスのばらつきの評価
- コントロール群と介入群のユーザー間にバイアスが存在しないことの確認
- データとシステムの記録の比較
- サンプル比率の確認
- 統計的検出力の計算のための分散の推定
A/Aテストの実行方法
1000回のAAテストを実施してp値をプロット。
A/Aテストが失敗したとき
原因を特定して、調整を入れてABテストを実行。
第20章 分析感度を向上させるトリガー
トリガーの例*
- 事前に定義された一部のユーザーにのみ介入
- 特定のユーザー行動によって介入が発動
- 影響範囲を広げる介入
- 影響範囲を変更する介入
- 機械学習モデルの為の反実仮想からのトリガー
数値を使った例(Kohavi, Longbotham et al, 2009)
割愛。
最適かつ保守的なトリガー
- 複数の介入
- 事後分析
全体的な介入効果
割愛。
信用できるトリガー
- サンプル比率の分析
- 補完となる分析
よくある落とし穴
- 一般化しにくい実験と小さなセグメント
- 実験期間に対しての不適切なトリガー設定
- 反実仮想のログのパフォーマンス影響
オープンクエスチョン
- トリガーの単位
- 時間をかけてメトリクスをプロット
第21章 サンプル比率のミスマッチと信用性に関連するガードレールメトリクス
サンプル比率のミスマッチ(SRM)
原因として考えられるのは以下
- ユーザーのランダム化のバグ
- ボットのフィルタリングのようなデータパイプラインでの問題
- 残留効果
- 誤ったトリガー条件
- 実験によって影響を受けた属性に基づいて設定されたトリガー
SRMのデバッグ
- ランダム化やトリガーのポイントの上流(過去)に違いがないかを検証
- 実験群の割当が正しいことを検証
- データ処理パイプラインの段階を追って、SRMの原因となるものがあるかどうかを確認
- 実験開始直後を除き、両方の実験群が同時に開始されていない可能性があるかに注意
- セグメントごとにサンプル比率を確認
- 他の実験を確認
第22章 実験群の間での情報のリークと干渉
直接的な例
- Facebookでビデオチャットを友達が使っていたら、私も使う可能性が高くなる
- LinkedInに私のネットワークの中の友人が投稿すれば、私も投稿する可能性が高くなる
間接的な例
- Airbnbにて介入群の予約数が増えることは、コントロール群にとって在庫が減るということである
- Uberで新しい繁忙期の価格変更アルゴリズムを試す場合の、車の台数不足により、コントロール群は影響される
- etc…
いくつかの実用的なソリューション
- 分離
- エッジレベル分析
干渉の検出と監視
システムによって監視すべきである。
第23章 介入効果の長期影響の測定
長期効果とは何か
介入が時間の経過とともに影響をもたらすこと。
短期と長期とで介入効果が異なる理由*
- ユーザーの学習効果
- ネットワーク効果(チャットワークなど)
- 体験と測定の遅延
- エコシムテムの変化(他機能のローンチ / 季節性 / 競合の状況 / 政府の方針 / コンセプトドリフト / ソフトウェアの劣化)
長期効果を測定する理由
- 帰属(データドリンブン)
- 組織的な学習
- 一般化
長期間の実験
割愛。
長期間の実験の代替方法
- コホート分析
- 期間後分析
- 時間をずらした処理
- ホールドバックとリバース実験