数据埋点非常看重两件事，一个是数据记录的准确性，另一个则是数据记录的完备性。
先讲数据的准确性。数据埋点非常强调规范和流程，因为参数的规范与合法，将直接影响到数据分析的准确性，如果准确性得不到保障，那么所有基于埋点得出的结论，都是不可信的。辛辛苦苦做了很久的方案，一旦因为一个疏忽的小问题，导致下游集中投诉，其实非常划不来。
道理每个人都懂，但现实情况中，数据埋点所面对的客观环境，其实非常复杂，例如：
因此本文有非常长的篇幅来写流程问题，其实是非常有必要的。
再讲数据的完备性。因为埋点主要是面向分析使用，对用户而言是个额外的功能，因此埋点的业务侵入性很强，很容易对用户体验造成影响。别的不说，仅仅是流量的消耗，就很容被用户喷。因此，要提前想清楚，我们要采集哪些东西，因为修改方案的成本，是伤不起的。
通常情况下，我们需要记录用户在使用产品过程中的操作行为，通过4W1H模型可以比较好的保障信息是完备的。4W1H包括：
规定好记录信息的基本方法之后，按照固定的频率，如每小时、每天，或者是固定的数量，比如多少条日志，或者是网络环境，比如在Wifi下上传，我们就可以开心的把埋点数据用起来了。
当然，数据记录的时效性也比较重要，但因为埋点数据通常量级会比较大，且各个端数据回传的时间不同，因此想做到实时统计，还是需要分场景来展开。在Flink技术日渐成熟的今天，全链路的实时采集与统计，已经不是什么难题。
在埋点的技术方案中，首先要重视的，是用户唯一标识的建设。如果做不到对用户的唯一识别，那么基础的UV统计，都将是错误的。
因此，在数据埋点方案中，有两个信息是一定要记录的，即设备ID+用户ID。设备ID代表用户使用哪个设备，如安卓的ANDROID_ID/IMEI，IOS中的IDFA/UDID，浏览器的Cookie，小程序的OpenID等。用户ID，代表用户在产品中所注册的账号，通常是手机号，也可以是邮箱等其他格式。
当这两个信息能够获得时，不论是用户更换设备，或者是同一台设备不同账号登录，我们都能够根据这两个ID，来识别出谁在对设备做操作。
其次，我们来看一下Web的数据采集技术。Web端数据采集主要通过三种方式实现：服务器日志、URL解析及JS回传。
浏览器的日志采集种类又可以分为两大类：页面浏览日志和页面交互日志。
除此之外，还有一些针对特定场合统计的日志，例如页面曝光时长日志、用户在线操作监控等，但原理都基于上述两类日志，只是在统计上有所区分。
再次，我们来看下客户端的数据采集。与网页日志对应的，是手机应用为基础的客户端日志，由于早期手机网络通讯能力较差，因而SDK往往采用延迟发送日志的方式，也就是先将日志统计在本地，然后选择在Wifi环境下上传，因而往往会出现统计数据延迟的情况。现如今网络环境好了很多，4G、5G流量充足，尤其是视频类APP基本上都是一直联网，因而很多统计能够做到实时统计。
客户端的日志统计主要通过SDK来完成，根据不同的用户行为分成不同的事件，“事件”是客户端日志行为的最小单位，根据类型的不同，可以分为页面事件（类比页面浏览）和控件点击事件（类比页面交互）。对于页面事件，不同的SDK有不同的方式，主要区别为是在页面创建时发送日志，还是在页面浏览结束后发送日志，区别在于业务统计是否需要采集用户的页面停留时长。
页面事件的统计主要统计如下三类信息：
埋点其实还需要考虑数据上传的方案，批量的数据可以通过Flume直接上报，流式的可以写到Kafka，或者直接使用Flink来处理。这些框架相关的内容不是本文考虑的重点，有兴趣的可以自行查阅资料。
有了指导思路和技术方案后，我们就可以着手制定相应的数据埋点流程规范了。
笼统上，流程规范会分成五个步骤，即需求评审、埋点申请、技术开发、埋点验证、发布上线。
第一步，需求评审。
前文提到过，数据埋点的方案一旦确定，返工和排查问题的成本都很高，但数据埋点之后的分析工作，又涉及到了PD、BI、算法、数据等多个角色。因此非常有必要，将需求内容和数据口径统一收口，所有人在一套口径下，将需求定义出来，随后业务侧再介入，进行埋点方案的设计和开发。
以前文提到的4W1H模型为例，常见的记录内容如下：
最后我们统计时，按照上述约定，统计用户在某个时间和地点中，看到了哪些信息，并完成了怎样的动作。上下游的相关人员，在使用这份数据时，产生的歧义或者是分歧，会小很多。
第二步，埋点申请
当下的热门应用，大多是以超级APP的形式出现，比如微信、淘宝、支付宝、抖音，超级APP会承载非常多的业务，因此技术方案上会十分统一。
因此，当我们的技术方案确定后，通常要在相应的埋点平台上，进行埋点申请。申请的内容包括分配的SPM、SCM码是什么，涉及到的平台是哪些，等等。SPM、SCM是什么，有什么用，同样可以自行查阅。
第三步，技术开发
当需求确定、申请通过后，我们就可以开始开发动作了，这里基本上是对研发同学进行约束。埋点的开发，简单讲，是分成行为埋点和事件埋点两个大类，每一类根据端的不同进行相应的开发。具体的技术方案详见前文01章节。
详细的设计规范，是需要留文档的，因为代码不能反应业务的真实意图，而不论是事后复盘与业务交接，都需要完整的文档来阐述设计思路。
第四步，埋点验证
埋点的验证很关键，如果上线后才发现问题，那么 历史 数据是无法追溯的。
验证有两种方式，一种是实时的功能验证，一种是离线的日志验证。
实时功能验证，指功能开发好后，在灰度环境上测试相应的埋点功能是否正常，比如点击相应的业务模块，日志是否会正确的打印出来。通常而言，我们需要验证如下三个类型的问题：
除去实时验证，我们也需要把日志写到测试环境中，查看数据上报的过程是否正确，以及对上报后的数据进行统计，侧面验证记录的准确性，如统计基本的PV、UV，行为、事件的发生数量。
很多时候，数据是需要多方验证的，存在一定的上下游信息不同步问题，比如对某个默认值的定义有歧义，日志统计会有效的发现这类问题。
第五步，发布上线。
应用的发布上线通常会有不同的周期，例如移动端会有统一的发版时间，而网页版只需要根据自己的节奏走，因此数据开始统计的时间是不同的。最后，应用应当对所有已发布的埋点数据，有统一的管理方法。
大多数时候，数据埋点的技术方案，只需要设计一次，但数据准确性的验证，却需要随着产品的生命周期持续下去，因此仅仅依靠人肉来准确性验证是不够的，我们需要平台来支持自动化的工作。埋点的准确性，大体有两种方法保障：一种是灰度环境下验证真实用户数据的准确性；另一种则是在线上环境中，验证全量数据的准确性。因此，发布上线之后，后续的管理动作，应该是对现有流程的自动化管理，因为团队大了，需要埋点的东西多种多样，让平台自己测试、自动化测试，就是很多测试团队必须走的路
埋点是网站和APP等产品进行日常改进及数据分析的数据采集基础，根据采集得到的用户行为数据（例如：页面访问路径，点击了哪一个按钮）进行数据分析，从而更加合理的推送跟优化，增强用户体验。现在市面上有很多第三方埋点服务商，百度统计、友盟、growingIO等。
常见的埋点方法包括：
手动埋点：根据业务需求在需要采集数据的地方进行埋点，是比较常见的埋点手段。
可视化埋点：一些事件带有元素唯一标识。通过在后台进行埋点配置，将元素与要采集信息关联起来，然后自动生成埋点代码嵌入到页面中，目前发展比较火的埋点方式，但是技术上的实现跟推广比较困难
无埋点：简单来说就是没有埋点，前端会采集用户所有的行为跟信息，然后后台再对这些信息进行筛选，由于数据量巨大，对服务器的性能要求很高。
网页布点即布局，网页的三种布局：固定布局，流式布局，弹性布局。
固定布局：以px来设置宽度。
流式布局：以百分比来设置宽度！在宽度较小时，行宽会变得非常窄且难阅读。因此我们要给它添加以px或者em为单位的min－width，从而防止布局变得太窄。
弹性布局：相对于字号来设置宽度，以em为单位设置宽度！由于字号增加时整个布局宽度会加大，因此可能比浏览器窗口宽，导致水平滚动条出现。所以，要给它添加一个max－width为100％。
扩展资料：
埋点分析，是网站分析的一种常用的数据采集方法。数据埋点分为初级、中级、高级三种方式。数据埋点是一种良好的私有化部署数据采集方式。
数据埋点分为初级、中级、高级三种方式，分别为：
初级：在产品、服务转化关键点植入统计代码，据其独立ID确保数据采集不重复（如购买按钮点击率）；
中级：植入多段代码，追踪用户在平台每个界面上的系列行为，事件之间相互独立（如打开商品详情页——选择商品型号——加入购物车——下订单——购买完成）；
高级：联合公司工程、ETL采集分析用户全量行为，建立用户画像，还原用户行为模型，作为产品分析、优化的基础。
参考资料：百度百科-埋点
1.先引入sensor.js文件
2.全局引入使用sensor
3.点击按钮进行埋点
4.在进入页面的时候会自动触发一个'pageView'事件，点击按钮会触发'webClick'事件
参考文档
