《企业埋点体系搭建方法论及实践经验》白皮书报告

1 .数据驱动系列白皮书 企业埋点体系 搭建方法论及实践经验 Principle of Tracking System with Best Practices 

2 .

3 .目录 Contents 一、理解埋点对数据分析的重要性 02 1、神策分析为何能实现灵活、实时、按需定义的自助式分析 02 2、数据分析中常见的问题 02 3、根源性解决方案：把埋点采集当成独立的研发业务来对待 04 二、如何高效、准确地实现埋点设计 06 1、什么是埋点 06 2、埋点设计的思路与方法 08 3、埋点采集方式和触发时机 12 三、如何规范埋点业务 14 1、确认埋点业务的组织架构和关键决策人 14 2、埋点业务职能角色以及工作流程 15 3、埋点采集全流程总览 17 

4 .企业埋点体系搭建方法论及实践经验 写在前面的话 《企业埋点体系搭建方法论及实践经验》白皮书，依托神策数据服务的 1000 余家企业客户的数据采集实战经验，全面展示 神策数据所沉淀的企业数据采集埋点的最佳实践，同时围绕企业在埋点过程中所遇到的困惑与苦恼，详解埋点体系搭建方 法论，从而真正解决企业数据采集困境。 01 

5 .一、理解埋点对数据分析的重要性 1、神策分析为何能实现灵活、实时、按需定义的自助式分析 了解过神策数据的朋友都知道，神策分析是一款通用性非常强、分析能力非常灵活的行为分析产品，在采集和分析两个端 都提供了非常完善的一体化解决方案，即使面临差异巨大的行业、业务、场景、都能通过可视化配置实现绝大多数的分析 需求。那么，神策分析是怎么做到这一点的呢？ 其实，这里面的一个根源因素，是神策分析采用了抽象程度非常高的 Event-User 数据模型，依赖于强大的查询引擎和技术 实力，实现了分析过程直接实时查询明细表的方式，摒弃了根据业务需求按照固定的规则加工出的中间表模式。同时，在 产品平台化的解决思路上，神策数据将不同业务场景的需求，拆解成了分析模型和数据采集两个维度去解决，分析模型将 分析过程和逻辑做了封装，具体能分析的是什么，则由两个层面的因素解决： ● 有什么数据能被分析：采集了哪些数据、哪些字段维度、什么字段格式，本身决定了分析可用的原材料是什么，数据不 全、不对，就算是分析模型再强大也没有用，神策在采集方式的全面性、采集数据的灵活性、数据上报、数据测试支持等 环节上都做了大量的工作，以最大限度保证数据采集的准确性； ● 对数据做什么分析：数据有了以后，希望了解数据在什么时间段、什么统计口径、什么计算规则的表现，这一块由分析 模型来完成，神策目前已有 10 个可灵活配置的分析模型，基本能覆盖绝大多数主流的分析诉求自助、可视化配置同时支 持了丰富的平台化应用的功能，如自定义概览报表、指标四则运算、指标预警等功能，以满足数据分析价值最大化的衍生 应用诉求。 其实，不仅仅是神策这样的分析平台，除了简单看看活跃人数、次数这些整体的指标外，一旦进入到精细化分析的程度， 数据的全面性和准确性上存在的问题就会不断暴露出来，常常出现数据缺失、自相矛盾等各种问题。接下来我们看下在数 据应用中，常见的问题有哪些，主要的原因会有哪些。 2、数据分析中常见的问题 在企业数据应用过程中，业务人员经常会遇到以下问题，接下来分别来看这几类问题常见的原因有哪些，跟数据采集环节 有关的因素有多少。 问题 1：“这个数据跟后台差异很大，数据不准” 导致这种情况的原因会相对复杂一些，以下是常见原因，主要与数据的采集和统计定义较为相关： 02 

