拒绝僵尸-移动App数据分析之道
QCon演讲者：陆兴海（英文名：Yak，微信：yak1982）
2007年硕士毕业于西北工业大学，信息化技术研究方向。工作从事软件产品设计开发多年，现任云智慧产品总监，致力于面向大数据的IT系统监控软件以及应用性能管理（APM）平台的规划、设计与传播。热爱互联网，专注产品设计，喜欢云计算，关注大数据，对一切新鲜事物都抱有好奇心
谢谢主持人，谢谢Qcon大会能给一个这样好的机会和大家一些沟通和分享一些知识；
我今天的题目是拒绝僵尸，移动App数据分析之道，那在开始之前，还是简单介绍一下我自己
我的大名叫陆兴海，在云智慧负责技术产品这块；
同时还有个网名叫产品经理朝阳陆，大家可能听过一个网站叫“人人都是产品经理”；
我个人平时喜欢写一些文字和大家分享，大家有兴趣可以去这个网站搜索一下；
有机会我们可以就产品设计的一些知识进行交流；
同时呢，我也是大数据文摘公众号的翻译志愿者，平时在文摘里做一些翻译和校对的工作；
也希望大家多多关注，并且有兴趣参加这个组织，结交一些好朋友，牛人；
好的，我们回到今天会议的主题；
不需多说，我们今天，大家身处的世界——我们都在云里畅享移动互联；
人们每天起床是被App叫醒，睡觉前放下的最后一件东西是手机；
地铁公交上满是低头族；
当我们在感慨人心不古的时候，更多的创业者看到的是机会，大好的创新机会；
国外有人在2013年时候提到一个口号叫：DEVELOP FOR MOBILE OR DIE!
充分证明移动开发的重要性，要想在当前时代快速捞金，
移动互联网无非是非常好的切入点；
我们敢肯定，再做的各位，很多都是在创业，或者打算创业；都在路上；
那如何能够在创业的路上走的更稳，风险更小，实际上，这就是我今天想和大家一起分享的话题；
我们敢肯定，再做的各位，很多都是在创业，或者打算创业；
因为很多朋友都是开发人员，开发人员创业时候的思路可能会有一些局限性，可能一下子更关心纯技术领域的；
——其实今天我不会太打广告，说我们厂商自己的东西，而是想从更高的一个level来和大家一起思考；
我是想把整个App生命周期内的各种环节，以及每个环节的工作怎么结合数据分析和大家一起探讨；
那我们看，相对于传统的Web类应用，移动App的开发特点：
生命周期更短；这意味着给我们创业公司的时间；更紧张
迭代周期更快，这个不必细说，竞争如此激烈，我们必须快速的响应市场；
开发成本更高，这个看拉勾网上相关职位描述就能看到了；
这导致了什么样的结果呢？
在移动互联网大潮来临的时候，很多人没有成为先驱，
反而成为了先烈；
就是这样悲惨的结局；
移动开发遭遇了见光死；
App出来没几天就销声匿迹了；
我身边有好几个朋友，他们有着很好的想法，也很勤奋；
但是都是这样的命运；
都是这样的情况；
这样的情况个人或者公司一共有多少？320万！
那我们看一组数据，一个App的生命周期只有10个月；
85%的用户会在一个月内将其删除，5个月后留存率之后5%；
更有很多App出生就逃脱不了死亡的悲剧；
虽然可以下载，但是早已无人问津了；
我们自己看看手机上的App，实际上常见的就那么几个；
我们能想象每一个创业者在最开始时候突然萌发了一个伟大梦想的激动
也理解每一个创业过程中的艰辛和泪水；
但事实是残酷的，怎么破？
这里给大家一个问题，哪类App死亡率最高？
正是因为移动开发有刚才说到那些的特点，
试错是一个很好的选择；
利用少量的资源来快速试错，试探反应，代价最小；
我们不妨看看纸牌屋给我们带来的启示，相信很多朋友都看过这部美剧；
这是一部典型的大数据算出来的电视剧
投资方Netflix甚至在《纸牌屋》开播前就知道该剧一定会火；
包含了3000万用户的收视选择、400万条评论、300万次主题搜索。最终，拍什么、谁来拍、谁来演、怎么播，
都由数千万观众的客观喜好统计决定，而不是由编剧和导演决定的；
这简直是不火都没有道理；
这里打个岔，大数据电影有一部经典片，叫点球成金，讲的是一个棒球教练利用数据分析的方法，成功塑造了一个球队，赢得冠军的故事；
有兴趣的朋友可以看看；
所以，快速试错比完美设计更重要，
而作为移动开发者，从萌发念头的那一刻起
数据分析就要开始了；
那移动App研发的一共有哪些环节，每个环节需要哪些什么样的数据分析呢？
我们不妨看一下移动App数据分析生命周期在各个环节上的工作要点：
在立项和概念阶段，我们需要对用户与产品进行分析；
在技术选项和方案阶段，我们需要对整体技术进行评估；
在团队组建阶段，我们会对人员的效能进行考核；
在产品上线之后，需要进行推广以及进行后续的运营数据分析；
同时能也需要对App的性能和用户体验数据进行分析；
当有了很好的想法之后，如果不对用户和市场进行深入分析，往往会死的很惨；
这点的反面例子很多，比如计划FM，
创业的本质对于我们自己而言是要赚钱、出名、上市。。。
但是前提一定在于为别人带来新的价值，服务他人。需求的挖掘十分重要。人性虽然复杂，然而需求往往是简单，直接的。
有些点子即使很好，但是如果用户的学习成本和限制条件较多，那么除非有充裕的资本推广，否则很难成功。
产品与用户分析方法，实际上有很多，比如我们经常见的MRD,但是MRD我写过不少，但是还是有些不足，就是不太量化；
这里给大家介绍的是一种比较经典，也比较传统的一种；
IBM在2012年提出的产品差异化模型($appeals)；
这个也是我在上一家公司，每年做公司预算时的通用做法；
$这个不用解释，代表金钱，但是包含非常广泛，不只是代表产品的收费售价，还包括你的用户获取成本开发及推广成本等多个因素；
Availability代表可靠性方面；
Packaging代表产品的包装，，外观以及视觉设计；
Performance代表客户期待的功能和性能；
当产品的市场定位、用户和需求分析等问题有了比较量化的考核和分析之后，
我们从实现的角度就要考虑技术问题；
当前移动开发有很多开源和商业的框架；比如从大的说，是native的还是H5的？
从细化来说，你采用什么样的第三方类库？网络的、缓存的、注解的。。。
同时我们也看到很多今天参会的友商，比如apicloud、appcan、云之讯，他们都从不同的角度和层面提供了自己的解决方案；
我们怎么选？怎么评估？
患有选择恐惧症的人怎么办？
哦，这里打个岔，我在人人都是产品经理中有一篇文章，专门写了选择恐惧症和产品设计的关系，
有兴趣的同学可以搜索看看；
这里还是说一些我们当初掉的坑，和大家一起回顾与反思问题；
当时在上一家公司的时候，2014年初，决定做一款app，
技术团队都在纠结选H5还是native，后来。。。。。
另外给大家的建议是，不要过度为将来考虑。。。。这里举聚美优品架构师的例子；
选择框架的原则是，快，哪些现有的技术能够实现，团队已经掌握或者学习成本低，那就是它；
积木柯林斯在从优秀到卓越一书中提到一个故事；一个海军上尉找销售工作的故事
选择合适的人，而不是当前他熟悉的技能；
其实这块是我讲的最纠结的地方
因为当人作为被考评的主体时候，很多事情不确定性很大；
讲何两年的例子；
