作者：donnyhuang，腾讯微信支付运营支持研发团队

数据驱动是近年来很火的概念，可以优化产品体验、可以用于运营增长、可以发现质量问题，看起来无所不能，时尚先进。但是，你得先有“数据上报”，而实际上我们在数据上报的处理过程中是有很多痛点的。业界“无埋点”的方案，早在十几年前就有了，但实际很多业务应用起来并没有那么理想，我们也调研过公司内外前人的经验，其中反馈被无埋点折腾到吐血的案例也数不胜数。那么到底如何破局呢？

一、背景

先从两个案例说起，左上角这个本来我们是计划做一个漏斗图，但是因为前面开始刷脸上报的事件缺失，导致出现了葫芦状的漏斗，第二个案例是中间有一段时间数据漏报了，导致出现截断的现象，整个数据就不能用了。类似的问题还有很多，我们统计了一下，发现漏报的问题占比最大，其中有些是产品没提需求，有些是提了需求但是研发忘了埋，当然还有一些是错报、报重，还有一种是是报对了，但是数据同学理解错了，导致开发出来的报表或者分析也不能用

二、为什么数据上报这么多问题

为什么上报这么多问题呢，我们从整个研发流程来看看。

首先在需求阶段，产品经理需要同步把功能需求和数据需求提给开发，但是产品同学最核心的职责是挖掘用户价值，商业机会，这个时候产品往往比较关注功能，因为数据分析是运营阶段才会用到，我们统计了上报 tapd，发现 42%的需求都是一句话的，40%的上报需求都是事后补上报。

到了研发阶段，开发同学不止要完成功能的编码，还要做埋点，比较琐碎，而且难以验证埋得对不对，因为埋点不像功能，做出来就可以自测了，它要等上线后报表做出来了才能看到数据。

最后到运营阶段，数据同学要做数据分析了，这个时候往往没有数据定义，需要他们到处拉群去问数据的含义，非常低效。

能不能把这个模式转变过来呢？能否通过一种规范化的上报，不需要产品再提需求，研发同学按照一定的模式现自动埋点，产品想用的时候再把这个埋点启用就可以了。另外，数据定义要系统化，数据同学要什么数据直接在系统上查就好了，不用到处去问。

看起来有点理想化，怎么做到呢？

三、规范化：无需提需求

首先要搞清楚我们平时都在报什么数据。数据上报的本质是记录软件变化过程，

我们研究了上千个上报 Tapd 单，2000 多个上报协议，得出我们的上报可以归为几大类，第一类就是行为数据，它是发生在我们系统的 UI 层，记录用户操作的过程。第二类是系统事件，记录的是系统的操作变化。第三类是业务实体，也就是我们后台数据库存储的对象，比如订单、设备、商户等信息。

我们就可以把这些规律总结成规范，指导研发什么时候该上报，这样我们就可以把所有需要上报的数据预埋到代码中，产品要用的时候只需要按需启用就可以了。

进一步的，如果代码架构足够合理，是可以把上报模式化，把上报自动映射到代码中，实现自动埋点。

四、模式化：自动埋点

自动埋点，其实就是自动化找到正确的位置，插入上报代码，我们基于前面分析出来的数据上报分类和规范，我们通过插桩、切面的方式映射到安卓客户端的代码组件中，比如用户行为，我们会基于一定的规范标准映射到 onClick、onShow、onHide 等组件，系统事件映射到 doFacePay、setProxy、sendMsg 等等。这样再通过后期的关联，我们就可以关联到事件图上面。

当然，只是找到事件还不行，还要能自动上报其中的参数字段，那么客户端如何感知需要哪些字段呢？基于上报规范，只告诉我们应该报哪些字段，但程序怎么自动把字段找出来。

对于基础字段，我们可以通过 hardcode 的方式默认上报，但对于个性化业务字段，怎么识别？

