随产品的不断发展、业务类型不断丰富、组织团队不断扩充，通常需要针对目标用户进行大量且广泛的试验，因此在开启实验前需要能够系统规划各团队进行实验的流量，实现更精细化的试验流量管理，精准调配、灵活调整、充分利用平台用户流量的同时还要保证试验结果的科学合理。本文为您介绍使用DataTester开展实验前进行流量规划的思路和注意事项。

分流服务是A/B实验的产品基础，确保每个用户进入不同实验的随机性和稳定性，才能保障实验结果的置信度。因此了解分流原理，对于实验设计、命中排查、解读报告都至关重要。

A/B实验分流服务、vid

开设A/B实验，顾名思义，我们至少需要一个A组和一个B组，那么究竟是什么决定了哪些用户被实验命中，以及哪些用户进入A组/B组呢？就是靠A/B实验分流服务。

• 分流服务会帮助实验者，从总体流量中抽取部分流量，并将抽取的流量随机地分配进A组与B组之中，尽量减少抽样误差。
• 需要注意的一点是，当分流服务分流完成后，被选中进入实验的用户会被赋予一个“身份信息”——ab_version(又称vid)，这个id标记着流量究竟应该进入实验的哪一组中。

分流原理：分流服务的input&output

分流服务的任务是对用户进行随机抽样，并均匀地分配到实验组和对照组中，使其生效不同的功能。
我们先来把分流服务看作是一个“黑盒”。也就是说，抛开分流服务具体包含了什么样的流程和逻辑，先将分流服务看作是一个整体。接着，我们通过输入输出来解释它的工作原理：

• 输入：业务端向分流服务发出请求，告诉分流服务用户是谁
• 输出：分流服务返回业务端这个用户是否命中实验，以及用户被分到了哪个实验组。

以最简单、通俗的话来说：实验中，我们向分流服务发出请求（request），告诉分流服务用户是谁，随后分流服务就会告诉我们，这个用户是否被实验命中，以及用户被分到了哪个组里。

• 分流服务的input
  当我们在向分流服务发出请求（request）的时候，我们要告诉分流服务的信息被称为“请求参数”。当中包含的信息有：用户是谁（用户的分流id【decisionID】）、用户从哪儿来（appkey）、用户符合什么条件（filter）。

  说明

  • decisionID：分流id，需要是唯一标识id，可以使用uuid，did。在实验过程中，究竟使用什么id去标记用户，需要业务方结合实验场景自行裁定。
  • appkey：应用的唯一标识，请求参数中的appkey标记了用户来源于哪个应用。
  • filter：实际上就是过滤条件。在开设实验时，实验者可能会为进入实验的流量增加一些限制条件，规定被实验命中的用户必须符合（或不符合）这些条件，进而达到缩小用户群体、精准找到用户的目的。这种限制条件就是filter。在向分流服务发出请求的时候，用户信息中必须带有和过滤条件相对应的属性信息。比如某实验中，实验者规定，被实验命中的必须是北京用户。那么在发出请求时，如果请求信息中不含有用户的定位信息/定位信息不为北京，该用户就会被过滤掉，无法被实验命中。
  有了这些信息，分流服务就有了“原材料”，并在内部进行加工，对用户进行分流处理。
• 分流服务的output
  如果用户被实验命中，分流服务会输出该用户的身份信息vid（ab_version）/vid list（一个用户可能同时命中不同层的多个实验，因此会输出vid list）和该用户应对应的实验配置。如果用户没有被实验命中，那么分流服务则不会输出信息。