携程机票的ABTest实践

携程ABTest伴随UBT(User Behavior Tracking System)系统一块儿，两年多的时间，从最初online寥寥几个实验，到如今单是机票BU每周就有数十个app/online/h5平台同时线上运行。

在14年-16年James领导下的技术驱动的大携程体系，对于项目上线的收益、年终KPI考核、CEO奖项的评比都须要拿ABTest数听说话（听说James对数据特别敏感，曾经在2016年某hackathon决赛中，未上线前一team在台上大谈项目收益，James立即打断说"大家的项目上AB了吗？没上的话不要讲了"，该team被当场淘汰） 。

携程市值不断增加的背后，是无数个ABTest的支持，而携程机票大部分的ABTest都放到前台来配置，有幸在2016年经历N多大项目的上线ABT过程，本文将以此为背景来讲明携程机票对于ABTest的应用。（ABTest在携程被简称为ABT）

1、ABTest的定义

ABTest自己实际上是物理学的"控制变量法"，经过只改变一个因素来肯定其变化对CR(conversion rate)或者收益的影响。其自己具有统计意义，并且具有实际意义。

试想一下若是没有ABTest，那新项目上线后的收益如何排除季节因素、市场环境因素的影响，并且一个页面上若是同时作多处改动，如何评判是哪一个改动形成的收益或损失？这对一个理性思惟的人是不可接受的。

简单理解为将一群人分红两类，经过展现新旧版version A/B来测试哪一种版本效果好，差别是多少。

2、ABTest流程

ABTest数据流：APP启动时，公共框架会拉取全部线上ABTest的试验号和对应版本（全部BU）存入本地，当用户进入机票频道时候，在特定场景触发本地实验号调用。好比往返实验，在用户首页点击往返搜索时，开发会从本地文件中查询160519_fld_round试验号该用户的对应版本，肯定跳转新/旧版页面。在试验号接收到调用时，同时触发一个ABTest的trace埋点o_abtest_expresult，该埋点会记录clientcode，sid，pvid，试验号及版本信息，最终通过ETL，BI会汇总一张AB实验表，将上述信息汇总，便于后续作关联计算。

分流计算：每一个设备在刚启动的时候会根据设备号+试验号+随机数组成一串N位数，对100取模的余数从0-99，假设ABCD四个版本流量 10:70:10:10的状况下，则余数0-9为A版、10-79为B版、80-89为C版、90-99为D版。A版为默认版，若是尾数异常（Null或溢出），则走A版。

AB版本：若是仅有新旧两个版本的状况下，通常会设置ABCD四个版本，（其中ACD为旧版，B为新版；若是有多个迭代新版，则从EFG开始）来进行AA测试和AB测试。

一、AA测试：CD版同为旧版，且流量各为B版一半，在流量随机分配的状况，经过对比CD版的数据表现来验证旧版的状态是稳定的。A版做为旧版，也称为兜底版本，BCD的剩余流量走A版，版本异常的状况下走A版。

二、AB测试：在确保CD数据相对稳定的前提下，再对比B和ACD版本的数据，来对比新旧版的差别。

实验正交性：

一、非正交实验：如左图展现，在旧版的基础上再作区分，会由于样本数量的问题而限制同时进行的实验个数，并且没法评估两个新版同时存在的影响。

二、正交试验：右图展现，不一样实验流量彻底打散随机分配，上一个实验与下一个实验理论上流量上没有关联，这样能够在一个页面同时进行多项实验。
这里再提一个Magic Number = 7，虽然理论上单页面上同时进行的正交试验数量没有上线，可是通过长期经验积累，单页面同时线上实验不要超过7，不然会形成难以捉摸的幺蛾子异常。

埋点下线机制：

像ABTest里面的埋点触发场景埋点仍是由开发控制的，也仍是会存在埋点不许确的状况，好比说往返的实验，触发场景是在首页点击往返搜索，理论上去程列表页的UV应该是参与式样的样本数抑制。实际状况是，去程列表页30W的UV，但ABT的报表显示天天样本为50W，通过SQL验算二者交集为20W,就说明有10W人是在往返流程但并无参与实验（数据通过脱敏处理，但不改变相对位置）。

因此基于这样的幺蛾子，在ABT结束后，既要删除代码，又要实验流量全开100%

