1. 什么是试验埋点

在试验设计阶段，当确定 AB 测试目标之后，需要选择合适的指标对试验效果进行衡量。为了实现试验指标的计算，我们需要采集用户和试验相关的行为日志，所采集的行为日志即为试验埋点。试验中涉及的埋点和神策分析系统中用于分析的埋点并没有本质的不同。

2. 什么是试验采集方案（试验埋点文档）

为了正确指引开发人员按需求、按格式进行埋点采集，我们需要一个文档清晰地说明所需的用户行为如何被定义、它需要被采集那些信息、如何结构化。而这份文档就被称为试验采集方案（也称为试验埋点文档）。

3. 试验采集方案如何设计

采集方案设计的核心思路，大体来说分为如下三点：

  • 将用户行为拆解为单个的点击或浏览动作；
  • 将需要分析的目标动作抽象为“事件”，添加事件维度；
  • 根据业务需求，整体完善采集方案设计；

为此我们录制了一个讲解视频：采集方案设计思路 。您浏览后若有疑问，可联系对应的分析师为您提供帮助。

4. 试验采集方案的结构说明

注：若您对埋点采集方案的结构比较熟悉，可以直接略过本节。若想以视频方式详细地了解采集方案设计模板，也可直接观看视频：采集方案模板视频解说

4.1. 事件简介

神策的底层数据模型是 Event + User 的事件模型，通过事件表（ Events ）记录用户行为及用户表（ Users ）描述用户特征，即谁在什么时间、什么地点、以什么方式、干了什么；简单地讲，我们可以认为用户发生的每个行为都是一个【事件】，当用户发生某个行为的时候，把行为抽象成事件，然后将这个事件的发生时间和其他细节信息也上报到神策，就完成了用户行为的记录，而事件发生时记录的其他细节信息（如操作系统、地区、ip等）就是 【事件属性】。

4.2. 采集方案简介

根据试验需求，确认要试验观测的数据指标之后，进一步明确应该在哪些地方埋什么样的点。这个环节的输出物一般被称之为“埋点需求文档（DRD）”，也就是将业务方所需要的需求指标转化为技术人员埋点需要的技术采集文档，以便技术人员埋点无歧义。

以下为采集方案模板图示，在这个文档中需要写清楚以下要素：

  1. 事件编号

    • 为了方便日后的管理和查询事件，每一个事件要有一个唯一编号。

  2. 事件及属性显示名和英文变量名

    • 事件及属性的中文显示名 和英文变量名都需要业务方自定义命名，英文变量名为埋点时研发人员使用，中文显示名可在神策环境中修改。事件及属性的英文变量名必须是合法变量名，即不能以数字开头，且只包含：大小写字母、数字、 下划线。

  3. 属性值类型及示例

  4. 应埋点平台

    • 明确您需要采集的平台来自于哪个技术栈，常见的客户端平台有Android、iOS、Js，常见的服务端平台有Java、C++等。

  5. 触发时机

    • 事件设计中每个事件的属性都是需要确保在该触发时机能够采集到的，触发时机需要写明确，避免产生歧义 。

  6. 预置属性

    • 预置属性是神策SDK自动采集的属性，并不需要研发人员额外编写代码进行采集，如您想了解都有哪些属性，可查阅 预置属性表。

注：如果您是首次接入神策系统，请在神策分析师的指引之下，确定适用于贵平台的用户标识方案；如果您已是神策分析的老用户，建议您在接入神策A/B测试时同步知晓过往的用户标识方案，以便于理解神策A/B测试系统用于分流和呈现报告使用的试验单位是否与您的试验场景一致（详情可查阅：标识用户）

5. 试验埋点设计步骤

试验埋点设计的总体步骤：

① 理解试验需求文档  ➜  ② 确定试验相关行为事件  ➜  ③ 确定是否需进行采集  ➜  ④ 填写试验埋点文档 

首先是需要理解「试验需求文档」，了解试验涉及的「试验相关指标」，进一步定位到「试验相关行为」。由于神策 A/B 测试和神策分析平台是使用同一套数据底层，因此，可能期望采集的用户行为在过往的数据基础建设中已经采集完备了，所以我们需要和已有的埋点进行比对，进一步评估该试验是否还需要进行埋点，最终再对「试验埋点文档」进行填写。

6. 常规试验埋点场景 & 案例

6.1. 常规试验埋点场景

常规的试验场景大体分为两类：「数量类」「概率类」

  • 数量类：由于某个试验改动，会导致用户的行为做的更多（或更少）
  • 概率类：由于某个试验改动，会导致用户在某个环节的转化率更高（或更低）

而所对应的试验指标从统计学属性上可以划分为：「人均值类」「概率类」

  • 对于人均值类指标，仅需采集该试验行为并记录该行为的度量值（如金额、时长等）即可。
  • 对于概率类指标，需要明确「分子指标」和「分母指标」对应的事件，通常要求是严格意义上的漏斗（即分母要比分子大）。

6.2. 常规试验埋点案例

