Gunosyデータ分析ブログ

Gunosyで働くデータエンジニアが知見を共有するブログです。

A/Bテストのベストプラクティスと落とし穴 ~KDD2019 レポート~

はじめに

研究開発チームの関です。古川未鈴さんの結婚、ニジマス大門果琳さんの卒業、uijinの解散とアイドル業界も激動の秋を迎えていますね。

f:id:Y_sekky:20190804072222j:plain

2019年8月4日から5日間、アメリカはアラスカ州アンカレッジで開催されたデータマイニング領域のトップカンファレンスであるKDD2019にGunosyから北田と関が参加・発表してきました。 これまでに2つのレポートを公開しています。

data.gunosy.io

data.gunosy.io

本レポートではTutorialとして開催された「Challenges, Best Practices and Pitfalls in Evaluating Results of Online Controlled Experiments」の内容をレポートします。 内容は現在のA/Bテストのガイドラインと言ってもいい内容で、非常に参考になるポイントが多かったです。

以下のページで資料も公開されていますので、本エントリを読んで興味を持たれた方はぜひそちらを御覧ください。 sites.google.com

以下本エントリの画像はチュートリアル資料から引用しております。

チュートリアルの概要

「Challenges, Best Practices and Pitfalls in Evaluating Results of Online Controlled Experiments」はA/Bテストに関するチュートリアルです。 このチュートリアルは以下4名のオーガナイザによって企画されました。

  • Xiaolin Shi, Snap Inc.
  • Somit Gupta, Microsoft.
  • Pavel Dmitriev, Outreach.
  • Xin Fu, Facebook.

彼らは全員元Microsoft Researchに所属したことがあるメンバーです。 XiaolinさんはSnapChatを開発しているSnap inc.の機械学習チームのリーダーで、KDD2016に採択された「Data-Driven Metric Development for Online Controlled Experiments: Seven Lessons Learned」の著者です。（当時は米ヤフー） PavelさんとSomitさんはKDD2017に採択されていた「A dirty dozen: twelve common metric interpretation pitfalls in online controlled experiments」の著者です。 PavelさんはOutreachという求人サービスを提供する会社のデータサイエンスチームのリーダを務めています。 XinさんのPublicationは見つけられなかったのですが、MSRからLinkedinでデータサイエンスチームのシニアディレクター、現在はFBでデータサイエンスチームのディレクターを務めており、複数のTech Giantでデータ分析の重要なポジションを歴任している方です。

このように研究業績としても事業のキャリアとしても非常に強いメンバーによってオーガナイズされています。 こうした企業間の研究者ネットワークや、研究者がこうした重要なポジションに付いていながら、論文も生み出しているような組織としての背景に強さを感じます。

このチュートリアルは非常に注目度が高く、前半は立ち見どころか部屋から人があふれるほどの盛況ぶりでした。 そのため休憩時間に使う予定のなかった大会場に急遽移動が行われました。 昨年度のA/Bテストのチュートリアルはそこまで人が溢れていなかったらしく、オンラインテストの業界での重要性の高まりを感じます。

なぜ我々はA/Bテストをしなければならないのか？

まずこのチュートリアルでは、「どのように良いアイデアをみつけるか？」について、Bingにおいて最も良かったアイデアを題材に議論しています。

f:id:Y_sekky:20190925184535p:plain
Part I. Introduction P.5 より引用

これがBingで最も良かったアイデアで、リスティング広告の説明文の冒頭をタイトルに付けて表示するものです。 非常にシンプルなアイデアですが、これが12%の利益向上、年間で$100M以上の改善をもたらしたそうです。

このアイデアは、数多くあった候補の中の一つで、その中でも重要視されておらず数カ月間バックログに残ったままになっていました。 それをあるエンジニアがたまたま見つけ、「実装コストが低そうだ」という理由で実装された結果、急激な売上向上がもたらされたそうです。 つまりこのアイデアがそうした成果を残すことを誰も期待してなかったということになります。

この事例を踏まえ、本チュートリアルでは「私達はアイデアの価値を評価することができない」ということを繰り返し主張しています。 KDD2009のワークショップであるData Mining Case Studiesで発表されたOnline Experiment at Microsoftでは実装されテストされたアイデアのうち1/3は良かったものの、1/3は特に影響を与えず、1/3はむしろサービスを悪化させることになったという結果が報告されています。 それは専門家が判断しても同様であり、世の中のベストプラクティスとされるものには矛盾が多いと主張しています。

f:id:Y_sekky:20190926111823p:plain
Part I. Introduction P.8 より引用

こちらはGrace Hopperさんの名言です。 彼女はCOBOLを開発したプログラマの一人であり、世界で初めてバグを発見したプログラマとしても有名です。*1 こうした事実は古くから知られているものの、現代でもやはり人は直感や専門家の意見を重視してしまっています。

