グロースを実施する時にやることのメモ

前回書いた記事が14,000文字ほどの大作で、以下Tweetのような状態に陥っている。

ダメだ、noteで記事を書き始めたが1500文字くらい書いてお蔵入りになった。対策に仕立てないとPublishしたくないという謎の病だが、大作に仕上げる気力がない。

これは深刻だ。Shortな記事でも公開していけるような仕組みと心構えを考えないと...

— 樫田光 | Hikaru Kashida (@hik0107) May 6, 2020

そのため、この記事はライトに書いてみる。
きっと、間違いや浅い知見もたくさんあるだろうが、知るかそんなこと。

だいたいいつも前置きで疲れるので、前置きなしで。

1 / LTVを見る

顧客が将来的にサービスにもたらしてくれる収益の総和
顧客獲得のコスト（CAC：Customer Acquisition Cost）という投資に対して、きちんと回収できているか= Profitableかどうか の判断のために使う。

LTV ＞ CACの関係になっていることを「Unit Economicsが合っている」などという言い方をすることが一般的。VCの人などはよく使っている印象。

実際に計算しようとすると諸々の定義が難しいが、特によく出るポイントとしては

・コストをどこまで入れるか
・PaidとOrganicどこまで入れるか
・登録何ヶ月分までで見るか（生涯でいいのか）

あたりだろうか。

コストとしては、顧客の活動単位でかかる変動費（購買の諸経費や維持コスト）を入れるのが正しいだろうが、あんまりキチキチやりすぎると辛いのでざっくりやるのがオススメ。顧客維持（例：ポイントなど）などにどれくらいのコストが掛かっているのかは、知っておく価値はあるので余裕があれば着手するのが良さそう。

PaidとOrganicといった獲得チャネルの問題については、大体のサービスに於いては獲得経路によってLTVは大きく違う（2x-3x違うとかもザラにある）。そのため分けて把握しておいたほうが無難。

特に、LTVをCACとのバランスで見るために用いている場合は、Paidによる獲得ユーザのLTVを見ていくほうが良いだろう。

また、LTVは点（ひとつの数字）でなく線（時間経過推移）で見ていくのがオススメ。登録後にday7, day30 day60, day90.... でどのような曲線になっているか。継続的に使われないサービスはSaturationが早い = 線の伸びが寝てくる。

ちなみに、SaaSだとLTVは12ヶ月でCACをPayし、また生涯のLTVがCACの>3xであることが好ましいらしい。

計算の仕方とか、数値的なベンチマークについてはそのうち調べたものを載せる。

2 / Retentionを見る

RR%（リテンションレート）は、一定期間たった後にもユーザが自社のサービス上に残ってくれているのかを表す。

FacebookのVP of Growthを務めたAlex Shultzが「グロースにおいて重要なことはリテンションだけ（Retention is single most important thing for growth）」と言っているくらい重要な指標。

「ユーザがなんと言っているかよりもどう行動しているかを信頼しろ」とはよく言うが、結局のとってサービス提供者からみたときにユーザの最も正直な声というのは、究極的には「使い続けているかどうか」という行動に現れる。（口で「気に入っている」「いいサービスだと思う」というのはあまり意味がない）そういう理由から、リテンションは重視される。

個人的にも、本格的なグロースの前段階にあるサービスについてはRetentionを最重要視してサービスを運営するのでほぼ良いことが多いと思う。結局のところ、RetentionはLTVのサブセット（≒構成要素）に近い感覚がある。

難しいのは、Retentionが嘘を付くケース。プッシュ通知などで水増ししうる点には注意が必要で、起動回数などに制限を設けて測定することもある（月に2日以上立ち上げた場合のみ算入、とするだけで月に1度でも、よりは遥かに実態に近くなることがある）

大体のサービスでは、まずはday7あたりのRetentionをどう高めるかに注力することになるだろう。

前提としてどんなサービスでも基本的に獲得したユーザの大半を獲得後すぐに失う。New data shows losing 80% of mobile users is normal, and why the best apps do better によると「we can see that the average app loses 77% of its DAUs within the first 3 days after the install」、つまり平均的なアプリサービスではインストール後3dayでDAUの77%を失うとされている。

7dayで40%がRetentionしているとワールドクラスレベルの優良サービス、30%でもまあ悪くないとどこかで読んだ（文献がぱっと出てこないので後で探して貼っておく）

3 / LTVのBreakdown（CVRとARPPUが多い）

LTVの構成要素をある程度、分解して理解しておくことは重要。
見たい点として

・初回課金のコンバージョンレート
・2回めのリピート率
・ARPPU
・購買頻度

など。ただしこれはサービスの内容によってだいぶ変わる。

よくあるパターンとして、1回目の購買転換には力を入れているが、それ以降はあまり手を入れていないため2回めのリピート率に問題があるケース。

4 / 現状のユーザ分布を見る

既にそれなりにユーザがいるサービスの場合、現時点での全登録ユーザがどのように分布しているのかを知っておく必要がある。

これはサービスの種類によってどのように把握するのかが良いのか、が大きく異なるため、クリエイティビティを要する作業になる。

例えば、無料でも使えるがサブスクリプションによって機能開放されるフリーミアムモデルのサービスの場合、「利用状況（アクセスあり・なし）」×「課金状況（未課金・課金中・過去課金）」で切った6象限のユーザボリュームを把握するなどは、施策の設計と現状理解に役に立つ。

※ 筆者はこれを6 box 分析と呼んで使っている

