[发明专利]一种数据埋点的配置方法、存储介质及设备

说明书

本发明的一种数据埋点的配置方法、存储介质及设备，其中方法包括以下步骤，S1、采用全埋点+代码埋点的综合模式，设定前端记录用户的行为日志，对页面访问、按钮点击这些基础事件，全面记录和上报，对功能事件，增加专门的埋点；S2、基于后端同步各项业务数据日志，建立维度信息表，完善EV事件的处理方法，确保数据的准确性和全面性；S3、进行埋点流程管理和数据过滤管理。本发明能够基于埋点配置、处理和埋点系统进行埋点流程管控和方案编制，完善埋点技术方案的顶层设计，通过业务映射增加对事件信息和属性信息的理解，监控使用情况，解决埋点的触发机制不清晰不明确的问题，提升埋点数据准确性和全面性。

技术领域

本发明涉及数据采集技术领域，具体涉及一种数据埋点的配置方法、系统及设备。

背景技术

所谓埋点，就是数据采集领域的术语，作为一种常用的数据收集方法，它的学名应该叫做事件追踪，对应的英文是Event Tracking，指的是针对特定用户行为或事件进行捕获，处理和发送的相关技术及其实施过程。

数据埋点是基于业务需求或者产品需求对用户行为的每一个事件对应位置进行开发埋点，并通过上报埋点的数据结果，记录汇总数据后进行分析，推动产品优化和指导运营，或者用于研究用户的行为习惯等方面。

比如直接采用友盟、百度统计这样的第三方统计工具进行数据埋点，通过嵌入AppSDK 或JS SDK，来直接查看统计数据。这种方式只能采集很基础的数据，比如页面访问，按钮点击等等，但是想分析各个维度的情况，分析服务端的库存、订单等情况，就基本上无法实现。

再如企业自行设计进行人为埋点，只使用业务数据库来完成数据分析，理论上可行，但是由于业务数据库面向OLTP的业务事务过程，很多中间数据不会保存，很多分析没办法做，且性能上完全不支持大规模的数据分析，运行速度迟缓。

在埋点的实际操作过程中，经常会遇到各种技术问题，比如：

① 业务兼容的问题

前期规范执行之后，后续随着业务的拓展，已有数据字段满足不了业务的分析需求；

②产品兼容的问题

埋点从应用端来区分，包括web/ios/android、小程序、公众号，还要区分是原生还是H5，新老版本之间肯定会带来一些模块化的差异；

③前后端埋点不一致的问题

前端请求服务端的数据大多是存在binlog里面的，数据日志同步解析的过程里面可能会存在丢包的可能性，数据仓库的稳定性也会影响数据质量；后端服务信息存储的数据是存在mysql，表字段结构化，分多表存储，需要靠主键进行关联，有大量的ETL过程，两者之间可能因为数据清洗、处理、实时技术等原因，造成数据差异化；

④ 自埋点和第三方应用统计口径的问题

自埋点一般都会定义一个唯一id作为区分用户的标志，但是第三方是缺少用户属性信息的判断，一般会以设备号uuid/imei，或者IP地址段、mac地址段作为区分标志，从而造成统计数据上的差异化，对于留存分析、转化分析、流失分析需要用到明细数据的场景，可兼容性不是很友好；

⑤ 埋点开发技术执行不到位的问题

绝大多数情况下说埋点，一般都是说前端埋点，前端开发工程师在做埋点的时候又多是人为埋点，在开发过程中，会造成部分信息冗余、重复、记录不完整的情况存在；

⑥多产品之间的模块差异化问题

埋点不能够只有一套标准规范，多生态应用下，业务繁琐，在产品、技术的架构上有明显的差异，不同的产品、模块、坑位、点击事件的定义也可能有一定的区别，这时候可能需要根据场景划分不同的埋点标准；

⑦自定义埋点信息的键对设计问题