A/Bテストが「やって終わり」になっている、A/Bテストからあまり学びが得られていない……A/Bテストを始めたばかりのチームや、A/Bテストが多く走っていて集計に追われているチームは、まずこういった課題を持っているのではないでしょうか。メルカリのAnalyticsチームも例外でなく、この壁にぶつかりました。

そこでAnalyticsチームでは、A/Bテスト改善の取り組みとして、A/Bテストの分析について手法を確立し、普及しようとしています。

この分析は、Experiment design docによって実験前に計画したゴール指標などの基本的な指標を計測した後、実験後にインサイトを得る目的で行なうため、「Post analysis（事後分析）」と社内では呼んでいます。そのため、この記事でもPost analysisという言葉を使いたいと思います。

この記事では、「A/Bテスト改善」シリーズの第三段として、Post analysisについてご紹介します。

執筆者：@suwachan

A/Bテストのデータはもっと活用できる

A/Bテストはデータの宝庫です。一般的にA/Bテストでは、ランダマイズした2群以上のユーザーの行動を分析することにより、因果関係を把握することができます。このA/Bテストのデータを活用できればユーザー行動をよりよく理解できるため、ゴール指標を集計するだけではもったいないと考えています。

A/Bテストのデータを活用してPost analysisを行なうと、次のようなことを通じて、より深いインサイトを得ることができます。

• 実験した機能の変更・追加により、なぜこの結果となったのかを明らかにする

• その機能の変更・追加により、どんな人が影響を受けたのかを明らかにする

Post analysisの流れと手法をまとめるとこのようになります。次の章から、具体的に紹介していきます。

A/BテストのPost analysisの手法

メルカリでよく行なわれるA/BテストのPost analysisは、おおむね次の5つの手法に分けられます。

• トリガーアナリシス

• 指標のドリルダウン

• 指標のセグメント分解

• 時系列の分析

• 機能の使用状況分析

これらの手法はひとつだけ使うのではなく、複数の手法を組み合わせて使うことが多いです。

トリガーアナリシス

その機能変更・追加を経験した人（Control群の場合は経験しうる人）のみに絞って、指標を見る手法です。

A/Bテストの中には、実際に機能変更・追加を経験する機会がなかったユーザーのデータが含まれているケースがあります。たとえば検索チームのA/Bテストでは、検索実行時に実験に割り当てられるが、実験対象は「絞り込み機能」の改善である場合、割り当てのタイミングと実際に影響を受けるタイミングが異なります。

実際に影響を受けていない人たちのデータが含まれていると、結果が薄まってしまうため、トリガーアナリシスを行なって実際に機能変更・追加を経験した人たちのみで集計をします。

注意点としては、トリガーアナリシスをするとバイアスが入りやすいということです。たとえば、

• SQLでフィルターする際に条件を間違える

• 「変更・追加対象の機能が商品との最初の接点だった場合」をトリガー条件にするなど、トリガー条件を誤るとバイアスが入りうる

といったケースが社内でもありました。SRM が起こっていないか、指標が明らかにおかしくないか、を確認しましょう。SRMについてはこちらの記事で紹介しています。

指標のドリルダウン

基本的な指標に加えて、さらに絞り込んで指標を見ていく手法です。

たとえば検索チームのA/Bテストであれば、検索を経由したコンバージョン率を見ていますが、検索の中でも「おすすめ順」や「新着順」での検索を経由したコンバージョン率などにドリルダウンしていく方法があります。

全体のコンバージョン率を見ても有意差はないが、細かく見ていくと効果が出ている場合もあります。ただし、その際にはカニバリゼーション（他の機能と食い合っていないか）に注意しましょう。

指標のセグメント分解

指標をセグメント別に見ていく手法です。たとえば、以下のようなセグメントの分解方法があります。

• 商品のカテゴリ別

• 登録からの経過年数別

• ヘビーユーザー・ライトユーザー別

セグメントは膨大に考えられるので、仮説から考えていくことが重要です。たとえば、「UIの大幅な変更があるので、慣れているお客さまには、この機能は使われなかったのではないか」という仮説があるのであれば、登録からの経過年数別に見ていきます。

「どんなお客さまの体験がこの機能で良くなったのか」を見ていくことで、機能とお客さまの相性などについてインサイトを抽出します。

時系列の分析

指標の変化を日次などの時系列で見ていく手法です。A/Bテストの開始後、指標が安定して動いているかなどを見ていきます。

• 指標がだんだん下がっている場合、導入時にのみ効果があるものなのではないか（いわゆるノベルティ効果）

• 指標がだんだん上がっている場合、機能がよくなったと認識され、効果が積まれているのではないか

• 指標がある時点で急激に変動している場合、何かの施策が関係しているのではないか

というような仮説を検証していきます。

機能の使用状況分析

上記の4つは主にゴール指標に対する分析でしたが、この分析は、新しい機能を導入した場合などに行なう機能の使用状況に関するものです。基本的な指標としては、次のようなものが挙げられます。

