Xcoder @ TW

什么是AARRR模型

AARRR是Acquisition、Activation、Retention、Revenue、Refer，这个五个单词的所写，分别对应这一款移动应用生命周期中的5个重要环节。下面我们来简单讲解一下AARRR模型中每个项目的意义。

获取用户（Acquisition）
运营一款移动应用的第一步，毫无疑问是获取用户，也就是大家通常所说的推广。如果没有用户，就谈不上运营。

提高活跃度（Activation）
很多用户可能是通过终端预置（刷机）、广告等不同的渠道进入应用的，这些用户是被动地进入应用的。如何把他们转化为活跃用户，是运营者面临的第一个问题。
当然，这里面一个重要的因素是推广渠道的质量。差的推广渠道带来的是大量的一次性用户，也就是那种启动一次，但是再也不会使用的那种用户。严格意义上说，这种不能算是真正的用户。好的推广渠道往往是有针对性地圈定了目标人群，他们带来的用户和应用设计时设定的目标人群有很大吻合度，这样的用户通常比较容易成为活跃用户。另外，挑选推广渠道的时候一定要先分析自己应用的特性（例如是否小众应用）以及目标人群。对别人来说是个好的推广渠道，对你却不一定合适。
另一个重要的因素是产品本身是否能在最初使用的几十秒钟内抓住用户。再有内涵的应用，如果给人的第一印象不好，也会“相亲”失败，成为“嫁不出去的老大难”。
此外，还有些应用会通过体验良好的新手教程来吸引新用户，这在游戏行业尤其突出。

提高留存率（Retention）
有些应用在解决了活跃度的问题以后，又发现了另一个问题：“用户来得快、走得也快”。有时候我们也说是这款应用没有用户粘性。
我们都知道，通常保留一个老客户的成本要远远低于获取一个新客户的成本。所以狗熊掰玉米（拿一个、丢一个）的情况是应用运营的大忌。但是很多应用确实并不清楚用户是在什么时间流失的，于是一方面他们不断地开拓新用户，另一方面又不断地有大量用户流失。
解决这个问题首先需要通过日留存率、周留存率、月留存率等指标监控应用的用户流失情况，并采取相应的手段在用户流失之前，激励这些用户继续使用应用。
留存率跟应用的类型也有很大关系。通常来说，工具类应用的首月留存率可能普遍比游戏类的首月流存率要高。

获取收入（Revenue）
获取收入其实是应用运营最核心的一块。极少有人开发一款应用只是纯粹出于兴趣，绝大多数开发者最关心的就是收入。即使是免费应用，也应该有其盈利的模式。
收入有很多种来源，主要的有三种：付费应用、应用内付费、以及广告。付费应用在国内的接受程度很低，包括Google Play Store在中国也只推免费应用。在国内，广告是大部分开发者的收入来源，而应用内付费目前在游戏行业应用比较多。
无论是以上哪一种，收入都直接或间接来自用户。所以，前面所提的提高活跃度、提高留存率，对获取收入来说，是必需的基础。用户基数大了，收入才有可能上量。

自传播（Refer）
以前的运营模型到第四个层次就结束了，但是社交网络的兴起，使得运营增加了一个方面，就是基于社交网络的病毒式传播，这已经成为获取用户的一个新途径。这个方式的成本很低，而且效果有可能非常好；唯一的前提是产品自身要足够好，有很好的口碑。
从自传播到再次获取新用户，应用运营形成了一个螺旋式上升的轨道。而那些优秀的应用就很好地利用了这个轨道，不断扩大自己的用户群体。
通过上述这个AARRR模型，我们看到获取用户（推广）只是整个应用运营中的第一步，好戏都还在后头。如果只看推广，不重视运管中的其它几个层次，任由用户自生自灭，那么应用的前景必定是暗淡的。

如何使用AARRR模型
通常大家在推广应用时，头痛的是后台统计的激活量比渠道提供的下载量小很多。但是前几天，有一位朋友找我咨询，说他们公司的一款App来自某个渠道的激活量突然猛增。但是他查了在那个渠道（是家应用市场）上的下载量，并没有明显的变化。于是他非常困惑，问我有没有办法帮他查到原因。
少了多了都会让人头痛——因为数据出现异常，通常就说明有某个环节出了问题。但是光看一个激活量和一个下载量，并不能揭示问题的根本原因。尤其是当我们已经了解了移动应用运营模型时，我们更需要了解在AARRR的每个环节中，我们应当关注什么样的数据，什么样的数据表现才是正常的——简单来说，只知道AARRR还不够，还要会用才行。

