1. 什么是留存？

任何应用都希望用户数能快速增长，不过单纯吸引新用户并非最明智的做法。无论是靠流量还是靠付费生存的应用，都需要保持用户的活跃度。一旦用户的活跃度下降，就意味着用户的离开或流失。基于此，我们引入“留存”的概念。

用户在某段时间内开始使用应用，经过一段时间后，仍然继续使用应用的被认作是留存；这部分用户占当时新增用户的比例即是留存率。顾名思义，留存指的就是“有多少用户留下来了”。留存用户和留存率体现了应用的质量和保留用户的能力。

2. 留存用户的报表

首先，您可以选择查看哪个渠道的用户留存率以及查看哪个时段内的用户留存率。

确定了查询范围后，您还需要选择查询的时间颗粒度，即按自然周或按自然月来计算留存率。如果选择按自然周查看，那么报表会依次显示所选时段所在的每个自然周的新增用户数，及该周的新增用户在1周后、2周后、…、8周后的留存率。留存率越高，色块的颜色越深。

选择按自然月查看与此类似，不再赘述。

3. 用户留存分析

通过用户留存报表，可以大致掌握对每周（月）的新增用户在n周（月）后的用户衰减情况。当某周（月）的新增用户的衰减情况相比平时出现波动时需特别留意，尤其是在应用发布新版或进行推广等活动之后。例如，您在3月12日 ~ 3月18日发布了新版本应用，随后发现新用户在1周后、2周后、3周后的留存率普遍低于先前，那么就应该思考新版应用在哪些方面可能出了问题，是新UI不受欢迎还是新功能的引导不够等等。

此外，还可以通过比较对不同渠道在固定时间长度后的用户留存率来评估渠道用户的质量。比如渠道1的每月新增用户在3个月后的留存率保持在30%左右，而渠道2的每月新增用户在3个月后的留存率大概是20%，两个渠道的新增用户数量差不多，但渠道1的用户质量优于渠道2。

更多关于友盟统计分析2.0的内容欢迎访问我们的Demo演示地址！

Demo演示地址：http://www.umeng.com/apps/9c00001132510725518564f4/reports?s=blog

在全体友盟人的努力下，友盟统计2.0终于在大家的期待下正式发布了！

友盟统计2.0界面清新、大方，功能更加完善、实用。帮助您从“数量运营”过渡到“质量运营”，全面深入的把握需求，创造更多价值。

欢迎大家体验2.0，也希望大家为我们提出更多的宝贵意见！

1.全新视觉及交互

（1） 优化左侧导航，查询维度的选择统一置于顶部，界面更加简洁大气。

（2）增加提示信息、重点指标注释及常见名词解释，让报告更易懂。

2.  新增核心功能

（1）留存用户分析，掌握不同渠道新增用户的留存情况，从而评估渠道质量及营销效果。

（2）漏斗模型，通过对关键路径的转化率分析，来定位流程中可能出现的问题，进而提高最终目标的转化率。

（3）增加周活跃用户、月活跃用户、周活跃率、月活跃率等数据，丰富应用的评价指标，让您的运营更游刃有余。

3. 关键功能升级

（1）渠道分析中增加更多记录用户行为、衡量用户忠诚度的数据指标，如启动次数、平均使用时长、活跃率、留存率；还支持渠道新增用户与设备、地域、应用版本的交叉分析。

（2）新版SDK强化了对自定义事件的统计，增加了对事件时长的统计和事件相关属性的统计。

2011年，小米手机因超高的性价比很快受到了无数粉丝的狂热追捧，从而迅速走红。历经高调的“雷布斯”式的发布会、工程机秒杀、量产机预定等阶段后，小米手机终于在2011年12月18日开始第一轮开放购买。再加上1月4日第二轮开放购买的10万台和1月11日的50万台，小米手机的出货量预计会超过90万台。但是，国产的小米手机到底怎么样了？是否有大家说的那么神？它到底有多火？

根据友盟统计分析平台的数据，我们对2011年12月15日到2011年12月31日期间小米手机的市场表现进行了研究。发现，由于2011年12月5日之后每天发货1.5万台，所以小米的日新增用户比例保持着强劲的势头；2011年12月18日，小米开始第一轮开放购买10万台，19日和20日的日新增比例到达了区间内的峰值；小米手机在日新增Android用户TOP 10机型排行中一直位于第四位，位于Lenovo A60、Galaxy Ace和 Galaxy SII之后。

那么，哪些地区的用户更喜欢小米手机呢？

通过我们对数据的分析可以很容易看出，北京和浙江两地的用户更喜欢小米手机。从小米手机占新增用户的份额看，北京和浙江两地的的份额分别占到了4.7%和4.1%。

