every Tech Blog

株式会社エブリーのTech Blogです。

トップ > 『DELISH KITCHEN』のA/Bテスト基盤を構築しました

『DELISH KITCHEN』のA/Bテスト基盤を構築しました

f:id:nanakookada:20211008171022p:plain

はじめに

こんにちは。株式会社エブリーでデータサイエンティストをしている伊藤です。

『DELISH KITCHEN』では、サービスをより良くするため、新機能の開発や既存機能・デザインの改善など様々な施策が行われています。 これらの施策は、一部のユーザのみを対象とする「A/Bテスト」によってオンライン評価され、その効果が認められてからユーザ全体にリリースされます。

直近、A/Bテストの信頼性・アジリティをより高めるため、データチームが主導となり新しくA/Bテスト基盤を構築・導入しました。 本記事では、新しく導入したA/Bテスト基盤の概観を紹介させていただきます。

今回紹介するA/Bテスト基盤の活用については、少し前の記事でも紹介していただいているので、そちらも是非合わせてご覧ください。

tech.every.tv

これまでの課題

これまで、A/Bテストは各運営チームが主導となって実施されてきましたが、改めて運用体制を見直すといくつかの課題点がありました。

ここでは特に

  • ユーザグループの選び方
  • 評価指標設定と結果の解釈プロセス

の2つに関して詳しく解説します。

ユーザグループの選び方

A/Bテストは Randomized Controlled Trial (RCT) とも呼ばれ、何らかの変化（介入）がユーザにもたらす因果効果を評価するための分析手法です。 具体的には、ランダムなユーザの割り当てによって2つの同質なグループを用意し、その片方のグループ（テスト群）にのみ介入を加え変化を計測します。

2つのグループが介入の有無を除き同質ならば、計測された変化をそのまま介入による効果として扱えますが、注目する介入以外の影響が混入している場合計測された変化にはバイアスがかかり、正確な因果効果が評価できません。 従って、A/Bテストではいかにランダム性の高いユーザ選定を行うかが重要になります。

これまで『DELISH KITCHEN』で実施されていたA/Bテストでは、アプリユーザにランダムに付与されるユーザIDを利用し、その末尾の数字を元に割り当てグループが決められていました。 この方式は、ランダムなユーザIDを元にグループを分けており、また「末尾1のユーザはテスト群にする」など集計時にSQLで表現しやすいというメリットもあるため、一見すると有効な方法だと思えます。

しかしながら、この方式は割り当ての粒度が粗く、運用する上で

  1. 同時に実施される別の施策と割り当ての重複が発生しやすい
  2. 割り当て対象は施策の担当者が決定する場合が多く、選ばれる番号に偏りが生じやすい

といった状況が発生します。

1つ目の状況では、関係のない施策の効果が本来計測したい介入効果のバイアスとなるため、正確な評価が難しくなります。 また、これを回避するために関係者間での調整が発生するため、アジリティの低下に繋がる可能性があります。

2つ目の状況では、過去に実施した施策の影響（キャリーオーバー効果）が特に問題となります。 特定のユーザグループに何度も介入を続けると、そのグループは複数の介入効果を含んだ性質を持つため、一度も介入を受けていないグループとの差分が単一の施策によるものであるという保証が難しくなります。

以上から、よりランダム性の高いユーザ選定を実施するためには、ユーザID末尾を用いない方式が必要だと考えられます。

評価指標設定と結果の解釈

A/Bテストでは、CVRや機能利用回数といったビジネス目標・ユーザ体験を表す評価指標を複数設定し、コントロール群・テスト群の差分から結果を評価します。

そのため、適切な意思決定を行うためには

  • 評価指標が正しく定義され、かつ継続的に正しさが担保されている
  • 結果を解釈・評価するプロセスが整備されている

の2点が重要となります。

『DELISH KITCHEN』ではデータ分析のためのBIツールにRedash1を採用しており、誰でもSQLを書いてログの分析やダッシュボード作成が可能な環境が整備されています。

A/Bテストについても、担当者それぞれがRedashを使って評価指標設定と結果の解釈を行っていましたが、それ故に

  • 評価指標集計のために書かれたクエリが散逸しており、統一的に管理されていない
  • 結果の解釈の仕方が担当者それぞれの方法に依存してしまっている

といった課題も生じていました。

従って、より信頼性の高いA/Bテストの運用体制を実現するためには、これらのプロセス整備も必要だと考えられます。

A/Bテスト基盤方針

要件整理

以上挙げた課題をふまえて、まずA/Bテスト基盤の要件を整理したいと思います。

