1 埋点定义
埋点也叫事件追踪（Event Tracking）。是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。在数据分析过程中，数据采集是第一步，而埋点是数据采集的重要方式。
用户使用产品时，填写\产生的业务信息（如电商类的交易数据、商品数据）会由业务系统加密储存在数据库里。但行为数据（一个用户在app/H5里面干了什么，看了哪些页面，点了哪些按钮）是不会被这些系统存储，这时候就需要采用埋点：植入一段代码或SDK。
2 埋点分类
埋点方式可以分为代码、可视化、全埋点的方式，也可以分为前端代码埋点和后端代码埋点（前端指客户端，后端指服务端。前端埋点用来记录用户在客户端的操作行为，后端埋点用来记录客户端进行服务器请求的日志）。前后端埋点同时存在的话，相同的数据指标可以相互印证，当一方出现问题，可以通过另一方发现；不同的数据指标可以相互补充。但需要注意的是，毕竟技术原理不一样，存在一定范围的差异是正常的，不应太纠结。
我工作遇到的项目，一方面是需要做精细化深度分析，一方面是介于数据安全（金融数据）考虑，常采用的是代码埋点（还会把常用公共参数的代码封装成一个组件，这样的好处是可以复用多个项目，免去重复开发）。但是这种方式往往周期较长，过程复杂繁琐，需要经历梳理业务、设计埋点、测试/上线流程，需要业务产品开发测试多人协作。
2.1 代码埋点（又叫手动埋点）
开发通过植入N行代码，在界面初始化时，初始化埋点SDK，用户触发事件或页面时，调用相应SDK，通过接口发送数据。因为是手动编码产生的，所以设计自由度高，功能强大，可自定义事件和属性，能精准监控对象，采集丰富数据。
1）前端埋点
应用场景：需自定义埋点事件属性才能满足记录用户在客户端的操作行为\分析业务环节
优点：·需采集全面完整的事件属性数据
·有些不需要请求服务器行为，只能使用前端埋点，如：页面停留时长
缺点：·需前端开发，人力成本高
·会产生延迟上报和10%左右的漏报丢失（如客户端未联网、数据打包上报、用户删除行为数据等原因造成）
·若客户端是APP，需要用户主动更新版本，新版本埋点才会生效。
2）后端埋点
应用场景： ·采集非点击、不可视行为
·需整合用户属性信息和行为的数据
·前后端都能采集到的信息，优先选后端方式
比如：抢群微信红包（红包人数小于群人数，即非人人可得）等等需要请求服务器，否则用前端埋点可能会产生用户端显示获得红包，但实际红包已经被发完了，就会被用户投诉。
优点： ·支持用户身份信息和行为的整合
·实时采集、无延时上报、数据准确
·发版即生效，不需要前端和用户更新
缺点： ·需服务端开发，人力成本高
·不能直接采集发生在前端，不请求服务器的行为数据，获取前端属性需接口开发
2.2 全埋点（又叫无埋点，属于前端埋点）
复用同一套全面的SDK埋点方案，先采集所有控件的数据，有选择的配置需要分析的控件。（可视化埋点是先选择要采集数据的控件）
应用场景： ·分析或统计需求简单，不需要对埋点事件进行自定义传参
·需频繁\紧急上线的H5运营活动
优点：·省去设计开发埋点的工期和人力，只要部署SDK，即可采集数据
·可获得全量数据进行分析，便捷的通过各种热力图等快速分析
缺点： ·传输数据大，消耗数据存储资源
·不能自定义交互事件
·一般借助第三方公司提供的埋点SDK，有数据安全隐患，且不便于改善丢包问题
2.3 可视化埋点
可视化埋点是把核心代码和配置、资源分开，通过部署在产品上的基础代码对产品的所有交互元素进行解析，并在可视化页面进行设定，界面启动时后端（服务端）更新配置和资源。用户产生操作行为后，根据配置上报相关内容。
应用场景： ·分析或统计需求简单，不需要对埋点事件进行自定义传参
·需频繁\紧急上线的H5运营活动
优点：·节省开发、更新埋点的工期和人力
·降低门槛，业务、运营可通过可视化界面配置和统计埋点
·不受版本迭代影响
缺点： ·覆盖功能有限，
·不能自定义交互事件
·不能支持内容瀑布流式交互
·一般借助第三方公司提供的埋点SDK，有数据安全隐患，且不便于改善丢包问题
3 埋点步骤：
数据分析流程：
以下以某电商页面为例
3.1 梳理业务
了解业务需求，明确跳转逻辑是埋点的前提。一般通过产品需求文档\原型图+APP/H5实测，对触发场景进行枚举.
1）页面功能
列举页面功能，有助于思考页面的功能，和期望用户达成的行为。
2）核心业务流程
找到核心业务流程，便于进一步明确数据观测需求。
如：此页面期望通过展示“用户近期浏览的商品”+“热门商品”结合“低价”“正品保证”激起用户购买欲，进而点击商品详情页，完成下单支付购买。
由此梳理出几个转化关键
3.2 确定指标
先梳理指标需求，不是每个页面、每个按钮都要埋点，这会给开发增加很多负担，甚至影响产品体验。且有的需求庞大复杂，应根据项目上线紧急情况，迭代完成。
此外，很多指标，可以有多种计算口径，究竟用哪一种合适呢？如果能抓住实际业务的重心，不同角色关注的重心，就可以有理有据的根据实际情况进行口径的制定和设计。否则，最后拍脑袋定下的，很可能会传递错误的效果信息。
举个例子，电商订单状态包括：未付款、取消、拒收、待发货、配送中、确认收货等，那么实际销售总金额的条件应该计算包含哪些订单状态下的销售金额呢？实际上如果监测对象是运营，则订单拒收及之后的状态与运营侧的关系不大，所以给运营制定的实际销售总金额计算口径，应该是包含拒收及之后状态的订单实际金额之和。而如果涉及到拉新推荐返现，计算佣金等，那么实际销售总金额肯定得是订单状态为已确认收货，甚至要叠加已过退货期的条件才能计算，否则不仅会影响分析的准确性，还可能会让羊毛党钻空子（比如反复下单支付后不断退款以白嫖佣金）
3.3 埋线设计
1）埋点拆解
为了使埋点文档更加高效，降低迭代成本，减少沟通成本。一般埋点设计会按照“Key-Value”键值对的组合形式来唯一描述一个埋点：
1）先划分最小原子维度 Key：事件、页面、模块等
2）再确定每个Key 的 Value ，一个Key可以对应多个Value，
3）但Key-Value 唯一确定一个埋点
事件：比如 点击／页面曝光 等
点击：用户每点击一下按钮就会记为一次点击事件。
曝光：当用户成功进入某页面时记录一次，刷新页面也会增加一条记录（home键切后台再进入页面，不记）。
页面：ABCD各种页面，比如首页、订单页、购物车页面等
模块：示实际产品复杂程度的需要添加，页面上各种模块分区，比如 广告位，搜索框等。
2）埋线文档
重点：事件描述模型：5w2h——(who,when,where,how,what)
记录了谁在某个时间点、某个地方、用某种方式、做了某一件事情(某个行为)
Who：唯一标识。可以是 用户ID、设备ID、平台id（微信...）、自己产品后台生成的账户id(user_id)...
When：事件发生的时间，时间戳，至少精确到秒
Where：位置、环境、IP（解析国家、省、市）、注册位置
How：事件发生时的状态。进入渠道、跳转的上级页面、网络(wifi\4g\3g)、屏幕分辨率等，浏览器、SDK版本、操作系统，
What：用户行为描述。操作（停留、滑动） 了什么首页、模块。如搜索(搜索关键字、搜索类型)、购买(商品名称、商品类型、购买数量、购买金额、 付款方式)等。
埋点规范：
埋点工作需要多岗位协同完成。为了能高效准确的传达埋点需求，需要在团队内部制定且共识形成一套统一的规范。同时，由于埋点工作往往需要分阶段多次迭代，所以要包含上文中的重点信息5w2h事件描述模型，还应有一些其他信息，包括不限于以下内容，才能便于维护好埋点文档，便于下次迭代顺利衔接。
1.埋点编号：数字
2.埋点需求名称(中)：能够唯一标识、准确描述事件。如 搜索页搜索按钮点击。
3.事件 (中/英) —页面 (中/英) —模块 (中/英) ：即上文提到的key value 。能够准确定义参数.
4. 公共参数 共有的常规事件（设备ID、sessionid会话、页面、模块、按钮、事件）会设置为公共参数， 封装成一个SDK，复用和自动采集
5. 自定义参数。 满足不同业务的特殊需求，制定的扩展字段。 备注合理参数的范围，例举参数的值。 注意通用性。
6. 备注：增删改查时间(版本)，埋点文档变更版本的时间点，便于追溯或回滚版本。
3.4日志上报
用户每一个操作行为，会上报一组带有数据的字段，包含了将要发送的完整的数据信息，形成对应日志。日志一般包含以下字段，简单举例，根据公司业务自行增删：
{
"batch_id":"批次ID",
"analyse_time":"报文解析时间",
"remote_host":"设备公网IP",
"device_id":" 设备ID",
" user_id": "用户ID ",
" app_key": " 唯一key ",
"version_code":"业务埋点版本"
"subversion_code":"业务埋点子版本"
"init_time":"SDK初始化时间"
"sdk_type":"SDK初始化时间"
......
}