6 .企业埋点体系搭建方法论及实践经验 ● 统计口径定义不一样：对比的数据名字和含义类似，但实际统计方式上，存在统计范围和结构上的差异，因此对不上， 比如登录，一个包含指纹验证登录，一个不包含指纹验证登录等； ● 埋点定义不一样：对比的两个数据，埋点采集的是一个事情，但其实触发方式和范围不一样，如提交订单，有些是点击 提交订单按钮时触发上报，有些是获取成功提交订单结果后再触发上报； ● 采集方式带来的误差：前端采集一般会有一部分数据丢失，与后端采集结果会存在一定的出入，一般 5% 以内是正常现 象。 问题 2：“想用的时候，发现没有我想要的数据” 导致这种情况的原因，通常有以下几类： ● 没有提数据采集需求：产品功能上线或者变更时，没有或者没有完整规整数据采集的需求，等产品上线有用的需要了， 才发现想要的数据并没有； ● 埋点不正确、不完整：需求提的粗，提完之后没有跟进需求确认和上线验收，导致技术实际采集的数据并不是自己真正 想要的，或者覆盖不全面，用的时候才发现没有真正想要的数据。 问题 3：“事件太多，不知道什么意思，用起来很麻烦” 导致这种情况的原因，通常有以下几类： ● 埋点设计的方式：埋点梳理的方式按照一个点、一个事件的方式提，没有进行结构化管理和抽象，这种设计方式下，点 击和页面浏览这两类事件就已经足够多了，加上自定义业务流程类事件，系统内常常是几百、几千个事件，业务人员基本 无法用； ● 埋点更新迭代的规则和维护：产品频繁更新迭代，对埋点的系统性规整和保持数据一致性也带来了很大的挑战，新增埋 点越来越多，但缺乏及时的规整和维护，事件会逐渐累计，且同类功能新旧埋点在使用上会出现断裂。 问题 4：“想分析一个问题，但是不知道应该看哪个数据、哪些指标” 这种情况通常有两大类原因： ● 数据定义不清楚：系统类的事件、属性、属性值，没有做对应的中文映射，业务人员不了解埋点方案的情况下，不知道 分别是什么含义，导致无从下手使用； ● 缺乏分析思路：缺乏业务分析需求和数据之间的关联思路，想不清楚分析什么数据、怎么分析数据是能解决业务问题的。 从以上常见的问题和原因来看，只有比较少是数据规整和加工能解决的问题，很大一部分问题都跟埋点本身有关，并且埋 点带来的数据本身可用性的问题，通常是根本性的问题，很难在后期通过其它方式弥补，必须从源头对数据采集和管理进 行规范管理。 03 

7 .3、根源性解决方案：把埋点采集当成独立的研发业务来对待 基于埋点的重要性，神策数据认为，埋点采集本身，应该被当成独立的研发业务来做，而不只是一个产品研发过程中的附 属品，属于可有可无、顺带做一下、优先级最低的任务项。下图是神策数据客户实施交付中的埋点业务流程，与功能类的 产品研发流程是一致的，只是在埋点的业务场景下，各个环节的操作规范和要求不一样而已。 图 1 埋点的业务流程 此外，即使内部有这个业务流程建立起来，但要保证这个业务流程的执行效果，还需要两个非常硬核的操作方法和规范， 一个是正确的埋点设计及规划，一个是制定埋点流程规范体系。接下来我们会重点讲解这两个部分。 图 2 埋点业务的质量管理体系 当然，这里也顺便提一个非常重要的观点，即埋点采集的成本问题。在神策数据对接的客户中，其实有不少客户都反馈过 埋点工作量和效率的问题。说实话，以神策数据服务 1000+ 客户的经验来看，以上两套体系搭建合理的情况下，除了首次 埋点接入成本会高一些外，实际后续的维护迭代的成本并不高。这里给一个数据给大家参考：埋点的任务量和研发的任务 量，比例应该不超过 1/10，一个持续 2 周开发周期的版本，实际上的埋点的投入应该在半天以内。神策数据咨询专家徐美 玲也曾介绍其之前所在的互金公司，这个数字大概是 3 个小时。 04 

