こんにちは。@chaspy です。本記事で紹介するスタディサプリ中学講座の PLG(Product Led Growth) Team の Engineering Manager をしています。
本記事では、2023年2月に結成したこのチームの活動について紹介します。
スタディサプリ中学講座について
スタディサプリ中学講座は、中学生向けのオンライン学習サービスで、2022年2月にフルリニューアルされました。*1
初期リリース後から現在に至るまでエンハンスを続け、プロダクトをブラッシュアップしています。
PLG Team 発足の理由
PLG チームができる前、2022年2月時点でのチーム体制は以下の通りでした。
- Learning Core（学習コア）: 講義を見て、問題を解く、という学習体験*2
- Learning Encourage（学習促進）: ログイン後から学習開始までの体験*3*4
- Growth: アプリを起動してログインするまで*5*6
いわゆる Growth Hack と呼ばれる、獲得やチャーンレートと言った数値を見ながらプロダクトを改善していくということを Growth チームでやりたかったのですが、実態は learning-core, learning-encourage の外側の「その他全て」を担うチームとして機能していました。また、小学1年生リニューアル対応も Growth 開発チームが担ってくれていました。
このような状況において、Growth 施策に集中して行うチームが必要ではないか、という経緯で PLG チームが結成されました。
メンバーは以下各1名ずつで構成されています。
なぜ A/B テストをやるのか
A/B テストとは、AとB、2つのパターンのどちらの方がクリック率やコンバージョン率などのKPIに効果があるかを検証する手法です。A/Bテストでは、ユーザーをランダムにAとBのグループに振り分けて、同時にテストを実施することが多いです。なぜ同時にテストをするのかというと、施策の効果以外の条件を２つのグループでそろえることで、施策の効果を正確に計測するためです。施策リリースの前後で数値を比較したとしても、他の施策との影響や季節・時期性の要因を排除できません。
A/B テストを行う方法
私たちの組織では Feature Toggle 基盤*9を用いて実施しています。User ID を Key とし、A群とB群に 50% ずつ割り振るようにしています。
多くの施策がフロントエンドで flag を取得し、コンポーネントの出し分けを行います。*10
分析を行うために、判定結果をログとしてデータベースに送る必要があります。フロントエンドからは Google Analytics for Firebase にログを送り、分析時は BigQuery 経由でデータを取得しています。
チーム結成直後に A/B テスト基盤の設計と実装を行い、早速最初の施策に取り組むことになりました。
指標設計
何はともあれ、成否判定をする指標を決める必要があります。
当時すでにプロダクトマネージャとデータチームによって KPI ツリーは策定されていました。ツリーの中では以下のような指標がありました。
- 初回課金率: 無料期間後に課金に繋がる比率
- 継続課金率: 現在の有料会員が翌月も課金継続する比率
また、これらに相関がある学習指標として「L10」（エルテン）と呼ぶ指標があります。Lはレッスンを指し、過去30日間にスタディサプリで10レッスン完了すれば達成と判定される指標です。A/Bテストでは、ユーザーがA/Bテストに参加してから30日以内に10レッスンを完了した時点でL10達成として、A/BグループそれぞれのユーザのうちL10を達成したユニークユーザー率をL10率と定義しました。
そして、我々は2つの継続課金率と L10率を指標としてモニタリングすることにしました。L10率ではA/B間で差が出ないこともあり、その場合は施策特有の別の前指標を用いることにしました。
事例紹介
記事公開日の 2024/02/15 現在まで、12個の施策を実施しました。そのうち、10件が採択、全てのユーザに展開され、2件が棄却されました。
事例は以下のテンプレートで記載します。
- 実施期間: yyyy-mm-dd ~ yyyy-mm-dd
- 背景と仮説
- 補足の画像
- 指標
- 結果
事例は長い！学んだことが読みたいぞという方は学んだことにジャンプしてください。
学習ガイドへの導線設置
実施期間
2023-03-08 ~ 2023-04-30
背景と仮説
スタディサプリ登録直後のユーザに対して、私たちは利用方法を伝えきれていないのではという仮説がありました。そこで既存のスタディサプリの活用方法を説明した「学習ガイド」への動線を設置することで課金率・学習指標が向上するかどうかを検証する A/B テストを実施しました。
グローバルナビゲーションに設置するほか、登録してすぐの体験期間中にユーザに対してはトップの目立つ場所に学習ガイドの動線を設置しました。
指標
- 新規登録ユーザの初回課金率および L10率
結果
- 初回課金率に有意差はなし
- バナーのクリック率は高かった
- レッスン数はバナーを表示した群の方が多かったが、有意差はなし
結果、該当期間では有意差を検出できなかったが、ポジティブな影響があったこと、ネガティブな影響が見られなかったことから全展開としました🎉
ホーム画面で定期テストの導線を目立たせる施策
実施期間
2023-03-28 ~ 2023-05-25
背景と仮説
定期テストは中学生ユーザにとって非常に重要なイベントであり、ここで点数を取ることをプロダクトとしても重要視しています。スタディサプリ中学講座では定期テストの期間を入力し、その期間に応じて定期テスト向けの特別なコンテンツをミッションで訴求する機能が存在します。しかし、Web のユーザは Native に対して定期テストの利用率が低いという分析結果がありました。その理由として、定期テストへの導線はグローバルナビゲーションにしか存在しないため、認知されていないのでは、という仮説を検証するために、ホーム画面上部に定期テストへの動線を追加する A/B テストを実施しました。
Before (Native)
Before (Web)
After (Web)
指標
- L10率
- 定期テスト日程入力率
結果
- 定期テストの日程入力率に有意差あり
よって全ユーザに展開しました🎉
ミッション教科選択のデフォルト教科変更
実施期間
2023-04-10 ~ 2023-05-01
背景と仮説
スタディサプリ中学講座では「ミッション」という、ユーザ一人一人の学習状況に合わせてレッスンをリコメンドする機能があります。ユーザ登録直後のオンボーディングで、ミッションで学習するコンテンツを選んでもらうことになっています。しかし、デフォルトは5教科が選択されており、多数のユーザがそのまま進むことで、ミッションの数自体が多くなってしまい、離脱してしまうユーザがいるのではないか、という仮説がありました。そこで、ミッションのデフォルト教科選択を [A]:デフォルト選択なし [B] 英数の2教科 [C] 従来通り5教科選択のA/B/C でテストすることにしました。
指標
- ミッション完了率
- L10率
結果
- ミッション完了率は A のデフォルト選択なしが優位に高い結果となった
- ミッション消化率、レッスン完了数は優位差なし
結果、デフォルト選択なしを全展開することにしました🎉
(webのみ)無料期間中、オンボーディング用のタスクリストを表示する
実施期間
2023-06-29 ~ 2023-08-29
背景と仮説
スタディサプリ中学講座には純粋にレッスンを解く機能の他に「定期テスト日程入力」「まなレポ」「サプモン」というユーザにとって有益な機能があります。これらの機能についてもユーザに認知してもらった方がよりプロダクトの利用率が上がるという仮説がありました。そのためオンボーディング期間後にこれらの機能を使ったかどうかを確認するタスクリストを表示する A/B テストを実施しました。
指標
タスクリストから誘導した各機能への UU
- 定期テスト日程登録
- まなレポ閲覧
- サプモン
結果
まなレポ閲覧率が優位差があったため、タスクリストを全展開することにしました🎉
(web) ホーム画面定期テストパネルUI の位置変更
実施期間
2023-09-22 ~ 2023-10-16
背景と仮説
"ホーム画面で定期テストの導線を目立たせる施策" で行った定期テスト動線追加施策ですが、右側よりも左側の方がより目立つのではないかという仮説を検証しました。
指標
- 課金継続率
- L10率
- 定期テスト日程入力率
結果
- 定期テスト日程入力率に有意差があったため、全展開することにしました🎉
レッスン名から該当のレッスンに遷移できるようにさせたい
実施期間
2023-09-19 ~ 2023-11-07
背景と仮説
過去の学習記録が閲覧できる「まなレポ」機能があります。このまなレポは過去に解いた問題の正答率が表示されます。その機能に対し、正答率の低いレッスンを解き直せるように動線を表示してほしいというユーザ要望がありました。この仮説を検証するため、A/B テストを実施しました。
指標
- 課金継続率
- L10率
結果
課金継続率、L10率 ともに有意差は見られませんでした。しかし、特定ユーザの UX を改善できている・また、ネガティブな影響はなかったことから全展開することにしました。
(web)まなレポ導線改善
実施期間
2023-11-08 ~ 2023-11-16
背景と仮説
過去の学習記録が閲覧できる「まなレポ」機能があります。ユーザは過去の学習記録を振り返って、モチベーションに繋げてもらったり、保護者と振り返るのに使ってもらっている機能です。このまなレポへの動線がグローバルナビゲーションにしかないため、閲覧率を高めるためにトップからの動線を追加する A/B テストを実施しました。
指標
- 課金継続率
- L10率
- まなレポへの遷移率・利用率
結果
課金継続率、L10率 ともに有意差は見られませんでした。しかし、まなレポへの遷移率・利用率に有意差が見られたため、全ユーザに展開しました🎉
また、この施策はインターン生の大石さん @umaidashi が開発してくれました。この場を借りてお礼申し上げます。ありがとうございました！
定期テスト対策講座、TOPICの見せ方改善
実施期間
2023-10-06 ~ 2023-11-09
背景と仮説
定期テスト対策講座はスタディサプリを利用するユーザにとって、効率的に定期テスト対策ができる有益なコンテンツです。「まずはこれだけ！厳選予想問題」「さらに応用！厳選予想問題（トップレベル）」「つまづいたら 復習動画」という3つのトピックで構成されています。これらの講座はスタディサプリとしてユーザに訴求したい特別なコンテンツであり、それが UI 上訴求できておらず、ユーザから見つけてもらえていないのではないかという仮説がありました。そこで、ラベルを用いて講座を目立たせることによって、これらのコンテンツの消化率が向上し、結果学習結果につながるのではないか、という仮説を検証することにしました。
指標
期間中1度でも「厳選予想」「応用問題」ラベルを見た日から計測した L10率
結果
学習指標である L10率 については A/B で差分は生じませんでした。しかし、プラスもマイナスの影響もないこと、今後異なる目的のラベルでの実装を行う際に活用できることから、採用することになりました。
「ノートに解く問題」ラベルをレッスンにつけたい
実施期間
2023-12-04 ~ 2023-12-25
背景と仮説
スタディサプリ中学講座では、オンラインのみで回答できる問題ではなく、実際にノートに書き取るタイプの問題も存在します。しかし、その問題タイプであることが実際に問題に取り組むまでわからないため、ユーザがノートを用意していない場合、問題に取り組むことができない課題がありました。そこで、ノートに解く問題であることを事前にユーザに伝えるために、レッスンに「ノートに解く問題」がわかるラベルをつけることにしました。
選択肢として、(A)現状のまま、(B)「ノートに解く問題」という文字ラベル、(C)アイコンを表示のA/B/C テストを実施しました。
- (B)「ノートに解く問題」という文字ラベル
- (C)アイコンを表示
指標
- L10率
- ノートに解く問題の完了率
結果
B「ノートに解く問題という文字ラベル」がノートに解く問題の完了率に有意差があったため、全展開することにしました🎉
また、この施策もインターン生の大石さん @umaidashi が開発してくれました！
ホーム画面に「今月のレッスン数」を表示する
実施期間
2023-12-18 ~ 2024-01-25
背景と仮説
ユーザにとって今月どれぐらいレッスンを解いたかは「まなレポ」というページに遷移しないとわからない状況でした。これをユーザにもより簡単に認知してもらい、目標を持ってもらうために、今月のレッスン数をトップページに表示することにしました。これは内部で利用している L10 率という指標であり、これが改善するのではないか、という仮説がありました。
アニメーションでお花が咲きます。とっても可愛いです。
指標
- L10率
結果
残念ながら有意差は見られませんでした。既存 UI の方が情報量が多いため、この案を棄却することにしました。しかし、有意差が見られないことがわかったことは私たちにとって大きな価値です。この結果を分析し、今後より良い施策を考えていければと思います。
この案件も Backend 部分はインターン生の @umaidashi が開発してくれてました。
スタディサプリ活用動画の視聴をタスクリストに追加したい
実施期間
2023-12-25 ~ 2024-02-01
背景と仮説
登録直後、スタディサプリの機能を理解しているユーザは多くないため、活用方法を学んでもらうためにオンラインで受講できる「スタディサプリ100%活用説明会」というコンテンツがあります。これを「無料期間中、オンボーディング用のタスクリストを表示する」という施策で作ったタスクリストにタスクとして追加し、L10率と、タスクリストから誘導した機能の利用率を検証しました。
指標
- L10率
- LP閲覧率（タスクリスト以外の導線も含む）
- サプモン率（タスクリスト経由のみ）
- 定期テスト日程入力率（タスクリスト以外の導線も含む）
- まなレポ閲覧率（タスクリスト以外の導線も含む）
- タスクリスト全完了率
結果
残念ながら LP への閲覧率に有意差がなく、かつタスクの全完了率とサプモン率にはネガティブに有意差があったため、棄却することにしました。
受験対策画面の作成＆ホームに導線設置
実施期間
2024-01-18 ~ 2024-02-08
背景と仮説
「受験対策講座」という、受験対策向けの専用コンテンツをリリースしています。これは受験生には非常に有益なコンテンツです。しかし、利用 UU が 10% 前後であり、認知されていないのでは、という仮説がありました。この仮説を検証するために、受験対策コンテンツ用のページを作成し、グローバルナビゲーションからのリンクを追加する A/B テストを実施しました。
指標
- L10率（中3のみ）
- 受験対策講座のレッスン開始率（中3のみ）
- 受験対策講座の平均レッスン完了数（中3のみ）
結果
以下の理由により全展開されました 🎉
- L10UU、受験対策開始率について有意差はなかったが、Bのほうが勝っている
- 平均レッスン完了数については1.6倍の差がついている
- 17%のユーザーがクリックしており、使われている機能だといえる
学んだこと
チーム立ち上げから1年間、計測基盤の構築から実際の施策展開をいくつもしてきました。その中で学んだことをまとめます。
指標設計の難しさ
最初は「初回課金率」というビジネス指標を目標にしていました。しかしこの指標は1つのエンハンスで差が出るものではありません。さらに L10率 という学習指標でさえ同様です。ほとんどの施策で L10率 以外の施策特有の指標を考える必要がありました。そしてその指標を計測可能にするための条件を考えたり、ログの送信条件を考えたり、実装する難しさなどさまざまな困難がありました。これはやってみないと分からないことでした。
必要なサンプル数を集める難しさ
一般的に統計的仮説検定で有意差を示すためには一定のサンプル数が必要です。施策によっては一部のユーザしかアクセスしない画面だったり、登録直後のユーザを登録するなど必要なサンプル数が集まりづらいケースもありました。その場合は意思決定が長引いてしまいますし、その間同一画面では A/B テストを実施することができません。このようなケースでは、より有意差が出やすい先行指標を検討することで意思決定をできるだけ早く行いました。
意思決定を早くするためのモニタリングの重要さ
A/B テストの結果は BigQuery に保存されているため、Query を叩けばその結果を見ることができます。しかし、より手軽に見れるように Google Spreadsheet から Connected Sheet で BigQuery の結果を自動的に取り出し、可視化する仕組みを Data Scientist の @shoko-ota が作ってくれました。
これは 「ノートに解く問題」ラベルをレッスンにつけたい」という施策の結果です。ノートに解く問題の完了率が明らかに差があることが一目でわかります。これを Daily standup でみんなで眺めることで、早期に意思決定することを助けてくれました。
おわりに
本記事ではスタディサプリ中学講座において A/B テストを実施するに至った背景と、結成から1年間で行った施策の紹介を行いました。
最後に、チームメンバーの皆さん( @myamamic, @miyamizu, @masahiro-iwata, @shoko-ota, @umaidashi ) に心から感謝します。私は Engineering Manager としてチーム全体の Reviewer として携わり、本記事を執筆しましたが、実際の企画・設計・実装・分析はメンバーの皆さんがやってくれています。また、コードレビューで支援してくれた @indigolain, @YutaUra にも感謝します。この場を借りてお礼申し上げます。
A/B テストの実施に興味がある方はぜひ @chaspy に連絡ください。お話ししましょう！
*1:最近では小学校1年生向けの講座もリニューアルしました https://studysapuri.jp/course/elementary/sho1/v1/
*2:WebView で開発されている
*3:おすすめレッスンを示すミッション機能、定期テスト日程登録機能、過去の学習統計を提供する”まなレポ"機能、レッスン検索機能など
*4:Web(Frontend/Backend), Android, iOS の職能横断チーム
*5:登録動線、オンボーディング、休眠ユーザへの通知等への利用喚起
*6:Web(Frontend/Backend), Android, iOS の職能横断チーム
*8:結成後2ヶ月ぐらいで加入してもらった
*9:最初は LaunchDarkly を利用していました。現在は内製の Darklaunch v2 を利用しています。参考： https://blog.studysapuri.jp/entry/2022/12/19/darklaunch-ujihisa
*10:バックエンドで行った事例もあります
