数据采集技术简介( 三 ) _数据采集

单独统计spm的a.b部分，我们可以用来评估某一个站点的访问和点击效果，以及后续引导和成交情况。

单独统计spm的a.b.c部分，我们可以用来评估某一个站点上某一频道的访问和点击效果，以及后续引导和成交情况。

单独统计spm的a.b.c.d部分，我们可以用来评估某一个频道上某一具体页面的点击效果，以及后续引导和成交情况。

基于SPM可以得到的效果统计指标：

PV ：通过指定spm编码引导到宝贝详情页面的PV 。
UV ：通过指定spm编码引导到宝贝详情页面的UV 。
支付宝成交人数：通过指定spm编码引导到宝贝详情页面的用户当天对同店商品的支付宝成交人数。
转化率 =支付宝成交人数/UV，代表通过指定spm编码引导的用户最终转化为购买用户的比率。

七、客户端日志采集
与网页日志对应的，是手机应用为基础的客户端日志，由于早期手机网络通讯能力较差，因而SDK往往采用延迟发送日志的方式，也就是将日志统计在本地，然后选择在Wifi环境下上传，因而往往会出现统计数据延迟的情况。现如今网络环境好了很多，4G、5G流量充足，尤其是视频类APP基本上都是一直联网，因而很多统计能够做到实时统计。
客户端的日志统计主要通过SDK来完成，根据不同的用户行为分成不同的事件，“事件”是客户端日志行为的最小单位，根据类型的不同，可以分为页面事件（类比页面浏览）和控件点击事件（类比页面交互）。
页面事件的统计主要统计如下三类信息：

设备及用户的基本信息，例如IMEI、用户账号等。
被访问页面的信息，例如商品ID、浏览店铺等。
访问的路径信息，例如上一个页面来源等。

与Web日志采集类似的是，交互日志的采集同样无法规定统一的采集内容，除了记录基本的设备信息和用户信息外，很多统计的方式是可以由业务方自定义统计的，也就是根据业务需求的不同，产品在配置平台上自定义一个统计项，下次SDK更新时便可以加入统计项，自主看到统计内容，便于自动化的管理运维。但在每个事件上，会提供一些额外的统计信息，例如事件名称、事件时长、事件属性、事件页面等。
八、客户端日志的聚合由于事件的统计涉及到很多参数，基本上是一个行为能够产生一条日志，不仅客户端会产生大量的记录数据，对于服务端的接收通常会产生很大的流量负担。因此统计SDK往往会有聚合和压缩的功能，对于一些展现场景，可以适当的合并日志，以减少数据量。例如在淘宝等APP中，一次商品页的浏览会产生上百条日志，从下游分析的角度来看，只需要知道哪些内容被曝光了即可，因此完全可以在一条日志中记录曝光的ID，而无需每个都统计一遍。
还有一种场景，因为APP存在回退的情况，因此在访问路径的分析中，往往会产生干扰统计，因此在统计时需要添加一些特殊的标识，来鉴别该行为是否属于回退行为。
九、统计SDK市面上最常见的，如友盟、Talkingdata、百度统计、腾讯云分析、GA等第三方统计服务提供商，也诞生了很多在某些分析方面更加专一、深入的统计服务商，比如诸葛io、growingio、神策等，看自己需求进行配置。
十、唯一设备标识符在客户端的相关统计中，如何鉴定一个用户是非常难的，因为网页有统一的Cookie来进行识别，但客户端并没有。历史上， IMEI、IMSI、mac地址、苹果禁用之前的UDID，都可以用，但由于用户自我保护意识的提高及系统的升级，很多基本的设备信息都难以获取到了，Android也进行了设备信息获取的限制。对于单个App的公司来说，识别唯一用户并不是难事，但对于多App的公司来说，这一点就尤为重要，也这是业界难题。
十一、H5与Native的统一App有两种类型，一种是纯 Native 的App，另一种是既有Native，也有 H5 页面嵌入的App，目前大部分的App都是两者兼有的状况。Native页面的数据统计主要通过SDK进行，但H5页面的数据统计还是基于浏览器的页面日志来进行，由于采集方式的不同，很多情况下两个页面互相跳转时，便无法还原用户访问路径，对于数据的统计分析产生很严重的影响。解决的思路有两种，一种是Native日志归拢到H5日志中，另一种是H5日志归拢到Native日志中，但综合考虑，归拢到Native日志更为合理，因为SDK能够采集更为全面的日子信息。具体实现方式上，可以在H5页面中嵌入JS代码，通过调用WebView框架中的JSBridge接口，来实现参数的传入，并由统计SDK进行日志的封装。当然方法不是万能的，有其他的好方式也可以尝试。