はじめに

ABEMAデータテクノロジーズの梅田と作花、秋葉原ラボの和田です。 今回は、ABEMAにおける全社的なA/Bテスト運用への取り組みについて紹介していきます。

A/Bテストとは?

A/B テストとは、同じウェブページについて複数のパターン(A と B)を用意し、それらをランダムに表示して成果を調べるテストのことです。 Google オプティマイズ 公式ドキュメント

弊社の例でいうと、「アプリUIの変更」「コンテンツのレコメンドロジックの変更」「キャンペーンの実施」などが行われた際にA/Bテストを実施し、施策の是非を判断します。

関連記事を以下に記載します。
参考) 「AbemaTV」のデザインは「A/Bテスト」にどう向き合うか?

取り組みの背景と目的

従来の社内で実施されるA/Bテストにおいて、下記の課題がありました。

  1. A/Bテストの結果が見やすい形でまとまっておらず、組織としてナレッジが蓄積できていない
  2. 分析者によって検証方法にばらつきがあり、レポートの品質が担保できていない
  3. 検証のたびに分析者がアサインされ、スケールしにくい構造になっている

一つ目は、過去のA/Bテストの結果ドキュメントが社内各所に散らばっており、関係者以外のメンバーが把握できてない状態になっていました。この状態では、ナレッジ共有が十分になされず、別のチームが過去に行った施策の類似施策を再度実行してしまうなどのリスクがあります。

二つ目は、検証方法やレポート内容、作成したクエリがアサインされた分析者によって属人化してしまっていたことが原因でした。過去に行われたA/Bテストに関する情報がまとまっていれば、本来であれば共有できる情報やクエリや検証コードの資産も共有できていない状態でした。

三つ目は、検証のたびに分析者の作業工数がかかりすぎることが原因でした。具体的には、施策関係者とのコミュニケーションコストやクエリとレポートの作成コストが検証ごとにかかるといったものです。これらの作業工数の削減が求められました。

 

上記の課題を踏まえて、理想状態を以下のように定義しました。

全社的にA/Bテストが適切な手法で実施され,データで意思決定がなされる状態

  1. 過去,現在,未来の全てのA/Bテストの概要・結果が誰でも把握できる状態
  2. 分析者に依存せず、適切な方法でA/Bテストが実施されている状態
  3. 分析者の作業工数が削減され,施策実行者が分析者と並走してテストを実行できる状態

これらを実現するために、実施フローの設計を行いました。

ABEMAのA/Bテスト実施フレームワーク紹介

ワークフロー詳細

実施ワークフローは下記になります。

図1. A/Bテスト実施ワークフロー

各課題に対する対策

上記ワークフローを前提として、各課題に対する対策を説明していきます。 以降で出てくる施策実行者分析者は、依頼チームに施策実行者、ABEMAデータテクノロジーズに分析者が所属しているものとします。

A/Bテスト全体俯瞰図

A/Bテストの結果を見やすい形まとめるために、A/Bテスト全体俯瞰図を作成しました。

Googleフォームに入力された情報が一つのスプレッドシートに貯まっていきます。 このスプレッドシートの情報をTableauを用いて可視化することで、「1. 過去,現在,未来の全てのA/Bテストの概要・結果が誰でも把握できる状態 」を実現させました。

図2. 実際のTableauダッシュボード

図のように、ガントチャートの形式でA/Bテストの実施状況を可視化しています。それぞれのテストの現状ステータスを表示させ、カーソルを合わせるとテストの詳細情報が表示される仕組みになっています。 また、検証結果の出ているテストのオブジェクトに、結果レポートの外部リンクを紐付けておくことにより、オブジェクトをクリックすると結果に即時アクセスできるように作成しました。

レポートの標準化(ベイジアンA/Bテスト)

検証方法としては、ベイジアンA/Bテストを採用しました。 A/Bテストといえば、カイ二乗検定のような頻度主義の手法をイメージする方も多いと思いますが、以下の理由でベイジアンA/Bテストを採用しました。

  1. 検証ごとのサンプルサイズの計算が必要ない
  2. 途中経過を出力できる
  3. 結果が解釈しやすい

1に関して、検証依頼者とのコミュニケーションの中で「サンプルサイズはどれくらい必要ですか?」という質問がかなりの頻度でされます。

頻度主義の仮説検定では、

  • 有意水準
  • 検出力
  • 効果量

から事前にサンプルサイズの計算を行わなければなりません。 しかし、ベイジアンABテストではこういったサンプルサイズの計算の明確な方法がないため、事前にシミュレーションした時に結果の安定したサンプルサイズを案内することによって対応しました。

2に関して、頻度主義の仮説検定では必要サンプルサイズを満たすまで、結果を出すことが厳密にはできません。しかしベイジアンA/Bテストであれば、事前分布のパラメタを更新していくことにより、途中経過を出力することができます。「途中経過を知りたい!!」という現場のニーズに応えることができます。

3に関して、ベイジアンA/Bテストの結果は、事後分布や相対効果値が出力できるため視覚的にわかりやすいというメリットがあります。ビジネス職の方向けに分析結果を説明する場面では特に有効です。

図3. 実際のレポート

Cloud Composerで運用

Cloud Composerでレポーティング作業を自動化することで、分析者の作業工数を削減することができました。

このレポーティングシステムは、

  • 依頼フォームの内容をBigQueryに取り込む
  • レポーティングに必要な検証パラメータを抽出する
  • レポートを作成とSlackの特定チャンネルにデイリーで共有する

という一連の工程を自動化しています。

実際のワークフローは下記の全5つのタスクで構成されるDAGで定義されています。

図4. ワークフローを表現したDAG

実装方法の詳細は、下記の記事を参照ください。
参考) ABEMAデータテクノロジーズにおけるCloud Composerを活用した機械学習のワークフロー管理

おわりに

今回は、ABEMAにおけるA/Bテスト運用への取り組みについて紹介してきました。 A/Bテストは、会社の意思決定において有益な示唆を与えてくれます。

私がA/Bテストをする前に施策実行者にしている問いが2つあります。

  • その数字でどう意思決定するのですか?
  • その施策でユーザ体験はどう変わるのですか?

こういった問いを投げかけることで、A/Bテストがただの仮説検証方法にとどまらない、プロダクトの未来を考える一つの契機になるのではないかと考えております。

今後もABEMAにおけるデータ活用の事例を紹介していきたいと思いますので、ABEMAデータテクノロジーズをよろしくお願いします。