8 .企业埋点体系搭建方法论及实践经验 实际上，造成埋点成本高、效率低下的真正原因，就在于没有找到合适的埋点管理和落地方法，埋点的全面性和复用性太低， 导致整个埋点体系持续陷入拆东墙补西墙、每个采集的需求都要单独走完整的采集业务流程，沟通、验证的成本高，对团 队的整体消耗过大。这好比建造房子，夯实的地基会让上层承载的建筑更为稳健，每次只需要在稳固完善的体系下，做一 些装饰补充即可完成。若实际埋点的成本超过了以上的参考值，建议大家对照本文给的解决方案，详细评估下究竟存在哪 些问题，并推动问题的优化和解决，让埋点业务体系回归正轨。 05 

9 .二、如何高效、准确地实现埋点设计 1、什么是埋点 埋点是为了满足快捷、高效、丰富的数据应用而做的用户行为过程及结果的记录。神策将每一个事件分为 Who、When、 What、Where、How 等维度进行记录，即用户在什么时间做了什么样的事情，当时他做这个事情的位置和场景是怎样的等。 先通过两个例子来了解下。 WHO ID WHEN WHAT WHERE HOW 图 3 神策数据埋点 案例 1：如何描述 APP 首页浏览这个行为呢？ WHO ID ID WHEN WHAT HOW IP WHERE 图 4 如何描述 APP 的页面浏览行为 06 

10 .企业埋点体系搭建方法论及实践经验 ● WHO：即参与这个事件的用户是谁。用户进入一个功能页面，我们要知道进来的用户是谁，并且同一个用户以不同身 份状态在不同的端操作时，都能是识别出来就是同一个人，一套合适且完备的 ID-mapping 解决方案，对于提高用户行为 分析的准确性、完整性有非常大的影响，对用户数量的统计、以及漏斗、留存、路径等期望用户行为流相关的分析尤其明显。 同一用户的识别出现断层，会导致以上分析数据不准确或不可用。因此，我们在进行任何数据接入之前，都应当先确定如 何来标识用户。以 APP 的页面浏览为例，在互联网时代，用户都以设备为载体，因此可通过设备 ID 来记录；具体业务场 景下，用户自身也带着业务属性，可通过 user_id、login_id 等类似的业务身份标识来记录，确保单个用户在多设备之间 的行为可以打通。总之，关于“WHO”大家要想清楚要如何准确地标识客户，一个项目的 ID 机制要在项目开始时特别慎 重地进行确认，之后技术人员需要遵循这个规范来埋点，否则后期修改 ID 机制、清洗 ID 错误都是一个非常麻烦的事情。 神策分析关于用户标识的原理及用户标识方案，已经有了非常全面的各行业、各业务类型下的 ID-mapping 解决方案。 ● WHEN：即这个事件发生的时间，神策分析通过自动采集的时间戳属性来记录。 ● WHAT：WHAT 描述了一个事件具体是什么，这里就是神策事件设计模型的一个独特的地方。在这里场景下，按照神策 的事件设计规范，事件是“APP 页面浏览”，而不是“首页的浏览”，通过增加『页面名称』这个属性来区分究竟浏览的是 哪个具体的页面，大家可以思考下，为什么是这种设计思路呢？实际上，一般一个产品会有 N 多个不同的页面，如果将每 个页面都单独定义为一个事件，那么后台的事件将会有几百上千个，业务人员在使用时会非常的麻烦，筛选事件的成本也 会非常大。神策分析在做埋点需求设计时，针对所有类似的触发机制和场景的事件，都会做聚合处理，因此企业的事件量 通常会维持在 30-50 个左右，配以神策的归类机制，极大方便企业进行事件管理，给业务人员带来极强的易用性。 ● HOW：即用户从事这个事件的方式，HOW 关联的是与事件强相关的属性内容。这是企业在事件梳理过程中非常容易出 纰漏的地方。比如在 APP 页面浏览或者 APP 的点击事件上，经常会出现找不到按钮，或者无法定位页面的情况，原因就 是研发的规范性较差，比如对页面标题的定义不规范等。神策针对页面标题做了自定义和规范，主要包括两方面：一是所 有页面本身都有名字，并且与 APP 的页面是同一个名字，如此保证业务同学定位该页面时很容易找到；一是针对 iOS 与安 卓经常出现两个同样的页面命名不一样的情况，神策分析会做维度字典的规整，如此，其可用性能够满足绝大多数的应用 场景。 ● WHERE：IP、国家、省、市区等用户的操作属性，神策分析都是会在基础信息采集上做加工衍生，可以做到自动采集。 端口、应用版本、操作系统、操作系统版本、设备制造商、设备型号、屏幕高度、屏幕宽度这些前端维度与属性，神策分 析的采集也是默认获取的。对于后端自定义采集来说，则需要根据分析需求进行判断和梳理，确认是否需要通过接口透传 等方式获取到对应这些前端属性，否则将会影响后续的多维分析。 07 

