A/B テストを始める前に知っておきたいグロースハックの考え方
データドリブンなプロダクト改善を進める上で、とりあえずのA/B テストに走らないように、サービスの全体像を見える化するAARRR モデルをおさらいしてみた。
AARRR モデル
ファネル分析でサービス成長のボトルネックを視える化するためのフレームワークです。 「アーモデル」って読むらしいです(知らなかった)。海賊の叫び声を模しているとか
Acquisition(ユーザー獲得)
ユーザがいないと始まらないので、まずはユーザを集めましょう。いろんなチャネルを使ってユーザにプロダクトを見つけてもらうステップです。
マーケティングの発想に近いので、大雑把ですがプロモーションの効果測定のためのステップということです。
Activation(ユーザー活性化)
プロダクトを知ってもらったユーザに利用開始してもらうステップです。初めての利用でユーザーに “良い体験” をしてもらうことが大切です。言い方を変えると、ユーザにプロダクトの価値を理解してもらうために必要なアクションが完了した状態を指します。
初回起動のチュートリアル完了や友達をフォローする、写真をアップロードするなど、プロダクトのユーザ体験にあわせた指標になります。
Retention(継続)
継続的にプロダクトを使ってもらうユーザを増やすステップです。継続的に使ってもらえないプロダクトだと、どれだけユーザ獲得してもどんどんユーザが流出してしまいます。
継続率が低いということは「ざるで水をすくう状態」なので、AARRR モデルで一番重要視されています。重要な指標でありながら、難しいポイントでもあるのでAARRR モデルでファネル分析すると、Retention が一番萎む箇所になりやすいです。
Referral(紹介)
ユーザーがプロダクトを周りに紹介するステップです。友達に紹介するとなると、ユーザ自身が “良い体験” を実感している必要があります。プロダクトが紹介されるということは、プロダクトの熱狂的なファンが増えていることになります。
また、Referral は新しいユーザ獲得になり、その紹介経由のユーザが活性化し新たに別の人に紹介する流れが出来ると、どんどんユーザが増える状態になります。
Revenue(収益)
売上、利益を増やすステップです。Revenue の前提には、 “良い体験” を実感してもらうActivation やRetention といったステップが入っています。AARRR モデルは “良い体験” と “収益” の両立するためのフレームワーク なのです。
これは「プロダクトを磨けばマネタイズはあとで考えれば良い」という訳ではないです。あらかじめビジネスモデル(マネタイズ)は設計しておくものの、まずはユーザに “良い体験” を提供することが大切です。
EC のAARRR モデル
「AARRR モデルにどんな指標を当てはめるべきか?」という問題が結構難しい。難しいと言うより、置き方次第でサイトの方向性が変わります。
たとえば、EC サイトで
- Acquisition : サイト来訪する
- Activation : お試し商品を購入する
- Retention : 何度もサイト来訪する
- Referral : レビューを書いてシェアする
- Revenue : 販促コストを回収する(CPA < LTV)
と置いてみる。
サイトに来たユーザが商品を買い、何度もサイトに訪れることでリピート購入する。リピート購入しているうちに、販促コストを上回る金額の売上になり投資回収ができる。また、レビューをシェアすることで、新しいユーザがサイトに訪れる。フォーカスするべき数値が明らかになり問題なくグロースしそうです。
一方で、同じEC サイトでも
- Acquisition : 会員登録する
- Activation : 購入した商品を自宅で受け取る
- Retention : 毎月1回以上、商品を購入する
- Referral : 友達にギフトを送る
- Revenue : 販促コストを回収する(CPA < LTV)
と置いてみる。
先ほどと大きく違うのは、 “オフラインのユーザ体験” が含まれていることです。このサイトはロジスティック(商品配送)もグロースハックで最適化する戦略を取ることを意味しています。ただし、プロダクト改善の施策はより難しいものになります。
どんなAARRR モデルを設計したら良いか?
プロダクトのビジョンやミッションステートメントにあわせて適切なAARRR モデルを設定するというのが大前提です。ただ、リリースしたばかりのプロダクトは、目指しているビジョンと現在のプロダクトに乖離も大きいので、背丈にあったモデルを設定しましょう。
僕が設定するときは、設定したそれぞれの指標について
- その指標は “現実的な期間内に” 測定できるか?
- その指標はコントロールできるか?
と自問自答しています。どちらかが “No” なら指標を置き直します。リリースしたばかりの時は、 “Maybe” でも良しとしますが、できれば両方の質問に “Yes!” と言えるのが良いと思います。
“現実的な期間内に” 測定できるか?
置いた指標は必ず数値を測定してモニタリングするので、そもそも測定できないと困ります。 “購入した商品を自宅で受け取る” と設定しても、ユーザの自宅に配送完了したこと示すデータを持っていないければ、プロダクトの良し悪しが判断できず改善が進みません。
また、 “販促コストを回収する(CPA < LTV)” と設定した時、もし投資回収期間が10年(10年間でLTV を測定)であれば販促コストの赤字を10年間許容することになります。10年間の赤字を許容できる資本がなければ、測定している間に会社が潰れてしまいます。
極端な例ではありますが、なるべく早く結果が分かる様な指標に置いた方が改善施策を回しやすいです。
コントロールできるか?
言い換えると「その指標を改善する施策(アイデア)はあるか?」です。打ち手があまり出ない指標を置いても、数値を眺めるだけで終わってしまいます。
“友達にギフトを送る” という指標ですが、「友達の住所が分からない」というプロダクトの外側の問題によって、プロダクト自体を一生懸命改善しても数値が全然動かないかもしれません。
実際やってみないと分からない事もありますが、施策を打っても動かない数値には要注意です。逆に、施策を打った結果、筋が悪くて数値が悪化したらある意味では良い兆候です。ダメな施策で数値が下がるなら、良い施策で数値が改善するかもしれないです。
AARRR モデルを変えることは良いこと
フェーズによりAARRR モデルを適切に変えた方が良いと思います。プロダクト全体を見渡す大事なファネル分析なので、あまり短期間で変え過ぎるのは良くないものの、一度決めたモデルに縛られ過ぎずにAARRR モデル自体も「仮説→実験→学習」のサイクルをぐるぐる回すのが良いと思います。