数据采集与分析的那些事——从数据埋点到AB测试

做者：网易有数郑栋。

 

1、为何企业须要一套完善的用户行为埋点和分析平台

 

产品初创期间，须要分析天使用户的行为来改进产品，甚至从用户行为中获得新的思路或发现来调整产品方向；产品成长过程，经过对用户行为的多角度（多维）分析、对用户群体的划分以及相应行为特征的分析和比较，来指导产品设计、运营活动，并对市场渠道效果进行评估。

配合上A/B试验平台，能够加速产品的迭代，更快获得用户的真实反馈。同时，这些数据沉淀下来，对业务的数据仓库建设、数据智能应用等方面也能起到促进做用，好比作实时推荐，须要能更快得到用户尽量多且明细的行为数据；作用户分类、意愿预测等机器学习业务，须要清洗过的规范化、结构化的数据作 训练。

要想作用户行为的分析，就须要有一套用户行为数据采集、传输、处理、分析的基础设施，而埋点和分析平台就是在作这件事。业界大多产品都是经过嵌入到多个终端的 SDK 来采集用户行为数据，然后续的传输、处理等过程对需求方是透明的，这样能够以很低的成本，完成数据的采集、清洗、沉淀工做，为企业节省成本，提高数据驱动的效率。

在分析平台上，用户的行为定义会经过特定事件来标识，好比 “buttonClick”，“playMusic” 等。一般这些事件是开发人员经过调用 SDK 提供的API来设置的，除了肯定事件的名称外，还能够加入分析须要的自定义参数和取值，这个过程就是“埋点”工做。固然，还有一些工具/产品支持可视化埋点，这种方式不须要开发介入埋点，SDK会自动采集用户在各个终端上的行为。

 

2、代码埋点、可视化埋点和无埋点有哪些区别，在使用过程当中该如何选择？

 

可视化埋点是指开发人员除集成采集SDK外，不须要额外去写埋点代码，而是由业务人员经过访问分析平台的圈选功能来“圈”出须要对用户行为进行捕捉的控件，并给出事件命名。圈选完毕后，这些配置会同步到各个用户的终端上，由采集SDK按照圈选的配置自动进行用户行为数据的采集和发送。

无埋点是指开发人员集成采集SDK后，SDK便直接开始捕捉和监测用户在应用里的全部行为，并所有发送到分析平台，不须要开发人员添加额外代码。在分析时，业务人员经过分析平台的圈选功能来选出本身关注的用户行为，并给出事件命名。以后即可以对特定用户行为（事件）进行多维分析了。

可视化埋点和无埋点比较像，都不须要开发人员手工加代码，也都须要业务人员进行所关注的用户行为的圈选。二者最大的不一样是在用户终端的表现上，可视化埋点只采集业务人员关注的用户行为数据，而无埋点是会采集全部用户的行为数据，一般状况下数据量后者比前者大不少。

也正是因为无埋点默认采集全部用户行为数据，它可以作到事件的回溯分析，即在业务人员新定义（圈选）事件后，就能去分析这个事件在前面一两个月的数据状况，这也是可视化、代码埋点支持不了的。但带来的问题就是采集全部数据对应用的侵入会比较大，也会增大用户端采集的数据量。固然，这能够经过一些策略，好比Wi-Fi下才发来缓解这些问题。

无埋点和可视化埋点都存在一个较大的缺陷，它们都是经过采集SDK去监测应用上控件的触发事件（用户对控件的操做），当产品UI在版本升级过程当中发生变更，或者产品作了大的改版，一些行为的“埋点”会发生丢失。如控件ID发生变化，而圈选的配置没变，致使数据采集不到；或者和业务的实际须要发生不一致的变更，好比圈选控件的做用发生了变化，但圈选配置没改；这些问题会致使对产品某些方面的分析出现差错，每每查起来还比较麻烦，在技术上彻底解决也比较困难。

另外，可视化埋点和无埋点都针对的是客户端数据采集，一些用户行为数据在客户端是采集不到的，或者客户端采集的精准度不够，好比支付，由于支付成功的判断绝大多数场景都是在服务端作的，因此在客户端作支付行为的埋点，偏差很大，这个时候就须要在服务端进行埋点。

在业务选择时，建议在产品初期，产品形态还不太稳定、分析的复杂度还比较低的阶段，采用无埋点或者可视化埋点，更快去作埋点，不然频繁的产品改动，会让开发人员大量时间花在琐碎的埋点代码维护上面。产品进入稳按期后，尽可能采用代码埋点方式，能够保证事件模型是稳定的，便于长期的数据监控、分析和数据沉淀。

 

3、实践中作了些工做，来促进埋点工做的落地以便更好的维护和管理？

 

