![見出し画像](https://assets.st-note.com/production/uploads/images/147017264/rectangle_large_type_2_114d59c404d42dc78e07d0cc45033c00.png?width=1200)
noteのA/Bテストによる改善サイクル(2024年版)
noteエンジニアの橘です。
2024年4月からUX改善を行うチームの一員として、主にA/Bテストを担当しています。読み手側のユーザーのUXを改善してクリエイターの売上を伸ばすことに注力しています。
noteのA/Bテストの基本的な流れは、上記の記事に記載されています。
上記の記事から半年以上が経っているため、この記事ではより詳細な現在のnoteのA/Bテストの取り組みを解説していきます。
A/Bテストの事例
![](https://assets.st-note.com/img/1720756284780-5HF1faDGU6.png?width=1200)
まず始めに、A/Bテストのわかりやすい例を一つ紹介します。
上記はクリエイターページで表示されているメンバーシップの記事一覧です。当時の仕様として、「クリエイターの記事一覧にもメンバーシップの特典記事が表示されるため、同じ記事が重複して画面に表示されることがある」という事象があります。
上記は想定していた動作なのでバグではありません。しかし、「同じ記事が何度も出てくるよりも、ユニークなコンテンツに少しでも多く触れられた方が記事のクリック率や購入率が上がるのでは?」という仮説がありました。
![](https://assets.st-note.com/img/1720756300922-Ko2kmarUc8.png?width=1200)
![](https://assets.st-note.com/img/1720756311866-dKWz12skyt.png?width=1200)
仮説を検証するために、まずはスマホの表示のみ変更してA/Bテストを行うようにしました。
今まで重複していたメンバーシップの特典記事を削除して、代わりにメンバーシップの概要を表示することで視認性が上がり、読者が求めているコンテンツを見つけやすくなりました。テストの結果としても、記事単体の購入率とメンバーシップの加入率の両方が上がりました。
また、サムネイル下に表示されている「1マガジン 12記事 39掲示板 が読み放題」という説明文を表示した方が、メンバーシップへの加入率が高くなるということもA/Bテストで実証されました。
説明文を変えるだけでも、売上が大きく変わる例はたくさんあります。ですので、インパクトの大きいページを改善するときは、小さな箇所から慎重に行うようにしています。
こういった仮説と検証を繰り返すことで、我々のチームは少しずつ成果を出しています。
A/Bテストの結果をどう判断しているのか?
A/Bテストの判断基準は、社内のMLチームが提供しているツールを使用しています。A/Bテストを行った際の変化量を、統計的に意味があるかどうかを判定しています。
クリック数などを統計的に判断して、予測の範囲内に収まっているかどうかを検知してくれるような仕組みです。異常値などの問題があるときにすぐにわかるようになっています。
ただし、ツールはあくまで参考値であり、最終的にはデータ分析やUX的な観点も含め、総合的に判断して公開するかどうかを決めています。
2024年上期のA/Bテスト改善
GrowthBookの導入
直近で一番大きい改善で言えば、GrowthBookを導入したことです。noteでは主に社内製のテストツールを使ってA/Bテストを実行していました。
しかし、コードを書いてデプロイしなければテストが実行できないため、工数がかなりかかっています。
そこで、UIからA/Bテストが実行できるようにGrowthBookを導入しました。まだまだ導入したばかりですが、A/Bテストを行うのが楽になりそうです。エンジニアだけではなく、デザイナーやPdMがA/Bテストを実施することができるようになりました。
GrowthBookについては上記の記事で解説をしています。ぜひあわせてご覧ください。
定期リリースへのMagicPod追加
アプリはMagicPodを利用してテストを行っています。しかし、アプリとWebではリリースサイクルが異なっており、WebのリリースでMagicPodのE2Eテストが実施されていませんでした。
noteではアプリ上でWebViewを用いたWebページの表示を行なっており、Webのリリースの影響をアプリも受けます。A/Bテスト起因のWebのリリースによりアプリでエラーが発生するも、事前にエラーを検知できず、本番環境で障害が起きてしまう課題がありました。
この課題に対処するため、Webブラウザ向けのリリースサイクルに合わせてMagicPodのE2Eテストを実施するよう運用の改善を実施しました。また、MagicPodのテスト時にE2Eテストであることをサーバーに伝えるためのフラグをリクエストヘッダーへ追加しました。
これにより、サーバーサイドではMagicPodのテストであることを認識し、E2Eテストを通しつつもできるだけ変更されたAPIを通るルートをE2Eテストに行わせるといった細かな調整を行えるようになりました。
MagicPodを定期リリースに組み込むことができ、A/Bテストもより安定して実行することができるようになりました。
今後の課題
小さい改善を進めるときに、期間中のサンプル数が少ないテストでは、テスト結果が検証に至らないケースがあります。そういうときに、サンプル数を満たすために想定以上に長い期間データを取ることもあります。個人的な課題として、少ないサンプル数でもUXの良し悪しを正確に判断できる指標がないかを模索しています。
また、A/Bテストの精度をさらに上げていきたいとも思っています。適切な指標の選定や実験計画の部分をブラッシュアップしていくことで、よりインパクトのある施策を打っていけるようにしたいと思っています。
実験と学習のサイクルをしっかり回していき、事業成長に貢献できるような取り組みにしていければと考えております。
※ この記事はエンジニアへのインタビュー内容をライターが再編しました
▼技術記事がもっと読みたい方はこちら