2017/07/25

たつおの部屋 : アプリのCPIの計算で見落としがちなこと

前回同様、これから広告出稿しようかな〜っていうフェーズの、どちらかというとカジュアルゲーム作ってるデベロッパーさん向けの記事だよ!


【質問】

前々回の blog で "LTV > 獲得単価" ならどんどんプロモーションしてビジネスを拡大させるべきだって話が出てきました。
前回の blog では、LTV の計算方法が紹介されてました。

前々回の記事 : 成功から逆算してアプリを作る - 北京の車窓から http://www.tatsuojapan.com/2017/06/blog-post_30.html
前回の記事 : たつおの部屋 : アプリのLTVってどう計算するの? → 2つの方法を紹介  http://www.tatsuojapan.com/2017/07/ltv-2.html



じゃあ広告でユーザー獲得しましょうってなったときは、獲得単価は広告ネットワークの管理画面に出てる CPI のことですよね先生!?

【回答】 

 実はそれだけ見ていると、チャンスを逃してしまう可能性があるので注意が必要なのです!

どういうことか解説する前に、最近とあるデベロッパーさんからいただいた嬉しいメッセを公開。(文体を一部修正してます)

AppLovin で 1 週間ぐらい広告打ってみましたが、広告経由以外のインストールも伸びてるので全体としては ROI プラスになりそうです。
今後も継続できるよう予算取ります!

太字にしたところがポイントです。

広告を出稿したとき、広告ネットワークやトラッキングツールに出てくる "インストール数" は、その広告ネットワークで広告に "直接接触した人" が所定の期間内にそのアプリをインストールした数、になります。

ですが実は、広告を出稿することで、そこに反映されないインストール増が見込める場合もあります。例えば、
  • ランキングが上がったり、検索順位が上がったことで、アプリストアで発見してインストールしてくれるユーザーが増加
  • 広告経由でインストールしたユーザーが、友達や SNS にシェアすることでインストール数が増加
などです。

("広告に直接接触していないユーザーのインストール" のことを業界用語で "オーガニック・インストール" と呼びます。健康に良さそうです)

この副次効果が大きければ、広告ネットワーク上での (purchased install に対する) CPI が多少高くても、実質的な CPI (eCPI = effective Cost per Install) は LTV の範囲内に十分収まることは十分ありえます。

いくつか事例を紹介しましょう。
(実例をもとにしてはいますが、数字とかは超適当にいじってるので、実際の数字とは全然異なります)

事例 1 : 国内カジュアルゲーム

平均 CPI 100 円 で週に 500 万円を、SNS や動画広告ネットワークに出稿。(合計 5 万インストール)
その結果ランキングが TOP 10 以内に入り、オーガニックで 5 万インストールが発生。

結果として、500 万円かけたことで合計 10 万インストールが増えたことになるので、eCPI は 50 円の計算。
LTV 80 円ぐらいのアプリなので、ROI 160% (80 ÷ 50) が達成できる計算。
この eCPI が維持できる限りは継続出稿することにした。

事例 2 : 海外 (US) へのカジュアルゲーム出稿

平均 CPI 100 円で日に 10 万円ほど出稿。(1 日 1,000 インストール)

テストしてみた結果、
  • 平日はプロモーションしていない日と比べて +4,000 インストールが発生
  • 休日や長期休暇期間はプロモーションしていない日と比べて +1,500 インストールしか発生しない
ことが分かった。

検証しようがないが、これはおそらく平日に限り、インストールしたユーザーが学校や職場で周りの人に (平均 3 人ぐらい) 紹介してダウンロードさせてるのではないか? と予想。

もしそうであれば、1 件広告経由でインストールさせることで合計 4 件のインストールが発生するわけなので、eCPI は 25 円 (100 ÷ 4)。
ただし休日や長期休暇期間の eCPI は 66.7 円 (100 ÷ 1.5)。

平日に関してのみ eCPI が LTV 50 円を下回っているため、平日のみ出稿し、土日祝日・長期休暇期間は出稿を止めることにした。

〜〜〜

以上いずれのケースにおいても共通しているのは、トラッキングツールで捕捉できない間接的なインストールが少なからず発生していること。

上記のような (他にプロモーションや PR などを積極的に行っていない、またはその影響を無視できる) ケースでは、このインストールは "プロモーションによって発生した" インストールだとみなすことができるはず、じゃない?

