遊覧飛行ーワインとゲームー

都内某所で働くゲームクリエイターのブログ。ゲームやビジネスに関する話題、シリアスゲームの紹介、作成したゲームの公開、ワインに関する記事など徒然なるままに書き記していきます。

スマホゲームの基本KPI -3. RR-

f:id:ngyope:20160417155010j:plain

スマホゲームの KPI に関する解説、第3回です。

今回は、前回・前々回で解説を行った DAU や NUU とも関連が深く、ゲームの運営上も非常に重要な KPI 、継続率を表す RR について見ていきます。

主な読者層としては、将来スマホゲームの業界で働きたいと思っている学生や、入社したてでこれから現場に入っていく新入社員の方などです。

 

基本 KPI 1. -RR-

RR (アールアール: Return Rate) とは、継続プレイが重要な指標となるスマホゲームに特有の KPI で、ある期間にアクセスしたユーザーが〇日後に再びアクセスした率を表します。

例えば、2016年10月23日にアクセスしたユーザーが 1,000人いたとして、その人たちのうち翌日の10月24日にアクセスしたユーザーが 500人だった場合、RR は 50% (500 ÷ 1,000 = 50%) となります。

一般的な用いられ方としては、ある日 (例えば 2016年10月23日) にインストールした人 (= NUU) を対象にして、その人たちのうち 1日後に再アクセスした率を 1-d RR (ワンデイアールアール: 1 day RR)、2日後に再アクセスした率を 2-d RR、3日後は 3-d RR……という感じで追っていき、どれくらいの人がゲームを継続プレイしてくれているのかであったり、どのタイミングでユーザーが離脱しやすいのかなどを見ていきます。

 

RR の注意点

上記の通り、RR はゲームのプレイ継続率を示すものとしてよく用いられている指標ですが、必ずしも各ユーザーの継続プレイを表している訳ではありません。

たとえば、ある日の NUU が 1,000 だったとして、その人たちのうち翌日にアクセスした人が 500 人であれば 1-d RR 50%、翌々日にアクセスした人が 300 人であれば 2-d RR 30% となります。この時、2-d RR にカウントされるユーザーはあくまで「インストール翌々日にアクセスした人」であって、インストールの翌日から継続して遊んでいる人も、翌日はアクセスしなかったが 1日あけて翌々日にアクセスした人も等しく 1としてカウントされてます。

なので、RR はユーザーの継続率を示す指標であるといえども、必ずしも個人の継続プレイをダイレクトに表しているものではないことを頭に入れたうえで見ていく必要があるのです。

 

NUU, RR, DAU

最後に、前回まででお話しした NUU と DAU、それらと RR の関係を見ていきます。

ゲームの運営にあたって、利用者数を表す DAU を増やしていくことが重要であることは前々回で述べた通りですが、この DAU を増やすにあたっては、いかに多くの NUU を獲得できるか、ならびにいかに RR を高めて獲得したユーザーに続けてもらえるかが大事になります。

この双方の KPI が十分でないと、そもそもユーザーを獲得できない、もしくは獲得した先からどんどん離脱を招いているという形になり、DAU はなかなか積みあがっていきません。

RR を高めるためには、そもそもユーザーがどのポイントで、どういった理由で離脱しているのかを特定し、それを1つ1つ良くしていくという地道な完全が求められます。ユーザーの離脱原因を特定するのは非常に難しいですが、RR は健全な長期運営に必須の要素ですし、これを向上させる UX の追及は非常に深いトピックですので、ぜひとも開発・運営に携わっている方はより良い UX の追及と RR の向上を目指していってください。

 

バックナンバー

スマホゲームの基本KPI -1. DAU, PUU, ARPU, ARPPU, 課金率-

スマホゲームの基本KPI -2. インストール数, NUU-

スマホゲームの基本KPI -3. RR-

スマホゲームの基本KPI -4. RR変化率-

スマホゲームの基本KPI -2. インストール数, NUU-

f:id:ngyope:20160417155010j:plain

スマホゲームの KPI に関する解説、第2回です。

今回はゲームを遊んでくれる「人」に注目した KPI、インストール数と NUU について解説していきます。

前回と同様、主な読者層としては、将来スマホゲームの業界で働きたいと思っている学生や、入社したてでこれから現場に入っていく新入社員の方などです。

 

