伴随着大家对成长黑客Growth Hacker的关注，AARRR运营模型也被提高到非常重要的层面。然而，运营是需要技术层面支撑的，没有技术支撑，AARRR恐难以真正有效。所以， 在做移动产品架构设计的时候，AARRR 应该作为一个新的非功能需求（http://blog.csdn.net/wireless_com/article/details/45935591），给予必要的考虑。
什么是AARRR？
AARRR是Acquisition、Activation、Retention、Revenue、Refer，这个五个单词的缩写，分别对应这一款移动应用生命周期中的5个重要环节。（参见 baike.baidu.com）
- Acquisition: 用户获取
- Activation： 提高活跃
- Retention： 提高留存
- Revenue： 获取收入
- Refer： 自传播
用户获取
如何确定典型用户的类型呢？ 用户的属性是否会产生变化？ 用户的数据是核心数据， 从架构层面要给予高安全等级，面对可扩展性和性能，存储考虑关系型数据库与NoSQL的融合。
关注冷启动？ 为爬虫脚步建立接口，和特殊标识。
下载绑定？ 独立的下载服务器是必须的，对着陆页的多平台适配要关注。
使引流更有趣？ 提供可嵌入式的代码。
提高活跃
AB测试？架构中提高HTML5 混合编程的比例
观察用户反应？关注灰度升级和增量升级
提高趣味性？ 融入游戏化引擎的架构
及时响应？ 自动化运行的脚本或机器人
提高留存
bug ？ 引入CrashAnalysitic，或者其它第三方工具
性能瓶颈？ 考虑引入听云之类性能分析工具的必要性，或者考虑架构上QoS
对新用户的快速引导？减少首次输入的数量，提供长期补全的机制
社交维系？ 必备第三方平台接口，引入交叉绑定
获取收入
免费？关注交叉补贴及三方市场的外部接口
收费？必备支付宝，微信支付，apple pay 的接口服务
递推？ 建立有效的线下推广的评估系统平台
自传播
Bug 营销？ 关注自己预留的坑，尤其是功能开关
推荐码？ 推荐码的系统性构建
成就分享？ H5 的重用
......
随手涂鸦，缺乏系统性架构的思路和方法论，仅做备忘录吧，毕竟功能性需求是第一位的！