abtest框架(ABtest案例)

选择个人档案计划就像找女朋友一样。经过初步的分析和了解，比如你选择了两个条件：长相和学历。这时候两个对象都差不多，你选择了一个容易(简单)的对象去追求(实现计划)。事后发现脾气大(踩坑)，长得差不多的时候其实差很多。这时候再回头看就尴尬了。这就是为什么看了这么多理由(方案设计)，我还是命不好(系统实现有缺陷)。
abtest系统的边界就是简单的用户导流。根据uid等。它只是简单的比较了AB方案A/B和灰度释放。你没看错，而且是混着放的。绿色部署，A/B测试，任意维度A/B的灰度发布，如地域、性别、新老用户等。首先，我们来看一个完整的案例。沪江abtest平台实践的主要内容如下(内容很零碎，用来反映设计一个ABTest需要考虑的问题):实验的两个要素：
流动。其实就是选择器，如何拆分参数。其实就是bucket/action，导流后的动作流模型的几个基本概念。
域，一个流量的划分，比如日本用户层，独立的流量划分，不同实验层之间独立实验，互不影响。实验，如上所述，不同的终端使用不同的用户标识id进行哈希和分流。
通过在web端使用cookieIdapp和在设备端使用openID作为applet的唯一标识符，有两种方法可以实现正交性：
在进行具体的流量划分时，为了实现实验层之间流量划分的正交性，将使用流量标识信息和实验层标识对实验流量进行桶划分，实验层标识盐称为离散因子。Bucket ID=hash (uid，salt)% 100学习ABTest和Gray Level Release对于不同的测试，最好使用独立且不同的哈希函数来保持正交性提示。
为了方便内部测试，我们还实现了白名单功能，在这个功能中，操作或产品可以在后台配置一个用户来点击特定的实验参数。在实际线路上运行ab测试时，我们经常需要针对某个实验参数来扩大或收缩流量。ABC变更前，桶区间0-7980-8990-99扩展了10%的C。0-7475-7980-99变更后，A、B、C覆盖的用户群体实际上发生了变化。其实更好的伸缩方案是：B的流量不变，C的流量从A切换到10%，这样可以最大限度的减少用户参与实验的变化。实验平台架构
实验管理，允许用户配置实验和管理流量管理，为实验参数分配流量数据，收集数据，客户端上报数据，最后分析BI部门Hadoop集群的数据，分析上报数据，计算置信区间等。最后以报告的形式展现出来。你可以从中猜测。
上海河的实验管理和流量管理是分开的。这个实验更多的是参数的集合。作为流量划分和报表生成单元存在于沪江的abtest，不标记客户端，整个过程大致由服务器完成。理论层面蓝绿调配，A/B测试，灰度发布。
A/B测试的目的是通过科学的实验设计、样本代表性、流量分段和小流量测试，得出具有代表性的实验结论，并确保该结论推广到所有流量时是可靠的；绿色部署的目的是安全稳定地发布新版本的应用程序，并在必要时回滚。精确交通分布控制与监控系统的支持，柔性发布系统AB测试和灰度发布平台架构的设计与实践
Twitter的文章偏于理论层面：
Twitter的A/B测试实践(1):为什么要测试以及测试的意义？大部分实验只能带来个位数百分比的提升，甚至是分数百分比。很多时候，不尽如人意的A/B测试结果，让我们能够及早发现，看起来不错的东西，其实未必那么好。因此，我们宁愿尽快得到坏消息。有些功能不适合A/B，比如A版用户想给B版用户留言，而B版用户没有这个功能。Twitter的A/B测试实践(二):技术概述应该跟踪哪些指标？它可以在实验配置过程中创建，也可以从其他现有的索引库中选择。Twitter的A/B测试实践(三):检测和避免A/B测试中的铲斗不平衡；Twitter的A/B测试实践(四):A/B测试中使用多个控件的启蒙有效机制技术；干货——AB测试和灰度释放；探索和实践的要点如下
立即生效，热启动生效，热启动生效意味着退出界面，冷启动再次生效，冷启动生效意味着杀死进程，然后重新进入进程。分流在客户端完成：客户端有完整的ab数据，根据设备信息选择AB方案的动作。比如在服务器端通过访问不同的URL来完成：服务器端根据同一URL的AB配置返回不同的数据。比如沪江方案的分流，要保证同一个用户不同时段的返还方案的稳定性。
abtest关闭后可以轻松关闭吗？AB的最终目的是产生一个结论。如何向所有客户广泛宣传这个结论(通常不现实)？这是否意味着abtest在一个客户端版本周期内无法关闭，最多将某个方案的用户数设置为100%？
新浪新闻客户端在工程中的实践：AB测试与灰度发布的探索与实践
适用场景是面向客户端，一般涉及ui变化，一般涉及客户端发布和面向服务器，没有ui变化。数据接口返回值的模式保持不变，但数据算法或来源发生了变化。比如一个专辑列表，返回所有的专辑数据，但可能来自用户的订阅、推荐、收听历史等。阿里巴巴的文章还是面向浏览器的A/B测试：基本概念A/B测试：实现方法。
整个设计是基于配置中心的(一切都是配置的)，ab的不同响应是基于配置中心的不同配置值。客户端非感知客户端有专门的abtest sdk服务器，只分发ab数据，客户端根据ab数据选择动作服务器直接告诉客户端策略(选择A还是B)。所以客户端在请求的时候需要携带设备本身的很多信息。代码实现如何表示一个abtest页面，数据存储如何表示一个abtest系统代码，哪些独立运行的进程，abtest的参与者是谁，他们会做什么样的操作系统。在操作系统的结构上，访问层和存储层是如何起作用的。对于服务器端，接口ihello服务{ void hello()；}，实现类除了hello方法之外还提供helloA和helloB实现。运行时，拦截hello方法的执行，根据abtest策略，基于配置中心选择helloA/helloB执行客户端来做，配置值相同，对应A/B用户的值不同。客户端保留两个子代码，abtest客户端sdk根据本机的设备信息和下发的abtest数据选择执行。阿里巴巴的A/B测试：实现方法，据推测，新浪新闻客户端应该也是这个方案。统计数据在后台相关。ab系统在后台记录打点日志，内容类似于谁得到方案A/B的响应，然后关联相关数据。该死的，给设备贴标签比如，如果我根据某个打点请求评估效果，那么假设打点请求总数为100，40个贴A标签，60个贴B标签，说明B方案不错。tag有两个来源(有些地方也叫bucketId):客户端本地保存用户画像数据，服务器返回ab规则，客户端根据AB规则画像数据做出决定(是用A还是B)，然后生成一个tag。服务器决定客户端应该使用A还是B，除了返回A或者B策略数据，还返回标签客户端发送行为日志，由AB补充2018 . 10 . 22。有一次和产品聊天，觉得他的想法挺好的。我曾经想，我做了一个abtest，然后有一个报道直接说了这个abtest的情况。后来他说，其实应该先有数据报表基础设施，再有abtest。abtest中的A B只是在原有的数据分析上增加了一个维度。例如，您最初有一份请求的点击率报告。有了AB之后，就有了一个额外的分析维度。并不是你坚持要给ab打报告。Abtest非常依赖整个公司的基础设施。如果连数据可视化都做不到，那就更无法进行效果对比，也很难让人相信ab系统可以做到。关于字节跳动的七年，张一鸣讲了五个故事：同理心是基础，想象力是天空，逻辑和工具在中间。我感觉这句话解决了如何判断产品发展方向的问题。
以数据为中心，哪个数据好用，哪个方案有一套思路，打算创造哪个价值，然后以用户最能接受的方式落地。我印象最深的是Tik Tok也是如此。想象一下，全屏视频让手机成为一个窗口，通过它你可以看到一个丰富的世界。Tik Tok是这个多彩世界的投影，感觉很奇妙。如果没有想象力，可能只会做一个对口型的流行应用或者搞笑的视频软件，而Tik Tok也不可能从一个很酷的音乐舞蹈小众软件进化成一个包含美景、戏曲艺术、感人故事、日常消费的流行平台。不要靠想象和移情，不要靠ab。而怎么做可以用ab来解决细节。AB测试只是一个工具，并不能衡量用户的需求。同理心是重要的基础。如果没有同理心，做出来的产品一定没有灵魂，满足不了用户的需求。但是仅仅感同身受是不够的。它只能制造有用的产品。想象力对于制作色彩丰富的产品非常重要。很多时候，ab只是帮助我们理解用户，而不是帮助我们做决策。
如何扩大客户端abtest的应用范围客户端abtest通常会涉及到ui的变化。对于AB用户，通常有以下要求
一个按钮/选项卡的副本和颜色是不一样的，所以这个信息可以作为配置，配置中心负责界面的配置。跳转行为完全不同，跳转系统一般负责屏幕的不同内容。一般是统一弹屏系统负责。可以看出，abtest的应用不仅仅是abtest本身，还会与其他系统进行交互。组态中心、导弹屏幕系统等客户端实现方案。一般如下
一般来说，由于业务系统数据会以一定的数据格式存储在客户端，这时，我们可以改变业务数据的访问逻辑。首先，我们可以去abtest查看某个具体数据中是否有abtest(持有同一格式的业务数据份额)。如果有，我们可以直接返回abtest的数据，否则我们可以访问原始的业务数据。
这样就可以把abtest和客户端的各种业务系统关联起来，实现不同的人有不同的ui，玩不同的屏幕，甚至运行不同的代码。
总结从现在来看，其实设计abtest系统最重要的是定义abtest系统的边界：是单纯的流量分割还是灰度分布，是单纯的面向客户端还是面向服务器，是新开发的还是依赖于配置中心等组件。清晰的边界非常重要。精炼理论
abtest包括哪些内容？调车斗/动作调车的要点是什么？在客户端或者服务器端做bucket有什么要点，在客户端或者服务器端做？