• 機能の使用率

• 機能の使用回数

• 機能のリテンション

• 上記の指標をほかの機能と比較

たとえば検索チームでは、「絞り込み機能」に項目を追加する実験を行なうことがあります。このときは、「絞り込み」を押したお客さまが何人その絞り込み項目を使ったか（使用率）、何回使ったか（使用回数）、1回使った人が3日後にどれくらい再度使ったか（3日リテンション）、ほかの絞り込み項目と比較するとどれくらい使われているのか、などを見ていきました。

これにより、機能がどれくらいお客さまに支持されているのか、インサイトを得ることができます。

A/BテストのPost analysisの手順

A/Bテストの手法について見てきましたが、すべて上から順に行なうわけではありません。A/BテストのPost analysisの手順はこのようなものになります。

1. 出た結果が、本当にその機能変更・追加によるものなのかを確認する

2. なぜその結果が出たのか、仮説を立てる

3. 仮説を検証するための切り口を考える

4. その切り口で集計し、仮説を検証する

5. 2〜4 の繰り返しを経て、結論を出す

6. 結果をドキュメントにまとめる

1. 出た結果が、本当にその機能変更・追加によるものなのかを確認する

ゴール指標が上がったとして、それは有意水準95%の場合、5%の確率で偽陽性の可能性があります。本当にその介入の結果なのかを、まず確認します。

ここでは、主にトリガーアナリシスと指標のドリルダウンを行ないます。

もし割り当てのトリガーと、介入のタイミングが異なるのであれば、トリガーアナリシスを行ないます。

割り当てと介入のトリガーが同じであれば、指標をドリルダウンしてみます。たとえば、ホーム画面のあるコンポーネントを変えたのであれば、そのコンポーネント経由で本当にゴール指標が上がっているかを確認します。もしその経由ではなく、全体のゴール指標のみが上がっているのであれば、ランダムを疑います。

2. なぜその結果が出たのか、仮説を立てる

もしゴール指標が下がっていた場合、なぜその介入によりそうなったのかを考えます。

• たくさん出品する人が不便になったのでは？

• 写真ではスペックが分かりづらい「家電・スマホ・カメラカテゴリ」で、使いづらくなったのでは？

• 最近登録した人は使い方が分からないのでは？

など、考えられる仮説を挙げていきます。

3. 仮説を検証するための切り口を考える

次に、2. で出てきた仮説を検証するための切り口 (dimension) を考えます。

上記の例でいうと、

• たくさん出品する人が不便になったのでは？ → 出品数

• 写真ではスペックが分かりづらい「家電・スマホ・カメラカテゴリ」で、使いづらくなったのでは？ → カテゴリ

• 最近登録した人は使い方が分からないのでは？ →登録からの経過年数別

が切り口となります。

4. その切り口で集計し、仮説を検証する

3. で出てきた切り口で、メトリクスを集計・可視化してみます。そして、仮説が正しかったのかどうかを検証します。

正しくても正しくなくても、解釈を考えてみます。

5. 2〜4 の繰り返しを経て、結論を出す

仮説検証の結果、新たな仮説や切り口が出てきたら、2〜4を繰り返していき、結論を出します。

どこまでもやり込みようはあるので、プロダクトマネージャーなど実験のオーナーと相談しながら、限度を決めて行なっています。

6. 結果をまとめる

アウトプットとしては、ドキュメントでまとめておくと親切です。

• 全体の結果

• 検証したい仮説

• 仮説検証の結果

• 得られたインサイト

• ネクストアクション

を一通りまとめています。

Post analysisの注意点

Post analysisを行なう上では、次のようなことに注意する必要があります。

• 無理やり効果があるように見せかけることが目的ではないこと

• 多くのディメンションや指標で比較すればするほど、多重比較となり偽陽性のリスクが高くなること

まず1つ目についてですが、無理に多くの分析をするのではなく、仮説に沿って効率的に分析しインサイトや仮説を得ることが大切です。

2つ目については、あるディメンション・ある指標のみに有意差が出たというだけで、施策のリリースの意思決定に使うことは避けたほうがよいと考えています。あくまで意思決定はExperiment design docで定めたシナリオ通りに（ゴール指標が上がり、ガードレイル指標にマイナスがない場合など）行なうようにしています。

以上のようなプロセスを取ることにより、ひとつのA/Bテストからより多くのことを学ぶことができるようになってきました。知見がたまっていくことで、より実験の仮説の精度を上げることにつなげられれば、プロダクト開発のスピードも上がり、お客さまに価値を届けられると信じています。

メルカリでは、A/Bテストの分析や改善に取り組むアナリストを募集しています。プロダクトマネージャーやエンジニアと協業し、プロダクト開発を前に進めていきたい方、ぜひこちらの採用サイトから情報をチェックしてみてください。