Gunosyデータ分析ブログ

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

Gunosy MLチームでのABテストの設計と運用

こんにちは、Gunosy Tech LabのMLチームでマネージャーをしている id:skozawa です。 今日はMLチームで取り組んでいるABテストの設計と運用について紹介したいと思います。

MLチームはプロダクト横断のチームです。メンバーはグノシー、ニュースパス、LUCRAなどのプロダクトチームにも属しながら、開発を進めています。 ABテストについては以前も少し書いたことがあり、基本方針は同じなのですが、横断チーム、ロジック開発だからこそある難しさもあり、そのあたりで少し工夫していることなどを書きたいと思います。

tech.gunosy.io

ABテストの設計について

ABテスト開始のために、タスク、KPI、拡大判断基準の設計をするようにしています。

タスク設計

仮説を立て、タスクのゴールを設定します。 ここでは、controlとtreatmentの差分を明確にすることと、controlとtreatmentの差分は1点のみにすることに注意します。 特に、システム変更とロジック変更を同時に行わないようにします。

ABテストが想定した結果にならなかったときに、どこに問題があるかの切り分けをしやすくするためです。 ABテストは必ずしもスムーズにいくとは限りません(というかうまくいかないことの方が多いです)。 特にロジック開発の場合、UI変更のような目に見える変化がないため、一見するとうまく動いているように見えてしまいますし、パーソナライズロジックの場合、ユーザによって表示される結果が異なるため、よりデバッグが困難となります。 controlとtreatmentの変更点が大きくなればなるほど、切り分けが難しくなり結果としてABテストの期間が長引いてしまいます。 そのため、controlとtreatmentの差分を極力1点にするようにしています。

KPI、拡大判断基準の設計

ABテストでみるKPIの設計と、拡大判断基準を設計します。

Gunosyでは主に、1%からABテストを開始し、バグがないことを確認してから10%、50%、100%と割合を拡大していきます(ユーザ、売り上げ影響が大きい場合は、もう少し刻んだりもします)。 この割合を拡大するときに、どのKPIがどのような値になっていたら、拡大してOKと判断するかを予め決めておきます。 予め決めておくことで数値が思ったように変化していないときに、どのタイミングで縮小、停止、要因調査をすべきかが明確になります。

例えば、CTRをKPIとした場合は以下のように、AB拡大の判断時の基準を決めておきます。

割合 判断基準
1% -> 10% バグがなく、正しく動作している
10% -> 50% CTRが5%以上低下していない
50% -> 100% CTRが2%以上向上している

ABテスト開始、拡大の流れ

横断チームで行うABテストを横断チームで管理するのか、プロダクトチームで管理するのかが曖昧になることがあったため、レポートラインを設けることにしました。

ABテスト開始までの流れとしては、

  • [担当者] ABテストのタスク、KPI、拡大判断基準の設計をする
  • [MLマネージャー] 設計レビュー
  • [プロダクトオーナー] 設計レビュー
  • [担当者] AB開始

ABテスト拡大時の流れは、

  • [担当者] ABテストの集計
  • [担当者] 拡大判断基準にしたがって分析
  • [MLマネージャー] 拡大判断レビュー
  • [プロダクトオーナー] 拡大判断レビュー
  • [担当者] AB拡大

という形にしており、基本的にはMLチームでKPIの数値影響を確認した後、プロダクトチームの確認をとって反映する流れとしています。

AB集計について

主要なKPIについては自動で集計されて、毎日Slackのチャンネルに流れるようになっています。 そのため、大きな悪影響がない限り、ABテストを開始してから、ABテストの判断に必要なサンプル数が溜まるまでは、基本的には他のタスクを進めることになります。

ここで少し気をつける点として、他のタスクを進めていると、ついついABの集計・確認が後回しになってしまうことです。 新機能・ロジックの開発などももちろん大切ですが、まだリリースされていない機能の開発より、既にリリースされてユーザに影響を与えている機能の確認のほうが大切だと考えています。 そこで、毎週水曜日をAB集計デーとして設け、ABテストの確認・集計をしてもらうようにしています。

まとめ

MLチームという横断チーム、ロジック開発チームのABテストについて紹介しました。 Gunosyではプロダクトや記事配信ロジックはもちろん、それらを進めるための開発体制、プロジェクト管理などについても日々改善を進めています。ロジック開発、横断チームのプロジェクト管理などに興味ありましたら、ランチなど気軽にお声がけください。