A/Bテストの実験成熟度を押し上げた話
CrawlからWalkへの進歩
はじめに
はじめまして、Eureka BI teamの noaki です！
この記事は「Eureka Advent Calendar 2023」13日目の記事です。
この記事では「A/Bテストの実験成熟度を引き上げた話」についてお話ししたいと思います。
簡単に自己紹介をすると、私は2022年に新卒入社した2年目なのにインターン経由でジョインしたためEureka歴は4年目に突入したややこしい人間です。普段はPairsプロダクト関連のData Analystとして従事しています。
私たちBI Teamでは 「価値のある意思決定」と「意思決定の効率化」の推進 をチームのMissionとしており、(https://medium.com/eureka-engineering/エウレカのデータ組織の3年間-276e2bc9fded)
2023年はプロダクト組織の中で各施策に対して明確で納得感のある評価と意思決定をしよう！という背景から、プロダクトに関連するA/Bテストの実施文化の定着と効率的な意思決定の仕組みの検討を1年間担当してきました。
2023年12月現在では結果的にProjectで年間に数多くのA/Bテストを実施することに成功し、納得感のある成果報告ができるようになってきました。
そこでこの記事では、Projectの中で如何にA/Bテストを浸透させ、PDCAを回し続けるかについて今年の実務経験を踏まえお話していきます。
前提：EurekaでのA/B テストの流れ
Eurekaでは主にPairsの一部機能やUIなどにおいてのテストが提供されており、
「PdM(or Data Analyst)が施策の立案 → Data Analystが実験のデザインと評価指標の決定・Sample Sizeの計算→ A/Aテスト → テストの実施 → Data Analystが結果の検定と報告 → PdMが意思決定」という流れでA/Bテストが進行します。
これまで
本題に入る前に、A/Bテスト運用に本腰を入れる前のEurekaのA/Bテストの状況を整理しておきます。
ざっくり課題を列挙すると以下のような状態でした。
- 入り口：そもそもA/Bテストをやろう！と言える人が限られていた
- ┗ Product ProjectでのA/Bテストは一部のアナリストやPdM発端で年に数件程度しか実施されていなかった
- ┗A/Bテストを実施する一貫した実施基準を持てていなかった
- 計測装置 : RCT(ランダム化比較実験)ができる割り当てシステムは存在したが利活用が活発にされていなかった
- 評価観点：SQLや検定、Review基準が標準化ができていなかった
- ┗ SRM(Sample Ratio Mismatch)の確認やA/AテストなどA/Bテストする上でのお作法が徹底されていなかった
- 属人化：実験デザインや評価方法の選択が属人化されていた
つまるところ、A/Bテストの経験が多くはなく、限られたごく一部の人だけがA/Bテストの評価や実施を適切に実施できているという状態でした。『A/Bテスト実践ガイド』(通称: カバ本) の実験成熟度モデルで言うところのクロール〜ウォークの段階でした。
A/Bテストを回し続けるために実施したこと
上記の状態からクロールからウォークへ進歩するために、評価基準の明確化、実験文化と組織づくり、A/AテストやSRMのチェックの徹底によってテストの信用性と実験の実施回数を向上させることに注力しました。
背景・目的のすり合わせ
まず、テストの設計前に私は特に「本当に知りたいことは何か？」をすり合わせました。例えば、ある機能のUI変更のテストをしたいとなった際に
- 施策の有無自体に効果があるかどうか
- 2つのUIのパターンにおける指標の差があるかどうか
どちらを検証したいかで実験デザインや評価指標は変わってきます。PdMがA/Bテストを通じて本当に知りたいことや知りたい背景などを腹落ちするまで議論するようにしました。
Data AnalystとしてはA/Bテストに限った話ではないと思いますが、時にはテストをしない選択肢すら出てくるのでここでの握りはやはり重要です。
評価指標の選定
上ですり合わせた背景・目的、仮説から検証したい指標(従属変数)を考えました。
『A/Bテスト実践ガイド』 にも記載されているような3つの指標 を整理してPdMと合意を取る動きを取りました。
- Goal Metrics
- Driver Metrics
- Guardrail Metrics
介入やテストによっては直接効果が見えづらい指標の場合があります。 (e.g. 一部の施策導線へのモーダル表示からCTRのLiftを検証したい)
こうした場合では分析感度を上げるAssignのトリガー条件を追加することやDriver Metricsを設定することが必要です。
特に、Driver Metricsにおいて偽の因果関係を作らないことに注意していました。(Cherry Pickの温床になるため)
上記のようなテスト設計や制約に注意しながらProjectのどのメンバーにもわかりやすい指標を設定していき目線合わせを行いました。
Action Planの事前整理
テストのPlanningでは「テスト結果に応じてどのようなNext Actionを取るか」を事前にきめ細かくすり合わせるようにしました。
事前にNext Actionを整理する理由としては、事前にPdM と合意してないと速やかな意思決定ができない可能性があるからです。
結果が判明し良い効果が見込まれる場合は、迷いなく速やかな全展開の判断に進められるようになってきます。
Action Planを事前に決めておくことは、統計学的な不正を防ぐ上でも有効です。例えば、あるテストで、Treatment群のほうがControl群より数値上結果が良いが、p値がギリギリ0.05を上回るような場合に、検定の結果を無視してTreatmentの施策を展開しようという力学が働くこともあります。
「それならこの指標ではどうか？」「もう少しテスト期間を長引かせれば有意差出るのでは？」といったCherry Pickやp-hackingといったアンチパターンの選択が議論のテーブルに載ってしまう場合もあります。
こうした事態を未然に避ける目的に、有意差が出た・出なかった場合などあらゆるケースを事前に整理して握っておくようにしました。結果的にAction Planを事前に整理するようになってから、テスト終了後のごたつきはかなり減って速やかな判断ができている印象があります。
すべてのテストが思い通りの結果になるとは限りません。実際、期待する結果が得られないテストも多々ありました。ビジネスの観点からどのような変化がProject上でどれだけ重要なのかは統計学的には決められません。A/Bテストと施策の全展開によるROIを理解し、判断のラインを立てていくことが重要だと考えています。
テストプランニングのテンプレート化
若干Projectの範囲を越えた内容ですが、効率化の面でかなり大きな役割を果たしたのがテストのテンプレート化です。
EurekaではConfluenceを使っていますが、上述した内容やSample Sizeの計算結果等を記載する枠や記述内容の雛形をテンプレートから呼び出せるようにしています。
これにより以下のメリットがありました。
- 実験デザインの統一化
- Reviewコストの削減
- PdMの記載パートを追加による責任範囲の明確化
A/Bテスト実装のスケール
A/Bテストを実行する上でテスト群のAssignやログの準備が必要になります。誤った解釈を起こすリスクを避けるため、エンジニアとどのように実装するかについてのコミュニケーションは必須です。
特にすり合わせていた観点としては以下の通りです。
- ランダム化単位
- Assignのタイミング
- ログの発火タイミング
- デバイス差分
- 施策の追加によるプロダクトのパフォーマンス
- 実験における仕様上の制約
- ┗ 複数のテスト群にAssignするケースはないか？
- ┗ 他の実験とAssignで影響し合わないか？
実際に、テスト進行中にSRMをA/Aテストで検知してテストをRollbackしたケースがありました。原因として、並行して実験しているテストとの間でユーザーのAssignが競合してしまう場合に例外処理としてControl群に倒す仕様が存在していたためでした。
このような経験もあり、現在ではProject間でのコミュニケーションはかなり活発に行うようにしており、現在ログの発火条件や仕様差分は密に連携を取ることができています。
自分からもA/Bテスト開発への理解を深めてもらうことを目的に、この実装パターンだと実験上どういうことが考えられるのか、のような話をエンジニアに丁寧に伝えることを意識しています。
またエンジニア側でもA/Bテストコードの実装を楽にすることなどに対してかなり投資をしてもらっています。
カバ本の中でもA/Bテストの計測装置は重要との記載があり、QAへの投資や文化的規範の確立を正しい計測装置の実装へのヒントとして挙げています。(第13章 計測装置)
大変だったこと
上記の内容を中心に今年1年A/Bテストを進めてきたわけですが、実はかなり失敗や大変だったことが多いです。正直な話、体感3割楽しくて7割辛いくらいでした。(つらい)
大変だったことを記事の後半として少しだけご紹介します。
PdMとのコミュニケーション
先で話しましたがPdMは関心事項がいくつもあり、すべてData Analystと同じ視点ではないですし、そして何よりもPdMは忙しいです。
例えば、施策をRoadmap通りにローンチしたいし、後に詰まっているRoadmap Itemの開発にも入りたいことはよくあります。
年の始めの頃はそもそもなぜ時間をかけてA/Bテストをしなければいけないのか、というところから説明していく場面もありました。
また、評価指標の観点、有意差の解釈、バイアスや落とし穴を避けるテスト設計、Sample Sizeなど、これらをノンテクニカルなメンバーへわかりやすく説明することに苦戦しました。
例えば、テスト群を2群に分けることによる一時的な売上低下の懸念、短期的な売上効果が見えづらい場合の代理指標の設計、Sample Sizeからテスト期間が長くなることへの憂いなど……
私たちの共通目標はあくまで施策の成果を最大化すること。
この実現を念頭に置き円滑なコミュニケーションのために説明責任を果たすことが至上命題になっています。
やっぱり統計学は難しい
見落としがちなバイアスや落とし穴が多いのもA/Bテストあるあるで、一定数をこなして経験と勘を養う必要性は1年間痛感していました。
例えば、同じ介入を性別ごとに実施するA/BテストのPlanningでテスト群間の干渉を起こしていたことが発覚し再Planningになったケースがあります。また実験のトリガー条件を厳しくすることで多くのバイアスを含むテストになってしまった経験もありました。
BI teamのA/Bテストに関係したメンバーの間ではちょくちょく「俺たちには統計は早すぎた…」みたいな話もよく出ています。まだまだ勉強フェーズです。BI teamとしてスケールさせていく観点でもA/Bテストのナレッジを貯めることへ投資していく姿勢が必要だと考えています。
まとめ
以下の内容を中心にA/Bテストを実行し続けられる体制を整えていきました。
- 背景・目的のすり合わせ
- 評価指標の選定
- Action Planの事前整理
- テストプランニングのテンプレート化
- A/Bテスト実装のスケール
結果として、私たちはA/Bテストを年間で10件以上実施して施策の成果だけでなく、テストを回し続ける知見をStockすることができました。これによってウォークフェーズに到達する足がかりにはなってきかなという実感があります。
1年間やり続けてきて、他のProjectへもこの方式が横展開され始めていて組織体制へ少しばかり貢献ができたような気持ちでいます。
ここまで記事に目を通してくださった方の中で今後何かの参考になれたら幸いです。
これから
正直なところ今年の課題は100%改善しきれていないのが現状で、手のつけられる箇所はまだまだあります。
個人的には、自動化や進行中のA/Bテストの可視化などに取り組みたいと考えています。
Assignログのdwhや検定スクリプトのテンプレートは整備した程度で、事前のプランニングに従って自動で集計や進行状況が可視化できると、工数の削減やさらなる素早い意思決定ができたり新たな化学反応が生まれたりするのが理想だな、と妄想しております。
今はまだ実施できるメンバーが楽になったくらいです。
A/Bテストの実施ハードルを下げることで、BI teamとしてはもっとできる人を増やして全社的にPDCAの回転数をあげていくことがより効率的な意思決定に貢献できるのかなと考えています。
これからもBI teamは 「価値のある意思決定」と「意思決定の効率化」をキーワードに更なる向上を図ります。