2017年にMicrosoftから発表された論文では、A/Bテスト環境の成長過程を表現したExperimentation Maturity Modelsが提案されています2。

このモデルでは、1つ1つのA/Bテストが単発的に実施される段階から、数多くのA/Bテストが絶え間なく実施される段階までを、Crawl、Walk、Run、Flyの4段階に分類しています。

A/Bテスト基盤での技術的な観点に注目すると、A/Bテストをより効果的かつ効率的に実施するためには、以下のような仕組みが必要であるとわかります。

  • 適切な割り当てグループの作成（検定力分析、A/Aテスト、キャリーオーバー効果の制御）
  • ユーザ体験への悪影響の最小化（アラートシステム、A/Bテストの自動停止、イテレーションの効率化、介入の相互作用の制御と検知）
  • A/Bテストの実施履歴の保存

全体像

Experimentation Maturity Modelsで示されていた技術要件全てをいきなり実現するのは難しいですが、これまでの課題と照らし合わせ、最初の取り組みとして新しいA/Bテスト基盤では次の内容に取り組みました。

  • 評価指標を管理するための評価指標ライブラリの作成
  • 他の施策の影響が含まれないランダムなコントロール群・テスト群の割り当て方式の整備
  • 統計的手法に基づく考察と意思決定が可能なダッシュボードの作成

f:id:sbrf:20211006162342p:plain
A/Bテスト基盤全体像

以下では、これら3つのより詳細な内容について紹介したいと思います。

A/Bテスト基盤内容

評価指標を管理するための評価指標ライブラリの作成

評価指標ライブラリでは、A/Bテストに使われる様々な評価指標の登録と管理を行います。

ひとくちに評価指標といっても、その集計プロセスは

  • イベントデータの組み合わせ方といった大枠の集計フロー
  • 集計軸や期間・アプリバージョンなどの集計条件

の2つの要素に分解できます。

例として「アクティブユーザ数」を挙げてみます。 大枠の集計フローは、評価指標自体の性質から「アクセステーブルに記録されたユーザ数」となります。 集計軸や集計条件はユースケースにより変化し、

  • ユーザ全体について日別で集計する場合 (DAU) は、集計軸を日付に設定
  • あるA/Bテスト実施期間内のアクティブユーザ数を集計する場合は、集計軸に割り当てられるユーザグループ、集計条件にA/Bテスト対象のユーザや実施期間、対象となるOSなどを設定

というような流れになります。

従って、評価指標を扱う上では、評価指標それぞれに対して大枠のフローを定義し、それに追加条件を付与する形で集計クエリを操作できると、運用上使いやすくなると考えられます。

エブリーのデータ基盤はLakehouseプラットフォーム3を採用しており、イベントデータのETL処理は一通りSparkSQLで記述してDatabricks4上で実行可能です。 このプラットフォームを活用し、SparkSQL形式で評価指標を登録でき、用途に応じてDatabricksから集計軸などのパラメータを与えてクエリを呼び出せるような、評価指標ライブラリを構築しました。

f:id:sbrf:20211006162526p:plain
評価指標集計の流れ

評価指標ライブラリは

  1. PythonによるSparkSQLクエリの発行
  2. 集計される統計量に応じた評価指標の分類
  3. 分類ごとに使用される統計手法（サンプルサイズ計算・仮説検定など）と可視化方式の管理

の3つの機能を持ちます。

1つ目の「PythonによるSparkSQLクエリの発行」は上で述べたような流れを実現する機能で、登録されている評価指標に必要なパラメータを渡すとSparkSQLクエリが文字列として発行されます。

2つ目の「集計される統計量に応じた評価指標の分類」、 3つ目の「分類ごとに使用される統計手法（サンプルサイズ計算・仮説検定など）と可視化方式の管理」は、登録される評価指標をユースケース別に管理するために用意した機能です。 例えば「アクティブユーザ数」は単純にユーザ数をカウントする評価指標ですが、「1人あたりの検索回数」の場合は検索が実行された回数をユーザごとに集計した値の平均値が統計量となります。 集計される統計量が変わると統計処理や可視化の方式も変わるため、これらを対応づけた状態で整理しておくと、他のチームメンバーも統一した形で評価指標を発行・利用できます。

以上のような評価指標ライブラリを活用し、A/Bテスト基盤では評価指標を集約的に管理された状態で運用しています。

他の施策の影響を取り除くランダムなコントロール群・テスト群の割り当て方式の整備