其实无埋点的方案，早在十几年前业界就有了，但实际应用起来并没有那么广泛，我们也去 km 和知乎上搜索过前人的经验，其中反馈被无埋点折腾到吐血的案例也非常多，核心是无埋点不能描述业务，对于个性化业务字段没有上报，也就无法做自动分析。

经过分析发现，其实客户端需要上报的业务字段，也来自于我们领域建模，不会凭空产生，而领域模型最终会转变成数据模型，会设计成库表存在我们后台，且微信支付所有的后台库表都已经实现了自动入库。

所以客户端只需要上报业务实体的 id 即可，比如播放海报这个事件，只用上报海报 ID 这个业务参数，如果要分析不同海报的数据转化，再关联海报实体中的海报类型字段即可。这样就好办了，客户端只需要订一个契约，凡是遇到非空实体 ID，都上报上来，数据定义的时候在关联即可，分析时关联后台入库数据即可。

当然，无埋点还要考虑流量的问题，全部乱报会容易把客户端的流量搞爆，所以我们的做法是预插桩，但只有通过下发配置启用埋点才上报。

五、系统化：无需到处问数据

过去理解数据，需要拉一个大群来问，因为一般客户端涉及到多个研发，需要经常要拉 10 个人以上的群讨论一个小时，有时候研发也不记得报了什么，需要看代码，然后下一人用数据又要再重新讨论确认。

我们做了一个数据上报定义工具，定义出来我们上报了哪些事件，数据同学要什么数据直接通过这个工具查就好了。

另外，因为有了数据定义，我们就可以做自动化校验，把数据问题在开发阶段就暴露出来消灭掉，这样我们现网反馈的数据问题就明显收敛了，最新的版本，数据 bug 数已经很少了。

六、成果分享

讲了那么多理论，来一点实实在在的成果吧！

成果 1：以前上线一个活动之后，需要看转化率，还要紧急提需求可以开发手工跑数据，一天就过去了，有时候发现少了上报只能紧急加上报再采集，啥时候能出数据就不知道了。

现在我们做到了全面的埋点，产品只需按需启用即可，并且由于有路径定义关联埋点，可以自动分析每个路径上的转化，想看哪个环节的转化直接获取，随要随得。

产品同学都很震惊，我们竟然提前预测到了需求。

成果 2：在数据监控上的应用，我们在升级版本的时候，观测到超时退出的比例飙升，然后活检成功率明显下降，后来反馈给研发是摄像头代码的一些问题，及时做了修复。

七、总结

数据上报，一个看起来很简单的事情，但其中的痛点相信很多做数据的同学深有体会，团队也经历过痛、无奈、迷茫的心历路程，与其去埋怨吐槽，不如当成这正是技术成长的机会，去探索突破。

坦白讲，本文介绍的绝非什么高精尖的技术，但值得一提的是思考顺序上的不同。往往看过有一些误区，即是先拿到一门看起来时髦的技术，然后看可以用到哪些地方，“好比手上有一把锤子，在想可以在哪里敲打敲打”，最后可能哪也不合适。而我们是先会看到底是“啥问题”，在看“用什么”解决，比如数据上报，我们不会一上来就说要无埋点，而先是分析了都在报什么，抽象提炼出了几种模式，然后才是怎么高效的报，高效的用。

笔者在过程中也非常纠结，无数次怀疑这个事情到底能不能做到，是不是太理想化了，是不是应该降低要求。事实证明，探索一个事情，首先要看到他的价值，如果是一个很有意义的事情，不需要一开始就用自己局限性的经验来判断它的可行性，也许经过多轮思考，它会由“不可能”慢慢变得“可能”。

但是，在行动上我们可以更巧一些，虽然长期我们追求很高的要求和目标，但不是说一定等着最佳方案才行动，因为大的突破思路往往是需要花比较长的时间进行讨论、推导，一些明确的实行是可以先并行做的。比如数据测试和数据模型定义，我们一开始就认为很明确，很早就开始并行实施，保证团队定期有进展和价值输出，不至于太焦虑。因为探索的路上很寂寞，很容易迷失自我，需要有一个良好的项目节奏在持续前进。