基本 KPI 1. -インストール数-

大半のスマホゲームは App Store や Google Play Store などのプラットフォームにて公開されており、そこで日々人々によってインストールされています。

このインストールされた回数を示す指標が、その名の通りインストール数です。誰がインストールしたかを問わず、1回のインストールを1インストールとしてカウントしています。また、インストール数はあくまでインストールされた回数を純粋にカウントするため、同じ人が2回、3回…と複数回インストールした場合は、2回、3回と複数回カウントすることになります。

それゆえに、インスト―ル数は必ずしも新しく入ってきた人の人数を表すわけではなく、通常はその人数よりも大きな値となります。

 

基本 KPI 2. -NUU-

インストール数とは別に、やはりその日に入ってきてくれたユーザーが純粋に何人いたかを把握したいですし、する必要があります。それを示す指標が NUU (エヌユーユー: New Unique Users) です。

NUU はインストール数をもとにした値ですが、同じ人に2回、3回とインストールされた場合でも、新規流入顧客数を示す NUU は 1とカウントします。スマホゲームではチュートリアル後のガチャでいいものを狙ういわゆるリセマラが良く行わるため、新規流入顧客を把握するうえではインストール数よりもこの NUU がよく用いられます。*1

1日の利用者数を表す DAU を増やすためには、いかにしてより多くの NUU を獲得するかがキモとなります。NUU を増やすために、CMやネット広告などの広告を出す、ゲームの記事を出稿してもらう、口コミによる拡大を狙うといったマーケティング施策が主に用いられています。NUU はそのマーケティング施策がどれだけうまくいったかを表す指標としても用いられ、次の施策に生かされているのです。

また、蛇足ですが、NUUとインストール数を組み合わせることでリセマラ率という数字を出すこともできます。式としては NUU ÷ インストール数と単純なもので、インストール全体のうち何%がリセマラによるものなのかを示します。開いているガチャのキャラが強力なものだったりする場合、このリセマラ率は通常跳ね上がります。 

 

おわりに

今回は基本 KPI の中でも「人」の流入と関連の深いインストール数と NUU について見ていきました。プロダクトの拡大を図るにあたって、顧客数を増やすことは非常に重要なため、これらの KPI は DAU や ARPU などと同様に現場では日々欠かさず確認されている数字です。

また、ゲーム中の「人」に着目した重要な指標として、もう 1つ RR (リターンレート: Return Rate) というものがあります。本来ならばこの回で合わせて紹介するべきものですが、RR はゲーム特有の指標でかつ理解が少し難しいもののため、回を分けて解説することにします。 

 

バックナンバー

スマホゲームの基本KPI -1. DAU, PUU, ARPU, ARPPU, 課金率-

スマホゲームの基本KPI -2. インストール数, NUU-

スマホゲームの基本KPI -3. RR-

スマホゲームの基本KPI -4. RR変化率-

*1:ちなみに、会社によって違うかもしれませんが、同一の人による複数回のインストールを NUU = 1 としてカウントする方法として、同一人物による最終インストールにフラグを立てて区別し、それのみを NUU としてカウントするという方法が取られています。同一人物を判別する方法としては、iOS の IDFA や Android の AAID といったものが用いられています。

スマホゲームの基本KPI -1. DAU, PUU, ARPU, ARPPU, 課金率-

f:id:ngyope:20160417155010j:plain

このシリーズでは、スマホゲームのKPI (Key Performance Indicator: 重要業績評価指標) の基本に関して解説していきます。

主な読者層としては、将来スマホゲームの業界で働きたいと思っている学生や、入社したてでこれから現場に入っていく新入社員の方などです。

スマホゲームのKPIに関しては、すでに多くの記事もあるのでご存じの方も多数いらっしゃると思いますが、参考までにご覧ください。*1

スマホゲームのKGI -売上-

KPIの話に入る前に、似たようで別の指標である KGI (Key Goal Indicator: 重要目標達成指標) について軽く触れたいと思います。

KGI とはその名の通り「目標 = Goal」の達成を図る指標で、一番基本的なものとしては「売上」や「利益」があげられます。非営利として開発・運営するならまだしも、商品としてゲームを制作・運営するにあたっては「売上」は無視できない指標なため、売上がプロダクトの最終的な目標として設定されることが大半です。