一、获取用户（Acquisition）
这个阶段，最初大家最关心的数据是下载量。到今天，一些媒体的报道中也还经常用下载量来衡量一个应用的用户规模和是否成功。不过，下载了应用不等于一定会安装，安装了应用也不等于一定使用了该应用。所以很快激活量成为了这个层次中大家最关心的数据，甚至是有些推广人员唯一关注的数据。通常激活量（即新增用户数量）的定义是新增的启动了该应用的独立设备的个数。从字面上看激活量似乎更应该是第二层Activation的指标，但是因为下载量、安装量这些数据都比较虚，不能真实反映用户是否已经被获取。所以大家都要看激活，这才是真正获取到了新的用户。
另一个非常重要的数据，就是分渠道统计的激活量。因为在渠道推广时，很多应用开发者选择了付费推广。结算的时候，自然要了解在某个渠道有多少真正激活的用户。即使没有付费关系，开发者也需要知道哪个渠道是最有效果的。
但是站在更高的高度看，CAC（用户获取成本 Customer Acquisition Cost）才是最需要去关注的数据。目前行业里有种粗略的说法，每个Android用户的获取成本大约在4元左右，而iOS用户大约在8元以上。当然，应用市场下载、手机预置、广告等各种不同的渠道的获取成本是完全不同的。这里面有个性价比的问题，有些渠道的获取成本比较高，但是用户质量也比较高（什么样的叫质量高，后面会有说明）。

二、提高活跃度（Activation）
看到活跃度，大家首先会想到的指标是DAU（日活跃用户）、MAU（月活跃用户）。这两个数据基本上说明了应用当前的用户群规模，在网络游戏行业这是两个运营人员必看的指标。通常活跃用户是指在指定周期内有启动的用户。但是启动是否真的等于活跃呢？如果在指定周期内只启动了一次，而且时间很短，这样的用户活跃度其实并不高（当然对某些特殊的应用来说可能算高，例如用来记录女性生理周期的应用，一月启动一次就够了）。所以其实还要看另两个指标：每次启动平均使用时长和每个用户每日平均启动次数。当这两个指标都处于上涨趋势时，可以肯定应用的用户活跃度在增加。
针对使用时长和启动次数的渠道统计同样很重要。我们把它们称为渠道的质量数据，如果某个渠道上来的用户，这两个指标很差，那么在这个渠道上投入太多是没有意义的。最典型的就是水货刷机的用户，很多预置的应用都是在刷机完成时被激活的。针对这种被动激活的用户，可以看另一个指标，叫一次性启动用户数量，也就是迄今为止只启动过一次的用户的数量。
除了渠道，另一个和活跃度相关的分析维度是版本。各个版本的使用时长和启动次数也会有差异。对产品经理来说，分析不同版本的活跃度差异有助于不断改进应用。
此外跟活跃度相关的，还有日活跃率、周活跃率、月活跃率这些指标。当然活跃率和应用的类别是很有关系的，比如桌面、省电类的应用的活跃率就比字典类的应用高。

三、提高留存率（Retention）
下载和安装——使用——卸载或者遗忘，这是用户在每个应用中的生命周期。成功的应用就是那些能尽量延长用户的生命周期，最大化用户在此生命周期内的价值（下一节会谈到生命周期价值这个话题）的应用。
对于大部分应用，应该关心的是1-Day Retention 和7-Day Retention。这里我之所以用英文，是因为其中文翻译不统一，容易引起歧义。1-Day Retention通常翻译为首日留存率，其实这个“首日”并不是指应用被安装使用的第一天（假设日期为D），而是D+1日，即安装使用的第二天。因为安装使用的第一天没有留存率这个概念（有的话，只能是100%）。到了第二天，前一天安装使用的用户中还有多少百分比的人还在启动使用这款应用，这就是1-Day Retention。因为是第二天，所以有些文章中也叫“次日留存率”。同样的，7-Day Retention是在D+7日启动使用这款应用的占D日首次安装使用这款应用的用户总数的百分比。通常用户新安装使用后的前几天是流失比例最大的时期（关于用户留存的细节，请参考我们同事的另一篇博客《读懂你的用户留存》）。所以这两个指标在留存率分析是最重要的。曾经有游戏行业的行家指出，如果想成为一款成功的游戏，1-Day Retention要达到40%， 7-Day Retention要达到 20%。
有些应用不是需要每日启动的，那样的话可以看周留存率、月留存率等指标，会更有意义。留存率也是检验渠道的用户质量的重要指标，如果同一个应用的某个渠道的首日留存率比其它渠道低很多，那么这个渠道的质量是比较差的。

