A/B测试介绍及FAQ

A/B测试介绍及FAQ



1. 免费A/B测试FAQ

1.1. 集成

1.1.1. 各端集成文档

H5：
http://ab.testin.cn/docs/websdk.html
iOS：
http://ab.testin.cn/docs/iossdk_4.1.2.html
Android：
http://ab.testin.cn/docs/androidsdk.html
小程序：
http://ab.testin.cn/docs/weappsdk.html
后端（服务器端）：
http://ab.testin.cn/docs/javaSdk.html

1.1.2. A/B测试在系统层面要做哪些改造？Testin云测平台能做什么工作?

以Web/H5、小程序或App为例，需要您在相关页面集成我们的SDK、埋设相关变量和代码，然后利用我们的平台进行分流和数据统计分析。

1.1.3. A/B测试的分流如何实现?

通过让用户拉取不同配置实现。用户访问页面后，通过SDK向服务器发送请求，服务器分好版本并将配置信息发回页面，页面再展示版本。

这里面有几个关键点:
  •  第一，需要在页面（后端实验则是服务器）集成SDK，这样页面才能处理系统的分流指令。
  •  第二，需要预先设置好版本信息，请在系统后台设置，并在代码中集成。
  •  第三，分配流量，开启实验。

1.1.4. 是否可以采集移动设备识别码（iMEI）来做分流?

相关问题：你们可以采集到iMEI吗?

针对这个疑惑，首先需要搞清楚，为什么会问到获取设备识别码？

您很有可能是这么认知的：系统的分流，是通过iMei来区别不同样本。简单来说，就是认为iMei是ID。但实际上并不是这样。

我们不一定能得到移动设备识别码。要想拿到用户设备识别码，需要用户允许读取权限，如果用户不允许我们读取权限，设备识别码我们是没有办法拿到的。

因此，为了防止出现这种情况，Testin云测的系统会为每台设备随机生成ID，并以此为标识进行分流。只要您的用户不手动清空所有缓存，ID就会伴随着设备一直存在。

（您可以搜索“平台如何识别不同用户”问题，来加深理解）

1.1.5. 集成SDK，集成变量和指标工作量如何？

可视化模式的实验，只需要技术同事集成一次SDK（10分钟左右），就可以由产品或者运营同事来创建试验变量和指标（几分钟就可以完成）。

