はじめに

今回の記事ではBIチームでA/Bテストの指標の見方を整理した話を紹介します。大きくまとめると、以下の内容になります。

背景：A/Bテストの実施に関わる人数が増えてきた一方、個人差も広がった
- A/Bテストのレポート品質の個人差を克服し、より施策につながる発見をしやすい状態にしたい
課題整理: 集計結果の情報過多がさまざまな課題を引き起こしている
対処: 情報過多を減らすためのガイドライン整備をおこなった
- 拡大フェーズに合わせ見る指標を絞る
- 仮説を検証するための指標に重点をおく

背景: A/Bテスト作業者の増加による品質差が出てきた

BIチームでは定常的にA/Bテストの設計から集計・レポートまでを行っています。直近1,2年の新卒メンバーのjoinやA/Bテストの増加に伴い、作業者が増員されました。
社内ではA/Bテストの自動集計ツールや資料テンプレートが整備されており、これらを使うことで新しく作業に加わるメンバーでも比較的早い段階で作業に参加できました。しかし多くのA/Bテストを実施できるようになった一方で、次のような問題が生まれました。

新しくA/Bテスト作業に加わったメンバーにとって自動集計結果の認知負荷が高く、集計結果をレポートに落とし込むまでに多くの時間と集中力を要する
数値レポートの可視化方法や共有順序が個人によって千差万別であり、読み手・聞き手が理解しづらい
- レポート資料のテンプレートには従っているものの、数値の羅列になり「つまりどういうこと？」となってしまう
- 共有ミーティングで内容に追いつけないメンバーが多く議論が盛り上がらない

このような個人の経験値・スキル差分をできる限り埋め、どのメンバーでも一定水準の品質を満たしたアウトプットができる状態を目指します。

課題: 情報過多がさまざまな課題を引き起こしている

まずはじめになぜ上記のような問題が起きてしまうのか、問題の構造化を行いました。
結論として、A/Bテストで見なければいけない指標×集計軸の数が膨大なことが根本にあると考えました。

原因: 膨大な情報をハンドリングするスキルが個人の経験値・地頭に依存してしまう

A/Bテストで確認する指標は 確認項目の数 = (KPI + それらの因数分解項) × (集計軸の数) のように組合せが膨大になりやすい構造にあります。
弊社のニュースアプリではKPIとしてSalesや継続率、それらの因数分解項(例えばSales = Imp/1000 × CPM のような) があり、さらに集計軸としてOS別・新規ユーザーか定着済みユーザーか・アプリ内でのUIエリア別などがあります。数えてみたところ、2023年11月現在で400件弱と膨大な数値を集計していました。

増員前はこの膨大な情報の集約を、担当者が長く携わるなかで経験的に体得していましたが、まだ経験の浅いメンバーでは同様の品質を担保することは当然簡単ではありませんでした。
そしてうまく情報をハンドリングできていないことが、以下のようなさまざまな問題につながっていました。

作業者の集中力がすり減りやすい
集計漏れが起きやすい
- 結果としてレビュー後の追加作業が増える
関係者へのレポートが正しく伝わらない
- その結果、本筋ではない方向に議論が脱線しやすい
謎資料化詳しく分析内容が書かれているものの記憶に残りづらく、読み手がso what? となってしまうレベルで終わってしまう

では膨大な情報をどう扱えばよいのか？

作業者の情報処理能力をAI並みにすることができれば問題は解決できそうですが、現実的ではなさそうです。(ChatGPTを使う手はありそうですが)
今回は次の2つの改善点を扱うことにしました。

改善1. 情報を削る

ベテランの作業者と始めたばかりの作業者の差としてもっとも大きいと考えたのが、情報の取捨選択です。
たとえばA/Bテストを10%以下で行っている場合に、ベテラン作業者はあまりユーザー規模が大きくないエリアの数値や広告コンバージョンは流し見程度で済ませ、現状判断に使える指標を重視できます。一方経験が浅い段階の作業者ではこのような取捨選択がスムーズにできず、確認する指標が増えていることで集中力を消耗してしまいがちです。
対策として、A/Bテストの拡大フェーズごとにどの指標まで確認すべきかを明文化することにしました。詳しくは次章で述べます。

