求思路，搭建一个类似友盟的 APP 运营数据分析的后台，数据该怎么设计？

[baizhebz]

现在需要做一个给自己公司用的，移动应用运营数据分析的后台，至于说为什么不直接用友盟？其实我们也在用，但公司有些特殊需求，就决定自己也做一个。

具体需求就不展开了，我想以用户留存率为例，向大家求教一些设计思路。
可查的数据(MYSQL中)有：每日的新增用户，每日的登录用户，以及它们具体的UID，渠道ID和版本ID。需要计算出每日的新增用户在1~7日，14日，30日的留存率，并且要细分到某个渠道或者版本。

我们定义 次日留存率=（第一天新增的用户中，在第2天还登录的用户数）/ 第一天新增的用户数；
以此类推。

我目前的想法就是(首先每日新增和登录都会被单独提取到一张表中)，例如计算昨天用户的次日留存，就是先得到昨日新增用户，然后从今日登录用户中，查找出存在于昨日新增用户中的数量，然后再除以昨日新增用户数，计算出次日留存，并在MySQL中持久化这个数据。
此外还需要计算各个渠道和版本的留存。渠道可达数十个，版本可达上百个，目前的想法就是依次单独计算，效率低还可以接受，可这查出来的数据如果放在一张表里，这表的结构怎么设计我并没有好的想法。

问题就是这样了，我想请教大家还有没有好一些的处理办法，或者是否可以利用NoSQL的特性来做这件事。

[ong]

思路基本正确
难度在流水数据
可以根据业务分表，比如按appid或日期

留存数据的持久化拆不拆看业务

[lshero]

只用Postgres+Redis 做过
Redis做计数器 用用你需要统计的最小粒度做key 次日读取当天计数器内所有计数器key对应的数值然后丢给postgresql进行聚合获得当日的数据，因为有计数器所以Postgresql基本都没有执行过count

UID是一个哈希值，按照UID前一位对用户表进行表分区，分了16份 离职前用户数据在2亿左右

不过缺点也是很明显，主要都是用的计数器所以只能知道当天的数字但是数字后面具体对应的列表也没有做，再加上用拍黄片这种最好的语言在我的能力范围内对分析数据也没有是什么特别的能力，所以也没有继续完善

要是用户数量不多的话你可以直接用 https://count.ly/

[akira]

用一个表统计出每日的各渠道各版本的数据，包括登录人数，次日留存人数等。
需要查看单一渠道/版本的数据的时候，根据上面那个表去获取数据计算出结果(DAU/DNU/次留等)就可以了。

[panlijohn]

楼主，我觉得你的思路是没有问题的。做一个JOB定期做任务，例如每天凌晨。将你需要的1-7日，14日，30日数据计算，然后插入一张目标表，例如tar_tbl。至于你后面所说的，计算很麻烦，实际不麻烦啊。复杂点的话，你利用报表工具，一个groupby就能出来。简单的话，你excel直接导出数据，数据透视表也能解决。（你用这种思路，去实现一下，如果你的groupby 后面的数据量极大，以及机器性能不是特别好，一张报表的查询需要耗时1分钟及以上。你可以将group by这个动作放到定期任务里，将计算过的数据，放到不同维度的表中。就是先group by 然后insert into tar_tbl1.然后通过简单的查询从tar_tbl1中取数据。）