最近刚刚做完手上产品的大改版，对新版本内的统计埋点花了比较大的功夫，因此在这里记录下来，也算是对自己最近一段时间的总结吧
常见的统计方法
移动端app在做统计时一般有以下两种方式：
- 自建统计sdk，较为安全和灵活，可以设计成自定义埋点统计或模型统计等
- 接入第三方统计sdk，常见端有友盟、GrowingIO等，但是自家等数据要传给第三方服务商，而且会受到诸多限制（如友盟对数据量级就有限制，不允许单个点的量级过大，或者统计点数量过多等等）
自定义统计
自定义统计时，往往是根据app内的动作或者事件，在动作或事件发生时，上报一次数据。也正是由于这种特性，自定义统计点最大的缺陷，就是“不全面”。因为需要与动作或者事件做绑定，因此在埋点之前，就需要产品人员提前考虑到一个自定义点可能涉及到的所有的情况，并对这些情况提前做埋点，一旦某种情况没有提前考虑到，就无法采集到数据。
也正是因为这种缺陷，自定义的统计方式往往用于统计单个的孤立事件，或者是做临时的统计，大批量的操作行为统计一般还是采用模型统计的思路，用以全面统计一次用户行为中的所有事件。
模型统计
模型统计的基本思路是，提前定义好如点击、浏览等行为，以及需要统计的页面内容（如首页、banner、内容页等等），将用户的所有行为数据全部上报，后期产品人员查询数据时，需要对数据做条件对筛选（如选择“行为 = 浏览 & 页面 = 首页”），得到所需要对数据。
我们公司采用的是自建统计sdk的方法，自己进行数据的采集和清洗。不过因为种种历史原因，我们自己的模型统计存在一定的问题，因此一直以来我们在统计时，都采用埋自定义统计点的方案。而这次的改版中的埋点，主要借鉴了模型统计中的思路，用自定义埋点统计实现，可以说是对以往我们的自定义埋点统计的一次大升级。
自定义统计点基本结构
虽然现在做自定义统计的方式有很多，各家想必都有自己的数据结构，不过基本的数据结构上都是大同小异的。一般自定义点上报时还会携带其他的基本参数（如用户imei、IP地址、网络状态等），这里我只用产品人员会涉及到的参数来随便举个例子
"eventID" : "Click_HomePage_Button" , "status" : "login" , "time" : "1500450788987" , "model" : "vivo X9"
可以看到，一条上报数据里基本结构就是“属性 - 属性值”，因此上面的这条数据其实是这样：
一条数据的基本结构
Click_HomePage_Button这个统计点在用户点击app首页按钮时触发上报，同时利用参数status记录当前用户的登录状态为login，利用参数time记录当前的时间戳，参数model则是记录了用户使用的手机机型为vivo X9。这样一条基本的自定义统计数据就完成了，这个统计点的pv即为点击“app首页”的次数。
用尽可能少的点统计更多信息
从上面的例子可以知道，一条数据在上报时，除了产品人员定义的参数外，还会携带很多其他的参数来统计基础信息。因此每条统计数据中，基础信息的参数可能占到了很大的比例。
对于产品人员定义的一些“没有参数”的统计点，一条数据中基础信息所占的空间可能已经超过了90%。虽然一条数据可能只有几k，但是百万甚至千万级别以上的数据量级下，一条数据中产品人员真正关心的参数占比如此的低，对于数据部门的存储来说，也是一种极大的浪费。
因此，利用好每一条上报数据，让每一条数据的价值最大化，是每一个产品人员都应该关心的问题，在这个基础上，尽量提升数据的灵活程度，也能极大地提升我们后期查询和整理数据的效率。
我的做法
在这次我负责的数据埋点方案中，我的核心思路就是上面提到的尽可能提高每一条上报数据的价值，以页面为单位，将页面内的所有操作一次性上报。
因此我们需要转变以往的“每个行为都上报一次”的埋点和上报思路，而是对同一维度内的操作做统一的上报。
举个例子
以常见的视频或直播页面为例吧，一个页面内集中了大量的功能，这种类型的页面就很适合进行统计点的精简和整合
某视频软件界面
可以看到，在“首页-推荐”这个频道内，集中了点赞、评论、转发、播放暂停等几个主要功能，他们的操作路径并不复杂，在统计时只需要统计他们的状态即可（如是否点过赞，是否有过评论等）。
因此在做统计点设计时，可考虑将这些操作合并到一个统计点内，用几个参数来分别代表这几个操作，并用对应的参数值来代表各个功能对应的状态。
页面内操作的统计点
可以看到，在这个点里除去统计点名称之外一共有4个参数，分别记录了点赞、评论、评论内容、转发这几个操作的状态。其中需要提前约定参数值的含义，在这里我定义参数值数字1为“有该操作”，0为“无该操作”，因此例子中这条数据的含义即为“有点赞、评论操作，没有转发”；而参数word下直接存放评论内容。
对参数值的定义
如此一来，这条数据上报时，会携带点赞、评论、转发三个操作的状态，相比于这三个操作用单独的统计点上报，合并上报会有效提升单条数据的价值。而在分析数据时，只需要针对各个参数去统计里面参数值数量即可得到这个功能操作对应的pv和uv。
需要注意的地方
这种对于统计点的整合处理，有两个地方需要注意
-
选择恰当的功能进行合并统计
并不是所有的统计点都适合用这种方式做精简和合并，这种方法只适合于在同一场景下的一些简单的、路径较短的操作。如果一个操作时线性的且路径较深，上一步和下一步操作之间有很强的关联性（如需要下一步、下一步的功能），就不太适合用这种方法了。 -
统计点的上报时机
上一个点内也提到，在同一场景下的简单操作可以精简和合并，因为只有同一场景下（如视频的详情页），才可以方便的找到一个统一上报数据的时机，如“离开视频详情页”这样的时机将统计点及时上报。
如果是在多个复杂场景下使用一个统计点，那么统计的参数值数据则需要提前在客户端本地存储，到约定的时机再上报（如每天上报一次），这样做的客户端的实现成本以及数据的准确性都有待商榷。
总结
这种统计点上报的方法，借鉴了模型统计的思路，在一定的条件下，提高了自定义埋点的方法的数据效率和价值，同时由于在一条数据内包含了多个参数，也就使得在分析数据时，可以将多个参数自由灵活的联立组合，从而得到更详细的分析结果。
但是这种方法也存在着一定的局限性，最显著的变化就是将原来自定义统计点“实时上报”的特性，变为了选择特定的上报时机“延时上报”，因此涉及到了客户端内对数据的存储，以及这样上报的准确性等问题都需要研发人员针对自己的产品进行详细的评估。
网友评论