これを、投資対効果や継続判断の際には無視してはいけないのだ。
(上記いずれのケースも、広告ネットワークの管理画面の CPI だけを見ると LTV よりも高いので、広告出稿を止めるという判断をしてしまい、成長機会損失につながる可能性がある)

ランキングに載ったりといった目に見えた影響がなかったとしても、プロモーションの開始をきっかけに、広告経由の直接的なインストール数以上にインストールが伸びることは多くのケースで起きる。
(冒頭でコメントを紹介したデベロッパーさんなんかはまさにそうだ)

複数の広告ネットワークに出稿している場合は、ネットワークごとの正確な値を算出することは難しいのだが、eCPI のいちばん簡単な計算方法はこれだ。

投下費用 ÷ {(プロモ開始後の日毎のインストール数 - プロモ開始前の日別のインストール数) x 対象日数}

簡単に言うとよーするに、
プロモに幾らかけたか ÷ プロモやって増えたインストール数の合計
という、これだけ。

  • プロモやる前までは 1 日 100 インストールしかなかったよー
  • 1 週間プロモやったら、1 日 300 インストールの状態が 2 週間ぐらい続いたよー
  • プロモに全部で 30 万円かけたよー
だったら、eCPI は
30 万円 ÷ {(300 - 100) x 14日} = 約 107 円
となる。
(30 万円かけて、2,800 インストール増えたので、1 インストールあたりの実質コストは 107 円)


最後に、以前同僚の雀鬼・谷やんが言ってて面白いなと思ったセリフを紹介したいのだが、それは「オーガニックインストールなんて無いですよ」というもの。

アプリストアでランキング上位にあげようと思ったら売上なりインストール数なりを積まないといけないわけで、そのためにはプロモーションをしないといけない。
フィーチャーされるためには、ストア担当者にアプローチしたり、フィーチャーされるに値する高いクオリティに仕上げたりと、(直接的なキャッシュアウトは伴わないとしても) 少なからずコストがかかる。
ストアの検索に引っかかるためにも ASO 対策をきちんとやってないといけない。

つまりアプリ広告業界で "オーガニック・インストール" と呼ばれているものは、"オンライン広告経由のインストールではない" というだけで、"コストをかけなくても自然と発生したインストール" という意味ではない、というかそんな自然発生的なインストールなんて世の中には存在しないんじゃないか、という論。

(...だと解釈しました。)

まぁ確かに、TVCM やって伸びたインストール数だって、トラッキングツールでは "オーガニック" ってカテゴリに入ってしまうわけで。

細かく数字を見ることも大事ではあるけど、時にはある程度ばっくり大きなドンブリに入れて計算してみることが、大きな方向性を決めるためには必要なんだな、っていう話でした。

〜〜〜

ちなみにぼくが先日リリースしたアプリ "漫画ウォッチャー" は、オーガニックでも全然ダウンロードされてないです!
みなさん冷やかしでいいのでダウンロードして ★5 つけてちょんまげ〜〜〜!!!

 
漫画ウォッチャー – 週刊マンガ誌の休刊情報をお知らせ
App Store (iOS) : https://itunes.apple.com/jp/app/id1247711148?mt=8
Google Play (Android) : https://play.google.com/store/apps/details?id=com.manga_watch

アプリ出したらワンチャンあるかもなんて、そんな甘くなかった!
でもまだ諦めずに頑張るもん!

Q

2017/07/06

たつおの部屋 : アプリのLTVってどう計算するの? → 2つの方法を紹介

これから広告出稿しようかな〜っていうフェーズの、どちらかというとカジュアルゲーム作ってるデベロッパーさん向けに書くよ!

【質問】

前回の blog で "LTV > 獲得単価" という話が出てきましたが、そもそも LTV ってどう計算するんですか?
過去の売上の累計を、過去のダウンロード数の累計で割って計算しているのですが、合ってるか自信がありません。

前回の記事 : 成功から逆算してアプリを作る - 北京の車窓から http://www.tatsuojapan.com/2017/06/blog-post_30.html

【回答】

ざっくり 2 つの計算方法があります。

