こんにちは。メルカリAnalyticsチームの@nakanipiです。私はメルカリでホーム画面周りやメタデータ機能の分析・改善、またA/Bテストの改善を担当しています。

今回は「メルカリにおけるA/Bテスト改善」シリーズの第二弾をお届けしたいと思います。第一弾ではメルカリにおけるA/Bテストの現存課題をお届けしました。打ち手である「テスト設計・分析方法の確立と普及」のテーマに対し、この記事ではSRM (Sample Ratio Mismatch : ユーザー数の群間の偏り) について紹介します。

第一弾でも少し触れたように、メルカリ社内では

• SRMを確認せずに結論付けているA/Bテストが存在する

• SRMが起こった時の対処方法がまとまっておらず周知されていない

といった問題があり、SRMについてのドキュメントを作成し、方法論やSRM発生時の対処法をまとめ、周知を行っております。
今回のブログでは、SRMに関する概観とメルカリでの取り組みについて紹介します。

なお、A/Bテスト全体のデザインに関しては過去に紹介した「メリカリにおけるA/Bテスト標準化への取り組み」が参考になるかと思われます。

SRMとは

Sample Ratio Mismatch (SRM) は、A/BテストのControl / Treatmentの割り当てにおいて、サンプルサイズが期待した比率で集まらなかった際に、間違った分析結果を導いてしまう可能性のある現象のことです。たとえば、実験デザインではユーザー割り当ての比率が50:50と仮定していたが、実際の割り当てでは60:40となってしまい、偶然とは言えない差と判定できるような場合です。

SRMが起こっている時、多くの場合はControl / Treatmentの間に属性や傾向面での差が生じており、分析結果にバイアスが生じる可能性が高くなります。

いわゆるA/Bテストのカバ本の著者Ronny Kohavi先生も

とおっしゃっているように、結果フラットであるのに有意と判定してしまうような分析結果にバイアスが生じた例をあげております。

SRMの検知

ではどのようにしてSRMを検知すれば良いのでしょうか。

Control / Treatmentの実験デザインの割り当て比率を帰無仮説として考えた場合、実際の割り当て比率が帰無仮説の元で得られる可能性が低い場合に、SRMが発生していると根拠づけることが可能です。つまり、適合度のカイ二乗検定を行うことで期待通りの比率でサンプルサイズが割り当てられているかを検知することができます。

カイ2乗検定の実施

• エクセル … bit.ly/srmCheck  from Kohavi 

• python …

import scipy as sp
import pandas as pd

## SRM detaction
assignment_ratio = 1 / 2

control_uu = 50
treatment_uu = 26

total_uu = control_uu  + treatment_uu
observed_values = [control_uu, treatment_uu]
expected_values = [total_uu * (1.0 - assignment_ratio), total_uu * assignment_ratio]
result = sp.stats.chisquare(observed_values, f_exp=expected_values)

print(f"control UU: {control_uu}")
print(f"treatment UU: {treatment_uu}")
print(f"P-Value in SRM: {result.pvalue}\n")

# in case significance level is 0.01
if result.pvalue > 0.01:
    print("Non SRM")
else:
    raise ValueError("SRM occurred")

SRMが起きた場合の原因の分類

ではSRMが起こった場合、どのように原因を究明すれば良いのでしょうか。
Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitionersでは複数企業におけるSRMの事例や過去のA/Bテストの再分析・分析者へのインタビューによるSRM原因の分類を紹介しています。私たちも参考にしているため紹介したいと思います。

SRMの5つの大分類 (FIVE COMMON TYPES OF SRMs) 

論文ではSRMの5つの例とともに分類結果を紹介しています。

1 . Experiment Assignment (実験の割り当て)

• テスト概要: MSN.comでのA/Aテスト (control vs controlのテスト) 

• SRM原因: 実験の割り当てシステムのバグで、49.9:50の比率になってしまっていた。

2 . Experiment Execution (実験の実施)

• テスト概要: Skypeの通話のオーディオ品質を改善することを目的としたA/Bテスト

• SRM原因: セッションの途中で実験設定が非同期でリフレッシュされ、約30％のTreatment User ログが記録されていなかった。

3 . Experiment Log Processing (実験ログの処理)

• テスト概要: MicrosoftのカルーセルUI改善のため表示するカードを12枚から16枚に増やしたA/Bテスト

• SRM原因: エンゲージメントの高い(カードにたくさん接触した) Treatment群のユーザーがbotに分類され除外されていた。

4 . Experiment Analysis (実験の分析)

• テスト概要: MicrosoftのFREページ (First-Run Experience: ユーザーが製品を初めて開いたときに表示されるページ) のスキップがユーザーのアクティビティに影響を与えるかどうかのA/Bテスト

• SRM原因: トリガー条件 (割り当ての際の条件) が分析対象の全ユーザーをカバーできなかった。

5 . Experiment Interference (実験の妨害)

• テスト概要: MicrosoftのHomepageの再設計のA/Bテスト

• SRM原因: 検索エンジンのキャンペーンにより、一部のユーザが強制的にTreatment群に割り当てられてしまった。

社内SRM事例

ここでは、実際にメルカリ社内で起きたSRMについて「SRMの5つの大分類」に照らし合わせ紹介したいと思います。

A. 割り当てのミス