そして、KPI は KGI を達成するためにその構成要素を分解し、最終目標がどれくらい達成できているか・できそうかを評価するために用いられます。

 

基本 KPI 1. -DAU, ARPU-

では、その「売上」はどのような KPI に分解可能なのでしょうか。

売上を分解する方法はいくつかありますが、最も基本的なものは売上を 顧客数 x 顧客単価 に分解する方法です。スマホゲームでは日次の KPI を追うことが多いため、顧客数は 1日の利用者数、顧客単価は 1日の利用者数の1人あたり売上を指します。前者を業界用語で DAU (ディーエーユー、ダウ: Daily Active Users)、後者を ARPU (エーアールピーユー、アープ: Average Revenue Per User) と呼びます。

日次売上 = DAU (1日の利用者数) x ARPU (1人あたり売上)

 ざっくり述べると、スマホゲームの運営にあたっては、この 2 つの KPI を最大化していくことで 売上の向上を図っていきます。

 

基本 KPI 2. -PUU, ARPPU- 

売上を分解するもう 1つの方法として、売上を課金者数 x 課金者1人あたりの顧客単価に分解するやり方があります。日次ではそれぞれ PUU (ピーユーユー: Paid User)、ARPPU (エーアールピーピーユー: Average Revenue Per Paid User) と呼びます。

日次売上 = PUU (課金者数) x ARPPU (課金者1人あたりの売上)

つまり、お金を払ってくれたユーザーの数と、その方々の平均課金額をかけた合わせることで、売上を出すことが可能というわけです。ダウンロード無料のゲームでは遊んでくれているユーザーを課金者/非課金者と分けられるため、こういった捉え方もあるわけなんです。

 

基本 KPI 3. -課金率-

これまで、DAU, ARPU, PUU, ARPPU と 4つの KPI を見てきました。最後に、これらと関係の深い「課金率」という KPI についてみていきたいと思います。

課金率とは、日次で考えるならば、1日の利用者数のうち何人の方に課金してもらえたかを表す指標です。

課金率 = PUU ÷ DAU

あくまで課金してくれた人数の割合を見るだけなので、課金者の課金額については何も語ってはいません。ですが、例えば 2つの日の課金状況について比較する際、実数値である PUU はそもそもの分母である DAU の大小の影響を受けてしまうため、その影響を除いた課金率で比較することも多く、ゲーム運営の現場ではよく使われる指標です。

 

おわりに

今回は最も基本的な KPI である 5つの KPI について見てきました。ゲーム運営の現場では日々これらの数字を追って現状を把握するとともに、これらの数値を基準に行った施策の振り返りをやっています。

もちろん、現場で使われている KPI はもっとたくさんありますが、ただ何でもかんでも数字を見ればいいのではなく、その数字が KGI にどうつながるのを意識し、その数字がどう変化すればどういうことが言えるのかを意識しつつ、運営を行っていくことが重要です。

 

バックナンバー

スマホゲームの基本KPI -1. DAU, PUU, ARPU, ARPPU, 課金率-

スマホゲームの基本KPI -2. インストール数, NUU-

スマホゲームの基本KPI -3. RR

スマホゲームの基本KPI -4. RR変化率-

*1:本シリーズではダウンロード無料、アイテム課金制のゲームを対象にして話を進めていきます。

SQLを学ぶ上で参考になったものまとめ

自分が SQL を勉強する上で約に立ったサービスや本を紹介します。

業務上 SQL を使うことが多いのですが、基本的なスキルは以下からちゃんと吸収すればしっかり身に着けることができるので、ぜひ参考にしてみてください。

 

ネット情報

まずは ドットインストール

まずはおなじみのドットインストール。
動画を使って、楽しく基礎の基礎を学ぶことができるため、最初のとっかかりとしてはすごくオススメです。

MySQLとPostgreSQLのほかに、SQLiteなんかもあった気がします。

 

MySQL初心者講座

ドットインストールの次に、復習もかねてこのサイトで勉強すれば、さらに基礎の定着が図れること間違いなし!

mysqlweb.net

 

練習問題