現状のユーザボリュームを把握し、サービスの特性を理解するとともに、切ったセグメントごとに施策を考えやすくなるという特典もある。

5 / ロイヤルカスタマーを知る

サービスの（現時点での）ロイヤルカスタマーが誰で、どのようなニーズが刺さって使っているのかを知る。アンケートやインタビューなどをうまく使うのが良いだろう。

ロイヤルカスタマーを知ることは、マーケティングとプロダクト開発の両面で意味がある。ロイヤルカスタマーが使っている機能／使い方は、ある意味で手本となる存在で、それらの機能の存在と利用の方法をすべてのユーザに伝えるべきだ。

また、ロイヤルカスタマーがいるようなチャネルや生活動線を理解することはマーケティング上の助けとなる。

また、多くのユーザでは「元々持っていた期待」と「実際に使って得られたベネフィット」が一致しているが、使ううちにそれを獲得したケースも存在する。（= 元の期待とは違うベネフィットを見つけた）その場合、それに気づいた理由や瞬間について理解したい。

6 / Magic Number, Magic Momentを見つける

facebookがグロースに際して「登録14day以内に10人の友達とConnectさせること」に注力して施策を打ったことは有名かもしれない。

2で書いたように、最終的にサービスの力を測る指標（=上げるべき指標）はRetention Rate (RR%) であるが、RRを直接上げる施策というのは基本的には存在しない。

実際にはプッシュ通知などが該当するが、Vanityだと思う

そのため、何らかのRetentionとの強い相関（というか因果）がある指標・行動を見つけ出してその行動量などをリテンションの代弁者として追うことにするのが良いケースが多い。

FBの「10 friends in 14 days」はまさにそれの例である。この数字を達成するとリテンションが飛躍的に高まった、と言われている。

真相は知らないが、おそらくこれは多少誇張を含んでいるだろう。
このMagic Numberについて困るのは、多くの人が「ユーザの行動が一気に変わる明確な臨界点がある」と思い込んでいる点だ。経験から言えば、それはない。FBでもConnectionが9人までから10人になった瞬間に、何かが一気に変わる、というものではなかったはずだ。

おそらく、Connectionの数に対してのその後のRetentionは単調に増加する（そしてある程度から飽和する）ような線であって、9人から10人の位置に極端に傾向の変わる変曲点があったわけではないと思う。多くの人はもっとわかりやすい変曲点を探し、そしてMagic Numberを決め損なう。

実際のところ「友達の数を増やすと継続率が上がる」は分析から明確に真だが、「14dayで10人」はある程度ブレが合っても良かったはずだ。「12日で12人」でも問題なかっただろう。

ただ、わかりやすさの観点で14day / 10人としたのではないかと想像する。

誤解を恐れずに言えば、Magic Numberというのは組織内の神話的なところがある。大枠の方向があっていればあとは、正確な閾値の解明よりも覚えやすさや施策のうちやすさのほうが優先されて構わないと思う。

Magic Numberの閾値を正確に出そうという試みにはあまり意味がないと思うが、決定木などの機械学習を使って文字通りに機械的に決めるのもありだろう。一般的なプロセスとしては、登録後7day（もしくは14day）でのいろいろな行動量と、その後の長期的な継続率の関係性を見るというものになる。

「どのような行動との相関を仮説として持つか」は人間が考えるしかないが、突き詰めて考えれば基本的にはそのバリエーションがさほど多くないはずだ（利用初期の時点で取れるクリティカルな行動が34種類あるサービスは、そもそもサービス設計を見直すべきだろう）

基本的にはそのサービスの価値を感じるためのファネルの導線上の行動になるはずで、ファネルの奥ほど関連が深いはずだが、利用初期でそこまでの到達確率が低い場合は手前の行動においてもいいだろう。

7 / 事業計画をProduct KPIと紐付ける

グロースの際に可能であれば事業計画を見直しておきたいことが多い。
これは目標を調整するなどという話ではなく、大体の事業計画というのはプロダクトのKPIと対応していないことが多い。

例えば、事業計画にはよくMAUなどが盛り込まれるが、プロダクトを改善する際にMAUを目標値として設定することはあまりない。

事業計画とプロダクトの戦略／KPIをアラインしておくことが重要だが、これは意外に行われていない印象がある。作る人間が別だからだろう。

必要ならユーザセグメントなども導入できるとBetterなケースがある。ここで言うユーザセグメントは、男女などのデモグラなどではなく、新規・既存などの打ち手が大きく異る単位のセグメントを指す。

メルカリの例では、大きく3つのユーザセグメントを構築してそれを事業計画に紐付けていた。 ⇨ 参考：Simple Analytics Leads Impact

とりあえず今日はこれくらいで。

編集後記

思いついたままに書いて正直30点くらいの文章だが、元の趣旨を鑑みてこれでリリースすることにする。

完璧主義の自分が、あまり時間を掛けずにnoteを書いてPublishするため、今回気をつけた点は

・文献を探しに行かない
楽しくて、飛び火して無限に時間を消費する。
また、一つの文章に文献をつけると全てにつけたくなる

・「だ、である」調で書く
誰かのために書いてる感を軽減でき、雑に書いても良いという気分になれる

・間を置かない
一度保存して寝かせると、どんどんと発酵する。
休憩時間に書きたいことを思い浮かんでしまう。
この記事は一切間を置かずに1.5時間ほどで一気に書ききった。

・推敲／添削しない
とりまリリースして、後から指摘されたり気になったら直す

など。
完璧主義な自分を打ち破る。