前述のように、A/Bテストではランダムなグループ選定によって同質なコントロール群・テスト群を用意する必要があります。 また、介入による変化で思わぬ悪影響が発生した場合にその影響を最小限に留めるため、割り当てグループは必要十分なユーザ規模であることが望ましいです。

これらを実現するため、新しいABテスト基盤では

  1. サンプルサイズ計算
  2. ランダムサンプリング
  3. A/Aテスト

の3段階による割り当てプロセスを構築しました。

本記事では、特に2つ目の「ランダムサンプリング」について紹介します。

ランダムサンプリング

ランダムサンプリングでは、計算されたサンプルサイズを元にユーザをランダムに選定し、コントロール群とテスト群を用意します。

ここで注意すべきは、「同時期に実施されているA/Bテスト」と「過去に実施されたA/Bテスト」の両方の影響を受けないようなグループでなければならない、という点です。

これを満たすような割り当て方式として、今年の3月にSpotifyのテックブログで紹介されていたBucket Reuse方式が目に留まり、エブリーでも実現可能だと判断できたため採用してみました。 ここでは大まかな方針を紹介に留めるため、詳細はSpotifyのテックブログをご覧ください。

engineering.atspotify.com

Bucket Reuseでは、何人かのユーザがランダムに所属するバケットというグループ単位を定義します。 ユーザの所属バケットは、アプリのユーザIDをハッシュ化し10進数に変換したものを、バケットの総数Nで割った余りによって算出され、サンプリングもバケットを最小単位として行います。 例えば、バケットあたりのユーザ数が7人だった場合、サンプルサイズ40人のA/Bテストでは6バケット（42人）をサンプリングします。

ここまではユーザID末尾をより拡張したグルーピングと考えられますが、Bucket Reuseの肝はA/BテストをNonexclusive experiments（非排他実験）とExclusive Experiments（排他実験）の2種類に分類し、それぞれに応じたサンプリング方式を選択する点にあります。

非排他実験は、割り当てられたユーザ（バケット）が別のA/Bテストにも同時に割り当て可能なA/Bテストで、サンプリングは他の実験を意識せずバケット全体から実施されます。 つまり、非排他実験に割り当てられたユーザは、並行して実施されている他の実験にも同時に属する可能性があります。

f:id:sbrf:20211006162606p:plain
非排他実験サンプリング例

例えば、「バナーのデザインを変更するA/Bテスト」の実施中に、「ボタンのアイコンを変更するA/Bテスト」を非排他実験として開始したいとすると、割り当て対象のユーザは全体からランダムに選ばれるため、すでに実施中の「バナーA/Bテスト」に割り当てられているユーザの一部は、これから開始する「ボタンA/Bテスト」にも割り当てられる、という状況になります。

一見すると、複数の実験に割り当てられたユーザが存在すると、測定される介入効果にバイアスが含まれるように感じます。 しかし、バケットは全体からランダムにサンプリングされているため、コントロール群・テスト群それぞれに他の実験のバケットが混ざる確率は同等になり、結果としてそれぞれの平均の差を測定する上では、他の実験によるバイアスが抑制されるとみなせます（より厳密には、このサンプリング方式の元で、測定された平均の差による推定量はATEの不偏推定量になるとBucket Reuse記事内の論文で証明されています）。

一方排他実験は、互いに割り当てユーザ（バケット）の重複が発生しないようなA/Bテストを指し、同時期に実施されている他の排他実験を除いた上でサンプリングを行います。 つまり、排他実験と非排他実験のバケットは重複する可能性がありますが、排他実験同士は重複がないような割り当てとなります。

f:id:sbrf:20211006162637p:plain
排他実験サンプリング例

排他実験は、検索画面などの介入の影響が大きい配信面でのA/Bテストで特に重要となります。 例えば、「検索画面のレシピの表示方法を変更するA/Bテスト」の実施中に、「検索結果のソートアルゴリズムを変更するA/Bテスト」を開始したいとします。 これらは検索体験に強く関わる介入であるため、同時に両方の介入を受けたユーザは検索体験が大きく変化してしまうおそれがあります。 従って、この2つのA/Bテストは排他実験に分類し、ユーザは多くともいずれか一方にしか割り当てられないように設定するのが望ましい状態となります。

非排他実験とは異なり、排他実験のサンプリング方式の元で算出された介入効果（平均の差）は、過去に実施された排他実験によって均質にサンプリングされず、バイアスが生じます。 しかしながら、前回の割り当てから十分な空白期間（必要な期間の計算方法も論文中で記載されています）があれば、そのバイアスは緩和可能であると示されており、運用上の工夫で対処可能であると考えられます。