11 .例 2：如何描述客户支付订单这件事呢？ WHO ID ID WHEN WHEN HOW IP MAC WHERE 图 5 如何描述客户支付订单 这是一个比较典型的业务类埋点案例。除了前面说到的一些要点外，这里重点介绍下业务类需求设计时的独特性。首先， 订单的流水会有一个唯一标识，类似前面 APP 页面浏览中的『页面名称』，是订单的唯一标识，这是必须要进行采集的， 否则无法与后台数据进行匹配，因为后台的数据通常唯一标识是按照订单的流水号。 针对支付订单事件，强关联的属性也会在 HOW 中，比如支付金额、支付方式（信用卡 or 储蓄卡 or 微信等）、所属银行、 是否成功。“是否成功”是一个非常典型的属性，我们判断用户“是否支付成功”，其触发机制必须等到前端拿到后端服务 器处理结果后，再进行上报。如果我们希望了解的是，“用户是否有意愿支付”，那么当用户点击“支付订单”这个按钮时， 进行前端采集即可，这部分在接下来的内容还会做重点介绍。 这个例子中的“是否成功”属性也再次提醒我们：事件采集显然是要与用户的分析诉求强相关的。在同一个事件中，对其 业务属性的价值定义和分析应用的场景，与技术端去做采集的触发时机是强相关的。这需要对接人有特别清晰的定义，才 能保证埋点的正确性。 2、埋点设计的思路与方法 （1）埋点采集的顶层规则设计 事件设计的顶层规则包括用户识别机制、同类抽象、采集一致、渠道配置四方面，这是保证数据采集的准确性、数据环境 可用性的基础。下面进行详细介绍： 08 