チュートリアルでは、アイスブレークとして、実際に各サービスで行われたA/Bテストで、どちらが良かったかを予想するという試みが行われました。 参加者全員が起立し、3つの事例について、どちらが良かったかを投票し、間違えると座ります。 40人程度いましたが、3つの事例をすべて当てることができた参加者は数人でした。 おそらくこのチュートリアルの参加者は、実務経験の豊富なデータサイエンティストが多かったことが予測されます。 このように、アイデアの価値を評価するのは非常に難しいということがわかります。

つまりアイデアの価値を正しく判断するために私達はA/Bテストをする必要があるということです。 We can’t trust our gut! To make the right choices we need data from real users!というフレーズが印象的でした。 インタビューやアンケートなども手段としてありますが、それではサンプリングバイアスが非常に強く、正確性に疑問があることや、 実際に良いとユーザが感じても、数値として向上しなかったり、向上するのは別の選択肢なこともよくあります。

データを正しく使おう

アイデアを正しく評価するためにデータを使おうという話をしましたが、データは正しく使わなくては意味がありません。 本チュートリアルでは「相関と因果」と「前後関係」の2つについて議論されました。

「相関と因果」はよくデータ分析の誤りの例として指摘されるもので、 2つの事象に相関があるからといって、その2つの事象に因果関係があるわけではないということです。 データ分析の結果、ある機能を使わなかった25%の新規ユーザが離脱したのに対して、ある機能を使ったユーザは10%しか離脱しなかったことがわかったとします。 この結果から、その機能にはユーザの離脱率を改善する効果があるのではないか、という結果を導き出すことは、尤もらしい気がしますが間違いです。 この結果は機能の利用の有無と離脱率に相関があることを示してはいますが、それは因果関係を示しているわけではありません。 例えばその機能を使うには離脱をしないぐらいにサービスを使い込んでいるという前提が隠れている可能性があります。 このようにデータを使うときに、相関の話をしているのか、因果の話をしているのかは明確に区別するべきです。

「前後関係」は実験期間中の適切にイベントの影響を考えましょうということです。 チュートリアルでは以下のグラフに示す2つのサイトにおけるKindleの売上比較を例が紹介されています。

f:id:Y_sekky:20190926153920p:plain
Part I. Introduction P.12 より引用

Oprah calls Kindle "her new favorite things" とは、アメリカの有名司会者であるオプラ・ウィンフリーが自身の番組「ウィンフリー・ショー」でKindleがお気に入りであると紹介したことを指します。*2 Kindleの売上はこのイベントによって急増しました。 ここで2つのサイトの比較をすると、常にサイトBがサイトAより売上が小さいため、サイトBはサイトAより悪いと見ることができます。 しかし、イベント前後をみると、イベントによって売上が急増したにも関わらず、サイトAとサイトBの差分はほとんど変化がありません。 イベント前は、サイトAはサイトBのおおよそ2倍良いという見方ができましたが、イベント後は10％程度の差にとどまります。 これを全体で平均して比較してしまうと、改善幅を見誤ることになります。 比較するときは、イベントや時期・季節要因の影響を考慮することが重要です。

ちゃんと仮説を立てよう

次にA/Bテストなどの実験をやるまえの仮説の重要性と仮説の立て方について述べられています。 こちらの議論はオーガナイザのPavelさんが著者の一人である「Three Key Checklists and Remedies for Trustworthy Analysis of Online Controlled Experiments at Scale」を元にしているようです。 こちらの論文は4つの企業が著者に入っており、現代的なA/Bテストについて高いレベルで一般化されています。 是非一度読んでみてください。

f:id:Y_sekky:20190926173344p:plain
Part I. Introduction P.22 より引用

こちらはExperimental HubというサイトのHypothesis-Kitで取り上げられているA/Bテストの仮説のフォーマットを元にした図です。 各項目は以下のようなことを述べています。

  • Context: 実験の背景、定量的、定性的にこの実験を行う理由として示されたもの
  • Description of the change: なにをどう変えるか？
  • Who will see the change: 対象ユーザはだれか？
  • How will the change impact metrics: この変更が数値をどのように変えるか？
  • How the impact connects to business goals: 数値の変化がビジネスにどうした影響があるか？

A/Bテストで重要な内容が見事に網羅されていますね。素晴らしいリストです。 弊社でもA/Bテストにはテンプレートがあり、類似したものを使っているので納得感があります。 A/Bテストをやるみなさんも当然このようなことは考えているのだと思うんですけど、こうした形で明文化することがより正しい意思決定をするために重要だと言えます。

