项目分享 关于用户行为分析类项目经验

      笔者有幸参与某公司对于本公司一款对于公司所有产品（约100多款应用）的用户行为分析项目类项目的开发。从预研到项目各个版本的迭代。。中间过程一波三折，同时笔者在此期间也接触了很多优秀的同类项目。现在将一些关于此方面的经验分享下。以便于有此开发意向的猿们少走弯路。

       1.自己开发还是套用三方？

             首先，这是最关键的问题，要知道相比于直接使用第三方应用，其实自己开发有很多好处，你不用担心数据的安全问题（我们公司开发的主要原因，客户特殊，保密性严格），能提供相应的行业业务方面的数据随心所欲做业务展现，毕竟其实套用三方应用最大的问题也是这个，绝大数的三方软件的客户群体都是相对于开发人员，开发人员需要用这些数据进行喜好分析，轨迹模拟之类的，相对来说说如果直接想作为一款产品卖点，套用第三方应用很难让客户直观看到这个功能的价值（不要指望客户看懂图表以外的任何专业数据），提供相应的业务数据也是便于客户了解。

             对于开发人员综合素质要求比较高，对于计算机组成原理，网络通讯有一定的了解。最关键的是项目组有充足的实战能力，毕竟你的坑一般人还真填不上。

             数据的要求是首先得考虑的刚性需求，其次便是开发成本和工时。这种项目相对于中小公司来说是难以短期见到效益的，同时成本也是相对较高的。但是相对的，随着时间的增长，应用的潜在价值也会不断上涨，毕竟现在是一个大数据时代。

         2.用户行为还是分析？

             这是一个重要的分界线，同时也是容易跑偏的地方。当你们决定自己开发时，这便是你们应用的核心定位，然而就像中国人都喜欢用筷子一般，对于产品的定位，产品经理很喜欢为自己的产品添加多种定位，最终也会导致你的项目哪方面都没做到。（我不是吐槽全栈攻城狮！！！），用户行为和分析代表的侧重点不一样，而要想每一个侧重点都实现对于团队的成本消耗是十分巨大的，说实话，想要做到两者兼备恐怕就是BAT等大厂都可能溺死。

              这里就说下类似淘宝鹰眼，大众的cat等其实本质上更像是监控，毕竟都是源于谷歌的Dapper来实现的调用链级别的监控，这样的应用侧重于用户行为的采集实现，相对的分析在整个核心开发中较轻。当然即使是作为信息采集上，这些系统为了不对应用造成更高的耦合和负担，采集的信息也很少，但起码实现类对于应用调用的跟踪。相对的业务数据获取则采取一些收集日志等曲线救国的方式实现的（很多依靠埋点和自身记录）。这里强调的是应用监控。当然这些大厂势必也在分析上下了很多功夫，但不是每个公司都有这么大的财力去耗费。

             在项目初期的产品定位就得明确你们的侧重点是监控用户行为还是分析，我们就遇到了产品两边都想兼顾，结果项目后期开发混乱，人员投入奇葩的情况。

           3.细节还是趋势？

             这个和第二点是息息相关的，侧重于分析自然展现的也是侧重更细致的数据，对于数据的粒度要求也就更细，这也就会决定你之后的应用设计。比如说如果是展示细节，那就得获取更多的详细数据，最好的做法自然是进行埋点，或者应用自行记录，相对的你们开发的应用也就更偏向于你们公司的业务。而其他的非侵入获取数据的方式实际上都是事倍功半的。

            而注重整体趋势分析的话，相对来说得考虑数据的获取方式，因为获取的数据较为粗糙，可以采取一些非侵入式和少量侵入去获取数据。适用公司产品过多，埋点修改成本过大时。

          4.数据时效性

           前三点要是都做好了，其实这点反而是最好做的，因为这个实际上看到还是你们的应用是否是需要实时获取数据。当然这个也会决定你们采取的框架。

           干货

            这里给出一些相应的方案建议应对我上面说的着几点

                     1.      三方应用的话使用市面上一些主流的应用就行这里说下几家公司，具体的各家应用有细微差别：

                            数盟，神策，凌云，GrowingIO，几家家都有类似的三方应用 。开源的有  pinpoint ...

                      2.自主研发偏向监控的话  建议翻看 dapper这篇万物起源的论文，使用调用链进行链路级别的监控（RPC和HTTP提前做好功课）。当然最近听说微服务的网关貌似实现了这种功能 。

                      偏向分析的话其实现在流行的一些大数据分析框架便能满足，这方面就不细说了（开发时没怎么向这边扩展过，同事项目倒是做了类似的）。

                       3.偏向细节的话，数据量会比较大，需要考虑数据库存储和运算能力，建议是使用elasticsearch之类的分布式非关系型数据库。（最新一版采取这种方式）  

                           偏向趋势的话需要考虑数据的时效性如何保证，可以采取netty和mina这种实时并发通讯框架，同时消息队列得考虑容量和丢失问题，这里推荐Disruptor这种具有环形队列得框架，而数据的存取可以考虑下生产者和消费者模式实现实时存取。（之前的版本）

                      希望对入坑的同胞有一定帮助