以上紹介したようなBucket Reuse方式による割り当てによって、「同時期に実施されているA/Bテスト」と「過去に実施されたA/Bテスト」による影響の少ない効果測定が可能になりました。

統計的手法に基づく考察と意思決定が可能なダッシュボードの作成

A/Bテストでは、ユーザの確率的な行動によりコントロール群とテスト群との間に多かれ少なかれ差分が出るため、施策の影響が全く無かったとしても差分がゼロになるのは極めて稀です。 このような結果の解釈では、適切な意思決定へ繋げるために「得られている差分が本当に意味のある差分なのか」を慎重に吟味する必要があります。

新しいA/Bテスト基盤では、適切な解釈プロセスを統一化された形で実現するため、統計的仮説検定などの検証手法を組み込んだダッシュボードをRedashで提供し、結果のレポーティングを実施しています。

ダッシュボードでは

  • コントロール群・テスト群それぞれのサンプルサイズと結果
  • 差分の統計的仮説検定と有意な結果のハイライト
  • 差分の信頼区間

を表形式で可視化しています。

f:id:sbrf:20211006162659p:plain
ダッシュボード例

可視化処理は、直接Redash上で記述すると管理が難しくなるため、社内向けのPythonライブラリにまとめてRedashサーバにデプロイしておき、Pythonデータソースからimportして使用できるようにしました。

実際の運用では、このダッシュボードを使いながら、運営チームとA/Bテストの結果を確認しつつ「事前に設定していた見込みの効果量と比較して意味ある差分が得られているか」「なぜこのような結果になったのか」といった部分を中心に議論を行っています。

現状と今後の展望

本記事では、新しく導入したA/Bテスト基盤の概観を紹介させていただきました。

導入にあたっては、所属するデータチームのメンバーをはじめ、バックエンド開発チームやクライアント開発チーム、プロダクトマネジャーの方々に多々ご協力をいただきました。

はじめに述べたように、これまでは

  • ユーザグループの選び方
  • 評価指標設定と結果の解釈プロセス

といった課題がありましたが、今回の取り組みを通して

  • Bucket Reuse方式による他の施策の影響が抑制されるユーザ選定
  • 評価指標ライブラリによる評価指標の管理と統計的手法を組み込んだダッシュボードを用いた結果の考察

が実現でき、以上の課題は一定以上解消できたと思います。

もちろん、A/Bテスト基盤としてはこれで完成ではなく、より信頼性・安全性の高いA/Bテストが絶え間なく実行可能なRun, Flyフェーズに向けて継続的に改善を続けていきたいと考えています。

お読みいただき、ありがとうございました。

参考文献

最後に、A/Bテスト基盤を作成する上で参考になった書籍・記事をいくつか紹介したいと思います。

  • Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing5
    • A/Bテストを通じたサービス改善の文化から具体的な方法までが一通りまとめられている書籍です。 Experimentation Maturity Modelsなども紹介されており、A/Bテスト基盤の構想はこの本を足掛かりとして進めました。 最近は邦訳版も出版されています。
  • Spotify's New Experimentation Platform (Part 1, Part 2)
    • SpotifyがA/Bテストをどのように運用しているかが紹介されています。評価指標ライブラリの設計やダッシュボードの設計で参考になりました。
  • Spotify's New Experimentation Coordination Strategy
    • 同じくSpotifyの記事で、ユーザ割り当てのBucket Reuseが紹介されています。
  • Reimagining Experimentation Analysis at Netflix
    • NetflixのA/Bテスト分析基盤について紹介されており、評価指標ライブラリの設計で参考になりました。
  • サンプルサイズの決め方6
    • サンプルサイズの計算方法について、基礎的な部分から体系的にまとめられており、勉強のための良い参考書でした。
  • 効果検証入門7
    • A/Bテスト (RCT) とは何か、A/Bテストが実施できない状況ではどのような分析があるのか、などが具体例を通じて紹介されており、実際に施策を進めていく中で活用しやすい書籍だと思います。

  1. https://redash.io/↩

  2. Aleksander Fabijan, et al. 2017. The Evolution of Continuous Experimentation in Software Product Development. In ICSE.↩

  3. Michael Armbrust, et al. 2021. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. In CIDR.↩

  4. https://databricks.com/jp/↩

  5. Ron Kohavi et al. 2020. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press.↩

  6. 永田 靖. 2003. サンプルサイズの決め方. 朝倉書店.↩

  7. 安井 翔太，株式会社ホクソエム. 2020. 効果検証入門〜正しい比較のための因果推論／計量経済学の基礎. 技術評論社.↩