エンジニアのすのうちです。

私の所属するチームでは、「ユーザーが興味のある記事に出会い、良い購入体験をできるようにする」ことを目的としています。

この目的の達成に向けて、A/Bテストを用いた仮説と検証を行いました。結果として、1年間で28回のABテストを実施し、13個の機能や改善のリリースを行いました。

この記事では、私のチームで注力した画面とA/Bテストの結果について説明し、そこで得た6つの学びについて共有したいと思います。

※ この記事はnote株式会社 Advent Calendar 2024の6日目の記事です。

実際にリリースした機能

「ユーザーが興味のある記事に出会い、良い購入体験をできるようにする」という目的を、①認知、②納得度（信頼）を上げる、③行動しやすくする、という3つに分解しました。

リリースした機能例1: メンバーシップの見え方の変更

クリエイターページに表示される記事について、同じ記事が何度も表示されることや表示順が固定されている課題がありました。より多くの記事を認知できるよう、記事以外の表示を改善したり表示順を選べるようにしました。

素晴らしい作品があっても、見つけづらければユーザーの目に留まることはありません。良質なコンテンツを認知できるための工夫が求められます。

リリースした機能例2: 高評価した人を表示するように

しかし、ただ認知度を上げれば良いというわけではありません。

購入を促進するためには記事の納得度（信頼感）を高める必要もあります。上記の例のように、多くの人に読まれ、評価されている記事だということを理解してもらい、信頼してもらうことが重要です。

リリースした機能例3: 「買われています」「返金可」を表示

また、機能を拡充していき、どんな人でも簡単に購入できるようにするなどの整備をしていくことも大切です。

単に購入を促すためだけに開発をするのではなく、①〜③のような購入に関わるすべての機能や流れを考慮し、ユーザーの行動を促せる施策を検討してきました。

A/Bテストの結果

ではここから、1年間で28回実施したA/Bテストの結果を紹介します。

まず、パターン数について平均は3つでした。最小はcontrolとtreatmentのみの2パターン、最大はtreatmentが4つの5パターンです。パターンは、ABテストを通して効果を計測したいものに絞りつつ、同義なものを除外することを意識していました。

ABテストを実施した施策のうち約5割の改善と機能をリリースすることができました。実データと他社事例に基づき仮説を立てたことで出た結果だと思います。

上記グラフの「保留」は、ABテストの結果を考察し、改めてパターンを用意し新しいA/Bテストを実施したもので、全体の約3割を占めています。仮説検証のサイクルを終了させた「棄却」は2割ほどでした。2割の棄却のABテストは無駄ではなく、しっかりと考察することで見えていなかったユーザーの行動に気づいたり、現状の機能が優秀だと判断するきっかけになります。

いずれの結果であっても、ABテストには実施するだけの価値があると考えています。

A/Bテストを通じた6つの学び

学び1：変数の制御

学びの1つ目は、変数の制御です。A/Bテストにおける変数とは、controlとtreatmentの間で変更した要素を指します。

例えば、スマートフォンのWebブラウザで表示される「追従フッター」を変更するA/Bテストでは、「デザイン変更」、「数字の追加」、「アイコンの変更」という3つの変数が存在します。そのときに、controlとtreatmentの2パターンしか用意しないと、それぞれの変数の効果が見えなくなります。

変数の効果を測定するためにも、各変数をtreatment_aやtreatment_bといったtreatment内のパターンに分けて1つずつテストし、結果を明確にすることが重要です。

学び2：「認知」と「noteらしさ」

2つ目の学びは、noteらしさについてです。認知とらしさは、反発しやすい傾向にありますが、noteにおいては重要な点です。

既存の機能に少し手を加えて認知を高めて、CTRや購入率に影響を生じさせることは簡単にできます。しかし、その一方でサービスらしさをないがしろにしている可能性もあるのです。

実際に、noteでも他社サービスの事例にならって、「n件が購入されました」などの文言にすることも検討しました。しかし、すべてのクリエイターが商業目的でnoteで創作をしているわけではないということに気づきました。らしさを失わないようにするため、デザイナーチームに協力いただき、最終的には「買われています」という文言でリリースしました。

らしさと認知のバランスは大事にするべきだという学びでした。

学び3：ログの不足

3つ目の学びは、ログ情報が不足しがちだという点です。ImpやClickのログは十分に実装しているつもりでも、漏れが生じたり不要なログまで計測してしまうことがあります。過去には急いで修正し、ログを追加実装したこともありました。実装段階で、ログが十分かどうかを常に確認する視点が必要でした。

学び4：利用ユーザーが少ないと、A/Bテストの期間が長くなる

4つ目は、A/Bテストの期間の長さについてです。テストの実施期間が長くなりやすいケースがあります。

期間が長くなる理由の一つは、データが十分に集まらない場合があるためです。利用頻度の低い機能を改善しようとすると、A/Bテストであまりユーザーが集まらないため、結果的にテスト期間を延長する必要があります。

上記のような場合は、そもそも抜本的に変更をして、機能全体を見直しすることも検討するべきなのかもしれません。

学び5：ユーザーの声に耳を傾けて、制度を高める

5つ目の学びは、ユーザーに耳を傾けて精度を高めることの重要性です。

多様性を大切にするnoteでは、私たちの予想を超えてnoteをうまく活用しているユーザーが数多くいます。我々が考えた機能が、特定のユーザーにはまったく受け入れられないこともあります。

そのため、ユーザー体験が悪化すると判断した場合、テストを直ちに停止し、迅速に修正して再開することもありました。

テスト中であっても、お問い合わせにきたユーザーからの意見を大事にすることが、A/Bテストの精度を高めるのに有効です。どのユーザーにとっても使いやすくするため、耳を傾ける姿勢を大事にしています。

学び6：カテゴリによって集計方法を変更する

最後の学びは、カテゴリによって集計方法を変える必要がある点です。

例えば、時流や速報性が重要な記事をテスト対象に包括すると、普遍的な内容の記事とはまったく異なる結果が得られることがあります。

特定のカテゴリの影響力次第では、結果がぶれてしまい、効果が不明瞭になります。そのため、カテゴリごとに計測するといった、サービス内の特徴を理解したA/Bテストが必要です。

まとめ

これからもA/Bテストでサイクルを回しながら、目標に向かって機能改善をしていく予定です。

A/Bテストから学べることは数多くあります。社内でA/Bテストを学びたい人がいるときには、チームの枠を超えて普及していけるようにしたいと思っています。

▼アドベントカレンダーはこちら

▼noteの技術記事がもっと読みたい方はこちら

※ この記事は社内での登壇内容を再編集した内容です