every Tech Blog

株式会社エブリーのTech Blogです。

A/Bテスト自動レポーティングによるビジネスサイドの意思決定支援

はじめに

この記事はevery Tech Blog Advent Calendar 2024の7日目の記事です。

エブリーでデータサイエンティストをしている山西です。
今回は、A/Bテスト結果のレポーティングを自動化した事例をご紹介します。
ビジネスサイドが抱く「統計学的なとっつきにくさ」を解消し、結果を解釈しやすく伝えるための試みです。

図1: 結果のレポーティングの雰囲気(評価指標に対して、ダッシュボード上で結果を確認できる)

※ 本記事はランダム化比較実験や統計的仮説検定の基礎知識を前提としています。これらの知見をビジネスに還元する取り組み事例として、何かしらご参考になれば幸いです。

以下、経緯を順に説明していきます。

背景

私たちが運営するレシピ動画サービス『DELISH KITCHEN』では、日々の機能改善にA/Bテスト基盤※1を活用しています。
これは、
1. ユーザー展開の準備(control群、test群への割り当て)
2. 観察指標のデータ集計
3. 統計的仮説検定(観察指標の「test群とcontrol群の差」を検定)
4. 結果のダッシュボード可視化(BIツールRedashをインターフェースとし、日次バッチ更新)
を一気通貫で行う仕組みです。

これまで数年にわたり活用実績を積み重ねており、現在では社内の複数事業部で利用されています。

  • アプリ内機能の開発・改善
  • 機械学習アルゴリズムの性能検証
  • 広告やランディングページのデザイン改善

など、その用途は多岐にわたります※2

こうして、ビジネスサイドがデータドリブンに仮説検証を試みる文化が着実に根付いてきました。

※1 A/Bテスト基盤の詳細については、以下の記事をご覧ください。 tech.every.tv

※2 参考までに、直近1年の実施回数は50回でした。A/Bテストの実験成熟度モデル:Fabijan et al. (2017)では、年間のテスト実施回数で成熟度を簡易的に見積もるアイデアが提唱されています。これにならえば、ちょうどWalk Phase(年に50回以下)からRun Phase(年に250回以下)の境界にあたり、大規模なA/Bテスト推進組織への道がひらけた状態ともいえます。

課題

一方で、

  • ビジネスサイドに結果を正しく解釈してもらうこと
  • そのために適切な実験のデザインをすること

に関しては、一定の課題感が残りました。

以下にその事例をAs-Is、To-Be※3の体裁で整理します。

As-Is(実際にあった例) To-Be(目指したい状態)
・有意差や信頼区間を考慮せず、指標の結果値だけで判断する
・誤差幅と有意性を考慮して結果を解釈できるようにしたい
・有意差が出ていないことを「効果が無かった」と断定してしまう
・有意差がない場合は「差があったとは言えない」と判断できるようにしたい
・有意差と効果量を混同し、「有意だからビジネスインパクトが大きいだろう」と解釈してしまう
・有意性と効果量を区別し、それぞれ正しく考察できるようにしたい
・「有意差が出ていないから、出るまで期間を伸ばそう」と判断してしまう(p-hacking)
・都合の良い結果を導く危険性を共有し、事前の実験デザインを遵守できるようにしたい
・結果を見ながら元の仮説を書き換える(HARKing)
・仮説が不明瞭なまま検証を進めようとする。
・A/Bテストは仮説検証の手段であることを共有し、後から仮説を変える危険性を伝えたい
・大きな変更によるネガティブ影響を恐れ、展開率を必要以上に抑える
・結果を早く見たいので期間を短く設定する
・検出力を確保するため、適切なサンプルサイズと実験期間を設定できるようにしたい

※3 To-Beの部分が全く実践できていないわけではありませんが、共通認識として推し進める段階には至っていない現状をAs-Isと対比して示しています。

発生要因

前提知識のばらつき

これらの問題の主な原因は、結果を解釈する人々の前提知識にばらつきがあることだと考えられます。
統計的仮説検定の結果は本来、有意差や信頼区間の意味を理解しつつ、適切に解釈する必要があります。
しかし、専門知識を必ずしも有していない人々にその解釈を委ねると、「事実が示す以上の解釈」が生じる可能性があります。
その結果、「数字の一人歩き」や「データに基づかない意思決定」といった問題が発生しやすくなり、意思決定のリスクが増大してしまいます。

「ビジネスの関心事」と「統計的な正しさ」とのギャップ

また、時には統計的仮説検定としての理想的な実験デザインが完遂できないことがあります。
先述した「サンプルサイズ不足の状態でA/Bテストを進めてしまう」ケースがその一例です。