1 つ目は貴方が言っている、"売上累計" を "ダウンロード (DL) 数累計" で割るという方法です。
例えば、過去 2 ヶ月の累計売上が 200 万円で、DL 数累計が 10 万だったとしたら、LTV は約 20 円、という計算です。

この計算方法が成り立つ前提条件があって、それは
  • ちょっと前にダウンロードしたユーザーが、"累計売上" に大きな影響を与えるほどには課金しない
  • DL 数累計が大きな影響を受けるほどは、新規の流入がない
の 2 点です。
割り算の分子も分母もだいたい同じぐらいの変化率で上昇している想定ということですね。

なのでこの計算方法が向いているのは、ある程度リリースから時間がたっているアプリということができます。



この計算方法の別の問題点として、改善によって LTV が向上している場合にその影響がなかなか反映されない (改善前の LTV に引きずられる) ことと、リリース初期の LTV の計算には使えない (DL 数はその日に計上される一方、将来の売上はそれより先にしか発生しないため、本来の LTV よりも常に低く計算されてしまう - 序盤は特にその傾向が強い) という 2 点があります。

こんな風なグラフになる。X 軸は時間 (左端がゼロ)

じゃあリリース初期の LTV の計算はどうするのかというと、それが 2 つ目の方法で、ARPDAU と継続率を使います。

ARPDAU とは Average Revenue Per Daily Active User のことで、アクティブユーザー 1 人あたり 1 日にいくらの売上になるか、という指標です。

(ある期間の売上合計) ÷ (同期間の DAU の合計) で、ARPDAU がわかります
例えば、リリース後 1-7 日目に 70 万円の売上があり、日々の DAU の合計が 7 万人 (平均 DAU 1 万人) だったとすると、ARPDAU は 10 円 (700,000 ÷ 70,000) です。

次に、継続率からユーザー 1 人あたりの平均残存日数を計算します。
例えば、リリース後 1 週間 で継続率が 20% で、'過去の同様なアプリの傾向から) 30 日後の継続率が 10%、60 日後にほぼ 0% になることが予想できた場合を想定します。

初日にいた 100 人のユーザーは、1 週間後 20 人まで徐々に減っていき、1 週間の "のべユーザー数" は 300 人・日 となります。
100 + 50 + 40 + 35 + 30 + 25 + 20
同様に、8-30 日目まではのべ 340 人・日
(20 → 10 人まで、23 日間で一定ペースで減る計算。 (20+10) × 24 ÷ 2 - 20)
31-60 日目まではのべ 145 人・日
(10 → 0 人まで、30 日間で一定ペースで減る計算。 (10+0) x 31 ÷ 2 - 10)

つまり 100 人のユーザーがゼロになるまでの間に、合計 785 人・日 (300 + 340 + 145) 遊ばれることになるので、ユーザー 1 人あたりの平均プレイ日数は 7.85 日になります。
初日で離脱するユーザーも 50 人いるけど、30 日以上プレイするユーザーも 10 人いるので、平均すると 1 週間ちょっとは遊んでくれるということです。

ユーザー 1 人あたり 1 日に 10 円の売上になる × 休眠するまでに平均 7.85 日遊ぶ = LTV は 78.5 円
という計算になります。

この計算方法の前提は、計算する期間以降の売上 (特に課金) の傾向が一定だということ。
例えば、リリース 1 週間後の時点での ARPDAU を計算したのだけど、実はほとんどのユーザーが最初に課金するのはダウンロードから 10 日目以降だ、という場合はこの方法で計算すると LTV を低く見積もりすぎてしまいます。

課金傾向がある程度一定で、かつ、ある時点での継続率から将来の継続率がだいたい予想できる (または、誤差が無視できる) ようであれば、わりと早い段階 (1-2 週間目) で比較的正確な LTV を計算することが出来るようになります。

また、アプリのアップデート等によって継続率や ARPDAU が変わった場合、変わった時点から計算をやり直せば LTV をアップデートできるというのもメリットの 1 つです。


以上 2 つの方法をご紹介しましたが、LTV のそもそもの定義から考えると当然、2 つの方法で計算した数字は時を経るといずれ "本当の LTV" に向けて収斂 (しゅうれん) します

なので個人的には、2 つの方法の両方でリリース時から LTV を計算し、だいたいその間のどこかに "本当の LTV" があるはずだ、とアタリをつけるというのが実務上のベストプラクティスかなと思います。

Q