编程模式的实验，需要技术集成SDK（10分钟左右），产品设计和创建试验变量及指标(每个实验5-30分钟左右，根据变量和指标的复杂程度），技术再通过代码管理两个版本（系统代码5-7行，时间主要看技术两套方案的代码编写时间）。

1.1.6. 运行集成SDK的代码会崩溃吗?

请把SDK的代码放在主进程集成。Testin云测A/B测试的SDK经受过诸多用户考验，并不影响您的App，如果有崩溃，很可能是没有按照文档正确集成。

1.1.7. 什么是应用、实验、版本、变量、指标?

http://ab.testin.cn/docs/dict.html

需要注意，各个版本只需共用同一指标名称，不用区分版本。系统会在列表中分别显示的。

1.1.8. 什么是转化率、转化人数、总值、均值?

举个例子。比如有个用户，第一天进入页面，点击某按钮，这时候uv1，转化人数1，转化率100%，当日均值1，总体均值1。第二天，他再次进入页面，又点击了按钮，那现在uv还是1，转化人数1，转化率100%，总数2，当日均值1，总体均值2。

1.1.9. 什么时候看转化率，什么时候看均值?

假设咱们在APP的某个商品详情页上投入了两种版本的A和B，分别给20%的流量。指标定在“立即购买”按钮上。然后我们发现，A和B版本，转化率恰好都是100%。如果只看转化率，那么A和B都是一样的，但是这时候如果发现A的均值比B高很多，那么就说明很多人多次在A版本中购买，这可能代表A比B更受欢迎。

1.1.10. 什么是下拉配置、拉取配置信息?

相关问题：页面如何获取变量，获取配置，是否存在本地缓存。

指用户访问时，页面通过调用特定API，向服务器获取版本信息的过程。页面会通过下拉配置，将变量值、分配的版本等关键信息，同步到本地。

请注意，如果有一个下拉正在请求中，再次请求不会重新拉取，会等待这次请求的响应数据。也就是一次只能允许一次下拉进行。此外，每一次拉取配置都会返回一个配置版本信息，下次拉取后台会比对配置版本信息是否一致，如果一致则不会返回sdk配置信息

1.1.11. 流量层是什么，有什么作用?

相关提问：如何实现流量复用；如何实现多个实验并行；如何让多个实验同时推进，什么是流量分层。

流量层是为了实现并行实验而存在的。A/B测试系统提供了流量分层的机制来提高流量使用率，具体表现为：对同样一份流量（比如1万用户），划分多个流量层，允许您在一个流量层开始实验的时候，能同时在另一个流量层（但样本还是这1万用户）对另一个页面开始第二个实验，并且无需增加额外的流量。

图解：http://ab.testin.cn/docs/flowlayer.html

1.1.12. 流量分层是什么样子的？

假设默认层有A实验，两个版本A1和A2；层一有C实验，两个版本C1和C2，那么进入A1的用户可能是1，2，3，进入A2的可能是4，5，6；但是进入C1的用户可能就是2，3，6，进入C2的可能是1，4，5；也就是说，不同层的实验，哪些用户进入哪个版本的分配、跟另一个层的实验是相互独立的事件，不会出现1，2，3进入A1，同时1，2，3也进入C1的情况。

1.1.13. 在大平台环境下，可能会有多个不同维度的A/B TEST同时进行，此种情况下如何分配流量保证多个实验的同时推进？会不会发生冲突？

我们的流量分配模型完全可以保证多个实验同时推进。

具体方法是把这些实验分别运行在不同的独立的层上即可，这样的话每个实验都独自享受到100%的用户流量，而每一个用户也就可以在同一时间参与位于不同层的多个实验、交叉获取不同层的实验版本，从而高效地进行A/B TEST。

但使用这种方法又一个前提：不同层的实验本身在产品逻辑上是独立且互不干扰的。比如，实验1与实验2如果逻辑上互相干扰，但又把它们运行在不同的层，那么一个用户有可能同时参与了实验1与实验2两个实验，这样可能会造成矛盾或不期望的结果。

在这种情况下，当希望用户只能参与冲突实验中的某一个时，我们可以使用同层互斥功能：将冲突的实验放到同一个层上运行，共享该层的100%流量，而由于用户在一个时间点只能参与一个层中所有实验里的其中一个，从而避免了冲突的问题。

1.1.14. 受众分组是什么，有什么作用?

相关提问：设置自定义标签，设置用户标签，个性化配置，如何定向进行实验，可否支持用户画像，是否可以选定不同（分流）维度的用户进行实验，是否可以设置特定用户的展示。

在实验开始前，可在“运行控制”内与“应用配置”中对实验进行定向指定人群设置，即是对该实验的用户进行定流量分配实验。当你希望实验流量只在一部分用户中运行实验时，就可以通过设置“受众分组”来实现。通过设置受众分组，只有符合分组条件的用户才会进行实验。受众分组功能在实验开始后不可再做更改。

受众条件可以为多个，目标标签可以组合。平台允许您基于用户标签进行组合，目前Testin云测 AB测试支持与、或组合条件，和等于、大于、小于和不等于的判断条件，并支持单层括号嵌套。 此外您也可以通过通过SDK上传自定义用户标签。自定义的用户标签需要通过 Testin云测 SDK 相关 API 设置和上传。

注意！小程序暂时无法设置受众分组。

1.1.15. 受众分组可以控制到什么维度，如何设置？

相关问题：SDK将会收集哪些信息？

受众分组包含两个大的维度，一是SDK可以采集到的设备维度，即受众分组中的预定义标签设置。比如设备型号，屏幕尺寸，系统版本号等；二是您这边需要特殊标记的用户属性，也就是受众分组中的自定义标签设置，比如性别，年龄，会员等级，这些用户标签通过API的形式与我们对接，我们根据您提供的维度分流。

预定义标签设置不用单独写代码，直接在平台操作，包括这几个种类的用户：http://ab.testin.cn/docs/usergroup.html

SDK默认收集的信息
（键&描述）
  • mac
  • platform 平台
  • appVersion App版本名称
  • osVersion 系统版本比如Android 6.0， iOS 10.1
  • packageName 包名
  • language 设备语言
  • country 国家代码
  • deviceType 设备类型
  • deviceModel 设备型号，如iOS7,MI5等
  • displayWidth 屏幕宽度
  • displayHeight 屏幕高度
  • net 网络环境
  • ip 设备IP地址
  • osVersionCode 系统版本号
  • referrer 访客来源地址
  • url 当前地址
  • browserName 浏览器名称
  • browserVersion 浏览器版本

自定义标签的设置需要单独调用API，涉及代码，需要您的技术人员协助。

具体设置（平台+页面代码）操作请参考：

iOS：
http://ab.testin.cn/docs/iossdk_4.1.2.html#5%E9%AB%98%E7%BA%A7%E5%8A%9F%E8%83%BD%EF%BC%9A%E5%9F%BA%E4%BA%8E%E5%8F%97%E4%BC%97%E5%88%86%E7%BB%84%E7%9A%84%E5%AE%9A%E5%90%91%E5%AE%9E%E9%AA%8C

安卓：
http://ab.testin.cn/docs/androidsdk.html#6

Web/H5：
http://ab.testin.cn/docs/websdk.html#%E5%9F%BA%E4%BA%8E%E5%8F%97%E4%BC%97%E5%88%86%E7%BB%84%E7%9A%84%E5%AE%9A%E5%90%91%E5%AE%9E%E9%AA%8C

1.1.16. 功能：定向分流到版本?

俗称个性化实验，即给不同版本分配不同受众分组。

注意。使用定向分流到版本的话，受众必须是互相独立的。由于定向分流到版本并不是说“非A即B”，而是属于哪个就走哪个逻辑，因此，一旦用户本身的属性同时属于两个受众，执行的时候，就可能走任意一个逻辑。换言之，如果两个受众有交集，那么用户可能会任意分配到其中的一个版本里，不管分配的流量是多少。

如果无法点击，说明这个层还有别的实验，因此无法分流到版本。定向到版本比较特殊，为了避免分流交叉影响，仅在每个流量层只有一个实验的时候，才允许定向到版本。

1.1.17. 我对同样的一个实验，要预先就埋进去4个不同的用户标签吗?

衍生问题：要预先埋入不同的变量吗 要预先埋入不同的指标吗？

可以一次性埋设好不同标签；也可以后续再埋入，在实验开始后不断加版本和新标签进去。

1.1.18. 系统内置的新用户，与我们产品的判断标准不一致?

Testin云测A/B测试对新用户的判断标准是：第一次访问集成了SDK页面的用户。

如果与您的不一致，我们推荐您通过自定义标签，创建新用户的评判标准。

建议您这边先根据具体需求界定一下“新用户”的判定标准，比如是只要刚注册都算，还是不管注册多久，只要首次进入某个活动页就算；然后根据这个标准去制定代码的实施方案，建立自定义标签

1.1.19. 设置受众与初始化的先后关系?

相关问题：初始化之后如何设置受众分组；受众分组可以在初始化之后调用吗；初始化；受众分组；动态改变这个配置信息；标签；Android

首先需要去看4-1API相关文档的第二节。

尤其注意后调用方法setCachedCustomLabels

初始化之前设置受众条件的话（常见方式）需要调用TestinConfig.addCustomLabel，如果初始化之后想要设置受众条件（特殊形式，金融类常用）可以调用TestinApi.setCachedCustomLabels

初始化之后完成受众设置的话，一般还要搭配手动更新（主动更新）方法：

  1. TestinApi.asyncGetExperiments(new OnExpUpdateListener() {
  2.             @Override
  3.             public void onUpdate(boolean update) 
这个update = true  的时候，就是表示拉下数据，更新成功。

1.1.20. 集成调试是做什么用的?

相关问题：实验开始前如何确认集成成功、检测效果；一台测试机可否直接访问某个版本来检测埋点；如何用不同的手机进入不同版本，进行页面测试；如何检测代码集成是否正确。

集成调试（入口为左侧功能区的“调试”功能）可在实验开始前对实验配置进行测试查看，以防实验内所有版本的相关配置有误而造成实验无效。

1.1.21. 如何进行集成调试?

我们为Web/H5提供了链接模式，您可以点击版本链接进入到对应版本进行调试。如果您创建的是Android与iOS应用，我们为其提供了扫描二维码的方式，您可以通过Testin云测 A/B Tester对二维码进行扫描来进入各个版本进行查看。集成调试时，您对版本进行的所有操作都不计入到实际的数据统计当中。

1.1.22. 怎样开始实验?

传统A/B测试：
选择定向分流条件，没有就选“全部用户”，编辑各个版本的流量并保存，开始实验。如有未分配版本的流量，饼图会显示为灰色并且该部分样本会看到默认版本（一般是原始版本），不计入数据统计。

智能A/B测试（依靠AI引擎进行自动智能调节，企业版客户可用）：
请按键盘Ctrl+F，搜索“如何使用AI引擎进行智能分流”。

1.2. 数据

1.2.1. Testin云测的流量如何分配的？是随机分配吗？如何保证流量分配后的每组用户有相同的用户特征？

相关问题：为什么每次分配到的版本都是一样的，流量如何分配？

从本质上讲，我们的流量分配遵从随机性，以保证不同实验版本的用户之间的差异性足够小，亦即保证每组用户的相似性尽量大。同时，对于某个特定用户来说，我们的流量分配又能保证一致性，即在实验版本流量分配策略不改变的情况下，某个用户每一次被分配到的版本都是恒定不变的，因为这样才能保证实验的准确性以及良好的用户体验。

对于用户特征，除了以哈希算法为核心的分配算法之外，我们还会通过SDK采集到的设备信息进行分流，避免分流不均匀。另外，我们在实验级别提供了定向分流功能，这样我们可以允许实验员自己定义拥有哪些特征的用户才能参与某个实验。比如，对于同一个产品，我们可以只让使用中文的用户进入实验1，只让使用英文的用户进入实验2。

1.2.2. 分配流量是一边一个1:1的吗?

否，分流是概率随机的，采用多种算法，最终实现真随机分配，如果1:1那样分发是不均匀不准确的。

1.2.3. Testin云测 A/B测试平台会进行什么类型的数据收集和统计?

系统会默认自动统计UV，H5中还会将pv的统计数字展现出来；

您还可以针对不同的触发事件，手动埋设相应的指标。例如，按钮的点击、成功注册、购买金额等等。这些数据都会在“实验概览”和“指标详情”中进行展示。其中转化率和转化人数，是指将数据进行去重后得到的“人数”，总值和均值是指未进行去重的“次数”

企业版还会提供“留存分析”和“多维分析”，允许进行数据筛选和对比等。

1.2.4. 上传若干次指标，但页面上为什么没显示指标的值，只有百分比？

相关问题：指标比例，指标值，数值

实验概览里，若要查看具体的指标数值，可以切换上方tab的“转化人数”查看；或直接切换顶部tab“指标详情”来查看。

 

1.2.5. AB测试只能测试某一短路径的转化率，但是不能持续监控用户路径，可否第三方数据分析打通，把用户传到第三方数据平台上，我去看这群用户的其他行为？

相关问题：可以查看每个用户的具体行为/具体数据吗；能否与神策/GrowingIO/诸葛IO/GA等打通？

由于A/B测试是对多个版本的表现进行宏观的统计分析，因此不能单独追踪记载每个用户的具体数据。如有相关需求，建议将Testin云测 A/B测试系统的分流能力，与其他用户行为分析工具相结合来使用。

目前没有打通数据，但是可以通过别的方式实现后续统计。

我们安卓、Web/h5、iOS的SDK都有一个API，可以获取当前设备分别进去了哪个实验版本的标签信息，把这个信息传给第三方统计平台之后，就可以观察A版本人群和B版本人群的其他用户行为了

这两个页面有这种方法的相关配置信息：

安卓：

http://ab.testin.cn/docs/api/androidv4/cn/testin/analysis/TestinApi.html#getCurrentExperimentsInfo--

iOS：

http://ab.testin.cn/docs/api/iosv4/Classes/TestinDataAnalysis.html#//api/name/getAllCurrentExperiments

1.2.6. 有什么可以传输给第三方数据平台的数据或者指标？

可以在做AB测试的时候，就先在每一个实验可、创建多个指标，这样在一个转化路径里的每一个环节的指标都可以拿来给第三方平台做对比分析。说起来，第三方统计的劣势是他们没有统计分析算法，像95%置信区间，p-value等数据他们就没有，这就需要跟我们产品结合来使用。

1.2.7. 给第三方平台传数据的时候，要怎么区别每个用户？

跟第三方数据平台打通的时候，只需要用第三方数据平台常用的用户id就行了（例如IMEI、用户id等都可以），不需要用我们AB测试系统的用户ID。因为，每一个设备调用我们获取实验版本的API之后，都会知道这个设备进了哪个实验版本，然后把这个实验版本信息和第三方数据平台常用的用户id还有其他用户行为日志一起传给第三方数据平台就好了。

1.2.8. 如何判断A/B测试结果可信?

相关提问：假设检验、p值/p-value、power、置信度、置信区间、结果显著、显著性明显？

简单解释：

通过置信区间进行参数估计，通过p-value和power进行假设检验。这些在平台上可以直接观察数值文字和颜色来分辨。如图，变化度后面的置信区间，会展示假如实验版本被放到线上，其可能的转化率波动范围；p-value和power则可以直接根据文字和颜色判断，灰色表示置信度较低、版本之间无明显差别，有色表示置信度高、版本之间存在显著差别（优或劣）


 
深度解析（围绕统计学关键指标进行解释，如果您只是日常使用，可不看以下内容）：

在进行A/B测试时，有些测试者会直接简单地通过对不同实验版本的指标均值进行比较，从而做出版本之间优劣差异的结果判断。这实际使用了点估计的方法。但是我们需要意识到：由于样本毕竟有误差，因此点估计的误差也往往比较大。一种更严谨和精确的方法是假设检验的方法，这也是如今市场上各类A/B测试工具的普遍做法。

假设检验的详细解释：
http://ab.testin.cn/docs/stat.html

一般我们通过几个因素一起来判定A/B测试的效果：

a) p-value：

判断两个不同版本的实验结果之间不存在显著差异的概率。

通常情况下，如果“p-value < α（显著水平）”， 表示两个不同版本存在显著差异，否则表示不存在显著差异。一般来说，我们期待并设置的最大的显著水平为5%。

b) power（统计功效）：

当两个不同版本之间存在显著差异时，实验能正确做出存在差异判断的概率。

该值越大则表示概率越大、功效越充分。一般来说，我们期待并设置的最低的统计功效值为80%。

c) 置信区间（Confidence interval）：