練習問題としては、このサイトに掲載されている問題を解きまくれば、さらに腕を磨くことができるでしょう。

テーブルの結合を結構使うことになるので、それまわりの練習にも最適です。

 

書籍

脱初級テキスト

とりあえずネットで基礎を学んだうえで、このテキストの内容を読み進めていくと飛躍的に実力が向上するでしょう。

実際の業務でも使用するようなテクニックはもちろん、DBに関する理論的な話や深い裏話なんかも載っているため、単純に読み物としても学ぶところが多いです。

なるべく標準SQLを使おうというスタイルのため、特定の方言に偏った内容ではありません。

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

 

 

分析系

分析系で参考にするならこのテキストかと。

PostgreSQLを使用した本で、特に WIndow関数あたりは分析を行っていくうえで自由自在に使えるようになったおく必要があります。

現場でも使えるような分析系の集計が主なため、これから分析に挑戦してみようという方は必見ですね。

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)

 

 

その他オススメ記事 

yuranhiko.hatenablog.com

yuranhiko.hatenablog.com

yuranhiko.hatenablog.com

yuranhiko.hatenablog.com

MySQLメモーDAU、課金UU、課金率の集計ー

MySQLを使ってDAU、課金UU、課金率を表示する方法のメモ。

 

使用するテーブル

サンプル用の仮テーブルとして、以下のようなものを想定します。

access_log

f:id:ngyope:20160908231832j:plain

  • d:アクセスした日時
  • access_time:アクセスした時間
  • uid:アクセスしたユーザーのID

 

spend_money_log

f:id:ngyope:20160908231834j:plain

  • d:課金した日時
  • t:課金した時間
  • uid:課金したユーザーのID
  • amount:課金額

 

DAU、課金UU、課金率の集計

MySQLのクエリ

SELECT
accesst.d AS date,
COUNT(DISTINCT accesst.uid) AS dau,
COUNT(DISTINCT moneyt.uid) AS puu,
ROUND(COUNT(DISTINCT moneyt.uid)
/ COUNT(DISTINCT accesst.uid), 2) AS p_rate
FROM
access_log accesst
LEFT OUTER JOIN
spend_money_log moneyt
ON
accesst.d = moneyt.d
GROUP BY
date
ORDER BY
date
;

 

  • まず、access_log と spend_money_log を d(日時)で join
  • DAU:access_log から、日別に DISTINCT で uid を集計
  • 課金UU:spend_money_log から、日別に DISTINCT で uid を集計
  • 課金率:課金UU ÷ DAU

 

集計結果

f:id:ngyope:20160908233542j:plain

R の caret パッケージメモ~train:caret 決定木~

R で "caret" パッケージを使用する際の備忘録です。
今回は "train関数" を使用して決定木の構築を行います。

 

使用するデータ

使用するデータは一般化線形モデルの際にも使用した "Titanic" です。
沈没したタイタニック号の生存者数を「性別」「年齢」「等級」ごとに分類したデータです。

 

データの下準備

データの下準備は、一般化線形モデルを構築した際と同じです。

テーブルを変換する "expand.table関数" を使用しています。

> install.packages("caret")
> library(caret)
> install.packages("epitools") #テーブル変換関数のパッケージ
> library(epitools)

> Titanic1 <- expand.table(Titanic) #テーブル変換
> head(Titanic1)
Class Sex Age Survived
1 1st Male Child Yes
2 1st Male Child Yes
3 1st Male Child Yes
4 1st Male Child Yes
5 1st Male Child Yes
6 1st Male Adult No

 

train関数で rpart を実行

決定木を構築するアルゴリズムには CHAID, C4.5 / C5.0 / See5, CART など様々ありますが、ここでは CART を採用します。
CART で決定木を構築するメソッドは "rpart" です。

> titanic.rp <- train(
data = Titanic1,
Survived ~ Sex + Age + Class,
method = "rpart",)
<以下省略>

 

"rpart" では木の複雑度である "cp" をもとに木をコントロールすることができます。
"train関数" を使った場合は Accuracy に基づいて最も適切な cp を探索し、その最適値で最終的なモデルを出力します。

> titanic.rp
CART

2201 samples
3 predictor
2 classes: 'No', 'Yes'