12 .企业埋点体系搭建方法论及实践经验 ID APP H5 图 6 事件设计的顶层规则 用户识别机制：用户识别机制的混乱会导致两个结果：一是数据不准确，比如 UV 数据对不上；二是涉及到漏斗分析环 节都会出现异常。因此企业应该做到：a. 要严格规范 ID 本身的识别机制；b. 跨平台用户识别。 神策分析 1.14 版本支持用户跨平台的识别，比较典型的应用场景是跨渠道推广，可打通用户在 H5 端与 APP 端的操作，无 论是匿名还是登录状态下都能唯一识别；另外，神策分析 1.14 版本支持用户原生 H5 的打通，用户从 APP 到 H5 页面，能 够无缝实现用户的漏斗的自动关联。 同类抽象：同类抽象包括事件抽象和属性复用。前面讲到了事件抽象，即将页面的浏览与点击进行聚合，以保证整个系 统环境的可用性。关于属性复用，属性在很多情况下也是可以复用的，比较典型的场景是“申请验证码”这个功能，用户 可能会在注册时、登录时、修改密码时等多场景下“申请验证码”，那么可以将其抽象为一个事件⸺申请验证码，并在属 性字段增加“场景”，借此从场景来区分用户究竟在什么情况下申请验证码。 采集一致：采集一致包括两点，一是跨平台页面命名一致，二是按钮命名一致。作为业务人员，最直观的感受是平台界 面展示的事件和属性，因为业务人员不了解埋点的规则，当其在平台上搜索想要的数据时，通常是按照页面来进行搜索， 如果命名不规范，很可能会拿一个错误的数据去做后续分析。作为系统的管理员，要规避这样的问题，才能保证企业内部 能够真正用起来。 渠道配置：神策数据有一套渠道配置的方法，实现渠道的监测，这里不做详细介绍。 （2）埋点采集事件及属性设计 在埋点设计环节，整体可以根据需求梳理和转化的路径，分为业务分解、分析指标、事件设计、属性设计的四个阶段。其中， 业务分级和分析指标，是事件设计和属性设计的关键信息输入，通过对业务场景和分析需求的梳理，确认埋点的内容和范围， 而事件和属性设计，则是将这些业务分析诉求，转换成面向开发的需求语言，让开发能看懂需要他在什么场景和规则下采 集哪些数据。接下来，我们以优惠券营销场景为案例，讲述该如何进行埋点设计。 例：优惠券营销场景的事件设计 09 

13 . - / ID 图 7 优惠券营销场景的埋点设计 业务拆解：做事件设计之前，需要先做业务拆解，梳理和确认业务流程、操作路径和各种不同的细分场景。一般的拆解 思路是，根据用户在产品上具象的操作方式和流程，定义用户行为路径。比如在优惠券营销场景中，核心环节是券投放 - 券使用 / 券过期，那么业务拆解则应该是“领取优惠券”“使用优惠券”“优惠券过期” ，领取优惠券又会有主动领取、系统 直接发放两种方式，使用优惠券是在下单时进行抵扣的，优惠券过期是在券即到了失效期还没有使用的情况下触发的。 分析指标：在业务拆解之后，对特定的事件，我们要思考，这些事件会用于哪些指标的分析，具体分析时的核心维护是 哪些。在该场景中，优惠券的领取率、使用率、促 GMV 成交金额、优惠比例、ROI 等都是关心的指标，尤其以活动页面投 放的场景来看，用户通过什么方式进入到领券活动页，优惠券的领取率是多少，不同优惠券的领取率是否有差异，就是领 取这个环节的核心指标。 事件设计：在定义分析指标之后，就需要从对应的指标涉及中抽取事件和事件的关联属性信息了。回到刚刚领取优惠券 的场景，从用户进入领取优惠券的页面、用户点击优惠券领取、使用优惠券成交等行为，这些都需要进行埋点，才能算出 优惠券的领取率、使用率、促 GMV 成交金额等指标。这里面涉及 4 个行为，其中进入优惠券页面本身是一个页面浏览行为 ，且不涉及到额外的一些页面特定属性，那么上报至页面浏览事件即可。领取优惠券的行为，涉及到大量优惠券本身的属 性信息需要记录，因此考虑单独一个事件。而使用优惠券成交，本质上是成交时是否使用优惠券的状态差异，因此不需要 单独一个事件，而是将是否使用优惠券、优惠券抵扣金额、优惠券类型等作为成交的属性。在事件设计的整体框架上，建 议大家按照功能模块 - 业务流程的方式，系统性的梳理业务场景以及对应的分析需求，再对事件设计做一层抽象归类。整 体来说，事件设计可以整体分为三大类，供大家在做具体的事件设计时参考： ● 常规通用采集事件：APP 启动、APP 退出、页面浏览、点击事件等等，这些基本涵盖了用户基本行为操作的主要部分， 神策分析目前对这些通用事件做了全埋点采集，基本上可以满足大多数行为记录的需求； 10 