置信区间就是用来对一个概率样本的总体参数的进行区间估计的样本均值范围。一般来说，我们使用 95% 的置信水平来进行区间估计。置信区间可以辅助确定版本间是否有存在显著差异的可能性：如果置信区间上下限的值同为正或负，认为存在有显著差异的可能性；如果同时有负值和正值，那么则认为不存在有显著差异的可能性。

1.2.9. 变化度、p-value、power分别代表什么，怎么计算的？

变化度表示测试版本均值或转化率较原始版本提升百分比。它的计算方式是： （测试版本转化率（或均值）- 原始版本转化率（或均值）） / 原始版本转化率（或均值）

p-value，即假设几率，是用于判断原始假设是否正确的重要证据。 在A/B测试中的原始假设一般为“两个不同版本的实验结果之间不存在显著差异”。 统计学根据显著性检验方法得到p-value。如果“p-value<0.05”， 通常表示存在显著差异，否则表示不存在显著差异。

power，代表能够正确地拒绝一个错误的原始假设的概率。 通常，“统计功效<0.2”代表功效极低；“0.2<=统计功效”且“统计功效<0.5”代表功效不足； 如果“0.5<=统计功效”且“统计功效<0.8”代表功效良好；“0.8<统计功效<=1.0”则代表功效极好。

p-value和power是基于Testin云测 A/B测试SDK端采集的数据信息，结合相关统计学算法模型计算后得到的。

1.2.10. 当实验结果呈现非统计显著时，并且效果也不显著时，该如何进行下一步实验或流量分配？

我们需要综合从多方面来做判断，比如p-value、统计功效、实验进行的时间、效果的稳定情况等。简单来说，无论哪种情况，如果实验不满一周，那么建议继续实验；如果至少满一周了，且p-value小于指定的置信度（默认0.05），那么要看统计功效是否达到最低标准（默认设为80%），如果没有则建议再进行一段时间实验，并且适度增加实验流量的分配；如果至少满一周了，且p-value大于指定的置信度（默认0.05），且p-value的值连续几天都稳定地大于置信度，则可以结束实验，反之则建议再观察几天以等实验结果稳定；等等。我们的产品将会陆续提供最小样本量计算器与实验剩余时间提示器等，以协助用户更加正确且轻松地决定下一步的操作。

 

1.2.11. 为什么我们的访问量很大，实验样本/UV却很少?

相关问题：A/B测试的数据量和我们用其他工具统计到的差距很大、数据比我们自己统计的少了很多、数据对不上、数据怎么这么少、数据不对？

