创业公司做数据剖析(五)微信分享追踪系统

　　创业公司做数据剖析(五)微信分享追踪系统

　　作为系列文章的第五篇，本文重点阐述数据采集层中的陌陌分享追踪系统。微信分享，早已成为联通互联网营运的主要方向之一，以Web H5页面(下面称之为陌陌海报)为载体，利用陌陌庞大的好友关系进行传播，实现宣传、拉新等营销目的。以下图为例，假设有一个海报被分享到了陌陌中，用户A与B首先听到了这个海报，浏览后又分享给了自己的好友，用户C见到了A分享的海报，浏览后继续分享给了自己的好友。这便产生了一个简单的传播链，其中蕴涵了两种数据：

　　这样的数据的意义在于：第一，统计剖析各个渠道的海报的传播疗效;第二，对传播贡献较大的用户领取陌陌红包奖励，提高用户的分享积极性。微信分享追踪系统，便是完成对这两种数据的采集和储存。在过去的一年里，受到公司业务和营运推广方向的影响，这部份数据驱动了近一半的推广业务。

　　熟悉陌陌开发的同事应当晓得，第一，每个陌陌用户在某个公众号下都拥有一个惟一的open_id，打开陌陌海报时，可以通过OAuth2静默授权在用户无感知的情况下领到其open_id;第二，通过陌陌JS-SDK，我们可以捕捉到用户对海报页面的分享风波;第三，拿到用户在公众号下的open_id后，便可以对该用户领取陌陌红包了。基于这三点，我们便可以实现相关的数据追踪和分享奖励了，本文主要是总结我们在陌陌分享追踪上的方案演变。

　　首先要说一点的是，其实陌陌分享追踪系统本身并不复杂，但是与复杂的产品业务结合到一起，就显得越来越复杂了。如何做到将数据逻辑与产品业务逻辑剥离开，以不变应万变，就是这儿要说的方案演化了。

　　1. 早期服务

　　早期的陌陌分享追踪系统，笔者以前在探讨微信公众号营销背后的技术一文中介绍过，其时序图如下所示。基本流程是：第一，用户打开海报时，通过OAuth2授权，将open_id加入到页面链接中;第二，前端上报浏览风波，需要带上open_id和传播链信息;第三，用户分享时，需要在分享出去的链接中加上传播链信息，所谓传播链信息，就是每位分享过的用户的open_id组合，比如“open_id_1;open_id_2”;第四，上报用户的分享风波，需要带上open_id和传播链信息。后端收到上报数据后，根据不同的功能需求，将数据保存到不同的数据表中，用于后期消费。随着业务的发展，这个系统曝露出一些问题：

　　随着推广活动的调整，统计和奖励新政也急剧变化，比如有的根据一度分享者的分享次数进行奖励，有的根据一度、二度分享者带来的浏览量进行奖励等等，还有须要依照上报的参数不同做不同的处理。所有逻辑都在上报的API恳求中处理，来一个需求加一段逻辑，导致该恳求的功能不断膨胀，而且一些推广活动早已下线了，相关的逻辑也没有清除掉。

　　参数比较混乱，页面URL中携带了不同的参数，包括陌陌相关参数、产品相关参数，前端上报时须要携带不同的参数，而后端页面太多，经常弄错。

　　2. neo4j的尝试

　　于是，我们思索，有没有可能在前端直接建立完整的传播信息，后期使用时直接按照条件就可以查询出所需的数据，前端上报时也不用携带传播链信息，我们想到了图形数据库储存技术。

　　图形数据库是一种非关系型数据库，它应用图形理论储存实体之间的关系信息。在文章开头的那张传播图中，用户的行为数据虽然可以归结为用户与海报之间的关系数据，这样，这个系统虽然就收录两种实体：用户、海报，三种关系：用户打开海报、用户分享海报、用户之间的传播。在众多图形数据库中，我们决定选择比较成熟、文档相对丰富的neo4j来做DEMO。采用neo4j的查询句型，很简单的就可以查询出所需数据，简单示例一下。

　　下图呈现基于neo4j储存的新系统时序图，在OAuth2授权的重定向过程中，建立User和Poster节点信息，以及两者之间的OPEN关系信息，并且对页面URL估算hash值(去除无用参数信息)，然后将用户open_id和URL的hash值加到页面URL中返回给后端。用户分享时，把该用户的open_id作为parent字段值，加到分享链接中，新用户打开该链接时，会依照该值来构建User与User节点之间的SPREAD关系信息。在用户分享的风波中，做一次数据上报，携带open_id和页面URL的hash值即可，后端领到信息后，便可以构建User与Poster之间的FORWARD关系信息。如此，便可以构建完整的陌陌分享追踪数据了。

　　然而，一切并非预期的这么完美，在DEMO过程中，我们发觉有两点问题不能挺好的满足我们的需求：