ビジネスサイドは収益最大化のため、時には短期間でPDCAを回す判断を行いたい場合もあります。
一方、観察指標によってはサンプルサイズの確保に時間を要する場合があります。
そうなると、「サンプルサイズ確保のために数週間、数ヶ月かけて仮説検定の正しさを立証する」ことよりも、「1施策を1〜2週間で実施し、不確実性を認めつつ結果を判断したい」ことに興味が向く場合もあります。
これはこれで一つの尊重すべき視点である※4一方、統計的視点を薄め、感覚と経験則に頼る傾向を強めてしまうことになります。
これでは、A/Bテストの意義が薄れてしまいます。

※4「1施策の結果考察の確からしさを犠牲にする」策が本当にKPIの最大化に寄与するか否かは、別途定量的に分析してみないとわからないことだと思います。が、本記事の範疇を越えるため、ここでの深入りは避けます。

それをサポートするのがデータサイエンティストの役割では?

「こうした問題を防ぐためには、データサイエンティストがサポートすべきでは?」という指摘はもっともです。
しかし、実際の運用においては、いくつかの課題が浮き彫りになっています。

運用規模の拡大

A/Bテスト基盤の導入初期は、データサイエンティストとビジネスサイドが密に連携して結果を解釈していました。
しかし、運用規模が多くの部署に拡大するにつれ、データチームが全施策に関与することが難しくなっています。

データ解釈の視点の啓蒙活動の限界

ビジネスサイドへデータ解釈の際の心構えを啓蒙することも有効な解決策ですが、それだけでは限界があります。
学習を促す側・される側双方に一定のコストがかかるうえ、個々人の学習意欲や、担当者交代による知識の断絶といった属人性の課題があります。

全社的な見解の統一の必要性

実務者間で解釈を共有しても、他の利害関係者がダッシュボードを見た際に、「数字の一人歩き」や「誤解」が再燃することがあります。
特に、これが意思決定の上層部との間で起こると、認識のズレが意思決定を揺るがす原因になり得ます。

課題解決のための方向性

ここまで挙げてきたように、「誰でも気軽にA/Bテストを推進し、結果をダッシュボードで観察できること」の弊害が見え始めました。
一方で、「データドリブンな仮説検証を全社的に試みようとする文化の良い点」は引き続き維持したいところです。

また、ビジネスのスピード感を優先するがために「科学的な正しさ」の比重を下げなければいけない場合も、「その不確実性によって起き得るリスク」を意思決定者が認知し、公平に判断してもらう状態を目指したいです。

このような経緯から、「統計的仮説検定のデータ解釈をもっと良い感じに共通認識化させたい」という機運が高まることとなりました。

解決策: ダッシュボードからレポーティングへの昇華

これらの課題間の解決策として「言葉で解釈を手助けする」レポートをダッシュボードに追加することにしました。

コンセプトは「記述的なダッシュボードから、言葉によるレポーティングへの昇華」です。

これまでビジネスサイドとA/Bテストの結果を振り返るやりとりの中で「事実の整理としてのレポートはある程度パターン化できる」という気づきから、実装する運びとなりました。

以下に、結果の説明文の生成イメージを紹介していきます。
有意性の有無や、観測値(testとcontrolの指標の差)のプラス、マイナスに応じて、動的に生成内容を切り替えるようにしています※5

※5: 今回の主題ではないため詳しくは触れませんが、Redash上でPythonを実行する機構を用いて、各種統計的検定結果を動的に取得、埋め込む形でレポートを構築しました。

例1: 有意に結果がプラスとなったケース

図2:有意に結果がプラスとなった場合のレポーティング

例2: 有意に結果がマイナスとなったケース

図3:有意に結果がマイナスとなった場合のレポーティング

例1、例2では、「有意性と実際の効果の量を区別し、それぞれ正しく考察できるようにしたい。」というTo-Beを意識しています。

例3: 有意差が観察されなかったケース

図4: 有意差が観察されなかった場合のレポーティング

「誤差幅と有意性を考慮して結果を解釈できるようにしたい」
「検出力を確保するため、適切なサンプルサイズと実験期間を設定できるようにしたい」
というTo-Beを踏まえた内容が含まれています。

こだわり

  • ビジネスサイドにとって理解しやすい言葉を意識する(専門用語を過度に使用せず、統計独特の言い回しを適宜言い換える)
  • 言外の解釈に発展させないようにする(「信頼区間を95%正しい」と誤認させない、「有意差がないことは、効果がなかったことを必ずしも意味しない」など)

などの工夫と共に、慎重に言葉を選びました。

また、例3で挙げたように、理想的な実験デザインが完遂できなかったとしても、その不確実性やリスクを事前に告知する工夫を説明文に施しました。
意思決定者が、ビジネス視点とデータ解釈の視点を公平に判断できる状態を期待しています。

最後に

A/Bテストの運用における実務での気づきから、「自動レポーティング」という新たなアプローチを開拓した事例をご紹介しました。

本記事執筆時点では、これから運用を始める段階です。
自動レポーティングの導入により、統計的な観点を伴う解釈を関係者間で共有し、データ解釈における視座の向上を期待しています。

今後も、データドリブンに施策推進を行う社内文化の醸成と、その質の向上を図っていきたいと考えています。