これから広告出稿しようかな〜っていうフェーズの、どちらかというとカジュアルゲーム作ってるデベロッパーさん向けに書くよ！
過去の売上の累計を、過去のダウンロード数の累計で割って計算しているのですが、合ってるか自信がありません。
前回の記事 : 成功から逆算してアプリを作る - 北京の車窓から http://www.tatsuojapan.com/2017/06/blog-post_30.html
1 つ目は貴方が言っている、"売上累計" を "ダウンロード (DL) 数累計" で割るという方法です。
例えば、過去 2 ヶ月の累計売上が 200 万円で、DL 数累計が 10 万だったとしたら、LTV は約 20 円、という計算です。
この計算方法が成り立つ前提条件があって、それは
割り算の分子も分母もだいたい同じぐらいの変化率で上昇している想定ということですね。
なのでこの計算方法が向いているのは、ある程度リリースから時間がたっているアプリということができます。
この計算方法の別の問題点として、改善によって LTV が向上している場合にその影響がなかなか反映されない (改善前の LTV に引きずられる) ことと、リリース初期の LTV の計算には使えない (DL 数はその日に計上される一方、将来の売上はそれより先にしか発生しないため、本来の LTV よりも常に低く計算されてしまう - 序盤は特にその傾向が強い) という 2 点があります。
じゃあリリース初期の 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 人のユーザーがゼロになるまでの間に、合計 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
【質問】
前回の blog で "LTV > 獲得単価" という話が出てきましたが、そもそも LTV ってどう計算するんですか？過去の売上の累計を、過去のダウンロード数の累計で割って計算しているのですが、合ってるか自信がありません。
前回の記事 : 成功から逆算してアプリを作る - 北京の車窓から http://www.tatsuojapan.com/2017/06/blog-post_30.html
【回答】
ざっくり 2 つの計算方法があります。1 つ目は貴方が言っている、"売上累計" を "ダウンロード (DL) 数累計" で割るという方法です。
例えば、過去 2 ヶ月の累計売上が 200 万円で、DL 数累計が 10 万だったとしたら、LTV は約 20 円、という計算です。
この計算方法が成り立つ前提条件があって、それは
- ちょっと前にダウンロードしたユーザーが、"累計売上" に大きな影響を与えるほどには課金しない
- DL 数累計が大きな影響を受けるほどは、新規の流入がない
割り算の分子も分母もだいたい同じぐらいの変化率で上昇している想定ということですね。
なのでこの計算方法が向いているのは、ある程度リリースから時間がたっているアプリということができます。
この計算方法の別の問題点として、改善によって 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
0 件のコメント:
コメントを投稿