一、流量调整100%目的：将历史版本的客户端旧版规避，须要操做100%流量。

二、下线代码：保证app的size不会过分冗余，同时因埋点场景的问题，有些时候虽然流量全切100%，但仍有部分流量走旧版（很是诡异），因此将客户端代码下掉是很是必要。

其余说明：

一、在任何状况下，分析的基础条件就是流量随机分配，若是质疑这件事情，则整个ABTest就失去意义.

二、实验分流通常采用设备号clientcode,可是也能够根据uid来，但状况较少

三、对于实验的显著性指标P值通常使用较少且不易理解，就不作过多解释（一年也没怎么用这个指标）

四、分流调节机制，新版流量不要忽上忽下，特别是涉及到核心页面的时候，不然可能会形成用户看到的页面反复变化，增长适应时间和学习成本以及影响用户体验。

3、分析数据

ABT的目的：ABTest是但愿经过如何改进新版优于旧版，而不是经过ABTest证实新版弱于旧版而下线实验，因此须要有效的分析数据。

如何看图表：

图表反映时间趋势，在ABTest中表现为新旧版本两条折线图，且通常会出现交叉的状况，那咱们就须要判断这些交叉是有随机性波动仍是实验的效果，我在实践中总结简单易用的一条原则是：“抓大放小”。

抓大放小（个别表现不影响总体趋势）：当你遮住有限个点的时候，不影响总体的差别。好比下图，当你遮住2-11和2-13两天的数据时，会发现蓝色B版优于红色旧版。（固然遮住点的数量因人而异，通常不超过总量10%）

这张图就很难用抓大放小的方式来判断差别，没法证实是新版好仍是旧版好，这时候须要分解这个指标来继续分析。

机票的核心指标是转化率CR(conversion rate)和收益(revenue)，一般他们之间的关系以下图所示。

携程机票前台以scrum team的形式迭代，每一个team对于需求的评审是以ROI（投入产出比，return on investment）来决定项目的优先级，而return多是CR的提高，也多是单票收入的提高。

对于上线实验数据跟踪，也是以当初ROI的预期来进行判断实验效果，尤为在没有达到预期的状况下，寻求解决方案。（这其中还有诸多限制条件，好比收益类项目，若是CR有明显降低须要重点关注。）

分析思路

这个分解公示也表明分析的思路，不管对于收益类项目仍是CR类项目，都会先看单UV收入和CR（通常状况下，ABTest不会改变每一个订单的票量，这是基于总体订单估算的平均值，咱们暂且认为TA是常量），当这两项都保持正向增加的状况下，那能够直接开大流量继续验证直至项目完美收官（这种案例比较少）。更多的状况是，对于重大项目，即便结果是积极正向的实验，咱们也会大概了解下改进点发生在哪一个页面或者哪一个产品，作到心中有数

而当发生问题的时候，咱们都会对CR和单票收入作分解：

1、CR降低的状况，看主流程每一个页面的CR，是哪一个页面降低，从页面的来源去向和点击来看，是否有明显的异常，通常来说，对业务足够熟悉的PM在这一步能够结合业务和这些数据大概会有一些预判，是哪些因素可能形成的影响，以后再请教BI专业人员或者本身拉SQL来验证数据，从而进行改进。

2、利润降低的缘由，继续分解指标，能够分产品、航司、利润构成等指标来分解，找到新旧版的gap，而后结合业务场景作一些预判，进行找数据来支持这个想法，继续迭代新版。

以前的状态是PM对于AB实验的数据有一大坨报表，可是并不知道如何使用，也不知道怎么看报表，不知道怎么分解指标，但其实对于总体进行了解以后，具有简单的分析能力，关键是有业务背景知识的状况下，这样的几个公式的八股文的分析能够解决80%的问题，对于实在没法定位的问题，能够找BI寻求帮助。

4、总结

ABTest其实核心在于如何定位问题解决问题，可是限于身份不能经过数据来进行举例说明。但其实分析思路应该是一致，好比机票场景下指标分解的核心公式来解决80%的问题，在每一个行业应该都会有这样的公式，能够根据特定业务背景本身总结运用。

PM如可以掌握这些基本的指标分析、可以看懂图表、这里面就可以自助解决80%的问题，这样的ABTest效率其实已是很是高的。