下载掌阅APP，畅读海量书库
立即打开
小白： 老姜，听了您的讲述，我大概了解了数据埋点的意义，以及其中常用的方式。但如果在工作中遇到，埋点的完整流程大概是什么样呢？以及我需要在其中担任什么样的角色？目前还是无法将整条链路串联起来。
老姜： 这个问题问得很好，我来帮你解答一下。首先，埋点有一套较为成熟的流程方式，其中主要涵盖三大方向，即埋点开发前、埋点开发中、埋点开发后，从新业务数据需求的提出到埋点产品的下线，贯穿埋点完整的生命周期，如图2-5所示；其次，数据埋点需要多方人员配合完成，其中涉及产品、数据、研发、测试等岗位，因此，就需要一套标准化的埋点流程，以保障埋点的准确性及效率。
小白： 那作为数据分析师，我们需要负责其中的哪些模块呢？
老姜： 理论上，这里的数据岗位，一般指数据产品岗，但由于一些公司部门未配置数据产品人员，因此，往往需要数据分析师顶替来完成。其中，数据岗位人员主要在埋点设计、埋点评审、埋点监控、埋点应用四个环节中负责部分工作内容，在图2-5中以红色进行标注。下面我们来一起看下每个环节涉及的工作内容，以及数据岗位人员需要承担的工作职责。
图2-5 埋点完整的生命周期
埋点前流程，主要指埋点开发前涉及的埋点的相关工作内容，主要涵盖需求梳理、埋点设计、埋点评审，下面我们来逐一看下。
数据来源于埋点，而埋点来源于业务需求，因此需求梳理作为业务与研发的桥梁，重要性不言而喻。需求梳理，主要需要将页面中需记录的内容标注出来，帮助下游合作方更好地理解需要记录用户的哪些行为。由于产品的新增、迭代主要由产品经理负责推动，因此，该环节的负责方也就顺理成章地落在了产品人员身上。
需求梳理，根据思路流程，可划分为四个步骤。
步骤一：输出原型图。 产品经理负责新页面及改版页面的思路设计，通过Axure等软件，将页面样式绘制成原型图。原型图涵盖产品上线之后所有的前端样式及功能，作为页面开发及埋点的模板。
步骤二：梳理关注指标。 产品经理根据原型图，梳理产品上线之后需关注的一系列指标，用以度量业务的健康度，指引后续产品迭代。
步骤三：反推埋点内容。 通过所需指标，反推页面需要埋下哪些点位，记录用户哪些关键行为，用于输出所需数据，达到分析目的。
步骤四：输出需求文档。 将以上梳理的待埋点内容及埋点时机落地到指定的需求文档中，作为与下游埋点处理方的书面凭证。需求文档重点涵盖埋点页面示意图、埋点位置图、埋点命名、上报内容、上报时机等方面，如图2-6所示。
图2-6 需求文档
输出需求文档的核心原则：能够清晰地告知数据、研发、测试人员，用户在哪些页面位置可以触发哪些事件行为，并且需夹带哪些参数信息。
除此之外，在需求梳理环节还有几点重要的注意事项。
注意1：梳理要全面。 需求梳理内容的多少，直接影响埋点内容的多少，如果在埋点上线之后发现某些指标由于没有埋点，而捞不回对应数据，那么即便后续将埋点加上也无法记录到过往的数据信息。因此，在页面上线前，需完整梳理内容，避免遗漏。
注意2：内容要细致。 埋点的上报内容往往需要涵盖众多业务参数，而这些参数是下游研发人员难以把关的，因此在需求梳理中要写清楚需要上报哪些参数。后续发现遗忘后再增加，同样无法回溯过往数据。
注意3：文档要规范。 需求文档作为与下游负责方的唯一书面接口，需要与数据、研发人员共同制订，并遵循梳理规范。谨防由于文档不规范，导致双方理解出现偏差，影响埋点准确性。
需求梳理环节侧重于业务层，根据业务思维输出需记录的用户行为信息。而埋点设计环节侧重于数据层，作为业务层的下游，将产品页面以一定的规范，设计为可用于下游开发的埋点文档。该文档具有重要意义，既可作为研发岗位开发的依据，又可作为下游应用层取数的参考。
该环节需要产品及数据岗位人员配合完成，产品人员负责同步需求文档中记录的内容，数据人员负责埋点规范的制订以及埋点文档的撰写，附上一张页面埋点设计图以供参考，如图2-7所示。具体设计思路，会在下面的章节进行详细讲解。
图2-7 页面埋点设计图
当本次埋点设计完成，且输出埋点文档后，便进入埋点评审环节。埋点评审的目的是将埋点内容同研发人员确认，评判埋点内容的规范性及可行性。如评审通过，则会进入埋点开发环节；如评审不通过，则流程回到埋点设计，由数据及产品人员共同修改埋点方案。
该环节主要由产品、数据、研发三方人员共同参与完成。如果页面埋点仅涉及客户端的内容，则主要由前端研发人员负责；如果涉及服务端的内容，即需要后端回传内容至前端，则仍需后端研发人员参与。
埋点中流程，主要指埋点开发中的相关工作内容，主要涵盖埋点开发、埋点测试、埋点上线。
埋点评审通过后，便进入正式的埋点开发环节，由研发人员根据埋点文档内容，逐一开发埋点。根据埋点的手段，又可划分为代码埋点、可视化埋点、全埋点。在开发环节，有几点注意事项需要关注。
注意1：编码格式。 当埋点内容为中文时，为避免在客户端与服务端传输过程中出现解析错误，往往需要在客户端将其格式进行转化。
注意2：参数类型。 埋点参数中，相同内容的参数，其类型要保持一致，以防造成数据混乱。例如，A参数类型为String，后续若无特殊原因，不做更改。
注意3：网络环境。 当用户网络较差时，客户端回传埋点失败，需要将数据存储于终端本地数据中，待网络条件满足后一并回传，以防埋点数据的遗漏。
在完成埋点开发后，便进入埋点测试环节，此环节目的是保障埋点的准确性，减少漏报、错报的情况发生。该环节主要由测试人员负责，研发人员辅助完成整体流程。
埋点测试的流程一般可划分为以下几个环节，如图2-8所示。
图2-8 埋点测试的流程
环节一：测试内容及标准对齐。 测试与研发岗位人员针对埋点测试流程及通过标准达成共识，制订标准化规范。同时，在单次测试需求前，需同步测试内容及细节，以防出现遗漏。
环节二：开始埋点测试。 大多数公司会利用埋点管理平台进行埋点的录入及测试，通过模拟用户操作，验证操作事件信息是否通过埋点记录下来。如测试通过，则将测试内容录入报告，同时存储备份，以便日后查看；如测试不通过，则需要将Bug统一记录在平台中，反馈给研发人员，让其修复问题，待修复完成后，重新进入测试。
环节三：周知业务方。 当测试完成，并无任何问题后，便可将测试结果通知产品及数据人员，至此，完成埋点测试的整体流程。
在日常工作实操中，埋点测试方式主要有以下两种。
第一种：平台测试法。 利用公司自有埋点管理平台或第三方平台，检验测试方在软件中模拟操作的数据是否准确存在。该种方式可以比较直观地反映埋点是否正确，并且可以自动生成测试报告，是目前埋点测试最常用的方式。
第二种：日志验证法。 通过查看底层的埋点日志，从日志中逐一捞回埋点测试的数据。该种方式较为传统，比较耗时，可作为第一种方式的补充。
埋点完成测试，并验收无误后，便可进入埋点上线环节。埋点上线往往需要跟随发布的节奏来进行，因此，无法立即生效。该环节主要涉及研发人员的工作内容。
埋点后流程，指埋点开发后的相关工作内容，主要涵盖埋点监控、埋点应用、埋点下线。
埋点上线后，此次埋点需求就基本完成了，但为了预防未来的某些改动对埋点数据产生影响，同时减少人力的损耗，往往需要在平台侧配置埋点数据的日常监控。该环节主要由研发人员负责，产品及数据人员配合完成。
根据监控内容，埋点监控主要划分为以下两个方面。
方面一：应用数据监控。 针对用户应用侧数据监控，例如PV、UV、CTR、停留时长等。将指标配置到平台，时时预警。
方面二：性能数据监控。 针对前端页面性能的监控，关注用户的页面加载时长、成功失败率、白屏率等情况。性能是直接影响用户感知的指标，而随着页面埋点的增加，性能往往会出现一定程度的下滑。因此，埋点上线后，性能监控的作用是不容忽视的。
埋点的最终目的是辅助下游的数据应用、数据分析、数据挖掘等，通过科学的分析方法及算法，将数据转变成对业务有价值的信息，推动产品的迭代。该环节主要涉及数据分析师及算法工程师的工作，此部分内容，会在下面章节中逐一展开。
埋点同产品一样，是存在生命周期的，当产品的某些功能需要下线时，必然会有一些埋点跟随下线，至此，该埋点完成了一生的使命。该环节主要由研发人员负责。在埋点下线之前，需要周知各业务方。
以上三个大环节构成了埋点的全部流程，其中，数据岗位人员主要涉及埋点设计、埋点评审、埋点监控、埋点应用四部分内容。其中，埋点设计对于数据岗位人员是比较重要的，直接影响下游的数据应用，而埋点设计涵盖通用内容设计、新页面设计两个方面，下面两节会为大家详细介绍。相信通过这两节的学习，你可以自己上手设计规范化的数据埋点方案。