产品业务数据驱动的 workflow 每每是这样的：

1、定义产品的阶段性目标；

2、规划和定义指标，包括产品、运营、市场的各项目标；

3、产品、运营等业务人员肯定数据埋点需求；

4、开发人员进行埋点以及数据的上报等开发工做；

5、数据开发人员进行数据的清洗、宽表建设、指标计算等工做；

6、业务人员分析数据、发现产品问题或潜在机会；

7、继续下一阶段的产品、运营、市场等的改进工做。

 

用户行为分析平台的目标就是将其中4-6阶段的工做变得简单和自动化，把开发人员解放出来去作更多对业务有价值的工做。而1-3部分的工做，看起来不复杂，基于业务现状去定义指标，排出埋点需求，和开发人员进行确认后就完成了。但这块从实践上来看，不少企业或者业务都作的不够好。

 

埋点事件数量迅速膨胀，团队可能大部分人都不知道某些埋点是作什么的；或者业务人员定义了埋点需求，但开发人员埋点作错了，很久都没发现，致使分析过程出现错误解读，影响决策。

 

这块有几件事情能够作：

l  指标管理系统，用来维护指标依赖的数据表、字段以及计算方式，来统一开发、分析和解读过程的口径。

l  埋点管理系统，用来管理埋点的元数据，包括事件 Event 的命名、自定义字段含义和特定取值等规范定义，埋点在产品端的位置或触发场景，埋点工做流等，做为业务人员、开发者、分析师沟通的桥梁和基准。

l  埋点测试和校验系统，提供 debug 工具方便开发人员快速进行埋点调试，以及使用事件定义的规范要求，在线上对埋点数据进行校验，尽早发现不符合规范的数据，提升埋点工做的效率和准确性。

汇总就是：元数据管理系统 + 测试和校验工具。

 

4、如何作好埋点工做和研发的协调和落地 ？

 

实践中，不少开发人员不太愿意作“埋点”的工做，以为很琐碎，并且随着产品的发展，包袱有时候会愈来愈大，维护的工做量不小。

要让埋点工做在研发比较好的落地，最能提高的地方仍是在于如何简化开发人员的工做，包括开发成本和沟通成本。

有完善的埋点管理系统，这样研发端能够依据进行开发，减小“口口相传”带来的低效和返工，也能统一口径和进度流程。有高效易用的埋点测试、校验系统，开发人员能够快速进行埋点debug，提升开发效率，也能让业务方尽早介入需求校验，而不是等应用真正发布后才去校验，去发现问题。

固然，最好能和开发人员持续分享数据是如何促进业务的发展，让你们明白这些工做的价值，才能更重视，更认真对待这部份工做。

 

5、埋点数据采集与企业数据资产建设怎样更好的合做？

 

用户行为分析平台在建设时，数据端会包含以下能力：

l  数据接入，要支持客户端、Web、服务端等多终端的数据采集，如iOS、Android、微信小程序等，以及各类数据源甚至三方服务的数据适配。

l  数据传输，在用户规模和数据规模增加过程当中，要能保证数据传输服务的高可用，以及采集数据在传输过程的及时性。

l  数据建模/存储，要能实时的进行数据清洗、建模和存储落地。

 

这些能力，在互联网业务的数据资产建设过程当中，尤为是用户、流量、产品相关领域，能起到基础设施的做用。规范的数据采集，加上高效的传输、建模能力，是企业业务数据资产有效建设的前提。

建模后的数据，能够做为数据仓库底层（ODS层）的宽表，和企业的其余业务数据整合，共同完善企业的数据资产建设。

另外一方面，这些用户端的结构化数据，加上实时建模和开放的能力，和机器学习算法结合起来，不管是个性化推荐，仍是精准营销，又或是银行、电商的风控，均可以发挥很大威力，为企业的智能驱动业务作好数据积累，扫清障碍。

 

拿DMP（用户画像）建设举个例子：

企业在建设本身的DMP库的过程当中，经常会从常规的人口属性等准静态类标签，以及像消费能力等从自身业务积累或三方合做获得的通用类标签入手。这些标签每每是泛业务的，针对具体业务而言，不少时候会须要用户画像标签更贴近业务，好比电商业务场景下的母婴用户、电子产品发烧友、化妆品品牌喜爱用户等。这些标签和用户的发掘，须要对用户的行为进行深度分析来获取，这个工做即可以借助用户行为分析平台的能力，如基于用户行为模式和用户业务属性对用户进行分群分析和比较，来发现和挖掘有价值的用户标签。

另外一方面，用户画像的数据，也能够和分析平台进行整合和集成，提高平台各分析模型对不一样用户群的洞见能力，让分析和指标的比较更有针对性，提高数据对业务的促进能力。

 

