埋点自动收集方案-概述

引言

埋点自动收集方案，由于涉及内容较多，考虑到篇幅原因，将分为三篇文章分别阐述

• 《埋点自动收集方案-概述》

• 《埋点自动收集方案-路由依赖分析》

• 《埋点自动收集方案-埋点提取》

其余两篇会在随后相继发布

本篇文章篇幅较长，对最终效果好奇的同学，可以优先查看“后台预览”部分的截图

痛点

埋点，作为跟踪业务上线效果的核心手段

其说明文档也是重中之重，但在很多公司或团队都在以最原始的方式维护

有的团队即便有统一的埋点平台，但整体运营成本也较高 

1）维护成本

每次提需求，pm需要花费大量时间维护埋点文档

新增埋点还好，直接加上就可以了。

如果有涉及老埋点删除或修改，还要先找开发同学确认，然后再更新文档

如果怕麻烦，文档只增不删。。时间长了，你懂的~

2）到底谁来维护埋点文档

前面提到，新增还好，主要是删除或者更新埋点，谁来推动埋点文档更新？

开发同学推动pm？

pm找开发要埋点更新list？

开发直接更新埋点文档？

开发同学在开发同时还要记录埋点更新list？

开发和pm会不会相互扯皮？

3）无阻断性流程

整个流程，单靠一方角色确实难以达成目标

最终无论谁来维护，但凡没有阻断性流程，就变成全靠自觉了。

靠自觉，那要是能持久，就见鬼了~

4）埋点文档不准确

由于前面的原因，也就造成了埋点文档和实际上报代码越来越远

时间长了自然没法看，尤其碰到人员变动或者业务调整

新同学接手后，脑门直接三道黑线。。

5）开发同学抵触情绪强

PM：“帮我查下xx项目的埋点吧，我急用”

PM：“之前做的xx活动的埋点能帮我查一下么”

PM：“上次需求迭代，埋点更新list给我一份”

...

尤其赶上倒排期的项目。。

作为FE的你，是否有同感。。

引发的思考

无论怎样，线上数据通过埋点反馈，而且业务调整的依据就是数据

这是客观事实。

所以埋点文档这个痛点必须解决。

可能有同学会问，为什么不用第三方的埋点方案（比如：growingIO、神策等）

因为，无论采用哪种方案，目前主流上报埋点的方式就两种：

1. 全埋点上报（含区域上报）

2. sdk主动上报（单埋点、多买点上报）

全埋点上报需要pm根据页面结构进行配置（主要维护方在pm），一旦页面结构变更，需要重新配置。

另外公司的现状就是有自己的数据平台，但如果采用全埋点上报，在数据分析层面会有非常大的负担，而且各业务线本身采用的是代码主动上报方式。

sdk主动上报，就会遇到前面提到的问题。

可能还有同学说：“这本来就是pm该干的事，我只负责我这部分就好。”

这本身也没毛病，但我们本质上还是想提升整体团队的效率

在做这个方案的时候，我们也和很多团队的pm沟通过，维护一个可用的埋点文档确实会消耗相当大的精力

这也让我更加坚定了决心！

方案思路

前面所有的问题，核心就两个：

• 没有统一埋点平台

• 没有科学可用的埋点协作模式

经过组内多次讨论，又将问题细分，

以及对应