今回は「KPI（ケーピーアイ）」についての紹介です。
3行にまとめると？
・KPIとは、重要業績評価指標（Key Performance Indicators）の略
・プロセスの進捗を確認するための指標の中で、特に重要なものを指す
・運営指針となる数値で、運営は日々この数値の変化を追いかけて対策を練る
KPIの種類
新規インストール数
AppleとGoogleの管理ツールからデータを取得する。
Googleは前日までのデータが見れるが、Appleは2日遅れでデータが反映する。
ただ、Googleはアメリカ西海岸時間で集計するため、日本で行った広告などによるインストール数の増加の反映に時差が出る。
新規登録数
新規インストール数と違い、新規でゲーム内の「ゲームID」を発行したユーザーの数。
ダウンロードをしてもゲームをしないユーザーも多く、アプリによってはインストール数に対してゲームIDの発行が70％ほどのアプリも多い。（＝30％がゲームID発行の前にゲームを止めている。リワード広告を出稿した場合は、もっと多くなるケースが多い）
DAU
DAUとは「Daily Active User」の略で、集計対象の日にゲームにログインしたユーザー数のこと。
アクティブユーザーの指標として一番多く使われている。
以前は下記のWAUやMAUなども多く使われていたが、ソーシャルゲームはサイクルが早く、週単位、月単位で見ていくと正しい判断ができないため1日単位のDAUが使われている。
WAU
DAUとは「Weekly Active Users」の略で、集計対象の週に1度でもゲームにログインしたユーザー数のこと。
実際の運営現場では、あまり使われず、上のDAUか次のMAUが使われるケースが多い。
MAU
MAUとは「Monthly Active Users」の略で、集計対象の月に1度でもゲームにログインしたユーザー数のこと。
1ヶ月間に1度でもログインするとカウントされるため、DAUよりも圧倒的に多い。
ARPU
ARPUとは「Average Revenue Per User」の略で、ユーザー1人あたりの平均課金額。
計算式は、「1日の売上」÷「DAU」
この数値から、DAUをどれだけ増やせば売り上げがどれくらい増えるかの推測ができるようになる。
ARPPU
ARPPUとは「Average Revenue Per Paid User」の略で、課金ユーザー1人あたりの平均課金額。
ARPUは、その日にログインした全ユーザーを母数として売上金額を割るのに対し、ARPPUは、その日に課金したユーザーを母数として売上金額を割るとの違いがある。
計算式は、「1日の売上」÷「課金ユーザー数」
ARPPUは高いほど売上げも上がるが、高すぎるとユーザーに過度な負担をかけている可能性が高く、その後は離脱率が高くなる傾向がある。
課金率
1日の課金ユーザー数（ユニーク）をDAUで割ったもの。
計算式は、「1日の課金ユーザー数（ユニーク）」 ÷ 「 DAU」
この割合が高いアプリの方が、ユーザーから「おもしろい」と感じられている可能性が高い。
広告出稿やキャンペーンに掛けたコストに対して、売り上げの見積もりを作るときの参考指標。
友達招待数
ゲームの招待システムを使って、友達招待を行ったユーザー数の数。
ゲーム自体の人気が高ければ高いほど、招待者数も多くなる傾向がある。
AppleのシリアルコードNGの影響で今後は減ってくる可能性が高い。
被招待者数
ゲームの招待システムを使って友達招待されて、登録したユーザーの数。
1人で複数の招待を行うことが可能なため、友達招待数よりは多くなる。
チュートリアル突破率
新規ダウンロード数に対する、ゲームの最初にあるチュートリアル（ナビゲーターが操作方法を説明するパート）を終了したユーザーの割合。
ここが低いと、チュートリアルが長すぎるか、分かりにくいなどの問題が潜んでいることが多い。
継続率
新規登録したユーザーが、ある日数（n日）後にログインしている割合。
計算式は、「n日後のログインユーザー数」÷「基準日の新規登録者数」
例えば1月1日に100人のユーザーが新規登録（新規ダウンロードではない）したとして、そのユーザーが3日後の1月4日に25人ログインしていた場合、継続率は25％。
売上
ガチャやゲーム内アイテムの販売金額。
これはプロセス管理の指標であるKPIではなく、目標を管理する「KGI（Key Goal Indicator）」と呼ばれる指標になる。
まとめ
PDCA
KPIは、運営担当にとって『羅針盤』のようなもので、これがなければ、どこを改善すれば良いか分からない重要な指標です。
この数値を毎日追いかけ、その傾向からユーザーの考え（ユーザーインサイト）の仮説を立てます。
たとえば、「チュートリアル突破率」が4ステップあるうちの3ステップ目で急激に落ちている場合、その箇所に問題があることが予想され、その3ステップ目の改修、もしくは短縮などの対応を行い、その後の推移をみます。（検証）
想定通り数値が改善されれば別の問題に取り組み、改善しない場合は別の対応を行うか、別の原因の可能性を考えて新しい仮説を立て検証していきます。
このように、PDCAのサイクルをドンドン回していくことで、より良い数値が得られるように運営は日々努力しています。