このリストでは、事前に数値を定義し、そしてビジネス目標との接続を明確にすることが求められます。 これによって仮説と数値の接続を明確にし、ビジネスの観点から優先順をきめることができます。 また実験が終わったあとに目標数値を変えることによる、間違った意思決定を避けることにも繋がります。

このように仮説を数値とつなげて立てることが非常に重要だと述べています。

評価指標を決めよう

仮説を設定する中で評価指標を設計しましょうという話をしました。次にどう設計するかという話をします。

正しい評価指標を設定しないとどうなるか

適切な評価指標を設定できないことにおける課題として、ハノイにおけるネズミ駆除の例があげられています。*3 フランス統治下のハノイでは、ネズミを駆除するために市民にネズミを駆除した証拠としてネズミの尻尾を提出することで報奨金を出す制度を導入しました。 その結果、提出されるしっぽのかじは急増しましたが、ネズミの数は減りません。 そのころのハノイでは2つの事象が発生していました

  • しっぽのないネズミがまちなかで観測されるようになった
  • ネズミの輸入業者と養殖業者が生まれた

このように施策に対して誤った評価指標を設定することによって、結果を歪めてしまいます。 これはコブラ効果とも呼ばれているそうです。

良い評価指標とはなにか？(STEDI)

良い評価指標がどのような特性を持つべきかについて以下の5つの観点が示されています。

  1. Sensitivity
  2. Trustworthiness
  3. Efficiency
  4. Debuggability and Actionability
  5. Interpretability and Directionality

この5つの頭文字をとって、STEDIと呼んでいます。

Sensitivity

Sensitivityは2つの要素からなります。 1つは変更に対して指標がどれだけの頻度で変動するかということ。これをMovement Probabilityと呼びます。 もう1つは効果による指標の変動があったとき、それをだれだけ確からしく特定できるかということで、これをStatistical Powerと呼びます。 Statical Powerはサンプルサイズが大きくなるほど小さくなり、変動係数(CV)が大きくなるほど大きくなります。 変動係数を2.5以下に収めるのが良いやり方だと示されていました。

Trustworthiness

Trustworthinessは数値を簡単に得られるか、そしてTwyman’s lawを考慮する必要があります。 数値を得られるかというのは当たり前のように聞こえますが、意味のある数値を得ることはそう簡単ではありません。 サーバのトラブルなどで数値が欠損することは珍しくありません。 またログの仕様が評価に適切でないことや、バグがあることもしばしばあります。 また例えばウェブの場合はBotのアクセスなどは施策の評価にはノイズなので取り除く必要があります。 このように数値を得ることは難しいため、容易に得られる指標であることは信頼性を高めます。 Twyman’s lawとは「興味深かったり違いが明確な図は大抵誤りである」と表現されます。 具体的には強い結果が出たときは、まずなんらかの外的要因やミスを疑うべきということです。 そんな明確に良い施策というのは早々あるものではありません。 *4

Efficiency

組織が成熟して、実験の体制が整ってくると、数十、数百と行うテストの数は増えていきます。Efficiencyは重要です。 EfficiencyにはTime, Conplexity, Costの3要素が示されています。 Ronny Kohaviは“An approximate answer today is worth much more than a (presumed) better answer three months out.”と述べています。 つまり３ヶ月後に得られる正確な答えより、今日得られる大雑把な答えのほうが遥かに価値があるということです。 Netflixは再生時間を１ヶ月継続率の代理変数として使っており、Courseraはコースマテリアルへのインタラクションとクイズの利用率をコース完走率の代理変数として使っています。 このように、大雑把でもより早く結果を得られる変数を探すことは重要です。 また複雑な指標も効率性を欠きます。例えばアイトラッキングやアンケート指標は扱いが難しいものとしてあげられます。 そしてそのデータを得るコストも重要です。例えば人手でラベルを付けなければいけないデータは、データ量が増えるにつれてスケールさせることは難しく、コストが大きくなります。

Debuggability AND Actionability

そのメトリクスが動いたときに、その理由をデバッグできるようにしておくべきということです。 特に、オンライン実験を行う場合にはどうしてもバグが発生することがあります。 特にユーザごとに出し分けたり、特定の条件でしか発生しない施策の場合、それを検知するのは難しいです。 そのため、バグやクラッシュを検知できる仕組みを指標として設計しておく必要があります。 先述したとおり、数字がすごく改善したときはバグの可能性が大きいです。 それを知るためにもDebuggabilityは重要であるといえます。

Interpretability and Directionality

Directionalityとは、その数値が改善したときに目的が達成されるのかを指します。 例えばニュースアプリでユーザエンゲージメントの向上を目的とした機能をテストするとき、その機能のCTRが向上していても、全体のCTRが低下していては目的を達成したとはいえません。 例えばクリック数が多いユーザの比率などを指標にすると良いと例では述べています。 また結果は意味のあるように集計しなければなりません。例えば満足度を５段階で評価したときに、平均を取るといった行為は適しておらず、不満のあると答えたユーザの割合などのような方法が適しているとしています。*5