四、获取收入（Revenue）
关于收入，大家最耳熟能详的指标就是ARPU（平均每用户收入）值。对应的比较少提的还有个指标叫ARPPU（平均每付费用户收入）。前几天，@吴刚在微博里贴图比较二战风云的ARPU值时就注明了是周付费用户ARPU（所以其实是ARPPU）。但是很多人误读了以为是六十多元的周ARPU值，就会让他们对Android游戏产生过分的乐观。
是不是ARPPU高，ARPU就一定会高呢？答案是不一定。因为其中还有个指标是付费用户比例，也就是付费用户在全部用户中所占的比例。如果付费用户比例较低，那么那些收入摊到所有用户身上的平均值就低了。通常来说，如果某个游戏为了提高ARPPU，提高了虚拟道具的价格，那么付费用户比例就会相应地降低。找到一个ARPPU和付费用户比例的平衡点，才能最大化收入。
但是收入并不是最重要的，利润才是。如何最大化利润呢？利润最简化的计算公式是：利润=收入-成本。首先我们看一下成本，我们在上一篇中提到过CAC（用户获取成本）。除此之外，还有应用本身的开发成本、服务器硬件和带宽成本以及运营成本等等。不过在用户量很大的情况下，CAC会成为最主要的成本，而其它成本不在一个数量级，所以我们在后续讨论中只考虑CAC。
那么收入如何计算？ ARPU是一个和时间段相关的指标（通常讲的最多是每月的ARPU值），还不能完全和CAC对应，因为CAC和时间段并没有直接关系。所以我们还要多看一个指标：LTV（生命周期价值）。用户的生命周期是指一个用户从第一次启动应用，到最后一次启动应用之间的周期。LTV就是某个用户在生命周期内为该应用创造的收入总计，可以看成是一个长期累计的ARPU值。每个用户平均的LTV = 每月ARPU * 用户按月计的平均生命周期。
LTV – CAC的差值，就可以视为该应用从每个用户身上获取的利润。所以最大化利润，就变成如何在降低CAC的同时，提高LTV，使得这两者之间的差值最大化。更进一步的，对不同渠道来源用户做断代分析，根据他们不同的CAC和LTV，就可以推导出不同渠道来源的利润率差异。

五、自传播（Refer）

自传播，或者说病毒式营销，是最近十年才被广泛研究的营销方法。虽然大家都听过一些病毒式营销的经典案例，但是要说怎样量化评估其效果，却很少有人知道K因子(K-factor)这个衡量指标。其实K因子这个术语并非起源于市场学或软件业，而是来源于传染病学——对，就是研究真正的病毒传播的科学。K因子量化了感染的概率，即一个已经感染了病毒的宿主所能接触到的所有宿主中，会有多少宿主被其传染上病毒。
K因子的计算公式不算复杂，K = (每个用户向他的朋友们发出的邀请的数量) * (接收到邀请的人转化为新用户的转化率)。假设平均每个用户会向20个朋友发出邀请，而平均的转化率为10%的话，K =20*10%=2。这个结果还算是不错的效果——当K>1时，用户群就会象滚雪球一样增大。如果K<1的话，那么用户群到某个规模时就会停止通过自传播增长。
很遗憾的是，即使是社交类的移动应用，目前K因子大于1的也很少。所以绝大部分移动应用还不能完全依赖于自传播，还必须和其它营销方式结合。但是从产品设计阶段就加入有利于自传播的功能，还是有必要的，毕竟这种免费的推广方式可以部分地减少CAC。

以上我们列举了在应用推广运营各个层次（各个阶段）需要关注的一些指标。在整个AARRR模型中，这些量化指标都具有很重要的地位，而且很多指标的影响力是跨多个层次的。及时准确地获取这些指标的具体数据，对于应用的成功运营是必不可少的。

參考這裡

使用 mysql 配合 innodb 引擎在預設的情況下所有的資料都會儲存在 ibdata1

用久了這個檔案會很大，比較好的作法是把每個資料庫的 ibdata 各別儲存。

先備份全部資料庫

mysqldump -u root -p --all-databases > /home/backup/all.sql

找到 my.cnf 或是 my.ini 並加入 innodb_file_per_table=1
以我使用 EC2 自架 mysql 來說是 /etc/my.cnf
重啟資料庫 #service mysqld restart
進入資料庫

#mysql -uroot -ppassword

檢查是否開啟分類儲存功能

mysql> show variables like '%per_table%';

若已開啟會長得像

+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+

再來把 ibdata1 以及 ib_logfile* 刪掉，此時進入資料庫應該就是空空的了
在還原之前最好先停止網路服務，我曾經還原到一半 ec2 就斷線當機給我看

#service httpd stop

還原

mysql -uroot -p < /home/backup/all.sql

啟用 innodb_file_per_table 後，當刪除資料表(DROP TABLE)、清空資料表(TRUNCATE TABLE)，佔用的空見會自動縮減。刪除資料表資料(DELETE)，則執行 OPTIMIZE TABLE 來縮減資料表空間。

OPTIMIZE TABLE 資料表名稱

最後補充一下使用別人整理的 innodb_file_per_table 的好處

1. 如果使用軟鏈結將大表分配到不同的分區上，易於管理資料文件
2. 易於監控解决IO資源使用的问题
3. 易於修復和恢復損壞的資料
3.1 相互獨立，不影響其他innodb表
3.2 導出導入針對單一table，而不是整個共享table
4. 解決單一文件大小的限制
5. 對於大量的delete操作，更易回收磁碟空間
6. 碎片較少，易於整理optimize table
7. 易於安全檢查
8. 易於備份

Xcoder @ TW

2015年9月11日星期五

分析 access_log

2015年6月30日星期二

About ASO

2015年6月25日星期四

AARRR Model

2015年6月9日星期二

Facebook 權限審核

2015年6月4日星期四

App Deeplink

2015年3月16日星期一

使用自訂 xib 搭配 Autolayout

2014年12月12日星期五

使用 innodb_file_per_table 解決 ibdata1 單一且過大

2015年9月11日 星期五