关于数据埋点，你需要知道的技术方案和规范流程

　　前面发文重点介绍OneID和用户画像，本次文章从基础技术的维度来介绍下数据埋点的方案，关注转发，是我分享最大的动力。01如何理解埋点
　　埋点是数据采集的专用术语，在数据驱动型业务中，如营销策略、产品迭代、业务分析、用户画像等，都依赖于数据提供决策支持，希望通过数据来捕捉特定的用户行为，如按钮点击量、阅读时长等统计信息。因此，数据埋点可以简单理解为：针对特定业务场景进行数据采集和上报的技术方案。
　　数据埋点非常看重两件事，一个是数据记录的准确性，另一个则是数据记录的完备性。
　　先讲数据的准确性。数据埋点非常强调规范和流程，因为参数的规范与合法，将直接影响到数据分析的准确性，如果准确性得不到保障，那么所有基于埋点得出的结论，都是不可信的。辛辛苦苦做了很久的方案，一旦因为一个疏忽的小问题，导致下游集中投诉，其实非常划不来。
　　道理每个人都懂，但现实情况中，数据埋点所面对的客观环境，其实非常复杂，例如：产品在移动场景下，既有原生的IOS和安卓端，也有H5和小程序端，每种场景的技术栈不同，出现问题的排查成本很高；埋点准确性的验证，需要人肉参与，不能保证完全正确，且一旦出现问题，只能随着下次发版来修复，修复问题的时间成本很高。
　　因此本文有非常长的篇幅来写流程问题，其实是非常有必要的。
　　再讲数据的完备性。因为埋点主要是面向分析使用，对用户而言是个额外的功能，因此埋点的业务侵入性很强，很容易对用户体验造成影响。别的不说，仅仅是流量的消耗，就很容被用户喷。因此，要提前想清楚，我们要采集哪些东西，因为修改方案的成本，是伤不起的。
　　通常情况下，我们需要记录用户在使用产品过程中的操作行为，通过4W1H模型可以比较好的保障信息是完备的。4W1H包括：Who（谁）；When（在什么时间）；Where（在什么位置）；What（看到了什么）；How（做了哪些操作）。
　　规定好记录信息的基本方法之后，按照固定的频率，如每小时、每天，或者是固定的数量，比如多少条日志，或者是网络环境，比如在Wifi下上传，我们就可以开心的把埋点数据用起来了。
　　当然，数据记录的时效性也比较重要，但因为埋点数据通常量级会比较大，且各个端数据回传的时间不同，因此想做到实时统计，还是需要分场景来展开。在Flink技术日渐成熟的今天，全链路的实时采集与统计，已经不是什么难题。
　　02埋点的技术方案
　　在埋点的技术方案中，首先要重视的，是用户唯一标识的建设。如果做不到对用户的唯一识别，那么基础的UV统计，都将是错误的。
　　因此，在数据埋点方案中，有两个信息是一定要记录的，即设备ID用户ID。设备ID代表用户使用哪个设备，如安卓的ANDROIDIDIMEI，IOS中的IDFAUDID，浏览器的Cookie，小程序的OpenID等。用户ID，代表用户在产品中所注册的账号，通常是手机号，也可以是邮箱等其他格式。
　　当这两个信息能够获得时，不论是用户更换设备，或者是同一台设备不同账号登录，我们都能够根据这两个ID，来识别出谁在对设备做操作。
　　其次，我们来看一下Web的数据采集技术。Web端数据采集主要通过三种方式实现：服务器日志、URL解析及JS回传。服务器日志：指Web服务器软件，例如Httpd、Nginx、Tomcat等自带的日志，例如Nginx的access。log日志等；URL解析：指访问服务器时，将URL信息及携带的参数进行解析后，上传服务器，例如访问百度首页：https：www。baidu。coms？ieutf8wd你好，我们可以获得本次访问的word为你好；JS回传：指在Web页面上添加的各类统计插件，通过在页面嵌入自定义的Javascript代码来获取用户的访问行为（比如鼠标悬停的位置，点击的页面组件等），然后通过Ajax请求到后台记录日志。
　　浏览器的日志采集种类又可以分为两大类：页面浏览日志和页面交互日志。页面浏览日志：别名为展现日志；指当一个页面被浏览器加载时所采集的日志，该类型为最基础的互联网日志，也是PV及UV统计的基础。页面交互日志：别名为点击日志；指当页面加载和渲染完成后，用户可以在页面上执行的各类操作，以便量化感知用户的兴趣点。
　　除此之外，还有一些针对特定场合统计的日志，例如页面曝光时长日志、用户在线操作监控等，但原理都基于上述两类日志，只是在统计上有所区分。
　　再次，我们来看下客户端的数据采集。与网页日志对应的，是手机应用为基础的客户端日志，由于早期手机网络通讯能力较差，因而SDK往往采用延迟发送日志的方式，也就是先将日志统计在本地，然后选择在Wifi环境下上传，因而往往会出现统计数据延迟的情况。现如今网络环境好了很多，4G、5G流量充足，尤其是视频类APP基本上都是一直联网，因而很多统计能够做到实时统计。
　　客户端的日志统计主要通过SDK来完成，根据不同的用户行为分成不同的事件，事件是客户端日志行为的最小单位，根据类型的不同，可以分为页面事件（类比页面浏览）和控件点击事件（类比页面交互）。对于页面事件，不同的SDK有不同的方式，主要区别为是在页面创建时发送日志，还是在页面浏览结束后发送日志，区别在于业务统计是否需要采集用户的页面停留时长。
　　页面事件的统计主要统计如下三类信息：设备及用户的基本信息，例如IMEI、用户账号等；被访问页面的信息，例如商品ID、浏览店铺等；访问的路径信息，例如上一个页面来源等。
　　最后，我们还需要考虑小程序等场景的埋点方案，小程序通常情况下，开发者会声明好相应的方法，按照需求调用即可，例如微信提供了API上报和填写配置两种方案。
　　埋点其实还需要考虑数据上传的方案，批量的数据可以通过Flume直接上报，流式的可以写到Kafka，或者直接使用Flink来处理。这些框架相关的内容不是本文考虑的重点，有兴趣的可以自行查阅资料。03埋点的流程规范
　　有了指导思路和技术方案后，我们就可以着手制定相应的数据埋点流程规范了。
　　笼统上，流程规范会分成五个步骤，即需求评审、埋点申请、技术开发、埋点验证、发布上线。
　　第一步，需求评审。
　　前文提到过，数据埋点的方案一旦确定，返工和排查问题的成本都很高，但数据埋点之后的分析工作，又涉及到了PD、BI、算法、数据等多个角色。因此非常有必要，将需求内容和数据口径统一收口，所有人在一套口径下，将需求定义出来，随后业务侧再介入，进行埋点方案的设计和开发。
　　以前文提到的4W1H模型为例，常见的记录内容如下：Who：设备ID、用户ID、手机号、微信识别码等；Where：在Web、移动端还是小程序下，如果是移动端，GPS地址在哪，使用的是哪个APP；When：记录日志的时间戳、日志上报的时间戳；What：操作系统、设备型号、网络环境、APP版本、当前页面、展示内容等信息；How：如果是搜索行为，则记录关联词；如果是内容点击，则记录内容ID、内容类型、列表位置；如果是交易动作，记录交易的商品ID、类型、数量；如果是支付过程，记录付款的方式与付款金额。
　　最后我们统计时，按照上述约定，统计用户在某个时间和地点中，看到了哪些信息，并完成了怎样的动作。上下游的相关人员，在使用这份数据时，产生的歧义或者是分歧，会小很多。
　　第二步，埋点申请
　　当下的热门应用，大多是以超级APP的形式出现，比如微信、淘宝、支付宝、抖音，超级APP会承载非常多的业务，因此技术方案上会十分统一。
　　因此，当我们的技术方案确定后，通常要在相应的埋点平台上，进行埋点申请。申请的内容包括分配的SPM、SCM码是什么，涉及到的平台是哪些，等等。SPM、SCM是什么，有什么用，同样可以自行查阅。
　　第三步，技术开发
　　当需求确定、申请通过后，我们就可以开始开发动作了，这里基本上是对研发同学进行约束。埋点的开发，简单讲，是分成行为埋点和事件埋点两个大类，每一类根据端的不同进行相应的开发。具体的技术方案详见前文01章节。
　　详细的设计规范，是需要留文档的，因为代码不能反应业务的真实意图，而不论是事后复盘与业务交接，都需要完整的文档来阐述设计思路。
　　第四步，埋点验证
　　埋点的验证很关键，如果上线后才发现问题，那么历史数据是无法追溯的。
　　验证有两种方式，一种是实时的功能验证，一种是离线的日志验证。
　　实时功能验证，指功能开发好后，在灰度环境上测试相应的埋点功能是否正常，比如点击相应的业务模块，日志是否会正确的打印出来。通常而言，我们需要验证如下三个类型的问题：记录正确：APP发生相应的动作，检查日志是否打印正确，如：打开页面（行为埋点）、点击按钮（事件埋点）时，是否日志会记录；位置正确：查看SPM、SCM码与平台申请的是否一致；内容正确：设备ID、用户ID等必须记录的内容是否正确，行为、事件记录内容是否与页面实际发生的一致。
　　除去实时验证，我们也需要把日志写到测试环境中，查看数据上报的过程是否正确，以及对上报后的数据进行统计，侧面验证记录的准确性，如统计基本的PV、UV，行为、事件的发生数量。
　　很多时候，数据是需要多方验证的，存在一定的上下游信息不同步问题，比如对某个默认值的定义有歧义，日志统计会有效的发现这类问题。
　　第五步，发布上线。
　　应用的发布上线通常会有不同的周期，例如移动端会有统一的发版时间，而网页版只需要根据自己的节奏走，因此数据开始统计的时间是不同的。最后，应用应当对所有已发布的埋点数据，有统一的管理方法。
　　大多数时候，数据埋点的技术方案，只需要设计一次，但数据准确性的验证，却需要随着产品的生命周期持续下去，因此仅仅依靠人肉来准确性验证是不够的，我们需要平台来支持自动化的工作。埋点的准确性，大体有两种方法保障：一种是灰度环境下验证真实用户数据的准确性；另一种则是在线上环境中，验证全量数据的准确性。因此，发布上线之后，后续的管理动作，应该是对现有流程的自动化管理，因为团队大了，需要埋点的东西多种多样，让平台自己测试、自动化测试，就是很多测试团队必须走的路