在一些统计系统中，为了观察用户的粘度，我们会计算一系列的叫做留存的指标——次日注册留存、2日注册留存...N日注册留存，比如昨天注册了1000名用户中，在今天有300名用户又登录了，那么对应于昨天的注册留存就是30%；如果再去细究，还可以去计算活跃用户的留存情况，比如昨天登录的1000名用户中，在今天，其中的100名用户又活跃了，那么对应于昨天的活跃次日留存就是10%。如果更细究下去的话，还可以去计算每个维度上的留存情况，维度组合的留存情况。
对于这种指标的计算，如果按照传统的关系型数据库的思维去计算，要进行一系列的联接操作，对于大数据量的统计性能上可能就是个问题，并且没法去实时地跟踪这些数据指标。换一种思路的话，可能这些指标的计算就没有那么费劲了。这里介绍一种基于实时流系统——Storm——进行这些指标的计算。
从总体上看，这些指标依赖于3个核心变量——用户的注册时间、用户上次登录时间记录、以及用户“此时（在流中）”的登录时间。以上的指标就是对每个用户对应地这三个变量进行日期减法即可，以下是具体的思路:
我们在KV数据库中保存一份用户注册时间的数据，类似于这样，两列分别对应UID和用户注册时间:
1 2012-03-04
2 2012-07-08
3 2013-02-08
我们在KV数据库中，同时维护一份用户“上一次”登录的时间，类似于这样，两列分别对应UID和用户上一次登录时间：
1 2013-01-06
2 2013-02-11
3 2013-03-12
下一个核心变量就是我们流中的实时数据了，类似于这样(假设我们正处于2013-03-13)：
dau_1_2013-03-13,dau_2_2013-03-13，dau_4_2013-03-13，reg_4_2013-03-13...... ------> 进入实时流处理系统
下面就以比较简单的注册留存来说明一下思路吧：
1. 首先，实时流处理系统接收到了reg_4_2013-03-13这样一个消息（数据），当我们发现她是以reg开始的消息时，我们明白，一个新用户来了，因此，我们要在我们存储用户注册时间的表中加入这条记录，当然，如果为了维护信息的一致性，可以先检查在现有的数据中是否有对应的用户记录，如果有的话，就应该以原有的为标准，当然如果有其它更好的措施来保证数据的一致性就更好了。下面我们的用户注册时间表就多加了一条，变成：
1 2012-03-04
2 2012-07-08
3 2013-02-08
4 2013-03-13
2. 紧接着，我们收到了dau_4_2013-03-13消息，这是合理的，因为用户刚刚注册完成，可能要立即登录。在得到这条记录之后，我们就要进行我们的注册留存计算了：首先，我们从这条消息中得到：登录的用户是4，而后，我们通过这个用户id，在用户注册时间表中找出用户的注册时间，对于用户4来说，他的注册时间就是2013-03-13。最后，我们要计算dau时间（2013-03-13）和用户注册时间（2013-03-13）之间的差值，并用这个差值和dau日期组合成一个key，这个key对应的统计数字进行加1操作（如果原来没有，就初始化成1）：
2013-03-13_0 1
3. 接着我们又收到消息：dau_2_2013-03-13，同样的思路，我们算出用户2的最新登录时间（2013-03-13），与其注册时间（2012-07-08）之间的差值（279），并形成key，对对应的key进行加1或初始化操作，得到如下：
2013-03-13_0 1
2013-03-13_279 1
依此类推，当我们处理完dau_1_2013-03-13这条消息之后，我们得到了：
2013-03-13_0 1
2013-03-13_279 1
2013-03-04_405 1
如果今天又注册了一个用户5，并登录了，那我们的结果表相应地更新成：
2013-03-13_0 2
2013-03-13_279 1
2013-03-04_405 1
至此，整个指标计算的流程已经完成，这是你会发现，对于某一天的那些注册用户，你能够轻松地拿到他们的N天留存，N可以是任意数。你所要做的只是，拿出那天（比如2012-03-04）对应的总的注册用户数（比如说是200），如果想看3天留存，那么就先计算出3天后的日期（2012-03-07），形成key:2012-03-07_3，拿出对应的值（比如说20），即是2012-03-04那天注册的200人中，有20个人又在3天后登录了，即是2012-03-04的3日留存，留存率就好算了 20/200 = 10%。
其它的指标亦是如此思路计算。以上只是计算的思路，实现中还需要多多考虑细节。