在一次痛苦和煎熬的酸爽经历之后，我又来了，带着对知识的敬意和向往，继续~~~
开始正题，本次续上篇《初始数据埋点——需求分析》篇，接下来我们再来聊聊数据埋点四部曲之核心输出篇——埋点方案设计。
埋点方案的目的
埋点是为了满足快捷、高效、丰富的数据应用而做的用户行为过程及结果的记录。埋点方案是也就是埋点的需求分析文档DRD文件，如同产品输出的PRD文档，在业务需求分析的基础上完整的输出埋点方案，明确埋点范围、埋点方式、埋点事件及采集的数据结构和属性特征等详细设计内容，以方便研发、测试等技术人员理解并进行项目开发，同时还可供业务人员查阅参考，理解埋点采集的相关事件及数据指标等情况，方便业务人员尽快熟悉数据结构，提高工作效率。
常见的埋点方式
常见的埋点方式主要分为三种：全埋点、可视化埋点和代码埋点，其中代码埋点又分为前端代码埋点和后端代码埋点。
全埋点
又叫做无埋点、无痕埋点、自动埋点，这种埋点方式想要实现的效果是全自动化埋点，将客户端的用户行为尽可能地全面采集，然后通过界面配置的方式对关键行为进行定义。
优势是操作简单，每次有用户行为分析的需求，不用再走一次完整的埋点流程，只用在产品中嵌入SDK，等于做了一个统一的埋点。劣势是采集到的数据分散，分析需要关联和结构化，只能针对客户端的数据采集，服务端数据是采集不到的。
可视化埋点
可视化埋点也被称为「无码埋点」，它的理念是降低实施埋点的门槛，以此来提升原来的工作流程效率。
优势：
操作简单，即时验证生效。实施埋点时，无需研发人员介入，产品运营可以直接在网站或移动应用的真实界面上操作埋点，而且埋点之后立即可以验证埋点是否正确，并且，埋点部署到所有客户端也是几乎实时生效的。
局限性：
首先，可视化埋点也只是针对点击可见元素的，一些动态页面、不可见的行为是采集不到的；其次，对于点击操作附带的业务属性，比较难实现；第三，为了确保埋点准确性，可视化埋点也逐步整合了更为复杂的高级设置，操作起来也很低效。
代码埋点
代码埋点是最经典埋点方式，实施埋点的研发将埋点代码结合到业务代码中，实现用户行为数据的采集支持任意场景。
代码埋点适合精细化分析的场景，这种埋点方式很低效，需要经历完整的埋点流程，包括业务梳理（产品运营）、埋点设计（产品运营/研发）、实施/测试/上线埋点（研发/测试）。整个过程需要多方协作，且要求产品运营也具备一定的专业水平，如果发生错漏无法快速补救。
代码埋点按照位置的不同，可以分为前端埋点、后端埋点。
前端代码埋点
前端埋点用来记录用户在客户端的操作行为。前端埋点能够收集更全面、精细的用户数据，尤其是不需要请求服务器的行为数据，但缺点在于，前端埋点的上报一般存在 15% 左右的延迟上报和漏报（客户端未联网、数据打包上报、用户删除行为数据等原因）。
后端代码埋点
后端埋点用来记录客户端进行服务器请求的日志，理论上只要客户端向服务器发送过求，服务端埋点能够收集到。相比于前端埋点，能实时采集数据，不存在延时上报，数据很准确；并且，服务端埋点支持与用户身份信息和行为附带属性信息整合；另外，每次上线新的埋点或者更新埋点时，发布后马上生效。
埋点事件触发类型
埋点事件触发类型指的是在埋点时采用什么样的方式触发埋点事件，实现系统自动采集相关数据。每种触发类型都有各自的优劣势，在具体设计触发时机时，选择哪种出发机制特别值得关注以下几点：业务含义、ID识别机制、前端软硬件环境属性获取、业务处理结果获取、数据准确性要求。
前端触发上报
用户在前端进行相应的操作时，即触发采集数据事件。
前端获取后端结果后上报
这种方式－般是由于除了记录用户操作外，连帽要获取用户操作的结果，比如需要收到 后踹结果的返回，以判断用户是否支付成功，以及失败情况下具体的报错原因，那么莫触发机制必须等到前踹拿到后端服务器处理结果后，再造行上报。
后端触发上报
这种方式是指后端处理后直接上报，比如后端处理付款请求出结果时直接后端触发上报。采用这种方式的主要好处是数据不会出现漏报，但也由于是直接后端上报，基本是拿不到用户的设备终端及软硬件环境属性的，比如用户在支付时用的是什么设备、网络环境是什么等信息。
后端获取前端属性后上报
为了解决后端埋点的软硬件环境属性问题，让前端在用户点击 “去 支付” 时，将相应的属性一并传回服务器，服务器发生 “支付成功” 时，带上相应的前端属性上报数据。当然这种方式理论上是数据准确性、完备性最高的，但同时这种方式的采集成本会比较高，会随着所有端的前后端接口做变更，因此，只有在对数据准确性、前端属性获取这两个需求都非常强时采用。
埋点事件与属性设计
事件设计做的不好，往往会给使用者带来麻烦，例如：数据定义不清楚、系统里的事件、属性、属性性值等关键参数没有做对应的中文映射，业务人员就无从下手，看到数据一团乱麻。
事件和属性设计，通常是在业务需求分析之后，确定了具体的数据分析指标之后开展的，将业务分析诉求，转换成面向开发的需求语言，让开发能看懂需要他在什么场景和规则下采集哪些数据。
事件设计
事件设计就是要采集用户行为数据，首先要根据业务分析需求明确采集的目标行为，进一步搞清楚应该在哪些地方埋什么样的点，最终输出的成果就是埋点需求文档。
事件设计可按照4W1H的原则进行事件的设计和定义，即按照“WHO”、“WHEN”、“WHERE”、“WHAT“、”HOW“，即时间、地点、人物、事件、场景，用户在什么时间什么位置在什么样的场景下做什么事情。通过这样的事件分析，对事件进行定义、描述（确定其关键属性）及属性值。
属性设计
属性设计主要是指在事件的产生时需要采集的属性信息，这些属性信息大致可分为以下四种：
①用户属性：主要指的是who触发事件的人的信息，如身份信息、动态属性（如会员等级、角色、活跃度等信息）；
②事件属性：通过什么方式触发的事件，主要是具体的操作行为，如来源、操作方式、操作结果、时长等；
③对象属性：操作对象自身的属性信息，对象的特征、对象的标签。常见的如电商中的操作对象，用户点击商品，那么“商品”即对象，这个商品具有的特征及数据标签信息等。
④环境属性：指的就是触发事件时的硬件设备、软件、地理环境等内容。
针对这些属性特征，这些属性往往会有自己的特征值，我们在做属性设计时需要对每一个属性值进行定义，采集时对相关数据进行采集并结构化存储。
通过对以上方案设计要点的分析之后，那么关键事件来了，方案要怎么写那？在研究了一些精品之后，总结到以下几点，希望可以帮到大家
※ 确定埋点方式：方案中需做好规划，明确事件的埋点方式。
※ 需求内容详情：必须包含以下内容，清晰的标书事件、属性及属性值。
事件：定义事件
属性：描述事件
属性值：具体行为描述，定量定性
~~~以上本次完成第二次作业，这次没有上次那么匆忙，前期看了一些文章，构思了文章的主体结构，按照我的理解开始分类罗列，阐述完了基本思路和概念方法之后，貌似就差我的案例需求文档了，后续补上，也给大家留点念想，看看笔者还有没有余力((*＾-＾*)(*＾-＾*)(*＾-＾*)