这是一种很常见的关键问题。可能的原因有以下几点。
  • 流量分配未分满。请查看实验的“控制”-“运行控制”，看总流量是否分到了100%。没分满流量是肯定不够的。
  • 集成或埋点等错误。这是大部分的问题所在。要看页面是否能集成调试，如果不能，那就说明实验存在代码上的集成错误，数据统计会不准确。可以让技术或者自行帮忙查看代码是否集成错误。
  • 网络问题。在实验过程中，我们统计的流程是用户下拉SDK的配置后，再进入实验；如果用户在使用过程中，自己的网络原因导致还没下拉配置，但是访问了；这个数据就会不在我们的统计中，但是在百度的正常统计中。
补充：配额不足（该点仅仅出现在使用旧版SDK的客户身上，新版SDK已经不会出现）：配额是合同约定的每月可参与实验用户数，也就是允许用户参与实验的资格。客户目前是购买了月10W配额的量，根据平均配置或者自行配置；如果某个时段超出了最大配额限制，则多余用户不会进入实验统计数字中，所以实验数据会偏小。（如果不是特别大流量，应该没问题）。

1.2.12. 是否需要让全部流量进入实验?

实际上，A/B测试并不需要将全量用户引入实验，因为其本身就是在用小流量的表现来预测整体。当然，放更多的流量进入实验，能让实验结果更加准确可靠。

1.2.13. 在运行控制中将两个版本的流量分配设置为50%与50%，但是UV分布非常不均匀，是怎么回事？

相关问题：原始版本和版本一的UV怎么差了这么多，分流真的是随机吗？

请检查您的流量分配是不是一直按照50%：50%分配的。比如，如果您一开始是按90%：10%分配流量的，就会导致一个版本UV特别多，一个版本特别少。在这种情况下，哪怕之后又把不同版本的流量等比分配了，UV统计到的两个版本的数据还是会不均匀。一般我们建议您在做A/B测试时，每个版本的流量一直都保持等比分配。

由于A/B测试的分流系统，是采用多种算法，最终实现真随机分配的，因此用户会进入哪个实验完全是按照概率，而不是按照数量。那么就有可能会出现分流数量有差异的情况，而这种情况，在总体流量足够大的情况下则会得到缓解；

（目前您的实验由于刚启动不久，数量级还较小，您可以再运行一段时间，然后对照较大数量级下的分流情况，效果就会比较明显了）

1.2.14. 新建实验 开始实验之后 会隔几分钟才会生效吗?

正常情况下，开始实验是立即生效的，不过，可能会由于网络问题导致拉取的延迟。

1.2.15. 我感觉10分钟左右才会看到数据更新，Testin云测 A/B测试是否实时传输数据？

相关问题：数据上传的间隔、数据更新的间隔、上报指标所需要的触发条件是什么、指标上传间隔。

最新SDK全部都是直接实时上传数据。没看到数据更新，可能是您的网络原因。

1.2.16. 想在测试环境对实验进行数据收集的校验，该怎么做?

http://ab.testin.cn/docs/data-accuracy.html

1.2.17. 数据中，转化率/均值/转化人数/uv是有去重的吗？

是的，是去重的。并且按天查询的话，是当天排重；按月查询的话，是当月排重。

举个例子。比如有个用户，第一天进入页面，点击某按钮，这时候uv1，转化人数1，转化率100%，当日均值1，总体均值1。第二天，他再次进入页面，又点击了按钮，那现在uv还是1，转化人数1，转化率100%，总数2，当日均值1，总体均值2。

1.2.18. 做Web/H5实验的时候，使用同一台设备，从微信上进入实验和从浏览器上进入实验看到的不是同一个版本？

相关问题：同一个设备不同浏览器计算了两个UV？

这个问题本质上是在两个浏览器上查看了实验，由于流量分配的时候使用的是cookieID，cookieID会因为不同浏览器的区别导致分配版本不一致。但是，会这么做的用户，在实际情况中是比较少的（一般大家就用一个浏览器打开），我们可以称为个例。而在实验数据足够多的情况下，做统计分析时是会排除个例的，也就是说，只要满足我们的检测，最终给出的结果不会受到影响

1.2.19. 停止实验了为什么还有流量进入?

相关问题：实验停止了，为何还在分配用户？

这个数据不是分配的新样本，新的访问者已经停止分配了，打入数据的是再次来访的老访问者。停止实验后，实验uv会有一个快速下降的曲线，但并不是说，实验停止就不传数据了。因为用户客户端，必须要拉取到“实验停止”这个信息后之后，数据才不会上报，因此停止后有老访问者数据上传是正常的情况。

1.2.20. 流量为0为何还有数据?

如果您这个实验是新开的，流量为0，那么用户肯定是进不去的；

如果这个实验已经开启了一段时间，那么当流量为0后，样本UV会有一个快速下降的曲线，并不是立刻就无数据。这是缓存导致的。新的实验样本确实已经停止分配了，但那些已经进入过1次实验，分配过版本的老样本，会因为缓存原因，在第2次访问时，看到该版本（并传输数据给服务器）。当然，这些老样本随后便会分入其他版本当中，并在下次（即第3次）访问时生效。

 
 


1.3. 平台使用（产品使用）

1.3.1. 如何选择适合自己的实验模式?

相关问题：编程模式，可视化模式，多链路模式（H5专用）的区别？

可视化模式，是通过SDK改造您的落地页，从而允许落地页在后台进行文字、颜色等属性的编辑和改动。第一次集成完成后，一般就不需要重复布码了。

编程模式，也是是通过SDK改造您的落地页，有新实验时，可以针对每个落地页一些小的架构变动进行调整。并且，如果您只是要修改某张固定图片、某些固定按钮的话，甚至只要一次集成，后续就不用修改代码了。

多链接合并模式，每个新加的页面要布玛。但是也不多，就五六行。不过，这个模式会生成一个合并链接，用户访问合并链接才能分流。

可视化是运营方便改页面，编程模式是开发方便改动页面。

1.3.2. 当停止实验、点击一键回滚按钮，或者点击发布版本按钮后，为什么再也无法重新分配流量了？只能重新建立一个新的实验？

产品这样设计的原因是：

（1）一键回滚、发布某个版本这种类型的操作生效之后，这个实验的生命周期就结束了。因为，之所以会对一个实验进行回滚、或者发布，是因为通过观察2-3周用户A、B版本的数据之后，做了决策：我该发布这个最好的版本（因为这个版本的转化率高于原始版本）、我该回滚到原始版本（因为新版本数据不好）；

（2）停止试验也是一样的，停止实验是由于不想再进行实验或者代码已改为最优版本。

所以，我们不允许已经发布、回滚或者停止的实验重新再开始。如果想达到重新开启的目的，只能重建一个新实验或克隆一个旧实验。

1.3.3. 得出结果的实验应该如何处理?

相关问题：旧代码怎么处理？

平台上，可以停止实验；

代码中，请务必再每个实验结束后，及时的删去不用的代码，避免实验过多对您的代码管理造成麻烦。

1.3.4. 如何进行灰度发布?