案例一：某电商购物类的APP，针对商品详情页做了页面布局的试验，建立一个「人均商品详情页浏览次数」，使用「人均值」的指标生成方式配置，分子选择商品详情页浏览事件的次数，分母为进组用户数，此时只需要设计「商品详情页浏览」事件进行埋点。

案例二：某阅读小说的APP，针对书籍尾页的“免费阅读”按钮做了文案的试验，建立一个「“免费阅读”按钮点击率」，使用「人均事件比值」的指标生成方式配置，分子选择「“免费阅读”按钮点击」事件 的点击次数/ 「书籍尾页曝光」事件 的点击次数，分母为进组用户数，则需要对分子中的都进行埋点，在用户进入书籍尾页触发试验再上报事件。

6.3. 常见错误的避坑指南

6.3.1. 原则一：要确保所有试验涉及的事件都是上报于试验触发之后

当用户触发试验时，A/B Testing SDK 会上报 $ABTestTrigger 事件以标识用户进入了试验。而试验报告为了保证试验效果的严谨性，只会统计用户触发试验后的行为，因此，我们需要保证所有试验涉及的事件均上报于试验触发之后。

案例：假设试验发生于充值场景，指标是「人均事件比值」类型，分子为「点击充值按钮点击人数」/「充值页面浏览人数」

(滴答) 正确顺序：$ABTestTrigger → 浏览充值页面 → 点击充值按钮 

(出错) 错误顺序：浏览充值页面 → $ABTestTrigger → 点击充值按钮 

错误后果：「浏览充值页面」可能会发生大量缺失，导致转化率计算不准

建议：检查代码执行顺序，确保先执行「参数获取代码」再执行「埋点上报代码」

6.3.2. 原则二：确保所有试验涉及的埋点都使用自定义埋点上报

由于全埋点是由 SDK 自动上报，较难控制其事件上报是发生于试验触发之后，因此我们并不推荐您使用全埋点事件构建试验指标。

6.3.3. 原则三：确保所有试验涉及的转化步骤事件能够清晰记录来源

一般常见的漏斗步骤事件是前后步骤严格一一对应的，用户的转化来源较为单一（或者在埋点上我们都收集到了同一个埋点中），并没有其他的转化路径。（如左图）

但在实践中我们发现，在部分场景下，由于转化入口较多，用户可能并不需要进入目标试验页面，也可以从其他转化路径发生转化（如右图所示）。但由于埋点时并未对不同来源的转化做区分，导致实际统计的转化率为「所有路径转化人数 / 试验所在转化页面浏览人数」，最终导致数据统计不正确。

因此，我们建议如果涉及到多个转化入口或路径时，需要在转化事件中通过事件属性记录转化的来源，否则在指标设置时可能因为不可区分来源而导致指标统计不正确。

7. 其他注意事项

7.1. 多链接试验指标统计问题

多链接试验，广泛应用于活动营销、广告推广等落地页效果对比的试验场景，其关注的指标绝大部分为「人均事件比值」指标，除了确保对应的事件都是上报于试验触发之后，由于其较为特殊的实现原理，因此还需要注意页面浏览事件重复上报的问题。

7.1.1. 技术实现原理

如果一个页面开启了多链接试验，当用户访问该页面的URL时，会请求分流服务获取试验结果（决定最终应跳转到哪个试验组的URL上）。由于各试验组是在当前访问页面（试验URL）基础上进行一次跳转，而跳转后的试验页面可能与当前访问页面是不一致的。所以在分流结果返回前，当前访问页面会被白色遮罩层盖住，避免用户在获取分流结果前后，看到两个不一样的页面，影响用户体验。

  • 为了尽可能减少页面跳转，如果一个用户命中试验，其分流结果为对照组，同时当前访问的URL与试验URL完全一致（即精确匹配）时，用户会停留在本页面，白色遮罩层被去除，恢复原始页面样式。
  • 如果用户命中试验组，或者通过模糊匹配命中对照组，则用户会进行一次URL跳转。若开启了遮罩层，用户只会看到跳转后的URL页面样式。

（备注：白色遮罩层默认关闭，需要在初始化配置参数进行开启）

 

7.1.2. 用户行为路径

因此，我们可以知晓多链接试验的用户可能存在两种行为路径

不发生跳转的用户：浏览上一级页面 → 浏览转化页面（直接访问的URL） → 点击转化行为

会发生跳转的用户：浏览上一级页面 → 浏览转化页面 （直接访问的URL） → 浏览转化页面（跳转后URL） → 点击转化行为

7.1.3. 埋点注意事项

  • 绝大部份情况下，该场景的指标为「转化率」类型，即分子为「转化行为点击人数 」，分母为试验进组用户数，因为该指标根据用户ID做去重，则事件的重复上报并不会影响您的试验结果，因此您无需额外注意。
  • 极少部分情况下，该场景的指标为「人均事件比值」类型，分子为「转化行为点击次数 / 转化页面浏览次数」，分母为试验进组用户数，则部分用户的「浏览充值页面」次数为实际意义上浏览次数的双倍，需要在埋点上限制仅在跳转前的页面进行上报，以避免重复上报问题。