14 .企业埋点体系搭建方法论及实践经验 ● 重要点击事件：由于全埋点经常会出现点击事件的内容等属性采集不完全，可用性不高，建议对重要的点击事件进行梳 理，根据具体的点击事件的类型以及个性化属性，进行归类采集，常见的点击事件有 Banner 位点击、icon 点击、频道 Tab、功能重要操作点击等事件； ● 业务流程：除了以上常规通用采集和重要点击事件之外，多数业务流程会有些特定的个性化事件，比如注册的输入手机 号、发送验证码、输入验证码，或者具备较多丰富属性的业务流程，比如电商主流程一般都需要记录丰富的商品、活动、 供应商、店铺等字段信息，建议这些都作为额外的自定义事件进行采集，以确保重要事件不遗漏、属性采集都完备。 图 8 事件设计文档规范样例 属性设计：回到刚刚领券的场景，要深入了解各个券的吸引力和营销效果，需要对比分析不同券的数据表现，那么关于 券的维度属性，例如优惠券 ID、优惠券类型、优惠券面值、优惠券适用条件、优惠券有效期等属性就非常关键了。值得强 调的点是，在属性设计时，除了维度全面之外，还必须保证每一个属性都是独立采集，比如优惠券类型和领取方式不合并 字段，以保证后续灵活的下钻分析。以下是埋点采集中常见事件属性的类型举例，主要包含用户属性、事件属性、对象属 性和环境属性四大类，并列举了一些常见的字段供参考，帮助大家完善和核对属性设计的完善性。当然，要对属性设计做 到游刃有余，核心还是要熟悉业务场景和分析诉求，知道哪些维度会影响业务的数据表现，做到心中有数，才会游刃有余。 ID 图 9 事件属性的类型举例 11 

15 .此图是一个简单分类，给大家作参考，避免在操作过程中会有遗漏。 3、埋点采集方式和触发时机 （1）常见埋点采集方式 目前埋点采集业态下，常见的采集方式，包含全埋点、代码埋点 - 前端、代码埋点 - 后端三种，以下是这三种方式在主要 维度的对比，方便大家在做事件设计的时候，能根据需求和场景，科学的选择最合适的埋点方式。 _ _ APP H5 APP H5 5% 5% 图 10 三种埋点方式总结 （2）埋点事件的触发逻辑类型 具体到一份埋点需求文档中的具体事件的采集，除了确定事件和事件属性，还必须要定义清楚事件的触发逻辑，即什么样 的情况下触发数据的采集和上报。从事件上报的触发逻辑上面来讲，可分为前端触发上报、前端获取后端结果后上报、后 端触发上报、后端获取前端属性后上报四个比较类别，如下图所示，下面以京东下单流程中的“购买成功”为例，详细介 绍下埋点事件的触发逻辑类型。 例：以购买成功为例看事件上报的触发逻辑 : / ID 图 11 事件上报触发类型示例 12 

16 .企业埋点体系搭建方法论及实践经验 前端触发就上报：点击“去支付”按钮就触发，这是最常见的前端采集方式，如果业务方是想了解的是“用户是否有 意愿支付”，那么当用户点击“支付订单”这个按钮时或者发出支付请求就触发采集即可。这是时机埋点采集时最常用的一 种方式。 前端获取后端结果后上报：这种方式一般是由于除了记录用户操作外，还需要获取用户操作的结果，比如需要收到 后端结果的返回，以判断用户是否支付成功，以及失败情况下具体的报错原因，那么其触发机制必须等到前端拿到后端服 务器处理结果后，再进行上报。 后端触发就上报：这种方式是指后端处理后直接上报，比如后端处理付款请求出结果时直接后端触发上报。采用这种 方式的主要好处是数据不会出现漏报，但也由于是直接后端上报，基本是拿不到用户的设备终端及软硬件环境属性的，比 如用户在支付时用的是什么设备、网络环境是什么等信息。 后端获取前端属性且触发后上报：这种情况就是为了解决后端埋点的软硬件环境属性问题，让前端在用户点击“去 支付”时，将相应的属性一并传回服务器，服务器发生“支付成功”时，带上相应的前端属性上报数据。当然这种方式理 论上是数据准确度、完备性最高的，但同时这种方式的采集成本会比较高，意味着所有端的前后端接口需要做变更，建议 是只在数据准确性、前端属性获取两个需求都非常强时采用。 通过以上的描述大家也能看得出来，每种触发时机有各自的优劣势，在具体设计触发时机中，决定具体采用哪种方式的因 素，特别值得关注：业务含义、ID 识别机制、前端软硬件环境属性获取、业务处理结果获取、数据准确性要求。神策团队 在给企业做事件设计时也会格外关注这些点；在后续企业自己做事件设计时候，企业也应该从这几个方面给研发同学讲解 清楚，以保证采集的数据更符合场景诉求。 13 

