数据应用一般会有采集、加工、存储、计算及可视化这几个环节。其中采集作为源头，在确保全面、准确、及时的前提下，最终加工出来的指标结果才是有价值的。而埋点作为一种重要的采集手段，可以将用户行为信息转化为数据资产，为产品分析、业务决策、广告推荐等提供可靠的流量数据支持。
一份埋点规范文档既能规范工作流程提高效率，又能明确需求规范减少沟通成本避免理解出现偏差。但是如果一开始的埋点规范文档由经验不足的同事整理出来的，那后续的问题将会在工作不断的暴漏出来，导致数据采集层可能存在问题。
数据埋点并没有想象中的那么简单。
什么是埋点？
埋点是互联网数据采集工作中的一个俗称，正式应该叫事件跟踪，英文为 Event Tracking，它主要是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。
埋点数据主要是用来收集用户的行为数据的，网站收集用的的行为数据可以分析网站的运行效果、用户行为特点、业务的目标达成。同时，还可以通过这些数据，实现为用户提供个性化的推荐功能，以达到最大的业务转化率。
埋点也是为了满足快捷、高效、丰富的数据应用而做的用户行为过程及结果记录。数据埋点是一种常用的数据采集的方法。埋点是数据的来源，采集的数据可以分析网站/APP的使用情况，用户行为习惯等，是建立用户画像、用户行为路径等数据产品的基础。
比如订单成交率：我们进入到商品详情页操作，同时按要求进行数据采集和上报，告诉服务器我们主动干了什么或者被动出发了什么？然后进入订单结算页面，进行其他操作，以此类推。
最后后台可以统计出各个点击事件和预置事件，根据得到的数据还原出用户的各种行为，最终将这些数据可视化出来，进行深入分析。
埋点的目的包括：
- 在产品流程关键部位植相关统计代码，用来追踪每次用户的行为，统计关键流程的使用程度。
- 在产品中植入多段代码追踪用户连续行为，建立用户模型来具体化用户在使用产品中的操作行为。
- 与研发及数据分析师团队合作，通过数据埋点还原出用户画像及用户行为，建立数据分析后台，通过数据分析、优化产品。
采集方式
无痕埋点（或全埋点）
利用浏览器或APP自带的监听方式，对用户的浏览页面、点击等行为进行收集，可以收集到的信息主要有：
- 页面的url、APP的包名等
- 点击元素的xpath路径、title或约定的dom元素
无痕埋点的优势有：
- 前端接入成本低，不需要额外开发
- 用户动作收集完整，不会漏失
但同时也会存在以下问题：
- 有用、没用的数据都会收集，数据上传消耗流量大
- 数据维度单一（仅点击、加载、刷新），无法采集到特殊的行为动作、业务参数
- 影响用户使用体验：用户使用过程中容易出现卡顿，严重影响用户体验
- 采集到的信息需要进行二次标注，才可以被用户识别
- 当按钮的位置不固定、名称存在重复或页面重构时，无法做到准确的标识
代码埋点
代码埋点是指依赖前端同学，自定义监听和收集处理。代码埋点的优势有：
- 事件标识明确
- 业务参数丰富
- 事件的触发方式可以灵活自定义
- 分析更方便、精确
随之而来的是以下问题：
- 前端代码的开发、管理成本
- 只能收集到事件上线之后的数据
在业务需求复杂，无痕埋点收集到的信息无法支持分析时，就需要进行代码埋点。
服务端埋点
可支持其他业务数据采集和整合，如CRM等用户数据，通过接口调用，将数据结构化，由于直接从服务器端采集，数据准确性更高，适用于自身具备采集能力的客户，或可与客户端采集相结合采集。
最理想的埋点方式？
任何单一的埋点方式都存在优点与缺点，企图通过简单粗暴的几行代码/一次部署、甚至牺牲用户体验的埋点方式，都不是企业所期望的。要满足精细化、精准化的数据分析需求，可根据实际需要的分析场景，选择一种或多种组合的采集方式，毕竟采集全量数据不是目的，实现有效的数据分析，从数据中找到关键决策信息实现增长才是重中之重。
因此，数据采集只是数据分析的第一步，数据分析的目的是洞察用户行为，挖掘用户价值，进而促进业务增长，故最理想的埋点方案是根据不同的业务和场景以及行业特性和自身实际需求，将埋点通过优劣互补方式进行组合，比如：
- 代码埋点+全埋点：在需要对落地页进行整体点击分析时，细节位置逐一埋点的工作量相对较大，且在频繁优化调整落地页时，更新埋点的工作量更加不容小觑，但复杂的页面存在着全埋点不能采集的死角，因此，可将代码埋点作为辅助，将用户核心行为进行采集，从而实现精准的可交叉的用户行为分析；
- 代码埋点+服务端埋点：以电商平台为例，用户在支付环节，由于中途会跳转到第三方支付平台，是否支付成功需要通过服务器中的交易数据来验证，此时可通过代码埋点和服务端埋点相结合的方式，提升数据的准确性；
埋点sdk
为简化前端同学的埋点开发工作，使其只需要关注于业务本身，并对埋点的一些约定进行必要的约束，需要开发了多个端（js/小程序/android/ios/java）的埋点sdk。
sdk默认支持以下功能：
- 访客标识管理
- 会话管理
- 环境参数默认收集
- 参数的生命周期管理
- 默认事件的收集
- 跨端的sdk通信（如app嵌套h5页面）
- 内部业务的特殊处理逻辑
- 日志的格式化、合并、生命周期管理
- 日志的上报机制
前端同学通过sdk提供的接口进行开发，只需要关注：
- SDK的初始化配置
- 事件怎么标识
- 事件需要哪些参数
- 事件如何触发
数据收集上来后，原始日志还处于非常精简的状态，需要进一步加工成日志中间层，主要有以下几个环节：
- 批量上报的日志拆分
- 日志模型的格式化处理
- 信息的二次加工和维度扩展如IP、http_user_agent的解析等
- 异常流量的清洗
- 会话信息的补充如落地页、二跳页、停留时长的计算
- 按业务拆分日志流和日志表
日志中间层
数据收集上来后，原始日志还处于非常精简的状态，需要进一步加工成日志中间层，主要有以下几个环节：
- 批量上报的日志拆分
- 日志模型的格式化处理
- 信息的二次加工和维度扩展如IP、USER_AGENT的解析等
- 异常流量的清洗
- 会话信息的补充如落地页、二跳页、停留时长的计算
- 按业务拆分日志流和日志表
如何正确的进行埋点？
位置追踪规范
在精细化运营及算法推荐等应用场景下，需要非常精确掌握行为发生的位置场所。如果每个业务都自定义一套标识方式，那么每次分析工作都需要重新开发，无法复用逻辑，这将极大的浪费开发资源，因此需要制定出统一的位置规范。
将位置分成了四个粒度：
- 业务
- 页面域（包括页面类型和页面id）
- 组件域（如图中红色部分，包括组件类型和组件序号）
- 展位域（如图中绿色部分，包括展位标识和展位序号）
业务+页面域+组件域+展位域+页面随机码，可以唯一确定一个访问的位置。基于位置分解出来的维度组合，可以很方便的分析出各个粒度的访问、曝光、点击数据。
事件模型
首次需要思考的是，如何描述和记录用户的一次行为。这里我们使用的事件模型，即：
- who 访客标识、设备指纹、登录ID
- when 事件发生时间、上报时间
- where 设备环境、网络环境、业务环境等
- what 事件标识、事件参数
我们设计了可以承载以上信息的日志模型，并保持必要的可扩展性，将数据映射到schema的各个字段中，一次行为便完整的记录下来。
事件的上报时机由事件的定义来具体决定。主要有以下三大类：
- 展示：展示时候上报，需要明确重复展示是否重复上报，像那种自动轮播的banner就不需要重复展示重复上报，因为这样的重复上报是没什么意义的，而用户反复滑动导致的重复展示可以重复上报；
- 点击：点击时上报，这个是最简单的上报时机，一般没什么争议；
- 接口：这个涉及到与后端的接口交互，上报时机则为客户端拿到后端返回的具体结果时上报。
埋点文档要求
首先梳理出产品的功能结构及业务流程，将核心流程梳理出来，确定关键指标，并细化各流程的影响因素，同时想清楚上下游的接入口是什么，避免埋点的重复，提高埋点复用性。其次：规划出数据分析的框架，基于产品功能的路径转化和重要指标链路，设计出可供记录的埋点框架，使埋点契合分析框架的逻辑，避免冗余。同时，埋点是用来记录用户的行为，埋点文档需要提供给前、后端研发进行埋点开发，所以文档中的信息尽量描述清楚，并且与开发拉会议，要求对埋点的理解对齐一致。
文档信息具体包括：
- 埋点文档中必须写出埋点上报时机，同时描述准确；
- 参数里记录的是针对埋点行为，所包含的信息以json形式，记录在字段中，分析时需要使用具体的信息，可通过函数解析出来（get_json_object）。示例：
埋点完成，安装包提交之后，数据同学会配合QA同学，一起做埋点验收，需注意以下几个方面：
- 转化漏斗是否正常：例如广告链路中，从广告展现-曝光-点击-关闭，这条链路的pv是呈漏斗逐渐减少，如果不是，那么需要定位埋点问题；
- 上报顺序是否正常：新手引导中，id顺序为1-2-3-4，可追踪单一用户id，按时间戳查看上报顺序是否符合规范；
- 埋点上报是否对应规范中的触发场景。
实际业务中的埋点验收，是一个复杂繁琐的工作，每个项目对应不同的规范，建议建立一个《埋点验收清单list》，记录需要验收的部分，指派到责任人，逐一签名查验，防止错漏。
埋点管理平台（以下内容来自有赞分享）
有赞的早期阶段，所有业务的埋点方案都是记录在wiki中。随着业务线和项目的快速增加，wiki记录的弊端也逐渐暴露出来：
- 登记格式无法统一，关键信息容易缺失
- 事件查找不便，分析同学不知道已有哪些事件
- 迭代更新事件无法合并，同时存在多份信息
- 开发进度、测试进度无法监控
- 埋点质量问题无法快速对接
基于开发中碰到的各类问题，愈发的让我们意识到平台建设的必要性，主要涉及以下几点能力：
- 埋点元数据的管理及开放能力
- 埋点流程的管理能力
当有了埋点元数据，可以延伸出来更多的操作空间，如：
- 埋点的自动测试
- 埋点的自助分析
- 埋点的开发提示
- 埋点的质量监控
埋点元数据管理
- 业务：由业务类型（微商城、零售等）和SDK类型（js/小程序/android/ios/java）唯一确定。页面、组件、展位、事件等属于且仅属于一个业务。
- 页面：具有相同页面结构的一类网页或者移动端页面。
- 组件：页面内的区块，也包括跨页面的可复用区块。
- 展位：组件内最细粒度的坑位，有三种位置标识，即递增（顺序排列）、固定（特定的位置）和正则标识（复杂布局）。
- 事件：埋点基本单元，对应用户的一个动作，比如进入页面、点击按钮、商品曝光等，每个事件还可以定义独有的参数。按其归属，可以分为全局事件、页面事件和组件事件。
埋点测试
上线前的埋点测试直接关系到数据质量，早期测试是使用抓包工具，每个事件肉眼判断，不仅效率低下，而且容易判断错误或遗漏。因此当元数据收集完成之后，为了解决以上问题，我们设计了埋点在线测试功能。
- 测试用户输入项目和用户标识，在线测试模块会将用户标识存储到redis中
- 校验任务消费实时日志，并定时同步埋点元数据和用户标识集合，以此校验日志并收集到埋点平台中
- 将收集到的实时日志返回给用户
- 项目已测试的事件进行汇总，生成概览数据
日志检测项：
- 日志格式是否标准
- 通用业务参数是否收集完整
- 业务、页面、组件、事件是否登记
- 事件参数是否缺失，格式是否符合要求
检测等级分为Warning/Error级别，会有相应的错误信息。
用户标识
为了方便测试同学快速找到自己的用户标识，平台提供了pc链接、手机扫码、手机号等快捷查找方式。
参考链接：