2011年12月18日，也许应该是小米公司值得记住的日子。小米手机首批开放购买10万台，日新增用户产生了爆发式的增长。我们以12月18日为时间坐标，研究了其前后的平均日新增用户发现18日之后的日新增用户数量是18日之前的4倍。

从数据中不难看出，小米手机在短短的时间内确实取得了不小的成绩，怪不得至今在市场上仍然一机难求。12月20日，小米公司又宣布同联通进行合作，采取了同iPhone一样的话费补贴模式来销售，同样受到了消费者的欢迎。据说一个营业厅也就只有一台现货小米手机。不管这是不是小米的饥饿营销，我们都必须承认，很多用户是万分渴求一款小米手机的。另外，2012年1月9日，传小米手机CDMA版本已经通过工信部无线电业务行政许可。也许在不久的将来,CDMA的用户也可以在手中把玩自己的小米。

不管怎么样，小米作为我们中国的品牌已经让我们眼前一亮。关于它的未来，我们拭目以待！

完整的信息图：

注：本文来自友盟-安卓巴士教程大赛第一名获奖作品，作者安卓巴士的ID为liupeinye。推荐给所有刚刚开始接触Android开发的朋友们！

本文面向Android初级开发者，有一定的Java和Android知识即可。

文章覆盖知识点：HttpWatch抓包，HttpClient模拟POST请求，Jsoup解析HTML代码，动态更新ListView

背景介绍：客户端（Client）或称为用户端，是指与服务器相对应，为客户提供本地服务的程序。而android系统上的90%客户端软件都有一个共性，就是为了改善网页在android系统上体验不佳而生，最具有影响力的软件有：新浪微博、人人网、淘宝等，这类软件最突出的特点就是，先有网站再有软件。由于网络技术发展的多样性，手机浏览器往往无法跟随它的步伐，为改善用户体验，网站客户端软件印运而生。

以下内容100%原创，并在安卓巴士论坛首发，如需转载，请注明作者和出处。谢谢合作。

开发Android网站客户端通常有两种方法：第一种，通过服务端的开放平台，调用提供的API接口来开发，比如说open sina；第二种，服务端没有提供任何接口，你也没有服务端任何数据库访问权限，就是一个纯纯粹粹的网站，要你做客户端。今天，我要和大家分享的正是第二种情况。

这是一个简单的示意图，告诉我们，数据是由网页从数据库中取出，我们要为这个系统做客户端，我们就应该这样去改造它。

通过这样间接的方法来访问数据库，只要网页能看到的内容，我们的客户端都能获取到，而UI是由你自行制作，就可以使使用体验上一个台阶。

既然网页是我们的数据枢纽，我们就从网页分析着手。

该教程来自本人项目-掌上民大-真实经验，所以用项目中的”掌上图书馆”板块来示范。

该项目任务为中南民族大学图书馆图书查询功能制作客户端。

最近看到越来越多的游戏开发者开始关注交叉推广所带来的收益。一些游戏只是简单的互相推荐游戏，而也有不少游戏花费了很多的精力和资源在不断的优化，打磨交叉推广的体验和效果。小小的手机屏幕上本来空间就不大，还要腾出地方来专门做推广，还有可能影响产品体验，到底是什么在吸引这些游戏这么做呢？

今天来跟大家聊聊这个模式，先回答几个基本问题。

什么是交叉推广？

交叉推广是最近开发者讨论的比较多的话题，其实就是 App 之间的互相推荐曝光，通过流量互换的方式来获得更多的自己的产品平时无法触及到的独立用户，简称交叉推广。

为什么要做交叉推广？

付费广告、限免、游戏 Review 站点、论坛、社交网站都是比较常见的推广方式，但或多或少都会存在效果不明显和性价比低的问题，交叉推广做为一种资源相对来说较容易获得，更易操作，而且交换回来的用户的质量相对更高一点，对于类似孤岛的 APP 模式，似乎这是一种行之有效的方式来触及更多的用户。

什么因素影响交叉推广的效果？

• 流量，日活跃用户多
• 位置好，比如用户经常停留的界面
• 内容相关性高，适合玩家口味的游戏推荐或者介绍

做交叉推广应当注意什么？

1，不要伤害用户体验，和产品风格一致。体验友好的推广，用户不会那么反感，但强行插入的广告，影响游戏主进程会把用户赶走。

2，和优质的合作伙伴换量，好的产品推荐，用户是可以接受的；但是推荐比较差的产品，用户也会不买账。

3，适当的换一些不同的产品做推广，保持新鲜感，也能触及到不同的用户群。

4， 流量小，不代表没用，和一些较大的产品做交叉推广时，可以要求先帮他们推一段时间，积攒流量，在你的新版本或新产品上线时，让他们在短时间里帮你集中做推广，也是一个很好的方法，效果也是比较不错，而这个资源，是你不花钱就可以争取的到的。