首先需要设定版本和启动实验。然后，根据您的需求，调整两个版本的流量，逐渐扩大新版的比例。一旦您确定可以全量放入新版，就可以使用“发布”功能，让流量全部访问新版。

请注意。发布功能，只是Testin云测A/B测试为您提供的一个临时解决方案，您的代码并没有完全固定在产品中，换句话说，灰度发布尚未完成。建议您摘去旧版代码与实验，正式发布一个新版，然后停掉原本的实验（因为实验目的完成了），此时灰度发布才算完成。

1.3.5. 灰度发布时，相当于两套都在app里面，但是新版本里是不会集成旧版本?

实际上，这与灰度发布的任务有关。灰度发布的任务是为您“探路”而不是最终的“定稿”。

我们分两个时间段来说，

第一，当您有改版意愿的时候，您可能会担心新版有没有bug、受不受用户喜欢。这个时候，您就可以用灰度发布，在旧版中放入新版代码，去搜集新版本的数据表现——请注意，这个阶段您是还没有真正更新新版的。只有部分用户能逐渐看到新版。

然后，第二阶段。您收集到了数据，认为新版是没问题的、该给所有用户的，您就可以正式发布新版，摘去旧版代码（如同上一问，删除旧代码一样），然后停掉原本的实验（因为实验目的完成了）。这个时候，新版本中是不会有旧版代码存在的。

1.3.6. 我的实验已经发布了，删掉变量的话，会不会影响到线上的玩家?

发布状态下，会。

发布功能是为灰度发布准备的，如果您通过A/B测试，发现版本一更好，可以更新版本一，并直接停掉实验。

如果您担心，有部分用户没有及时更新到新版本，关掉实验后，他们会直接还原到老版本——那可以先保留实验在发布状态，同时更新新版。

1.3.7.  在查看数据表现时，复合指标中出现的“（交集）”与“（并集）”分别代表什么数据？

（a）交集：复合指标所包含的所有单项指标各自的转化人数的交集。

转化人数：等于复合指标所包含的所有普通指标各自的UV的交集。比如，复合指标a由普通指标b和c得到，且公式为a＝b＋c。实验进行截止到目前，对于版本A来说，总的有7个用户｛u1,u2,u3,u4,u5,u6,u7｝进入实验。而对于b指标，共有｛u1,u2,u3｝这3个用户触发；对于c指标，共有｛u2,u3,u4,u5｝这4个用户触发。那么对于版本A的复合指标a来说，它应该包含2个用户｛u2,u3｝，所以转化人数就是2。

转化率：复合指标的转化人数与进入当前实验版本的总UV之间的比值。按照上面的例子来看：复合指标的转化人数＝2，进入当前实验版本的总UV＝7，所以复合指标的转化率就是2/7。

（b）并集：复合指标所包含的所有单项指标各自的转化人数的并集。

转化人数：等于复合指标所包含的所有普通指标各自的UV的并集，再去除重复的UV。比如，复合指标a由普通指标b和c得到，且公式为a＝b＋c。实验进行截止到目前，对于版本A来说，总的有7个用户｛u1,u2,u3,u4,u5,u6,u7｝进入实验。而对于b指标，共有｛u1,u2,u3｝这3个用户触发；对于c指标，共有｛u2,u3,u4,u5｝这4个用户触发。那么对于版本A的复合指标a来说，它应该包含7个用户｛u1,u2,u3,u4,u5,u6,u7｝，所以转化人数就是7。

转化率：复合指标的转化人数与进入当前实验版本的总UV之间的比值。按照上面的例子来看：复合指标的转化人数＝7，进入当前实验版本的总UV＝7，所以复合指标的转化率就是7/7。

1.3.8. 平台如何识别不同用户?

相关问题：为什么同一台手机即使删除了app再装也是上次拿来的数据；实验流量未做调整前提下，同一手机上卸载、重装App是否会重新分配版本；SDK如何识别不同用户；ClientID

1）Android

Android通过imei、mac以及其他一些设备信息生成clientid，如果获取设备信息权限被禁止，则clientid通过uuid生成。因此在这种情况下，只要重新生成clientid时（重装或清缓存等情况发生时），都可能会得到不同的clientid，可能会下拉到不同的实验配置。

2）iOS

除非有人重置钥匙串，否则即便在清缓存或重装应用行为发生后，用户都会得到相同的clientid，所以会下拉到一样的实验配置。这是为了分配版本的唯一性和用户体验一致性考虑而设计的。当有人重置钥匙串，那么在重装或清缓存等情况发生后，可能会下拉到不同的实验配置。

3）H5

在识别独立用户，也就是UV的方法上，我们通过clientid来记录。我们存储的clientid 是存在浏览器本地localStorage里的，如果禁用了，那么每次刷新都在数据层面视为一个新的UV。

而使用无痕浏览，就禁用了本地localStorage，导致您每次刷新，UV会增加。

我们建议您在实验过程中，使用普通浏览模式，或者不要禁用localStorage，数据会更加准确。

1.3.9. 我是不是换个浏览器看到的版本就可能不同了？

是的。如上一问所答，我们会为每个访问者创建clientID，缓存在本地，当您更换浏览器时，会给生成新的ID，建立一个新的缓存，重新分配。

当然，原本的浏览器，版本还是不变的。

因此变换浏览器会被识别为两个用户。但一般来说用户不会换着浏览器来访问一个网站，因此此类个例对最终数据结果的影响可以忽略不计。

1.3.10. A/B TEST时如何选定控制组和对照组，以排除干扰因素？

使用Testin云测的A/B测试平台，用户只需要给控制组和对照组分配相对一样大小的流量即可以排除干扰因素。因为我们可以在实验级别就通过定向分流条件使得同一类用户才能进入实验，所以所有进入实验各个版本的用户在本质上都是特征相似的用户，而且版本之间的流量分配又遵从了随机性，从而从根本上剔除了干扰因素。

1.3.11. 如何判断什么情况下需要引入A/B TEST，怎样评估成本？

相关问题：我的产品该不该做A/B测试

A/B TEST是帮助优化营销和设计决策的利器，一般可以在用户稍有一定规模的时候引入。在用户量极低的时候，比如小于几百人，那么意味着产品或营销本身还有很多明显的地方可以被完善，此时即便引入A/B TEST，统计效果可能也未必好。

关于成本，主要包含平台研发成本、技术引入成本和日常实验成本三大部分。首先，如果用户选择自研技术或平台，那么无论财务成本和时间成本往往都会很高，甚至有研发效果不达标的风险，因此这部分成本是最大的，所以购买一个成熟稳定的第三方产品实际是能够降低成本和风险的有效手段。其次，在有了可用的测试平台后，实际还需要在实际项目中将该技术或平台引进，对相关人员有技术培训，因此这部分的成本在所难免。不过，如果引入的平台或技术是成熟、稳定且容易操作，那么这部分成本也可以得到有效控制，否则有可能在这部分产生较大的引入成本，甚至由于成本太高引起干系人的抵触从而增加了项目推进失败的风险。 最后，日常实验成本受平台和技术的成熟度和稳定度影响非常大，如果使用了不成熟的平台，那么这部分成本会很高，而且随着时间推移不断增加，但如果引入了成熟的平台，那么之后做实验的成本其实就非常小，因为平台本身提供了稳定和便捷的功能，使得用户可以非常方便灵活地进行实验验证新方案效果。综上所述，A/B TEST的成本受平台和技术成熟度的影响非常大，因此需要在一开始的时候谨慎选择方案。