これは、実験の割り当ての設定を間違えてSRMが起こってしまった事例です。この実験は3群の割り当て(Control / Treatment1 / Treatment2)  のある実験で、Control群の割り当て数が有意に多くなっていました。原因究明のため、まず実験の設定を確認しました。メルカリでは内製の実験システム (いわゆるFeature Flag) を持っています。実験前に、Feature Flagの設定画面で各群に対して何%を割り当てるかウェイトの設定をします。この設定の確認をしたところ、このウェイトの設定が34:33:33になっていたことが分かりました。正確にはSRMではなく、設定通りであるということが分かったため、問題なしと判断しそのまま実験・分析を行なっています。

B. ログの送信エラー

これは、ログの送信エラーによってSRMが起こってしまった事例です。APIの読み込みでエラーが起こった際、集計の対象となっているテーブルへのログの送信が、Treatment群のみスキップされるような実装になっていました。SRMが起こっていることが確認できた後、システムの調査を行なってバグが発見されました。実験の設定もクエリも間違っていない場合、システムを疑うという流れで進めています。

C.クエリミス

これは、実験の分析中にクエリのミスによってSRMが起こってしまった事例です。Treatment群への割り当て数が有意に多くなっていました。実験の分析を行うクエリで割り当てユーザーと観測したい指標とを紐づける処理において、INNER JOINが原因で特定の行動をしていたユーザーが最終的にUU数として出力されていました。そのため当初の割り当て比率に対しControl/Treatment群ともにユーザー数がともに歪んでしまっていましたことが分かりました。この事例より手動でのクエリの使い回しなどには特に気をつけるべきだという教訓が得られました。

D.人為的介入

これは、実験への人為的介入によってSRMが起こってしまった事例です。Treatment群への割り当て数が有意に多く、集計クエリは問題ないことが確認できました。実験中、ずっとSRMが起こっているのか、ある期間だけSRMが起こっているのかを確認するため、日次で実験対象ユーザーの数を確認しました。すると、ある期間においてのみSRMが発生しており、この状況をプロダクトマネージャーに伝えたところ、その期間にTreatment群のユーザーにのみ通知を送っていたことが発覚しました。この実験では、ある画面を見ることが割り当てのトリガーでしたが、Treatment群に対し、その画面にアクセスを促すような通知を送っていたようです。これにより、通知を送ったタイミングでTreatment群でユーザー数が一時的に多くなり、SRMが起こっていました。この事例から、トリガー発火前に通知を送ることは避けたほうがよい、という教訓が得られました。

F. ランダム

SRMの大分類として考えられる原因を全て検証したのち、それでも結果が分からないということもあります。その場合は、SRMの判定はランダムが原因 (偶然判定が有意となった)と結論づけ再テストを行っております。

AnalyticsチームにおけるSRM調査の優先順位付け

現状、メルカリにもA/Bテスト集計自動化ツールは存在しますが、全チームで使用することはできていないため、手動の集計のようなヒューマンエラーにより近い地点から調べるようにしております。

前提として、この原因究明プロセスは、A/Aテストが済んでおり、複数のA/Bテストが行なわれたことのある領域においてSRMが発生した場合を想定しています。もしはじめての画面やデバイスにおいてA/Bテスト行なう場合は、まずA/Aテストを行ない、Feature Flagの設定やシステムに問題がないかを確認しましょう。

まず疑うべきなのは、集計のミスです。集計期間が正しいか、トリガーや絞り込みの条件を間違えていないか、などを確認していきます。また、クエリをスプレッドシートなどに貼り付けてさらに統計量を計算したりする際には、関数やセル参照の間違いがないかなども確認していきます。

もしここで集計が正しそうであれば、実験の設定を見に行きます。そもそも割り当て設定がアンバランスであれば、もちろん結果もアンバランスになります。その他にも、使っているツールによりますが、Treatmentの数を増やしたり減らしたり、実験の開放率を上げるときに閾値ではなく群間のウェイトを変えてしまったりした場合には、SRMが起こる可能性が高まります。また通知を送っていないかなど、実験への人為的介入についてはプロダクトマネージャーに確認します。

集計と実験の設定が正しそうであれば、最後に実装が正しいかを確認します。Control / Treatmentで異なる挙動をするところはないか、ログの送信やパフォーマンスは正しいか、パイプラインの調査などをエンジニアの方にもご協力いただきながら確認していきます。

ここまで調査しても原因が分からない場合は、上述の通りランダムの可能性もあります。一定の確率で起こりうるので、その場合は実験をやり直します。

論文の10のSRM調査の指針 (Rules of Thumb for SRM Investigations)ではSRMの診断と分類を迅速に行うための10の観点について紹介されているのでこちらも大変参考になるかと思います。

今後の展望

優先順位を定めていてもSRMの調査には莫大な時間を要するのが常です。
SRMの根本原因をなくすために今後の展望として、ヒューマンエラーをなくすためにもA/Bテスト自動化ツールの適用範囲を拡大することを目標としています。

最後に

今後もMercari Analytics BlogではABテスト改善ための3つの取り組みに沿って記事を紹介していこうと思います。次回は「テスト設計・分析方法の確立と、その普及」に関連したA/Bテストの結果の分析・解釈方法に関する記事が出る予定です。今後もぜひ @mercari_data をフォローして新しい記事をチェックしてください。お楽しみに。

メルカリ社内では、ABテスト改善ための3つの取り組みで述べたとおりA/Bテスト周りではまだまだやるべきことが多い状況です。この改善を通じ社内全体のデータの活用のレベルを引き上げることで、きちんとした意思決定への貢献を行うことができるようになると考えております。これに共感し一緒に働いていける方を募集しております。詳細は採用サイトをご確認ください！