17 .三、如何规范埋点业务 1、确认埋点业务的组织架构和关键决策人 为了保证埋点业务有序、高效的推荐，企业应该在企业内部设置与埋点业务流所匹配的组织架构，以保证埋点采集的质量 和效率，积累高价值的数据资产。以下是神策数据在服务千余家客户后，观察和总结实际数据驱动落地较好的客户，其埋 点业务的组织运作体系。其中，比较关键的是埋点业务统筹人及由其领导的组委会协同机制，以及具体业务线或项目的业 务负责人、技术负责人两个角色。其中，埋点业务统筹人和组委会这个部分非常重要，负责联合各业务线和项目组，制定 顶层业务规范建设及持续迭代，推广及共享埋点采集规范和经验，确保各业务线 / 项目组的数据接入符合规范，数据质量 有保障。简单的模式下，埋点业务的统筹和具体业务线的业务对接人其实是同一个人，埋点业务体系由业务负责人和技术 负责人共同维护和迭代。 / 1 / 2 Web / 3 / 4 图 12 埋点业务的项目架构 在业务架构里面，最重要的是确认关键决策中，具体在一个埋点业务中，核心的角色是埋点业务统筹人和技术对接人，主 要原因是业务统筹人对埋点需求梳理和规范的制定管理起核心作用，保证需求输入和转化环节的质量，而技术对接人则对 具体埋点落地环节的质量和效率提升有着至关重要的影响。以下分别是埋点业务统筹人、技术对接人两个关键角色的关键 信息，供业务组建选人或者招聘时做参考。 14 

18 .企业埋点体系搭建方法论及实践经验 务形态与特 点 · 主动性强， 较好的数据 团队合作意 · / 识强 sense / · · 较强的体系 较强的培训 图 13 关键角色：业务对接人 · · / / · Web · APP 图 14 关键角色：技术对接人 2、埋点业务职能角色以及工作流程 以下是一个完善的埋点业务体系下各个职能角色和工作流程示意图，除了上面说的统筹层外，具体的项目运作层面，就会 涉及到分析需求、埋点需求、需求评审、开发自测、埋点测试、验收上线的这个完整流程了，整体上是与产品研发流程非 常相似的，差别只在于这个环节中，负责具体职能的人员和工作的标准要求不一样。具体可参考以下示意图，蓝色加粗标记， 表示是该环节的主要负责人，黑色细小标记，则表示是该环节的参与人员。 15 