改善点2. 情報の抽象度を上げる (仮説ありきで考える)

情報を削る以外の方法として、情報を圧縮(抽象化)する方法があります。
A/Bテストの集計結果を確認していくつかの仮説を立てる方法もありますが、仮説を立ててから集計結果との整合性を確認する方が簡便です。

仮説から考えづらい状況になっている原因として、集計作業のゴールが「変更内容を適用するか、撤退するか」に比重が置かれていることが挙げられました。拡大・撤退判断にフォーカスしている状況では、大きく変動した指標が注目されやすく、それ以外の指標の優先度が相対的に下がりやすい状況にありました。
またA/Bテスト結果のレビューや共有ミーティングで仮説の検証結果について共有・議論するフローが取れていないことも、拡大・撤退判断にフォーカスしてしまう一因として挙げられました。

そこで集計作業のゴールを「今回の施策で持っていた仮説は当たったか？」まで引き上げ、レポートテンプレートやミーティングアジェンダの改修を行いました。
下記は改修後のレポートテンプレートの仮説検証欄です。何度かブラッシュアップを重ねており、特に検証結果をYesかNoで書く点が良いと実感しています。内容が記憶に残りやすくなり、検証可能な仮説立てに一定誘導できるようになりました。

対処: 見ないべき指標ガイドライン整備

A/Bテストの拡大フェーズ (弊チームでは1%, 10%, 50%, 100% or 撤退)に応じて見るべき指標を整理しました。見るべき指標を書いてはいますが、それ以外の指標は潔く見ないことが大切だと考えています。

1%では、新規ログが正常に送られているか、バグがないかのみの確認にとどめます。
10%以降は、次の順序で指標を見ることにしました。
基本の流れ

KGI (Tier1指標) を見る
まずはじめにKGI (Key Goal Indicator) を確認します。(KGIとKPIの違いを定期的にググってしまうため個人的にTier1指標と呼んでいます。)
具体的にはDAU、継続率、Sales/DAU を集計軸で分けていない全体値で確認します。
「ユーザー基盤は拡大したか？」「売上は増加したか？」の2つの問いのYes/Noをつけます。
指標を信じてよいか？
施策結果の解釈に入る前に、前提条件を確認します。指標の変動が有意なものなのか、本当に喜んで良いものなのかの濃淡をつけることで後で見る指標の優先度をある程度決めます。
2.1 指標の妥当性: 「サンプルサイズは十分か？」「A/A時点でcontrol群とtreatment群に偏りはないか？」を見ます。
2.2 予想外の毀損の有無: 施策で意図していない毀損がないかを確認するために、ガードレールメトリクスを確認します。もし施策の狙い通りの指標変動がおきていたとしても、ガードレールメトリクスに毀損がある場合は手放しでは喜べません。例えば記事のクリック数を増やす施策を実施し、実際にクリック数が増加していたとしても、Sales毀損がある場合などです。
Tier1指標の変動は何が要因か？
1, 2で大まかなトレンドを把握し終えたら、次に「何が全体のトレンドを牽引したのか？」を説明付ける現象を探していきます。
ここではすべての観点を網羅する必要はなく、仮説→結果確認→次の仮説... というように仮説ベースの検証を繰り返します。以下のような観点で整理することが多いですが、不用意にセグメント分けした指標に立ち入るとサンプルサイズが小さくなり示唆が得られない可能性があるため、2の妥当性が弱まっていないか注意が必要です。
- ファネル: Imp → Click (→ Conversion, Swipe,…) のどこで伸びたか？
- UIエリア別: アプリ内の特定範囲でのみ変動していないか？
集計軸別でも全体と同じトレンドか？
A/Bテストで見られた数値変動について、どこまで抽象度を上げて言えることなのか、例外はあるのかを確認します。例えば「新規ユーザーに絞っても定着済みユーザーと同じトレンドか？」「OS差分はあるか？」などです。