Metricの種類について

本講演では評価指標の設計において、4種類の評価指標を設計すべきだとしています。

  • Optimizing for OEC metrics
  • Protecting Guardrail metrics
  • Understanding the Why. Local feature, debug, and operational metrics
  • Data Quality metrics

Optimizing for OEC metrics

OECはOverall Evaluation Criteriaの略で、その施策がゴールとすべき指標です。 先に述べた指標が満たすべき役割の中で、特にDirectivityとSensitivityを満たすものが良いOECになります。 OECとして適切な例としてUXのMetricsフレームワークであるHEARTが紹介されていました。 HEARTはHappiness, Engagement, Adoption, Retention, そしてTask successの５つの項目の頭文字をとったものです。*6 HEATについては、資料の中でより詳細に実例を踏まえて説明されているので、読んでみてください。

Protecting Guardrail metrics

OECが施策がどのようにサービスを改善したかを測るための指標なのに対して、Gardrail Metricsはサービスに対して悪影響を与えないかを測るための指標です。 よかれと思って行った施策がユーザの離脱や売上の低下を招いてしまうことは珍しくありません。 講演ではHEARTに対してPULSEというフレームワークが示されていました。 PULSEはPage views, Uptime, Latency, Seven-day active users, Earningsの頭文字をとったものです。 こうした観点は我々も施策を実行するときにもっていましたが、このようにフレームワークとしてしっかり整備して名前をつけているところがすごいなと思いました。 フレームワークにすることで、誰もが意識できるようになるし、業務フローの中に容易に組み込むことができるようになります。 非常に洗練された指標だと感じました。

Understanding the Why. Local feature, debug, and operational metrics

OECやガードレールで施策の結果を知ることはできますが、それがなぜかを知るには探索的にブレークダウンしていく必要があります。 施策に関係しそうなユーザ行動を洗い出し指標化しておきます。 ここで重要なのは、事前にその数値が上がるか下がるかに対して良さを決めないことです。 OECやガードレールで施策の良し悪しは決めているので、ここの指標はその結果を解釈するために使います。

Data Quality metrics

最後のData Quality metricsはその名の通りデータの品質を測るためのメトリクスです。 弊社には「数値が神より正しい」という言葉がありますが、エンジニアの中にはそのためには数値が正しくないといけないということも同時に言われています。 同様のことをいっていて、例えばログに欠損がないか、定義は正しいか、比較がおかしくないかといったことを検証するためのメトリクスです。

まとめと感想

このようにオンラインテストを行うための指標についてかなり密な議論がありました。 全体を大雑把に紹介しただけですが、それだけでもこれだけのボリュームになってしまいました。 定義がしっかりしており、適切な名前がついているので、だれもが運用したり議論できるようになっているんだろうなと感じました。 それぞれの項目としては特に新しいものはないのですが、それを体系的に整理して名前をつけているというのが、組織で運用するために大事なことだと思うので、非常に参考になるよい内容でした。 他にも紹介できなかったコンテンツがあるので、ぜひとも実際の資料をみていただければと思います。

おわりに

KDDは学会ではありますが、このように産業界の実際の課題について、現場レベルの発表が多く、それが学術的な視点と融合しているのが印象的でした。 また本チュートリアルのオーガナイザが元MSコミュニティなように、テックジャイアントのコミュニティ形成力の強みも感じました。

Gunosy では論文執筆・投稿を目的として研究に全力で取り組むリサーチインターンを募集しています。今回 KDD2019 の参加および発表を通じて様々な最先端の研究に触れることができました。ぜひご興味がある方は応募してみてください。

hrmos.co

*1:バグはもともと電気系のトラブルを指す言葉として使われていましたが、彼女は開発中に、コンピュータの中に蛾が挟まっていて、それが原因で動かなかったことを発見しました。これがソフトウェアのエラーをバグと呼ぶことが広まったきっかけとされているそうです。この蛾は彼女の日記に貼り付けられて、現在博物館に展示されています。

*2:Oprah calls Kindle "her new favorite thing," gives everyone $50 off

*3:詳しくはこちら ハノイのネズミと「コブラ効果」 - akihitosuzuki's diary

*4:Twyman’s lawについて、詳しくは事例なども含めこちらを参照してください: Twyman’s law and Controlled Experiments

*5:色々調べたところ、このあたりは諸説あるそうですが、個人的な意見としてもTutorialの立場に乗ります。

*6:Rodden+, Measuring the user experience on a large scale: user-centered metrics for web applications.(CHI10)