5，跟合作伙伴谈交叉推广，可能会花费一些精力，比如谈合作模式，产品设计，推广时间，位置等等，对于中，小团队来说可控性较差，而且也通常没有专人来负责，所以一些第三方的交叉推广平台会是首选。

6，另外，交叉推广入口上线了，不要放在那就不管了，需要不断的做测试，根据统计的数据来做分析流量和转化率的效果，也是必不可少的运营手段。

讲完理论，我们来看看国外和国内几家产品的交叉推广设计案例。

GLU-Contact Killer Zombies

第一个交叉推广，玩家启动游戏界面，会弹出一张大图的游戏推荐。

2011年的移动互联网发展更加迅速，Android和iOS成为更多人的大众话题。只能移动终端也备受瞩目，每一款新设备的发布和新版本系统的问世都赚足眼球。

今年苹果发布了最新的iOS 5正式版，Google也发布了名为ice cream 的Android 4.0系统。但是这些最新的系统在多长时间后能在市场占一席之地呢？让我们看看如下信息图：

这张信息图来源于对《友盟第三季度国内Android数据报告》的分析，清晰的勾画出Android和iOS的成长历程。很有趣的是：iOS一个新版本系统的发布，在3～4个月之后将会有50%以上的设备使用。而Android则相对慢了很多，一般会在10～12月后到达50%。同样是两款炙手可热的手机操作系统，为什么会有如此大的差别呢？一起从几方面来看：

其一，OS使用权决定了新版系统爆发时间点

 iOS新版本发布之后很快的就可以进行大规模使用。iOS是一个非开源系统，只有苹果公司的系列产品才搭载使用。而且，苹果新产品的发布都会使用最新版本的系统。所以，新版本的iOS系统发布后很快就能够进入系统的爆发期。

Android是Google的开源系统。三星、HTC、摩托罗拉等比较大的国内外手机生产商都可以在新版本代码开源后进行使用。但是，除了Google Nexus使用原生的Android系统外，其他的手机生产商几乎都对Android系统进行了二次开发。比如HTC的sense系统和摩托罗拉的blur系统。当然也有其他根据最新Android系统进行本土化设计的公司，如点心OS、MIUI和乐蛙。 所以，搭载某新版本Android系统的移动终端会在各大厂商进行二次开发后才开始大规模销售，爆发点会晚几个月。

其二，自主刷机难易程度影响了OS版本的升级速度

   即使手机厂商会售出很大一部分搭载新版系统的机器，但肯定不是全部。很多用户也会主动的升级自己的移动终端来体验更新的OS系统。从这个角度看，iOS和Android又有很大的不同之处。

让用户感觉使用非常流畅。迟缓会潜移默化地留下不好的印象。用户看见App的图标，便会在心中和“迟缓”、“卡”、“不稳定”画上等号，产生“打开畏惧症”。

用户滑动Listview、Gallery、Coverflow时觉得卡，多半是因为相应Adapter对getView的处理不够好。每个Item都会和数据源绑定，而数据源的获取方式有多种：网络、本地文件、SQLite数据库、SharedPreference以及内存，它们的传输时间分别是7秒、2秒、1秒、100毫秒、5毫秒。

对于最耗时的网络请求，很多人会采用异步操作，不会让用户耗费精力在网络等待过程中。但在I/O以及SQLite查询时，用户的等待时间容易被忽略，从而降低滑动的流畅感。Android用户常常遇到的ANR（Application Not Responding），便是这个问题的升级版。要知道，Activity Manager和Window Manager监视着应用程序的响应，当发现按键或触摸发生后5秒还没执行完处理逻辑，或是BroadcastReceiver处理时间超过了10秒，系统便会抛出ANR错误，并提醒用户强制终止应用。

我的建议如下：

• 对于无法在短时间完成的操作，在独立线程中处理，Android有多种异步处理模型可供使用，包括Thread-Handler、AsyncTask以及Loader and CursorLoader。

• 尽可能减少复杂计算和降低I/O，充分估计对象的使用频率，选择合适的数据源。个人认为大部分应用中不会存在太多太大的对象，可以考虑将数据缓存在内存中。如果应用中有太多图片不能一直缓存，可采用LRU（Least Recently Used ,最近最少使用）算法将不常用的缓存清理出内存，这样缓存大小可控，从而不会出现Out of Memory（内存溢出）的Bug。

但要注意，算法是把双刃剑，如果你享受到类似LRU带来的提速后的爽快，就可能会挖空心思探索更高效的算法。这时要慎重，后面会讲到看上去很牛的算法带来的问题。