1.3.12. A/B TEST的测试周期和需要覆盖多少用户量才能达到效果？

相关问题：什么时候可以停止实验；需要多少样本才可以停止；我实验跑了一天（三四天）了，可以停了吗；最小样本量是多少？

A/B TEST的测试周期建议至少1周，以2到4周为佳。实验需要覆盖到的最小用户量受多种因素的影响，比如实验设置的置信度α和最低统计功效、新版本较之原始版本的最小提升率、原始版本的转化率等。可以点击导航栏的“工具”，进入样本量计算器来统计

1.3.13. 平台上，使用客户端的A/B TEST和服务端的A/B TEST方案模型有什么不同?

相关问题：前端和后端的区别；后端SDK；

前端是直接通过页面上写好的前端代码，依据拉取的不同变量走不同的逻辑，来实现分流。

后端的话是将sdk部署在服务器上的，通过控制服务器渲染不同页面实现分流。

1.3.14. 客户端和服务端，采用什么样的数据埋点方便数据收集？

相关问题：前端和后端哪个更适合数据统计；前端和后端，我应该选择什么方式进行实验？

无论是客户端的A/B测试还是服务端的A/B测试，都同样方便数据埋点和数据收集。两种方案各有特点，且各自有其适用的场景。简单来说：

客户端的A/B测试可以将测试成本和影响控制在客户端应用中，而不用更改任何后台服务代码或增加后台服务的压力；客户端可以轻松完成很丰富灵活的基于UI的A/B测试（比如利用可视化技术，用户可以轻松做到无代码埋点，轻松更改客户端的UI展示，完成相关A/B测试）。

对于服务端的A/B测试来说，它很适合做后台算法类的实验，可以在不更改前端应用代码的情况下轻松完成A/B测试；后台服务器可以访问更丰富的数据源，为A/B测试中的获取客户标签、定向分流等功能提供更强大的支持；它还可以完全避免了由于前端网速导致下拉配置首次失效的问题，使得所有前端用户都可以即时准确得到相关实验版本（比如，在任意一个前端新用户的首次登陆时，后台都能够准确发现，并且及时给他们展示为新手特意准备的落地页）。

1.3.15. 服务端实验怎么支持A/B测试？

我们提供了Java SDK，它以http server的方式提供给开发者，需要开发者部署在服务器上。开发者在自己的逻辑代码中通过http request，向server发送请求，包括初始化SDK，获取实验变量，上传指标操作。http请求方式为post。

具体使用方法请参考：http://ab.testin.cn/docs/25-java-sdk%E9%9B%86%E6%88%90.html

1.3.16. 使用服务器渲染测试页面，导致返回上一级的时候会返回一个空白页?

由于客户做A/B测试的页面是使用服务器渲染一个空白页来实现的，所以当从该列表页面返回上一级页面时，会因为服务器渲染的原因返回这个空白页。

解决方法有两种：

1、使用浏览器来渲染测试页，就不用多一个空白页来渲染了。

2、使用我们的Java SDK，从后端服务器方面来解决渲染问题。

 

1.3.17. Testin云测的A/B TEST对于用户量级较大的产品支持程度如何？SDK接入是否会影响应用的稳定性及性能？

Testin云测的A/B TEST是一款成熟稳定的优秀A/B平台，目前有多家日活千万级别的用户在同时使用，使用效果良好且并未影响应用的稳定性及性能，值得用户放心。

1.3.18. 看板功能主要解决什么场景的需求？

看板功能的使用场景是跨应用的实验数据聚合查询。举例来说，某App的iOS端和安卓端在我们平台上是两个独立的A/B测试应用，这两个应用都做了1个首页改版的实验。通过看板的功能，我们可以在一个看板里面，把该App iOS端的首页改版实验的数据和安卓端首页改版的实验数据放在一起做横向对比，这样能方便的实现跨应用的实验数据的横向对比和查询。

1.3.19. 能否支持实验过程中添加指标？

在实验运行过程中，不能再添加单项指标，但是可以添加复合指标，因此建议大家在实验开始运行之前，设计好本次实验相关的单项指标，如需修改该实验对应的指标，建议关闭该实验，并重新建立一个新实验。此外，在实验进行中，是可以添加新的实验版本/变量的。

1.3.20. 实验过程中调整流量的话，会不会导致用户命中的实验组跳变？

如果参与实验的用户流量是从少变多的话（例如调整前分别各有5%的用户参与原始版本和版本1的实验，调整后分别各有10%的用户参与原始版本和版本1的实验），不会导致已参与实验用户的实验组跳变，即已参与原始版本和版本1的用户会继续参与之前的版本，而调整前未参与实验的90%用户中，有5%用户会参与原始版本的实验，另外5%参与版本1。

但是，如果参与实验的用户流量是从多变少的话，会有一部分用户在调整前参与了实验，但是调整后变成未参与实验的状态（即跳变成原始版本，且不被统计实验数据）。所以，我们建议对一个实验的流量调整要遵守“从小流量调节至大流量”的原则，以保证用户前后体验一致，以防干扰实验结果准确性。

1.3.21. 编程闪现。修改的控件，在使用设备进行访问的时候，会先显示原版的样式，然后再切换为实验版本的样子。

相关问题：编程模式下出现闪现；原始版本会闪现一下；闪烁；实验版本切换有延迟？

举例说明：设置原版文案为“原文案”，版本一文案为“实验文案”。A进入版本一，会先看到“原文案”，然后经过一小会儿，文案才会突然变成“实验文案”。并且，再次进入版本一仍会出现。这是由于用户集成sdk的位置在偏下的地方，导致页面渲染完原版才渲染版本一。

请注意，该问题针对编程模式，如需查看可视化模式下的的闪现问题，请访问“可视化闪现”

这是因为用户第一次访问时，需要通过下拉配置，才能显示新的版本导致的，是比较正常的现象。第一次访问该页面会因为页面渲染顺序的先后，导致一定的延迟。正常情况下，在第二次及以后的访问中，这个现象就会被缓解了。

如果想要解决这个问题的话，可以试试把集成Testin云测相关代码的部分，移动到头部，优先加载

此外，这个情况其实比较短暂，对用户的影响相对较小，如果不方便调整代码的话，也可以忽略。一般来说，当用户第二次加载该页面的时候，情况就会得到缓解。

 

1.3.22. 订单金额比较敏感，Testin云测一般的解决方案是什么？

这类敏感问题，我们可以通过在您那边实施“私有化部署”，该部署可以更安全的保护数据。

1.3.23. 如何实现缓存和安全?

缓存使用Redis，

安全主要是：全网使用Https访问，API请求加一些验证限制等。

2. 企业版A/B测试FAQ


如果您是企业体验版本，到期后会直接转为免费A/B测试，您的实验不会报错，只是权限会受限（如Java后端实验和AI智能分流将不能进行）。并且，过去配置好的实验是不会失效的，系统只限制新建实验。

比如，您在企业体验版期间创建了10个实验，变成免费版后，10个实验仍然在，但是必须删除到5个以下，才能创建新的实验。

