一、项目背景
在数字产品的数据分析实践中,手动代码埋点方式因其精确性和定制化的优势长期被许多组织采用,但随着业务快速发展和迭代需求的增加,传统手动埋点方法的时间消耗、一定的技术门槛和较高的维护成本成为研发角色的负担。另外,全埋点的埋点方式提供了全面数据捕捉的解决方案,但其带来的海量数据处理难题和潜在的隐私风险也不容忽视。
原有商家后台通过手动埋点方式实现业务埋点的收集。
埋点流程从明确需求到上线&验证共计上图 5 个步骤,手动代码埋点经历 v1.0 到 v2.0,减少了研发熟悉埋点流程、平台建节点、埋点 coding 成本,从前期产品随需求提出埋点诉求,到进入迭代进行需求开发,再到需求正式上线,并生效查看数据。
在偏 B 类产品系统中,前期更关注产品功能实现,手动代码埋点的流程周期和成本的问题易导致埋点的覆盖率不足,在长期功能交互迭代试错或者精细化优化产品体验时,往往存在缺少及时和丰富的数据支撑来为决策优化方向提供保障。导致阶段性的体验较差,甚至极端研发资源浪费等问题。
可视化埋点相对手动埋点流程上得到明显减少,且具有以下价值:
- 埋点实时生效,数据 T+1 可查、加速数据驱动决策,业务埋点及时率高达 90%+。
- 提升链路整体效率,大部分场景下研发手动埋点开发 0 投入,0 沟通。
- 能够可视化的看到全量埋点,及时发现差异变更,及时调整,埋点丢失率 0%。
二、可视化埋点方案
产品定位
可视化埋点,主要目标服务于产品/运营同学,能够基于可视化形式快速进行埋点配置,做到实时生效,同时提供埋点通用能力,如埋点验证保障埋点准确率。
对比神策等埋点:
可视化埋点重点针对适配国内,国际,B 端,C 端等不同场景,最大程度兼容现有埋点能力,支持多种埋点上报。
SDK 和数据采集,支持通过判断 Query 参数或 UA 信息,动态引入依赖,如 Facebook
、神策、Google
、BaseSdk
依赖,加载对应 CDN 的 JS 来进行底层数据上报。
本身可视化能力重点关注简化埋点编码过程,同时提供公共埋点能力,如提供数据劫持,加载自定义参数,埋点统一有效性验证等。
需求埋点整体流程图
埋点操作流程
如下为可视化埋点功能流程:
- 开启可视化埋点配置可移动配置面板,针对需要埋点的元素进行圈选。
- 页面圈选指定元素,配置相关名称、事件、自定义业务属性、维护人等,保存至管理后台数据库。
- 埋点 SDK 监听点击、曝光事件,读取配置信息,针对指定配置元素进行埋点上报。
三、商家可视化埋点的实践
技术实现流程
埋点定位&圈选方案
元素标志需要全局唯一且不易受到产品交互变更影响,并在确认受到影响后,需在功能迭代上线前,完成埋点变更。
标识结构设计
常规的 Xpath 设计,在针对外部结构变更时,很容易导致失效,需要进一步降低外部影响,因此唯一标识方面整体采用自定义Data-Trackid
+ 相对路径的Xpath 路径
。
标志生成&匹配流程
- 首先研发人员在研发时,需提前安装 VScode 插件 AddTrackId 埋点插件『用于生成
Data-Trackid
的 Data-Set 属性』。 - 安装完成后,在开发
JS
、TS
、TSX
、JSX
、Vue
等格式文件中任意位置,右键生成埋点所需 Data-Trackid
,即可扫描当前文件,针对指定 Dom 标签加上Data-Trackid
属性,每个标签使用新生成 TrackId【控制长度】,第二次保存时,已有 TrackId 不变,没有的新增 + 路径的拼接,转 MD5。 - 用户在页面圈选元素时,会寻找最近的带
Data-Trackid
的标签,如果没有则继续向上找,最终拼接一个相对的 Xpath
路径。
元素圈选方案
参考开源的 Dom-Inspector,圈选的本质就是在用户鼠标移动的时候,在元素上层出现一个同样大小的浮层,以便用户识别。
获取用户鼠标移动和鼠标移动处的元素,在 Body
上监听 MouseMove
事件并取其 Target
即可获取目标元素,接下来只需要获取元素的 content
大小、padding
、margin
大小及元素的位置,然后根据其位置挂载浮层。
数据采集SDK容器
依赖加载
- 可视化埋点为适配国内,国际,B 端,C 端等不同场景,最大程度兼容现有埋点能力,支持多种埋点上报 SDK 和数据采集,通过判断 Query 参数或 UA 信息,来通过动态引入依赖,如
Facebook
、神策
、Google
、BaseSdk
依赖,加载对应 CDN 的 JS。
配置读取&数据上报
- 读取配置: 可视化埋点是通用型埋点,不依赖具体埋点代码,根据当前产品所做埋点配置信息,通过匹配当前系统和页面 URL,按照对应规则,获取到当前页面的配置 JSON,进行加载。
- 数据劫持: 通过劫持 Fetch 等对象,获取页面请求数据,支持用户自定义配置上报的业务参数。
- 页面级别通用业务参数维护:研发在管理后台维护页面级别通用业务参数,通过 InjectCommon 方法将如订单 ID、类目 ID 等埋点需要关注的业务参数注入至 JSON 中,产品、运营通过选择业务参数即可进行埋点。
埋点上报
- 通过监听页面级别事件,判断是否为对应埋点元素,命中后,进行使用对应加载的 SDK 进行数据上报。
埋点验证更新
产品需求变,容易造成原有埋点失效,导致埋点覆盖率下降,目前支持三类方式进行埋点验。
手动埋点验证,埋点数据异常告警,埋点巡检任务。
手动埋点验证
埋点数据异常告警
可视化埋点管理平台,通过 CronJob 定时任务检查节点数据是否正常同步,若有节点异常则发消息给相关创建人。
埋点巡检任务
通过 Pupptter 记录用户行为,每天定时执行用户行为记录,检验节点是否丢失,若有丢失则发消息给相关创建人。
四、总结&规划
目前平台的监控、巡检体系用于保证数据准确性,避免数据丢失和异常,造成业务误判。埋点流程还存在一定可优化的空间,如:
- 埋点 SDK 存在一定耦合,未来功能粒度将拆的更细,做到各司其职。
- 监控体系的可配置化能力,将支持针对特定人群和数据维度进行指定配置化等。
- 优化 C 端可视化能力,提升 C 端可视化埋点体验。
平台的重点都是为业务服务,助力业务各类指标能力是平台价值最大化的最佳实践。
*文/勋
本文属得物技术原创,更多精彩文章请看:得物技术官网
未经得物技术许可严禁转载,否则依法追究法律责任!