エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

効果検証初心者の落とし穴 〜メルマガ配信時刻最適化システムを例に〜

エンジニアリンググループ AIチーム 新卒2年目の金山 (@tkanayama_)です。

今回は、私が新卒1年目に開発を担当していたメルマガ配信時刻最適化システムの経験をベースにしながら、ABテストで得られたデータを用いて効果検証する際に注意すべき点を架空のストーリー形式でお届けします(ストーリー中に出てくる数字を含め、実際のものとは異なります)。

f:id:tepppei:20200713111515j:plain:w400
カンガルーです。

状況説明

エンジニアのKさんは、メルマガの配信時刻を最適化するアルゴリズムを改善するプロジェクトを担当することになりました。これは、メルマガ配信対象者20万人に対し、各ユーザーにとって適切な時間帯に配信することによって、メルマガの開封率を最大化することを目的としたシステムです。また、メルマガを配信できる時刻は、t1, t2, t3の3つです。

既存のシステムは下記のようなアルゴリズムで配信時刻を決めていました。(これを、アルゴリズムXと呼びます。)

f:id:tepppei:20200712233050p:plain
記述1

Kさんは持てる力の全てを使って、アルゴリズムXよりも性能がいいであろう全く新しいアルゴリズムYを考案し、実装しました。

さて、KさんはABテストを実施することによってアルゴリズムXとYどちらが優れているのかを検証することにしました。ABテストは、以下のような手順で行いました。

  1. メルマガ配信対象者20万人を10万人ずつランダムに2分割する。
  2. 一方のグループ(コントロール群)にはアルゴリズムXを、もう一方のグループ(テスト群)にはアルゴリズムYを適用してメルマガ配信を行う。
  3. 各群の開封率を集計して比較する。

集計結果1

集計結果は表1のようになりました。

f:id:tepppei:20200712193959p:plain
表1

残念なことに、テスト群の開封率はコントロール群の開封率を下回ってしまいました。*1

しかしKさんはこの結果を見て、まだ慌てるような時間じゃないと考えました。なぜなら、アルゴリズムXは「t1, t2に割り当てられなかったその他のユーザーを全てt3に割り当てる」というロジックであるため、時刻t3の扱いに大きな改善余地があると見込んでいたためです。もし時刻t3に絞った時にアルゴリズムYの性能がXを上回っていたら、例えば「まずアルゴリズムXでt1, t2に配信するユーザーを決め、残りのユーザーに対してはアルゴリズムYで配信時刻を決める」といったハイブリッドなアルゴリズムにより、Xの性能を上回ることができる、とKさんは考えています。

集計結果2

そこで、表1の結果を実際に配信された時刻ごとに集計し直し、コントロール群とテスト群で開封率の比較を行いました。

f:id:tepppei:20200712194228p:plain
表2

t1, t2に関しては悲惨な結果ですが、t3に限ってはテスト群の開封率がコントロール群の開封率を大幅に上回っています!あとは、当初の想定通り「まずアルゴリズムXでt1, t2に配信するユーザーを決め、残りのユーザーに対してはアルゴリズムYで配信時刻を決める」というアルゴリズムを適用すれば、表中のt1, t2, t3のいいとこ取りができ、既存アルゴリズムXを上回れそうですね!

落とし穴

Kさんの出した結論は正しいと言えるでしょうか?はい、正しくありません。実際、前述したハイブリッドアルゴリズムの期待開封率を正しく計算すると5.5%ほどとなり、もとのアルゴリズムXの開封率7.75%を依然として下回ってしまいます。

表2では一見上手くいっているように見えるのに、なぜこんなことが起きるのでしょうか?正しい議論をするために、定式化して検討してみます。

あるユーザーがどの群に割り当てられるかを表す確率変数を Z(コントロール群なら Z = 0, テスト群なら Z = 1)とします。また、アルゴリズムX, Yが適用された場合に、メルマガを開封するかどうかを表す確率変数をそれぞれ O^X O^Y(開封しなかったら O = 0, 開封したら O = 1)とします。

さらに、アルゴリズムXにより決定される配信時刻を T_X(ただし、 T_X = \{t_1, t_2, t_3 \})、アルゴリズムYにより決定される配信時刻を T_Y(ただし、 T_Y = \{t_1, t_2, t_3 \})とします。

これらの記号を使って表すと、表2の最下段では  E[O^X | T_X = t_3, Z = 0] と  E[O^Y | T_Y = t_3, Z = 1] を比べていることになります。条件部分を見ると T_X = t_3 T_Y = t_3で全く異なる条件の比較を行っていることがわかります。そのため、Kさんが行った比較は意味を持たないのです。

ではどうすればよかったのか

Kさんが本来得たい数値を数式で表現すると、

 E[O^Y - O^X | T_X = t_3 ]

となります。言葉で表すと、「アルゴリズムXが  t_3 に割り当てたユーザー群に対して、アルゴリズムXとYのどちらが開封されやすいか」です。

この式はさらに下記のように展開できます。

 E[O^Y - O^X | T_X = t_3 ]

 = E[O^Y - O^X | Z = 1, T_X = t_3 ] + E[O^X | Z = 1, T_X = t_3 ] - E[O^X | Z = 0, T_X = t_3 ]

 = E[O^Y | Z = 1, T_X = t_3 ] -  E[O^X | Z = 0, T_X = t_3]

ただし1つ目の等号において、コントロール群とテスト群でアルゴリズム改善前の開封期待値が同一であること

 E[O^X | Z = 1, T_X = t_3 ] = E[O^X | Z = 0, T_X = t_3 ]

