サービス成長のための高速仮説検証グロースサイクルの設計
■ はじめに
こんにちは！Repro Growth Marketerの稲田宙人(@HirotoInada)です！
このnoteは「モバイルアプリマーケティングアドベントカレンダー2020」の5日目の投稿です。
面白かったら是非ハッシュタグ「#アプリマーケアドベント 」を付けてシェアをお願いします！
”ローマは一日にして成らず”という言葉があるように多くの人が愛し使い続けるサービスはそう簡単にはできません。
サービスをグロースさせるには、高速で実験を繰り返し続ける必要がありますが、良質な仮説無しに闇雲に実験を繰り返すだけでは長期的なユーザー体験の品質向上には繋がらないでしょう。
今回このnoteでは、どのようにして良質な仮説を元に高速でグロースサイクルを回していけばいいのかを、サイクルの各ステップに関して詳述していきます。
仮説検証グロースサイクルの全体像
サイクルの各ステップに入る前に、サービスグロースのための仮説検証グロースサイクルの全体像を把握しましょう。
以下に簡単に図式化してみました。
ご覧頂くと分かる通り、サイクルには大きく分けて4つのステップが存在します。
■ 仮説検証グロースサイクル
ステップ1. データ分析・洞察収集
ステップ2. アイデアの生成
ステップ3. 施策の優先度の決定
ステップ4. 実験の実施・振り返り
作業ステップ数と工数が比例するわけではありませんが、注目頂きたいのが実験の実施後の振り返りのステップが複数存在することです。
グロースサイクルを回していくためには、施策をやって終わりではなく、失敗だったとしてもその結果から学び、次の良質な仮説構築に繋げるのが重要です。
これが、グロースサイクルがサイクルたる由縁です。
本章では、まずは継続的なグロースの為には、4つのステップが存在し、振り返りを行うのが重要と覚えてもらえればと思います。
では、次章以降で各ステップの実施内容や注意事項に関して説明していきます。
ステップ1. データ分析・洞察収集
まずは、ステップ1. データ分析・洞察収集です。
このステップのゴールは以下の通りです。
■ ステップ1. データ分析・洞察収集
事象の把握：何が解決するべき課題なのかを把握する
データ分析の実施：
・課題の原因を定量・定性で分解し評価軸を構築する
・どのドライバーを動かすことで課題が解決しそうかを把握する
まずそもそも何が課題であるかが明らかになっていないと手のつけようがありません。
最初に現状の課題を言語化することで、課題の定義を行います。
課題を定義する際には、マクロの大きい視点から始めて、順々にミクロの小さい視点に切り替えていくのがオススメです。
以下に、課題から原因仮説に分解していく際のイメージモデルを、ニュースアプリを例にとって図示します。
この例では、まず課題として「アクティブユーザー数が増えない」と定義しました。
次にやるべきなのが、関連するKPIへの分解です。
課題は「アクティブユーザー数」なので、「リテンションレート」と「新規流入数」の2つに分解してみます。
これで、どのKPIをベースに細かく見ていくべきかの目安がつきましたね。
その上で、さらにリテンションレートに関わる各イベントの実行率や、各ファネルの突破率を見ていきます。
また、新規流入数が伸び悩んでいるのであれば、ペイドとオーガニックの粒度に分解して、それぞれの施策の状況を確認していきます。
このように、ステップ1. データ分析・洞察収集では、まずそもそも何が課題であるのかを定義した上で、マクロからミクロに要因を分解していき、どのドライバーに対して施策を実施するべきかの見当をつける作業を行います。
尚、課題のドライバーへの分解においては、以下のような軸で切っていくのもオススメです。
サービスカテゴリによって若干の違いはあれど、基本的には汎用的に使用できる分析軸かと思いますので是非活用してみてください。
①：ヘビーユーザーの行動
・使用している機能
・ 曜日と時間
②：使用頻度ヘビーユーザーの属性
・流入経路
・デバイス
・人口統計
・併用アプリ
③：アプリを使わなくなるきっかけ
・ 離脱率が高いページ
・ 価格設定
・ 離脱までの利用機能・期間
ステップ1. データ分析・洞察収集におけるデータ分析方法に関しては、手前味噌ですが以下のnoteに詳しくまとまっていますので、抽象的な分析手法を学びたい方は以下からご覧下さい。
ステップ2. アイデアの生成
さて、前述のステップでどのドライバーを動かせばいいのかの見当がついているかと思います。
このステップ2. アイデアの生成では、具体的にドライバーを動かすための施策実施方法を検討します。
■ ユーザー行動モデルの整理
最適な施策手法を選択するには、まずはサービス内でのユーザー行動モデルを整理します。
行動モデルの整理には、BJフォッグ氏が提唱する消費者行動モデル「B=MATモデル」が非常に有用です。
Source：Tiny habits and the Fogg Behavior Model
「B=MATモデル」では、動機(Motivation)・実行力(Ability)・きっかけ(Trigger)の3要素を元に、ユーザーが行動を起こすか起こさないかをモデリングしています。
詳細はnote CXOの深津さんのnoteが簡潔にまとまっていて分かりやすいのでそちらを参照頂きたいのですが、要は「どれか1つでも前述の要素が欠けていると、どれだけユーザーに働きかけてもユーザーは行動を起こさない」ということです。
例えば、まだサービス利用に楽しみを感じていないのであればサービスを使う動機(Motivation)は存在しませんし、スマートフォンを持っていなければサービスにはアクセスできないので実行力(Ability)もありません。故に、何度もプッシュ通知やリタゲ広告などのきっかけ(Trigger)を用いてユーザーにアプローチしようとしても、ユーザーは行動してくれないわけです。
このアイデア生成段階では、ユーザーの各ステップ・モーメントにおける行動実行を阻害する要因(=ペイン)を取り除くための施策を、上記3要素を元に考えるのが非常に重要になるため念頭においてください。
■ 仮説と想定される結果を言語化する
実際に施策アイデアを生成していく際には、確固たる仮説とその施策によって想定される結果を言語化するのが必須です。
このステップでは、5W1Hを網羅して施策概要をまとめる他、その施策によってどのくらいの効果があるのかをまとめていきます。
以下は、あるホテル予約サイトを例にとった言語化の例です。
このように仮説を言語化しておくことで、後述のステップ4. 実験の実施・振り返りにおける、振り返り作業が効率的・且つ高精度なものになります。
以下にテンプレートを置いておくので是非使ってみてください。
【定量・定性分析の結果】に基づき
【実施施策概要】を行うことにより
【想定される効果】が見込まれる。
これにより【KGIへの効果】が達成されると考える。
尚、施策により期待される効果は厳密に算出する必要性はありません。
極論、施策をやるまではどんなシミュレーションも取らぬ狸の皮算用に過ぎないので、今までの経験則を元に設定しましょう。
■ カウンターメトリックを考慮する
アイデアの生成のステップにおいて、忘れてはいけないのがカウンターメトリックの存在です。
カウンターメトリックとは、あるメトリック(ドライバー)を動かすことでその変動の作用を受け得る指標のことを言います。
例えば、「新規アクティブユーザー数」というドライバーを動かした場合は、概して「新規リテンションレート」が低下する傾向がありますが、ここでいう「新規リテンションレート」は「新規アクティブユーザー数」の増減が作用するカウンターメトリックということになります。
このカウンターメトリックは、ドライバーの変動によりプラスにもマイナスにも変動し得るのですが、マイナスに作用する場合もあるので注意が必要です。
実際、マッチングアプリの「Badoo」ではいいね送信数を向上させる為に、いいね数増加施策を実施しました。
結果としていいねの送信率自体は向上しましたが、その後のメッセージ返信率は大きく低下し、それだけで済まず最終的なリテンション率も低下する結果に終わっています。
Another nice example was shared by Badoo at last year’s Playtime event. Badoo owns a group of dating apps and decided to test a feature where users could send each other hearts. What happened? It seemed like it worked: 20% of users sent a heart. Winning! Engagement metrics up!
But what happened when the team looked more deeply at the data? The response rate after receiving hearts dropped, -6% for men and a terrible -35% for women. The retention rate for women also dropped by 1%. This is another example that highlights why it’s so important to measure the right thing. Badoo has shared that the behavior it’s trying to drive is meaningful conversation. That is a very different thing than just “engagement,” or “daily active use,” and results in different design choices.
Source：Putting back users to the forefront: sustainable engagement tips from behavioral science
このように、施策を実施する前に、動かそうとしているドライバーが変動した際にどのような影響が他のドライバーにあるかを、垂直的・水平的に俯瞰して考えるのが非常に重要です。
ステップ3. 施策の優先度の決定
さて、いよいよ実際に施策を実行する手前のステップまできました。
前述のステップで改善に向けた施策案が無数に出てきているかとは思いますが、全ての施策を同時に行うことはできない為、優先度をつける必要性があります。
このステップ3. 施策の優先度の決定では、どのような判断軸に基づいて施策の優先度を決定するべきかを解説します。
■ ICEシステム
まずはICEシステムです。プロダクト開発の優先度決定システムとして「RICE」をご存知の方も多いかと思いますが、本システムではRを除いて優先度を算出します。
Impact：どれほどの影響が見込まれるのか
Confidence：その効果にどれくらい自信があるか
Effort：実験にかかる工数
RICEと大きく違うのが、ICEそれぞれの3項目を単純に10点満点で評価して平均点数を算出する点です。
(I + C + E ) / 3 = 優先度スコア
■ Low-Hanging Fruitを狙う
前述のICEシステムを用いて優先度を決めるのもオススメなのですが、いまいち点数が付けにくいという方もいるのではないでしょうか？
Impactの7点とConfidenceの7点が同じ重要度かというとそうではないケースも往々にして存在する為、確かにいきなり使いこなすのは難しいとは個人的にも思います。
そこで、オススメしてるのが以下の3つのフレームワークを複合的に用いた改善施策の優先度決定です。
Source：もう「データ分析」は聞き飽きた~仮説ドリブンの"真"の課題発見~
①：CVからの距離の遠近
・ユーザーフローとしてCVに近い距離の課題からアプローチしていく
・概して部分最適になりがちなのでファネルの落ち幅も考慮する
②：CVファネルの落ち幅の大小
・CVまでのファネルを組んだ際の落ち幅が最も大きい部分からアプローチしていく
③：想定インパクトと工数
・施策を実施する上での工数とインパクトのマトリクスで優先度を決定する
・第一優先：工数小×インパクト大
・第二優先：工数大×インパクト大(不可欠度は吟味する必要あり)
※工数小×インパクト小は原則優先度は下げる
上記3種類のフレームワークを複合的に用いることで、より効率的にサービス利用フローに沿って、実施施策の優先度が決定できるかと思います。
■ ユーザー目線の優先度決定フレームワーク
また、個人的にはユーザー目線の優先度決定フレームワークもオススメしています。
このフレームワークでは以下3つの項目を元に施策実施優先度を決定します。
Reach(リーチ規模)：その施策によって影響されるユーザー規模
Annoyance(うざさ)：その施策をユーザーがどう感じるか
Conversion(CV可能性)：その施策によりユーザーは行動に至るか
以下は、課金促進のメッセージをどの画面で出すべきかをフレームワークを用いて整理してみたものです。
ここでは、X回目プレイ終了時かX回目ミッション失敗時に課金アイテムを訴求するのが効果的そうだと考えられますね。
Source：アプリ内課金をハックする〜アプリ売上・収益性を改善する〜
このように、先ほどのサービサー目線でのフレームワークに加えて、利用ユーザー目線の優先度を考慮することで、ユーザーセントリックな施策の実施が可能になります。
ユーザーの体験向上ありきのサービスグロースである点は忘れないでください。
以上3つの優先度決定システム・フレームワークをご紹介しましたが、どのフレームワークも絶対の正解というわけではありません。また、各項目の精度を突き詰めるのは時間の無駄でしかありません。
重要なのは大量にある実験アイデアの中から直近やらなければいけない物を絞り込んでいくこと、そして容易に手に入る成果(Low-Hanging Fruit)を高速で積み上げていくことであることをお忘れなく。
ステップ4. 施策の実施・振り返り
さて、いよいよ施策を実施し結果を振り返るステップまできました。
このステップ4. 施策の実施・振り返りでは、施策実施前の準備と、その後の振り返りに関して解説していきます。
■ 施策実施の準備
実際に施策を実施する前に、施策に関する情報をまとめておきましょう。
この段階では、どのような計測基準でどのような結果が出たら施策を終了・中止するのかを定義します。
最低限以下の3つは明確に定義してください。
①：実験群・対象群は設定するのか？
→どんな施策でも基本的には施策の影響を受けない対象群の設定を推奨
②：信頼水準は何％に設定するか？
→99%を推奨。最低でも95％は必要。90％は10回に1回結果が覆ることを意味する。
③：有意差が出ない場合の処理は？
→基本的には対照群(旧バージョン)を採用する
この3つが定義されていないと、施策が成功なのか・施策を終わらせていいのかの判断がつかなくなってしまうので、施策実施前に組織内で共通認識をもつようにしましょう。
■ 施策結果の振り返り
実は、ここがグロースサイクルでは最も重要なステップになります。
施策が成功したにしろ、失敗したにしろ、その結果から学べることは確実に存在します。
施策を実施して終わりではなく、このステップを忘れずに行うことで継続的なサービス改善に繋がります。
このステップでは最低でも以下の要素は、施策知見としてドキュメントとしてまとめることをオススメします。
①：実験の名称と概要
②：実験の仮説
③：実験の時期(開始日と終了日・曜日)
④：使用した変数・ターゲット顧客
④：実験の種類
・プロダクト機能のテストかマーケティングメッセージのテストか
・影響を受けた機能
⑤：指標の変化
・何の指標を改善しようとしたのか・その結果は？
・想定されるカウンターメトリックの動き
⑥：結果の分析
・潜在的な交絡要因の有無(施策実施中の他プロモーション施策・季節要因)
⑦：導き出せる結論とネクストアクション
この振り返りステップで得た知見を元に、再びステップ1. データ分析・洞察収集に戻り、グロースサイクルを回していくのです。
尚、同じ文脈でサービスのデータ分析結果の知見を社内に展開している事例として、英単語帳アプリの「mikan」さんの取り組みが真似しやすく非常に参考になるので是非ご覧ください。
グロースサイクル3ヶ条
最後の本章では、グロースサイクルにおいて必ず守るべき鉄則3ヶ条を説明します。
①：完璧よりも量を
ステップ3. 施策の優先度の決定でも触れた内容ではありますが、グロースサイクルにおいては完璧を求めるよりも、失敗を繰り返しながら高速で大量の施策を回す方を重視します。
優先度決定は、あくまでも無数にある施策の中から絶対にやるべきものと、今はやらなくてもいいものに大きく分ける作業でしかないので、ここに精緻さを求めるのはあまり良くありません。
まずは、ざっくりと優先度をICEシステムを用いて優先度をつけ、その上でサービス利用フローに沿った優先度決定を行いましょう。
ただ、もちろんその施策の結果ユーザー体験を毀損しては元も子もないので、ユーザー目線の優先度決定フレームワークも用いながら、ユーザー体験向上・サービス成長を両立できるような施策を順番に実施しましょう。
大事なことなのでもう一度言いますが、ユーザーの体験向上ありきのサービスグロースです。
②：振り返りをする
施策を実施した際には必ず施策結果の振り返りを行いましょう。
その施策が仮説に反して失敗に終わったとしても、なぜ失敗をしたのかを深掘りしていくことで新たな施策のヒントが得られるかもしれません。
また、施策結果の社内蓄積もお忘れなく。一度やって失敗した施策を知見ドキュメントが存在しないせいで、再び実行するのは、社内リソースが無駄になるだけでなく、ユーザー体験の毀損にも繋がり得ます。
③：実験を継続する
改善に終わりはありません。
あのTwitterやInstagramのような超巨大サービスでさえ超高頻度でサービスアップデートをしています。
新たな施策のアイデア出しに詰まった際には以下の軸で考えてみるとアイデアが広がるかもしれません。是非活用してみてください。
・成功要因への集中投下
効果が出た要因をさらに深掘りし資源を集中投下する
・データの深掘り
分析がし切れていない箇所を深掘りする
・チャネルの拡充
既存チャネルでの実験が頭打ちになったタイミングで別チャネルへの投資を実施する
・アイデア生成のオープン化
実験アイデアが頭打ちになったタイミングで別部署などからもアイデアを募る
■ 最後に
以上、今回はサービスグロースにおける高速仮説検証サイクルに関して解説してきました。
かなり抽象的な内容ではありますが、ステップ3. 施策の優先度の決定でご紹介した、サービス利用フローに沿った優先度決定フレームワーク・ユーザー目線の優先度決定フレームワークの2つは明日から早速使えるものかと思いますので、ぜひご活用頂けると嬉しいです！
このnoteが皆様のサービスグロースの一助になれば幸いです。
最後までご覧いただきありがとうございました。
---------------
ぜひこのnoteの感想やご意見を、ハッシュタグ「 #アプリマーケアドベント 」をつけてTwitterで教えてください！
この記事が気に入ったらサポートをしてみませんか？