6、埋点及分析平台和 A/B 试验平台如何更好的互相促进？

 

A/B测试产品是经过提供专业高效的试验平台，帮助产品进行产品决策的验证和分析。常规使用流程以下：

接入 SDK -> 建立试验版本 -> 设置变量、以及优化指标 -> 调节试验流量 -> 运行试验 -> 实时监控数据进行效果评估 -> 正式发布

试验平台和分析平台的SDK在不少功能上是重合的，在SDK实现上能够整合，减小业务应用接入太多SDK的负担。

在数据采集、建模、分析层面，分析平台能够做为 A/B 试验平台后端数据的承载，优化指标的效果评估就能覆盖用户的全量行为，无需业务及开发人员维护多个工具带来的重复埋点定义和开发工做。另外，在分析平台积累的不少分析模型和指标，在A/B试验平台直接能够选取使用，无需在试验平台再进行设置，除减小业务人员工做外，还能保证统计口径的一致。

反过来，A/B试验平台的一些对比试验，以及特定灰度发布的用户群，也能整合到分析平台，经过分群分析能力，将这些群体应用到各个分析模型进行针对性的分析，甚至试验结束后，也能持续对这些用户进行追踪和分析，更好的洞察用户。

 

7、如何打通产品多端的埋点数据？

 

这是个归因的问题，通常提到帐号打通，就会有归因的讨论。

如今的分析产品在通常状况下，移动端会经过SDK生成惟一ID来标识用户/设备。移动化发展早期，不少采集工具用过 mac address、IDFA、android_id、IMEI等从移动操做系统能够获取的设备软硬件信息来标识设备，但随着操做系统的发展，不少信息获取接口要么被封禁，要么已经失去了精准性。反却是一开始就经过本身生成的ID来标识用户的工具，受到的影响不大，基本保持了用户/设备标识的稳定。

但这种方式存在一个问题，当用户卸载、重装或者刷机后，ID信息会丢失，致使生成新的用户/设备ID。

 

咱们采用过ID Mapping的技术来作过ID的打通：对每一个用户生成一个虚拟ID，对同一个用户的多个设备和账号进行映射，并绑定起来。

l  能够经过操做系统提供的一些稳定性稍差，但短期还比较稳定的指标，如iOS的IDFA，来作mapping。

l  借助分析产品的应用覆盖率，如用户是应用A和B的用户，卸载并从新安装B应用后，能够经过应用A的ID修复应用B的。

l  经过引入产品用户帐号体系来作绑定，这种方式稳定性最强，但非登陆匿名用户的问题很差解决。

l  经过IP、Wi-Fi信息、机器型号、甚至地理位置进行mapping，这种方式须要用户受权更多数据获取权限，虽然是近似匹配，但当信息足够多且发散（信息熵足够大）时，也能够起到统一标识的做用。

 

经过这个虚拟ID实质上就打通了产品的多端数据。ID Mapping体系的建设工做量不小，Mapping后用户标识若是须要发生调整，在基于事件的分析产品上须要对老数据进行重写，比较复杂。因此对于一些强帐号体系的产品，能够退化到只用用户帐号来作关联，只有非登陆匿名用户才用设备ID来标识，这每每是性价比比较高的方案。

推广渠道归因就方便了。

支持营销效果评估的分析平台会要求产品在平台上生成推广连接进行投放。用户在点击连接时，会从分析平台的域下作跳转再到目标页，这样就能够借助浏览器的cookie机制进行匹配，对用户来源进行归因，但这种方式在移动端上面的表现不太好（iOS已经取消了SFSafariViewController多应用共享cookie的支持）。除此以外，也能够采用ID Mapping提到的近似匹配技术，不少厂商声称的设备指纹技术大多也是这种，不太精准，可是作定性分析是能够的。

 

归因这块，一些推广渠道作了些工做，解决移动端溯源困难的问题：支持设备ID的回传功能来方便产品归因问题的解决。

产品方在投放连接的时候，遵守特定格式便可，好比

 https://xxx.com/aaaafD?idfa=__IDFA__&imei=__IMEI__

渠道在用户点击广告连接后，会把设备ID如IDFA或IMEI加到连接的内容里面，用户激活后即可以经过相应ID匹配来归因。

 

网易有数是网易旗下的企业级大数据可视化分析平台，可点击免费试用。

 

网易云免费体验馆，0成本体验20+款云产品！

 

更多网易研发、产品、运营经验分享请访问网易云社区。

 

相关文章：
【推荐】 爬虫开发python工具包介绍 （1）
【推荐】 试水新的Angular4HTTPAPI