教你如何对产品做AB测试（abtest）

ABtest一个总的目的和意图是，判断哪种种UI或rerank策略更优，通过事实的依据（ CTR或下单率）判断哪种策略更符合用户的习惯和需求。

一、需求驱使 

我们经常会面临多个设计方案的选择，比如app或pc端某个界面的某个按钮是用红色还是用蓝色，是放左边还是放右边。传统的解决方法通常是集体讨论表决，或者由某位专

家或领导或文青来拍板，实在决定不了时也有随机选一个上线的。虽然传统解决办法多数情况下也是有效的，但A/B 测试（A/B Testing）可能是解决这类问题的一个更好的方法。

所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符

合设计目标。

下面看一个例子：

在展示“格林秀上午酒店”这个poi时有客户端两种UI：

方案A：如左图，评分展示星状图片，消费人数再右边； 

方案B：如右图，只展示评分分数，后边添加消费人数；

       我们很难知道那种方案比较好，那我们可以做个实验，把a和B方案同时放到线上的生产环境，让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用报表如下图，通过大自然的优胜劣汰法则，我们可以通过CTR或下单率等指标看哪个方案更符合设计目标。

二、系统模型

abtest实验可以分成两种，客户端client实验和服务端server实验，客户端实验一般来说只是UI上的实验，比如上面的例子，纯粹是展示端的策略；而服务端的实验是返回给client数据的内容做实验，比如推荐的策略，订单列表rerank策略等。下面通过client和服务端的实验分别做介绍。

（1）客户端实验：

方案1:

ABTest业务流程描述：

（1）客户端在需要获取ABTest策略的地方，通过RPC接口获取uuid在ABTest1这个实验下的规则：

{
    "data": [
        {
            "name": "test1",//实验key
            "strategy": "strategy1",      //策略key，客户端根据策略key选择策略方案
            "flow": "flow1",      //流量组，用于上报。每个流量组只属于一个策略。
            "finished": false     //标识实验是否终止，如果已经终止，则不再向utm_compaign参数的F字段append该规则，但是不影响规则，原规则依然生效。
        }
    ]
}