盆暗の学習記録

データサイエンスを中心として,日々学んだことの備忘録としていく予定です。初心者であり独学なので内容には誤りが含まれる可能性が大いにあります。

[読書メモ]「A/Bテストの効果的な実施法」(HBR 2018年7月号)

ハーバード・ビジネス・レビュー2018年7月号の記事「マイクロソフトの分析チームに学ぶ A/Bテストの効果的な実施法」を読んだのでメモ。

はじめに

この記事はMicrosoftの実験チームのゼネラルマネージャーのRon Kohavi氏がMicrosoftとBingの具体的な事例をはさみつつA/Bテストの概要,メリットなどを述べたものです。

以下では,細かな事例は省いて要点を抜き出してまとめていきます。

A/Bテストのメリット

小さな変化が大きな影響を及ぼす

  • ほとんどの進歩は革新的で大きなアイデアではなく,何百何千という小さな改善を実行することでもたらされる。
    • メールのリンクをクリックしたときや検索結果などを「新しいタブで開く」ようにするだけでクリック数が数%上がるという実験結果になった
    • Bingでは文字色の色をわずかに変えただけで,この変更が毎年1000万ドルの売上増をもたらすという実験結果になった

実験は投資決定の指針になる

  • 大きな投資をしてもわずかなリターンしかないこともあるが,実験によってリターンが定量化できれば投資すべき額が判断できる
    • 「この変更で売上が1%上がりそう」→「会社の売上高が毎年これくらいだから,この変更で年間〇〇万円になる」→「この変更にかかるコストと比較して〇〇万円プラスになるな!」と判断していける

A/Bテストの注意点

成功の定義を考える

  • 実験に際して,事業の長期的成果と合致する短期的な指標を決める必要がある
  • 全体評価基準(overall evaluation criterion:OEC)を決めるには徹底した議論が必要になることも多い
    • 戦略を理解している経営陣と,指標やトレードオフを理解しているデータアナリストが密接に協力しなければならない
    • 一度きりで終わる話ではなく,OECは毎年調整するのが望ましい
  • 実験が別の分野に思わぬ影響を及ぼしていないかどうかを知るために,様々な指標をチェックすることも重要
  • 実験の中でどのテストにどの指標が最も効果的なのかがだんだんわかってくる
    • Bingは何年もかけて,実験で使える6000以上の指標を作り,テストの分野ごとのテンプレートに分類している

複雑な実験設計は避ける

  • テストの変数が多すぎても因果関係はわかりにくくなる。
    • 結果の解釈が難しくなってしまうため。
    • 因果関係がわかりやすいシンプルな実験を設計するのが望ましい。
  • 複雑な実験設計はバグに弱くなる。

サンプルサイズが均衡しているか注意する

  • 「対照群と処置群のユーザー数の比率が,実験の設計時のものと一致するかどうか」もチェックすべき事項
    • Microsoftの実験プラットフォームでよくチェックされる項目の一つ
  • 例えば 50.2 : 49.8は想定していた50:50から相当離れており,それが偶然生じる確率は1/50万より低い
  • 実験チームはこうした現象を認知し,その理由を知り解決を図るべく,たえず努力しなければならない

質の低いデータに注意する

  • 異常値の除外,収集エラーの特定などが必要
  • 例えばAmazonは大量に本を注文する一部の個人ユーザー(図書館など)がA/Bテストの結果を歪めかねないことを発見した

実験結果を検証する

  • 実験システムの有効性を実証し,チェックと予防を自動化することに時間や資源を配分する必要がある
    • チェック方法のひとつは,厳格なA/Aテストを実施すること
  • 意外な結果が出た場合は,それが有効であることを確認するため,また人々の疑念を和らげるために,繰り返しテストして結果が再現できなければならない
  • 原因がわかったがそのメカニズムがわからないときは,因果メカニズムを知ろうとするべき
    • とはいえ,「なぜそうなったのか」はわからなくても実験によるエビデンスがメカニズムを説明する理論の代わりになることがある
      • 文字色を変えるだけでユーザー体験が変わって成果があがるのは「なぜ」はわからないが処置効果のエビデンスはある
  • 予想された結果と実際の結果の差に注目する
    • 予想外の事実を知ったときこそ重要な学習をしたときである

因果効果の異質性(セグメントごとの効果の差)への対処

  • 場合によっては,ひとつのセグメントが良かったり悪かったりするだけで平均値が歪み,結果全体がおかしくなる
    • 例えば,Microsoftのある実験では,IE7のユーザーだけBingの検索結果をクリックできなくなるバグのために,本来はポジティブな結果になるはずが総合的な結果がネガティブになったことがあった
  • 実験プラットフォームはそうした異常なセグメントを検知しなければならない

キャリーオーバー効果への対処

  • ある実験で使った処置群・対照群を再利用すると,実験での経験がその後の振る舞いに影響を与えてしまう(キャリーオーバー効果) → 実験ごとにユーザーをシャッフルしなければならない

実験の大部分はうまくいかないため,たくさん試行する必要がある

  • GoogleやBingでは実験のうち良い結果が出るのは10~20%程度
  • Microsoft全体では実験のうち3分の1が有効,3分の1が変化なし,3分の1が悪影響

おわりに

A/Bテストの概要と,実際の運用の話をいくらか知ることができるいい記事だと思います。

「実験のうち有効だった施策は3分の1」
「有効だった施策も,評価指標の増加率が1%以下のものがほとんど」

であるからこそ,たくさん実験を回せるように優れた実験プラットフォームを構築していく必要もある,といった話は印象的でした。

一方で,もっと体系的に細かな話も載っている本を読みたくなります。例えばこの記事には

「一日数千人のアクティブユーザーがいる企業なら,こうしたテストを実施できる」

という記述もあるのですが,一日数千人のアクティブユーザーを集められる企業は限られるでしょうし,「ではサンプルサイズはどの程度だったら実用に耐える精度で実験ができるのか?」「もっと小規模な企業はどうしたらいいのか?」といった部分も気になります。今後調べてみたいと思います。