19 . 图 15 埋点业务职能角色以及工作流程 前面已经讲解了埋点需求梳理的方式，接下来我会重点讲解下其它几个环节的要点。 埋点方案评审 埋点方案评审能够避免研发人员没有事先了解、评估和确认过需求，在具体埋点操作时，面对不确定的需求按照“自己的 理解”来盲目埋点，或者面对开发实现成本高（也可能是他没更好的解决方案）的需求直接跳过，导致上线的数据与需求 不一致。在整个机制运作良好的情况下，也可以简化为负责埋点的研发同学、技术对接人与业务同学一起沟通和 review 埋点需求，主要能达到确保研发同学能够明确“需求”究竟是什么，有疑问的地方进行了合理的调整即可。 测试验收 埋点测试验收应该保证埋点数据正确性、顺序性、完整性： 正确性：确认是否有数据上发，并检查上发数据内容与格式是否与需求文档一致； 顺序性：数据上发正确，还需要检查上发顺序是否正确，如 A→B 应该线上发 A 后 B，结果是先发 B 后 A； 完整性：测试时，针对多场景要全部测试，如申请验证码的各个场景都应该上报。 另外，关于埋点测试，强烈建议在提交代码给测试之前，研发必须先做自测，确保所有的采集需求都已经覆盖，事件名和 属性名都正确上报，再进入测试同学测试的环节，以提高测试效率，避免频繁返工。 其次，埋点采集本身的业务有特殊性，针对通用采集事件，一般遵循相同的采集逻辑，可以不必要对所有页面、点击进行 遍历，做抽样测试即可，重点测试自定义埋点上报的准确性及场景完备即可。 16 

20 .企业埋点体系搭建方法论及实践经验 3、埋点采集全流程总览 最后，给大家总结下数据采集的完整流程，期望大家在提高数据采集质量事业中能走的更远，为上层的数据驱动业务的应 用打下坚实的基础。 Review 图 16 埋点采集到应用全流程 未完待续�� 后续【神策数据】公众号，将发布部分行业的事件设计模板，让埋点快速上手， 敬请关注。 17 

21 .

22 .企业埋点体系搭建方法论及实践经验 关于神策数据 神策数据是专业的大数据分析平台服务提供商，致力于帮助客户实现数据驱动。公司围绕用户级大数据分析和管理需求， 推出神策分析、神策用户画像、神策智能运营、神策智能推荐、神策客景等产品。此外，还提供大数据相关咨询和完整解 决方案。神策数据积累了中国银联、中国电信、百度视频、小米、中邮消费金融、海通证券、广发证券、东方证券、中原 银行、百信银行、中青旅、平安寿险、四川航空、翼支付、好未来、VIPKID、东方明珠、华润、有赞、百姓网、货拉拉、 闪送、驴妈妈、Keep、36 氪、拉勾、VUE、春雨医生、聚美优品、边锋游戏、捞月狗、纷享销客、妈妈帮等 1000 余家付 费企业用户的服务和客户成功经验，为客户全面提供指标梳理、数据模型搭建等专业的咨询、实施和技术支持服务。希望 更深入了解神策数据或有数据驱动相关问题，请拨打 4006509827 电话咨询，会有专业的工作人员为您解答。 关于神策数据用户行为洞察研究院 用户行为洞察研究院，旨在提供更具行业深度的洞察、领先的行业最佳实践、创新的技术解决方案等，为广大企业客户、 大数据产业链从业者的发展提供指导。目前已出版多份深度案例、行业白皮书等，涉及人物专访、前沿编译、产品案例、 研究方法等多项内容。未来，将进一步汇聚更多大数据与用户行为分析领域的最佳创新实践和行业深度洞察。 19 

23 .声明 本白皮书由神策数据用户行为洞察研究院推出，版权归神策数据持有。未经神策数据书面许可，任何其他个人或组织均不 得以任何形式将本白皮书的全部或部分内容转载、复制、编辑或发布使用于其他任何场合。报告内的信息“按现状”提供， 不附有任何种类的（无论是明示的还是默示的）保证，包括不附有关于适销性、适用于某种特定用途的任何保证以及非侵 权的任何保证或条件。本白皮书仅为提供通用指南，并不视为针对企业提供的专业建议。 20 

24 . 试用产品 关注神策数据 关注用户行为洞察研究院 联系我们 邮箱：contact@sensorsdata.cn 电话：400 650 9827 网址：www.sensorsdata.cn