および、改善幅は割り当てられる群によらないこと

  E[O^Y - O^X | Z = 1, T_X = t_3 ] = E[O^Y - O^X | T_X = t_3 ]

を仮定しています。

したがって、比べるべきは E[O^Y | Z = 1, T_X = t_3 ]  E[O^X | Z = 0, T_X = t_3] です。言葉で表すならば、「アルゴリズムXが割り当てた配信時刻がt3であるユーザー群において、コントロール群とテスト群の開封率を比較する必要がある」と言えます。

集計結果3

上記の議論を踏まえて、改めてABテストの結果を集計したものが表3です。表2との違いは、集約対象が「実際に配信された時刻」ではなく「アルゴリズムXが全ユーザーに対して割り当てた配信時刻」になっている点です。

f:id:tepppei:20200712194500p:plain
表3

これを見ると、どの時刻で比べてもアルゴリズムYが開封率の面で劣っていることがわかります。したがって、前述のようなハイブリッドなアルゴリズムを採用しても、開封率の向上は見込めないでしょう。Kさん、残念!

現象の直感的説明

表1・表3を見るとアルゴリズムYはアルゴリズムXに対して劣っているはずなのに、なぜ表2のt3だけはアルゴリズムYが大きく勝っているのでしょうか。こんなことは現実的に起こりうるのでしょうか。それとも、今回用いた擬似データはとても特殊な状況なのでしょうか。

この疑問に対して定量的に答えることは難しいですが、データの発生原理を考えると、あり得ない話ではないと納得できるはずです。アルゴリズムXの説明を改めて見てみると、「その他のユーザーに対しては、時刻t3にメルマガを配信する」とあります。「その他のユーザー」とは何でしょうか?これは、例えば「メルマガに登録したものの一度もログインしていないような、非常にアクティビティの低いユーザー」かもしれません。適切な配信時刻をサイトアクティビティから判断できなかったために、デフォルト値としての時刻t3に配信されているような状況が想像できます。その場合、アルゴリズムXの特性上、アクティビティの低いユーザーが時刻t3に集まるようになっているため、必然的に時刻t3の開封率は下がります。一方アルゴリズムYは前述の非アクティブなユーザーが他の時間帯にもまんべんなく割り振られるようなアルゴリズムだったとしたら、アルゴリズムYでt3に割り当てられるユーザーのアクティブ度はアルゴリズムXでt3に割り当てられるユーザーに比べて相対的に高くなることが予想できます。

このように、ABテストで得られたデータの集計方法を間違えると、本質的な改善をしていないのにアルゴリズムを変更しただけで性能が上がったように見えてしまうことが起こり得ます。

集計の全体像

念のため、今回用いた集約前の擬似データも示しておきます。

f:id:tepppei:20200712194802p:plain
表4

「群」で集約すると表1が、 「群・実際の配信時刻」で集約すると表2が、「群・Xの時刻」で集約すると表3が得られます。また、一見適当に決められた数字のように見えますが、ID1とID2、ID9とID10、ID17とID18のように、「同一条件下ではコントロール群とテスト群の開封率が(ほぼ)等しくなるはず」という制約を満たしていることも注目です。

最後に

今回の内容はかなり単純ですので、データ分析を行う段階でKさんのように間違った結論を導くことは少ないかと思います。個人的には、今回の話はシステム設計時にこそ意識する価値がある話だと思っています。自然にABテストのシステムを設計した場合、「まず全ユーザーをコントロール群とテスト群に分割し、コントロール群にはアルゴリズムXを、テスト群にはアルゴリズムYをそれぞれ適用する」というシステムを作ることになると思います。しかし、その場合「アルゴリズムXをテスト群に適用した場合の配信時刻」のデータが取れないため、表3のような集約ができません。したがって、コントロール群・テスト群に分割する前の段階で各アルゴリズムを適用するような設計にする必要があるのです。これをシステム設計者が意識することで、ABテストで得られたデータを活用した効果検証がしやすくなると思います。

もちろん、ABテスト開始前の段階で「アルゴリズムXの配信時刻ごとのセグメントに対してABテストを実施する」ということを決めた上でABテストを設計するのが効果検証の観点ではベストですが、今回は「ABテストを実施してしまった後で、得られたデータを後ろ向きに使ってどうやって正しい示唆を得るか?」というストーリーでした。

参考文献・謝辞

今回の話は、「効果検証入門 ~正しい比較のための因果推論/計量経済学の基礎(安井翔太 著)」の1章で紹介されているセレクションバイアスの一例と見なすことができると思います。業務でも大いに活用させていただいております。

We are hiring!

エムスリーはプロダクト数に対してエンジニアの数が比較的少ない組織であるため、エンジニアが複数の役割を求められることが起こりえます。例えば私の所属するAIチームでは、プロダクトごとに主担当者が存在し、施策の検討・システムの実装・効果検証などを一貫して行うような体制になっています。「最後に」の章で、システム設計者が効果検証方法を考慮することの重要性について触れましたが、このように一人が複数の役割を担当することにはメリットがたくさんあると思っています。興味を持ってくださった方はぜひ下記リンクからご応募ください。

エンジニアリンググループ 募集一覧

jobs.m3.com

*1:この結果が統計的に有意な結果なのかどうかは別途検討する必要がありますし、1回のメルマガ配信だけで結論をくだすことは実際にはできません。ただ、今回は本題と異なるため省略しています。