noteのA/Bテスト

🎄この記事は note株式会社 Advent Calendar 2023 の19日目の記事です🎄

はじめに

noteではプロダクトの改善にA/Bテストを実施することで、施策の効果を客観的に評価しユーザー体験も含めて最適な選択をとれるようにしています。
この記事ではnoteで実施しているA/Bテストの全体的な流れと工夫していることを書いていきます。

A/Bテストの流れ

A/Bテストは大きく以下の流れで実施しています。

1. 施策の効果検証方法を決める

2. A/Bテスト設計

3. A/Aテストの実施

4. A/Bテストの実施・効果検証

施策の効果検証方法を決める

noteでは毎日さまざまな施策が動いています。施策の種類もさまざまなので、最適な効果検証方法も違います。
簡単なUIアップデートであればリリース後に目指した指標があがっているか時系列で確認するだけで問題ないです。

その中で、A/Bテストを効果検証に使うのは主に2つの狙いがあります

• 変更箇所が重要なため、一部のユーザーのみで実験することでリスクを減らす

• 施策の効果が本当に真なのか統計的に検証する

私が所属しているチームでは変更箇所がプロダクトにとって重要なポイントであることが多く、A/Bテストを採用しています。

A/Bテスト設計

施策の内容によってターゲットユーザーやデバイスを指定していたりするケースがあるので事前に条件を一覧化してログ実装時に漏れがないようにしています。

よくある条件は以下です。

• 対象記事のカテゴリ

• ログインユーザー or 非ログインユーザー

• アプリ or Web、デバイスサイズ

また施策の内容によっては目標指標はあがりそうだが、他の指標（反指標）が下がってしまう可能性があります。
反指標はプロダクトの体験を損なったうことが多く、事前に察知することが重要なので洗い出すようにしています。

A/Bテスト設計についてはメルカリさんの事例を参考にしています。

A/Aテストの実施

A/Aテストはプロダクトの動作は変えずにログの変更を先に実施することで問題なくA/Bテストを実施できるか確認するテストのことです。

私のチームではA/Aテストを実施することで主に3つ確認しています。

• ログの出力箇所に不足がないか

  • 集計時にログ不足が発覚するとA/Bテストやり直しになる

• A/Bテストのグループに含まれるユーザー数が均等になっているか

• A/Bテストの実施期間の見積もり

noteではA/Bテストの分析時に有意水準を決めて統計的に有意差があるか確認しています。
有意差の有無はログ量とA/Bテスト間で発生した差に依存しているので、対象の画面でどれくらいのログが出てるかを得るためにA/Aテストを実施しています。

A/Bテストの実施・効果検証

A/Aテストで問題なければA/Bテスト用の変更を実装し、リリース・効果検証を実施しています。

A/Bテストの効果検証では統計的仮説検定を実施し、有意差の有無を出してからチームで実験結果の考察を議論しています。
数値上の変化のみ確認するだけではなく、チームでなぜあがったのか or 下がったのかを深掘ることで新しい仮説を発見できます。この仮説が次の施策につながるので一番大事です。

工夫していること

統計的仮説検定の自動化

A/Aテストで実験期間を見積もったり、A/Bテストの有意差判定は統計的な知識が必要になります。
noteではMLチームに作成してもらったA/Bテストツールを使うことで、ログをCSVに出力すれば自動的に検定できます。
中でどう計算しているか把握することは大事ですが、統計の知識が豊富でなくとも数値を出せるのはとてもありがたいです。

A/BテストのTipsドキュメント作成

エンジニアメンバーのなかでも人によってはA/Bテストを実装したことがなかったり、noteのA/Bテストに使ってる技術を触ったことがないケースがあります。

そこでだれでも同じ実験ができるようにチーム向けのドキュメントを作成しました。
今回かいてるA/Bテストの流れに加えて、用語の定義やしくじりポイントをためておくことでスムーズにA/Bテストできるようにしています。

分析クエリのテンプレート化

分析用のクエリは実装したエンジニアが書くことが多いです。施策によっては指標が多くなってクエリ作成コストが増えたり、エンジニアによってクエリの定義が変わってしまう課題がありました。
そこでクエリテンプレートを作成してコピーすれば同じ定義の分析をできるようにしています。

今後はテンプレートから自動的にA/Bテスト結果がでるくらいまで自動化を促進して分析コストを下げられるようにしたいです。

解決したい課題

A/Bテストの実装時に実験グループ数に応じて検証コストが大きくなってしまっています。実験グループの変更にデプロイが伴ってしまうので、既存UI含めて多いと5パターンの検証が必要です。
この課題を解決するためにFeature Flagサービスを利用してデプロイせずに実験グループ設定を変更できるようにすることを検討しています。

▼noteエンジニアアドベントカレンダーはこちら

note株式会社のカレンダー | Advent Calendar 2023 - Qiita