另外，网络等待虽然是最耗时，但却容易被忽略。因为粗看上去网络是不可控的，与开发无关。一般会设置几秒钟的超时，超时则重发。事实上，在国内，中国移动的GRPS网络占主导，所以手机上网普遍很慢，HTTP连接上下行10秒是很正常的，超时设置20秒都不为过。同时，根据友盟对Android应用使用的统计，用户在每个App上的一次启动花费时间是1分钟左右，理论上有3次重发机会，但一次超时（假设是20秒）后，用户就已经失去信心，不会再等待一次了。所以在开发时，要结合具体使用场景，设计数据预取机制，尽量降低网络请求次数，同时考虑gzip、protobuf等数据压缩和编码机制，保证一次取到的数据不至于太大而造成额外延时。

Android架构图（图片来源：http://developer.Android.com/guide/basics/what-is-Android.html）

更多文章：

   用户体验导向的Android应用开发——友好的体验

   用户体验导向的Android应用开发——节省电量

（本文曾发表于《程序员》杂志2011年11期：http://www.programmer.com.cn/8852/8672/）

Android开发目前是移动开发中的“当红炸子鸡”，大量Java程序员涌向Android，同时会习惯性地将桌面和Web端的开发/设计经验带到移动设备上。这样的好处是充分利用了移动开发和桌面/Web服务的共性，比如广泛使用的列表、本地数据库等常用组件；坏处是移动和桌面/Web的使用场景和载体完全不同，直接移植桌面端开发的经验有害无益。

比如，手机主要在碎片时间使用，用户容易对复杂的界面设计感到疲惫；同时，移动环境中上网慢，网络连接频率和失败重发机制的设计更有讲究；此外，手机电池续航能力差，后台复杂的计算会加速耗电速度。这些开发理念直接影响用户最终体验，下面我们来讨论一下在Android中如何以用户体验为导向进行开发优化。

虽然不用深入了解底层，但需要对系统有基本的了解。Android系统分层清晰，最底层是Linux Kernel 2.6，之上包含了Webkit、SQLite、OpenGL ES等基础C/C++库，同时Dalvik虚拟机运行于Kernel之上，帮助应用进行底层内存管理（这样使Android应用无法直接进行内存释放）。这些库一方面被系统大量使用，另一方面也通过Framework层提供接口给开发者。此外，Framework层还提供其他系统级的服务，如消息通知服务、位置获取服务、设备信息读取服务等。

由此可见Android对于开发者非常开放和灵活，尽管如此，开发时仍然要注意不要过于随意，以免产品过于复杂而让用户不知所措。当然，除了少数系统级应用开发需要深入了解Framework层实现机制之外，一般第三方应用开发者并不需要深入了解每一层原理，应把重点放在如何理解和灵活运用庞大的Android SDK API。

友好的体验

不友好的体验来自三个方面。

其一是Android的碎片化带来了UI适配问题。Android机型众多，和iPhone相比，界面适配饱受诟病。要保证应用能运行在不同分辨率的手机上，需要理解Android提供的自动适配方案。事实上，Android系统为UI适配做了充分的考虑，只要理解系统对此的精心设计，就能在开发时少走很多弯路，给不同分辨率的用户提供友好的呈现界面。

随时都得插在墙上充电的设备，不叫移动设备。如果你的App让用户一直守着墙角，用户也会很快把你丢到墙角。你会问：“他怎么知道我的应用耗电？”很抱歉，目前来看，Android用户中有大量发烧友和技术高手，同时系统很不客气地记录了每个应用的耗电量，于是用户偶尔会去系统后台查查耗电大户，之后会毫不客气地打开卸载工具。

所以需注意以下几点：

第一，不要绞尽脑汁设计复杂算法，不要在后台跑服务，不要网断了还不停重试。在开发一个模块前先想想会不会费电，如果会，就不要去做。代码是为了服务用户，而不是折腾用户。

高手喜欢挑战，尤其在手机上实现精巧的算法，这样能带来更强的征服感。有人曾在手机上实现了布隆过滤器（一个庞大精巧的类哈希表，多用于在服务器端如垃圾邮件查找），其内存消耗和计算复杂度都远远高于普通的HashMap，且实现并不容易。结果App发布之后，出现用户抱怨耗电量大，并且经常出现Bug，最后还是老老实实换成了HashMap。任何算法的目的都是为了服务用户，如果简单自然的方法能更好地做到这点，何乐而不为？如果真的在客户端找不到简单的算法，则需要反思——为什么在手机上需要复杂的计算？是否该将这些计算放在服务器端？

第二，不要在后台滥用Service。Android非常开放，开发者可在后台触发任何处理逻辑，肆意占用CPU和内存。一般来说，Service的目的是为了监控变化，包括系统和网络变化。系统变化可通过注册BroadcastReceiver监听控制，比如应用安装和卸载等事件，这样耗电量非常小，完全可替代在Service中轮播。网络请求无法用BroadcastReceiver监听，但是有两个建议。