2.1. 可视化实验（企业版可用）

可视化模式仅需在第一次集成SDK时添加相关代码，之后进行的每一个可视化模式的A/B测试实验，产品和运营只需要通过可视化的操作方式就可以完成新版本编辑、指标埋点、新版本上线、对比新老版本数据、产品决策等整个A/B测试流程。

可视化模式适用于App UI相关的A/B测试，例如修改按钮文案、按钮颜色、控件透明度、隐藏控件、替换控件背景图等场景。可视化模式的优势在于，产品和运营同学可以零代码独立完成新版本的编辑，并且新版本可以实时在用户的App中生效，不需要等待应用市场的审核，极大加快了产品迭代的速度。

2.1.1. 将新版本的流量调成100%，为什么后台记录打开的APP还是原始版本？

请检查您的手机是否正处在”可视化编辑“模式。可视化编辑开关需要在代码中关闭，否则不会进行数据配置更新。

  iOS方法


 
   Android方法

 

2.1.2. 可视化编辑无法和手机连接成功是什么原因？

可视化编辑是长链接的端口，如果网络有做限制长链接，那么将无法连接成功，所以需要去掉网络限制。

2.1.3. Testin云测 A/B测试的可视化会不会受苹果热更新的限制？

不会像热更新一样被限制：因为热更新有能力执行第三方恶意代码，而我们只会修改已有控件的标准属性（例如颜色，文字），不能无中生有，相当于热更新是自选动作，我们是规定动作，所以不会被苹果封。

2.1.4. 为什么在修改一个页面A的按钮文案时，另一个页面B的按钮也受到了影响？

造成这个情况的原因有两种。

第一，请先确认您的同事是不是也在做A/B测试，会不会是他们的A/B测试对页面B的按钮文案进行了修改？

A/B测试为了最大化利用流量，提供了流量分层的机制来提高流量使用率。具体表现为：对同样一份流量（比如1万用户），划分多个流量层，允许您在一个流量层开始实验的时候，能同时在另一个流量层（但还是这1万用户）对另一个页面开始第二个实验，并且无需增加额外的流量。

因此，如果您在流量层1中对页面A的按钮进行A/B测试，但您的同事也在这个时候使用流量层2对页面B进行A/B测试，并修改了按钮文案，那么您自然会在两个页面都看到改变以后的按钮了

第二，（一般是这个原因）可能由于您的产品在开发的时候，没有区分不同页面的控件id，对两个页面即页面A、页面B的按钮使用了相同的选择器，并且集成了同一个SDK，从而导致在下拉配置时，页面B识别到了与页面A相同的选择器。于是页面A按钮的修改就被同步到了页面B的按钮上。

要解决这个产品开发上的小问题很简单，有两种方法：

1. 修改需要编辑的控件选择器（只要简单增加个id属性来做区别即可），这个方法最简单快速，举个栗子：

  1. <div class="main-box"> //这里就是使用了相同的选择器
  2.      <div>
  3.          <p id="detailBox"> //这里就是添加了id，从而将页面A的按钮与页面B分开
  4.              <button>1</button> //这里是受到影响的按钮
  5.             </p>
  6.         </div>
  7. </div>

2. 不用可视化模式而是通过编程模式修改页面。

2.1.5. 原本能正常渲染、进入版本，但是经过某些操作，设备无法进入实验了?

让用户检查一下（实际上，我们自己应当先用后台打开他们的页面检查实验）两个版本的所有URL是否完全相同。可视化实验，必须让各个版本的URL所有完全一致，包括设置版本样式和埋点两个步骤的所有URL都必须一样。如您的url有相同域名、但参数多变，请在创建实验的时候选择“模糊匹配”并使用通配符{**/**,**}

例如，

http://www.example/book/{**/**,**}

就允许将可视化修改作用在所有http://www.example/book/+后续参数的页面上，如：

 

2.1.6. 可视化闪现。访问页面后，会先出现原始版本，然后突然变成（闪现）新版?

相关问题：可视化闪现，跳变？

请注意，该问题针对可视化模式，如需查看编程模式的闪现问题，请访问“编程闪现”

这是正常现象。从现有的A/B测试行业来说，可视化有些微闪现的情况是普遍现象，可视化是把界面编辑转化为动态脚本，涉及结构性的懒加载，因此会有个执行先后的问题。您页面的代码会被优先执行，故出现了原始版。然后，执行好新版后，会将页面变成新版的样子。

如果您这边感觉闪现影响过大，可以考虑使用我们的“开启白色的遮罩”的API。
https://ab.testin.cn/docs/api/web.html#openOverlay



2.2. 后端实验（企业版可用）

2.2.1. layerId在页面上没找到，我是在日志中看到的，页面上如何能看到？

请注意：出现layerId的需求，说明您是在阅览后端（JAVA）实验的文档。实际上，后端实验目前只允许企业版用户使用。如果您使用的是免费版本，请先联系Testin云测A/B测试的相关工作人员。

layerId在实验列表页面查看，有个xx层

 

2.2.2. clientid是我们自己随便定一个么？有什么规则吗？

clientid是唯一标识用户用的，您可以根据您的用户系统自行设定，只要尽量保持不变就行

2.2.3. 一个后台程序里有两个实验，流量各占50%。通过layerId获取参数时，只能获取一个实验的参数么？

同一个流量层中的实验是形成同层互斥的，每个用户只能获取其中一个实验的变量

 


2.3. 智能分流AI（企业版可用）

2.3.1. 如何使用AI引擎进行智能分流？

相关问题：智能A/B测试，智能实验

在创建实验时，选择“创建智能分流测试”


 
完成创建后，在“控制”中，选择定向分流条件，没有就选“全部用户”。

然后选择一个核心指标。

编辑你要进行智能分流的流量总量，保存分配实验的总体流量，如果进入AI引擎的流量不是100%，未分配部分的样本会看到默认版本（一般是原始版本），不计入数据统计。

开始实验。AI引擎将会根据各版本核心指标的数据情况，自动调节流量。

2.3.2. 如果用户反复访问，会重新分配版本吗？

由于智能分流实验的目的，就是让用户最终能进入效果较好的版本，因此每次访问都会根据当前整体的实验表现重新分配。所以，我们建议您将此类实验用于落地页等用户不易反复访问的页面。

2.4. 分析功能（企业版可用）

2.4.1. 留存分析如何使用？

这个数据是SDK自动判断的，以用户再次进入实验页面为“留存”判断标准

留存的判定标准？

相关问题：算不算留存；

留存分析功能是以用户是否进入实验为判断条件的。

以下图第一行为例，新增代表当天进入版本的 去重 样本量（记为第一批），“1天后”代表这第一批样本中，第二天再次 访问 实验的样本量。


 
假设您是第一天访问，则第一行，新增+1。第二天没访问实验，第一行的1天后留存为0。若您第三天访问，则第一行2天后留存为0，但是第三行新增=0（去重）。

2.4.2. 为什么注册实验中会出现留存数都为零的情况？

现在ab测试只针对实验页面的留存进行统计。统计方式为判断用户当天有没有打点上传，而想要触发打点，用户就必须再次进入注册页面。但是一般用户进入注册页一次之后就不会再进入了，因此也就没有打点上传，所以之后就不会有该用户的留存情况