No pre-processing
Resampling: Bootstrapped (25 reps)
Summary of sample sizes: 2201, 2201, 2201, 2201, 2201, 2201, ...
Resampling results across tuning parameters:

cp Accuracy Kappa
0.01125176 0.7822764 0.4195169
0.02250352 0.7769538 0.4161458
0.30661041 0.7189166 0.1863290

Accuracy was used to select the optimal model using the largest value.
The final value used for the model was cp = 0.01125176.
data = Titanic1,
Survived ~ Sex + Age + Class,
method = "rpart",)

 

 "summary関数" を用いれば、モデルに関して様々な情報を確認することができます。

> summary(titanic.rp)
<以下省略>

 

決定木のプロット

最終的な木のモデルは x$finalModel に格納されています。
ここでは "fancyRpartPlot関数" を用いて木のプロットを行います。

> library(rattle)
> fancyRpartPlot(titanic.rp$finalModel)

 

f:id:ngyope:20160830124513j:plain

R の caret パッケージメモ~train:caret 一般化線形モデル~

R で "caret" パッケージを使用する際の備忘録です。
今回は "train関数" を使用して一般化線形モデルで回帰分析を行います。

 

使用するデータ

使用するデータは "Titanic" です。
沈没したタイタニック号の生存者数を「性別」「年齢」「等級」ごとに分類したデータです。

 

データの下準備

いつも通り、"caret" パッケージをライブラリ化します。

また、"Titanic" のデータはそのままでは使いづらいため、テーブル変換用の関数を使って使いやすい形に変換します。

> install.packages("caret")
> library(caret)
> install.packages("epitools") #テーブル変換関数のパッケージ
> library(epitools)

> Titanic1 <- expand.table(Titanic) #テーブル変換
> head(Titanic1)
Class Sex Age Survived
1 1st Male Child Yes
2 1st Male Child Yes
3 1st Male Child Yes
4 1st Male Child Yes
5 1st Male Child Yes
6 1st Male Adult No

 

train関数でglmを実行

一般化線形モデルを指定するメソッドは "glm" です。
一般化線形モデルはパラメータ調整が必要ないため、コードは以下の通りとなります。
ロジスティック回帰分析を行うため、family は「二項分布 "binomial()"」を指定します。

titanic.glm <- train(
data = Titanic1,
Survived ~ Sex + Age + Class,
method = "glm",
family = binomial())
<以下省略>

 

Accuracy は約78%ということでボチボチかなと思います。

> titanic.glm
Generalized Linear Model
2201 samples
3 predictor
2 classes: 'No', 'Yes'
No pre-processing
Resampling: Bootstrapped (25 reps)
Summary of sample sizes: 2201, 2201, 2201, 2201, 2201, 2201, ...
Resampling results:
Accuracy Kappa
0.7772942 0.4447814

 

summary関数を使ったあとは、普通の glm関数と同じですね。

> summary(titanic.glm)
Call:
NULL
Deviance Residuals: 
Min 1Q Median 3Q Max 
-2.0812 -0.7149 -0.6656 0.6858 2.1278
Coefficients:
Estimate Std. Error z value Pr(>|z|) 
(Intercept) 0.6853 0.2730 2.510 0.0121 * 
SexFemale 2.4201 0.1404 17.236 < 2e-16 ***
AgeAdult -1.0615 0.2440 -4.350 1.36e-05 ***
Class2nd -1.0181 0.1960 -5.194 2.05e-07 ***
Class3rd -1.7778 0.1716 -10.362 < 2e-16 ***
ClassCrew -0.8577 0.1573 -5.451 5.00e-08 ***
---
Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
(Dispersion parameter for binomial family taken to be 1)
Null deviance: 2769.5 on 2200 degrees of freedom
Residual deviance: 2210.1 on 2195 degrees of freedom
AIC: 2222.1
Number of Fisher Scoring iterations: 4

 

メソッドで "glmStepAIC" を選択する

メソッドで "glmStepAIC" を選択すると、AIC (赤池情報量規準) に基づいて変数選択を行い、最適なモデルを構築してくれるので便利です。

titanic.glm <- train(
data = Titanic1,
Survived ~ Sex + Age + Class,
method = "glmStepAIC", #AICに基づきモデル構築
family = binomial())
<以下省略>