2.4.3. 如果想要看上一问这两拨用户留存情况，有什么办法吗？

AB测试平台的设计是针对每一个实验在实验级别进行数据分析(包括留存分析)，这是AB实验的一个基本出发点。这也是为什么落地页实验的留存的确很低：因为用户下次基本都不再登录同一个实验页面（比如注册页面）了，所以没能再次触发实验级别的PV信息（我们主要根据PV信息来计算留存）。对于当前的设计理念来说，的确不能在实验中看到超出实验所包含页面范围外的留存信息

2.4.4. 多维分析如何使用？





 
您需要先点击右上角的时间进行设置，然后选择多维分析条件进行搜索。由于多维分析调用的数据较多，可能需要一定的时间来缓冲，请您耐心等待

3.A/B测试视频专区

3.1创建A/B测试

3.1.1Web/H5

  1. Web/H5应用创建演示
Testin云测平台上将A/B测试实验分为了三个层次：应用-实验-版本。其中，应用的作用，便是“实验的集合”。每个应用下可以包含多个A/B测试实验，每个A/B测试实验中又可以有多个实验版本，从而实现方便快捷的代码集成、实验管理。

  1. Web/H5编程实验创建演示
编程模式支持对所有控件的修改。需要先在页面上集成SDK并写好两个版本的逻辑，比如变量=a显示原始版本，=b显示新版本。开始实验后，SDK会向平台请求到一个变量值（a或b），然后页面就会根据变量显示相应版本了。

  1. Web/H5可视化实验创建演示
可视化模式，允许您直接在Testin云测平台上，0代码修改实验页面的控件属性。当实验开始后，系统会通过SDK，把这种界面编辑操作转化为动态脚本，并展示给用户。

  1. Web/H5多链接实验创建演示
多链接合并模式允许对不同url直接进行实验。准备好多个集成了SDK的页面，然后利用平台将这些页面的URL合成一个合并链接。当用户访问合并链接时，就会跳转相应版本，从而实现A/B测试。

3.1.2Android

  1. Android应用创建演示
Testin云测平台上将A/B测试实验分为了三个层次：应用-实验-版本。其中，应用的作用，便是“实验的集合”。每个应用下可以包含多个A/B测试实验，每个A/B测试实验中又可以有多个实验版本，从而实现方便快捷的代码集成、实验管理。


  1. Android编程实验创建演示
编程模式支持对所有控件的修改。需要先在APP中集成SDK并写好两个版本的逻辑，比如变量=a显示原始版本，=b显示新版本。开始实验后，SDK会向平台请求到一个变量值（a或b），然后APP的实验页面就会根据变量显示相应版本了。


3.1.3iOS

  1. iOS应用创建演示
Testin云测平台上将A/B测试实验分为了三个层次：应用-实验-版本。其中，应用的作用，便是“实验的集合”。每个应用下可以包含多个A/B测试实验，每个A/B测试实验中又可以有多个实验版本，从而实现方便快捷的代码集成、实验管理。

  1. iOS编程实验创建演示
编程模式支持对所有控件的修改。需要先在APP中集成SDK并写好两个版本的逻辑，比如变量=a显示原始版本，=b显示新版本。开始实验后，SDK会向平台请求到一个变量值（a或b），然后APP的实验页面就会根据变量显示相应版本了。


3.1.4小程序

  1. 小程序应用创建演示
Testin云测平台上将A/B测试实验分为了三个层次：应用-实验-版本。其中，应用的作用，便是“实验的集合”。每个应用下可以包含多个A/B测试实验，每个A/B测试实验中又可以有多个实验版本，从而实现方便快捷的代码集成、实验管理。

  1. 小程序编程实验创建演示
编程模式支持对所有控件的修改。需要先在小程序中集成SDK并写好两个版本的逻辑，比如变量=a显示原始版本，=b显示新版本。开始实验后，SDK会向平台请求到一个变量值（a或b），然后小程序的实验页面就会根据变量显示相应版本了。

  1. 小程序编程实验创建演示
编程模式支持对所有控件的修改。需要先在小程序中集成SDK并写好两个版本的逻辑，比如变量=a显示原始版本，=b显示新版本。开始实验后，SDK会向平台请求到一个变量值（a或b），然后小程序的实验页面就会根据变量显示相应版本了。

3.2集成代码

3.2.1Web/H5

  1. Web/H5编程模式集成
请注意，此处我们以4.2.2版本的SDK集成为例进行演示。而在您实际使用SDK的过程中，请前往Web/H5 SDK集成文档，集成最新的SDK。
集成相关的文字说明、API信息等，均可在帮助文档中找到。

  1. Web/H5可视化模式集成
请注意，此处我们以4.2.2版本的SDK集成为例进行演示。而在您实际使用SDK的过程中，请前往Web/H5 SDK集成文档，集成最新的SDK。
集成相关的文字说明、API信息等，均可在帮助文档中找到。

  1. Web/H5多链接模式集成
请注意，此处我们以4.2.2版本的SDK集成为例进行演示。而在您实际使用SDK的过程中，请前往Web/H5 SDK集成文档，集成最新的SDK。
集成相关的文字说明、API信息等，均可在帮助文档中找到。

3.2.2Android

  1. Android编程模式集成
请注意，此处我们以4.2.6版本的SDK集成为例进行演示。而在您实际使用SDK的过程中，请前往Android SDK集成文档，集成最新的SDK。
集成相关的文字说明、API信息等，均可在帮助文档中找到。

  1. Android可视化模式集成
请注意，此处我们以4.2.6版本的SDK集成为例进行演示。而在您实际使用SDK的过程中，请前往Android SDK集成文档，集成最新的SDK。
集成相关的文字说明、API信息等，均可在帮助文档中找到。

3.2.3iOS

  1. iOS编程模式集成
请注意，此处我们以5.1.4版本的SDK集成为例进行演示。而在您实际使用SDK的过程中，请前往iOS SDK 4.1.2 及之后版本集成文档，集成最新的SDK
集成相关的文字说明、API信息等，均可在帮助文档中找到。

  1. iOS可视化模式集成
请注意，此处我们以5.1.4版本的SDK集成为例进行演示。而在您实际使用SDK的过程中，请前往iOS SDK 4.1.2 及之后版本集成文档，集成最新的SDK
集成相关的文字说明、API信息等，均可在帮助文档中找到。

3.2.4小程序

  1. 小程序编程模式集成
请注意，此处我们以3.1.1版本的SDK集成为例进行演示。而在您实际使用SDK的过程中，请前往微信小程序SDK集成文档，集成最新的SDK。
集成相关的文字说明、API信息等，均可在帮助文档中找到。

3.3特殊功能讲解

  1. 流量层的概念
流量层能满足并行不同业务或不同场景的需求，提高流量利用率。它使得大量实验能共享同一批样本，而不用互相争夺。换个角度来说，就是允许一个样本在同一时间段，反复进入不同实验。
由此可以衍生出同层互斥和分层分流：分层分流即上文所说，不同实验位于不同流量层，样本共享；同层互斥则是将多个实验置于同一层中，样本相互独立、不共享。
​