推荐系统入门#

产品经理的工作职责#

背景#

假设，你正在一家电商公司工作，部门领导让你牵头做一个推荐系统，它会应用在你们公司App“猜你喜欢”的页面中。

当你拿到任务的第一时间，应该是明确推荐系统的整体架构与职责分工，这其实和大多数的产品设计初期并无二致。

作为推荐系统的产品经理，当然不需要像算法工程师一样死磕算法模型，也不需要像研发工程师一样专注代码开发，那我们的工作职责到底是什么呢？

召回阶段#

!!!tip

召回：推荐系统根据算法帮你初步筛选出你可能喜欢的商品的过程，叫做推荐系统的召回，你也可以把召回简单理解为商品的粗筛过程。

!!!

在召回阶段，产品经理要对召回策略进行评估。实际工作中不需要产品经理设计召回策略，但你要了解常用召回策略的优缺点，以便根据实际场景做出合理的选择。

我们知道，召回就是对商品进行初步筛选，过滤出用户可能感兴趣的商品列表。之所以说“可能”是因为在召回这一步，为了提高覆盖率，我们通常会使用多个算法进行召回。在这些召回算法中，产品经理需要了解的召回算法有基于用户行为的协同过滤召回算法和基于内容标签的召回算法。

基于用户行为的协同过滤召回算法#

!!!tip

协同过滤的基本思想很简单，就是基于用户对商品的偏好找到和用户最相近的一批人，然后把这批人喜欢的商品推荐给当前用户。

!!!tip

比如说，现在有三个用户，分别是用户 A、用户 B 和用户 C，以及四个商品，分别是商品 A、商品 B、商品 C 和商品 D。我们对三个用户的行为进行分析，发现用户A喜欢商品 A 和 C，用户 B 喜欢商品 B，用户 C 喜欢商品 A、C 和 D，我们把这些信息整理到一个表格中。

通过这个表格，我们能很直观地看到，用户 A 和用户 C 都喜欢商品 A 和商品 C。由此，我们可以猜测用户 A 和用户 C 的兴趣偏好可能相同。这个时候，我们就可以把商品 D 推荐给用户A。

!!!tip

协同过滤策略的基本原理，在算法的实现上就是将用户对商品的操作行为，如浏览、收藏、加购和下单，变成向量形式的数学表达方式，然后通过相似度算法，常见地有通过余弦相似度算法计算这些行为的相似度，最后得出一个相似度分数的排序。这样，就能找到和你行为最相近的其他用户，并过滤出他们喜欢而你没有接触过的商品。

!!!

通过相似度计算，我们可以得到和某个用户最相似的其他用户的一个列表。

举一反三，我们就能得出和某个商品最相似的一个商品列表。

协同过滤算法需要有用户行为数据作为基础，才能根据行为计算用户之间的相似度以及商品之间的相似度，在系统冷启动阶段很难实施，所以在冷启动阶段，我们还需要考虑其他的召回策略，比如我接下来要说的基于内容标签的召回策略。

基于内容标签的召回策略#

!!!tip

基于内容标签的召回算法（Content-based Recommendations，CB）是最早被使用的召回算法，在现在的工业界中仍然被广泛使用，因为它的效果很好。

它的基本思想就是给用户和商品分别打标签，然后召回同类标签的商品，最终把它们推荐给用户。

!!!

比如说，现在有两个用户，分别是用户 A 和用户 B，还有四部电影，分别是《钢铁侠》《蜘蛛侠》《蝙蝠侠》和《神奇女侠》。我们给每部电影打上标签，《钢铁侠》是“科幻片”和“漫威”，《蜘蛛侠》是“科幻”和“漫威”，《蝙蝠侠》是“科幻片”和“DC”，《神奇女侠》是“科幻片”和“DC”。

为了方便你理解，我简化了标签的数量，在实际工作中，我们可能会给每一个电影打上几十甚至是几百个标签。

给电影打完标签之后，我们还要给每一个用户打上兴趣偏好标签，如用户 A 刚看完《钢铁侠》，就给用户 A 打上“科幻片”和“漫威”的标签，用户 B 看过《蝙蝠侠》，就给用户 B 打上“科幻片”和“DC”的标签，我们把这些信息都整理到了下面的表格中，你可以看看。

通过这个表格，我们能很直观地看到，用户 A的偏好标签为“科幻片”“漫威”，正好和《钢铁侠》《蜘蛛侠》的标签相同。很显然，我们应该把《蜘蛛侠》推荐给用户 A，再把《神奇女侠》推荐给用户 B。

这就是内容标签召回算法的基本原理，具体的算法实现就是将用户的偏好标签和电影的标签，变成向量形式的数学表达方式，然后通过相似度算法，常见地会通过余弦相似度算法，去计算这些行为的相似度，最后得出一个相似度分数的排序。这样，我们就能找到和用户偏好最相似的TopN部电影了。

优缺点#

排序阶段#

在推荐系统的排序环节中，产品经理要以目标为导向来确定排序的目标。如果产品是以提高 CTR 为目标，那么推荐系统可以使用 **CTR（Click-Through Rate，点击率）**预估的方式来构建排序模型，根据用户历史的浏览记录，来预测用户的点击行为。

但在电商场景中，还存在 CVR、GMV、UV 等多个核心指标，所以产品规则并不是一个指标所能决定的，要根据业务目标来优化排序模型。也就是说，如果公司追求的是 GMV，那么单纯地提升 CTR ，在一定程度上只能代表着用户体验的提升。

当然，你可以把这些指标的诉求抛给算法工程师，让算法同学给出 CTR 或 CVR 预估的方案。这个时候，你需要关注的就是如何评估算法同学交付的算法模型的性能和稳定性。

由于冷启动阶段用户个性化和行为化特征过少，如果我们把评估的重心定位在“针对用户的精准化预测”就是不合理的。这个时候，你可以让算法工程师给出冷启动阶段的排序模型，如果没有更优的方案，你也可以给出一套打分策略来进行商品列表的排序融合，这也是面向策略的产品经理必须要具备的能力。

我们使用了3种召回策略，分别得到了3个商品列表，以及每个商品所在列表中的评分。

有3种排序策略可以供我们参考，它们分别是加权平均法、CTR 动态加权平均法和CTR 预估加权平均法。

加权平均法#

加权平均法是统计领域内常用来综合指标的基本方法，它的计算方法最简单。以商品A为例，我们根据专家经验，预先定义三种召回策略的权重：0.4、0.3、0.2，然后结合上面的评分列表，让商品的权重分别乘上每一种策略的权重，再除以策略权重之和，就能得到商品的评分。那么，商品A的评分就是：(\left(0.9^{\star} 0.4+0^{\star} 0.3+0^{\star} 0.2\right) /(0.4+0.3+0.2)=0.4)。同理，我们能够得到其他商品的评分，按照字母顺序分别是0.62、0.66、0.29、0.09。

最终，根据分数排序，我们可以得到：C>B>A>D>E。这种排序策略的特点简单明确，每种排序策略可以根据业务规则预设权重。

CTR 动态加权平均法#

使用这种方法，我们需要每天离线计算三种召回策略的 CTR，把它们作为每天更新的动态权重，最终根据动态的权重做加权平均。CTR 动态加权平均法可以看成是加权平均法的一种改进，每种召回策略的 CTR =每种召回源的点击数 / 每种召回源的展现数。

CTR 预估加权平均法#

通过 CTR 预估三种召回策略的权重，然后做加权平均。因为需要用到前两种方法，所以它的实现方法是最复杂的。

作为一个完整的推荐系统，它还要包括最后的调整的步骤，产品经理要与业务和运营人员充分沟通，以及结合实际的业务场景，把如广告商品、流量坑位、特殊扶持等相关的运营策略结合到推荐系统中。

因此，产品经理还有一个非常重要的工作职责，那就是评估一个推荐系统的好坏。

实战项目#

假设，你是一家电商平台公司的产品经理，公司经过一年多的供应链打造和用户运营的投入，业务已经发展到了一个高速增长的阶段。

但问题也随之暴露了出来：之前产品首页是人工配置选品的，每个用户在浏览 App 的时候，看到的都是千篇一律的商品。这种无法体现用户对于商品兴趣的偏好情况，不但削减了用户的体验，也没法让供应商满意，因为随着接入的供应链多了起来，供应商也希望自己的商品能有更多的曝光。

为了尽快解决这个问题，老板决定让你牵头打造一个个性化电商MVP推荐系统（Minimum Viable Product，最小可行性产品）。已知，推荐系统的建设可以分为 4 个重要的阶段，分别是需求定义、数据准备、技术实现和评价标准。

需求定义#

在需求定义环节，我们最重要的工作就是产出需求文档。具体来说，产品经理需要做的有3件事，分别是交代需求背景、描述交互逻辑，以及明确预期目标。下面，我们一一来说。

构建需求背景#

在需求背景部分，我们要重点交代清楚为什么要建设推荐系统，让协同部门能够理解背景，和我们对齐这个项目的价值。一般来说，我们会和业务方进行频繁沟通，发掘他们最核心的诉求。

那么，今天这个例子中的核心诉求其实就是要展现所有用户对商品的偏好，避免“千人一面”。

描述交互逻辑#

接下来，我们要对推荐系统的交互逻辑进行描述，主要包括描述用户的动线流程、模型诉求和产品功能上的逻辑。

因为我们这次构建的是MVP推荐系统，所以不需要通过算法模型来实现所有的推荐逻辑，而是分成两部分，一部分通过算法进行推荐，另一部分通过运营系统配置进行推荐。

首先，当用户进入商品主页的时候，推荐系统会检查是否已存在当前用户的画像信息。
- 如果存在就获取用户的商品偏好标签，执行商品召回的算法逻辑。
- 如果不存在就把运营系统配置的商品数据展示给用户。
**然后进入商品召回模块，由于只需要打造一个 MVP 的推荐系统，因此我们只设计一种召回策略就可以了，如“基于协同过滤的召回策略”。**这样，推荐系统就不涉及多路召回融合的问题，在产品需求中也就不用涉及“排序阶段”的需求了。
所以我们直接进入“调整阶段”。
- 这一阶段，推荐系统需要通过规则，将算法召回的商品列表和运营系统配置的商品列表进行融合。
- 常见的运营配置有，商品在第一周上新期内需要在展示列表中置顶等等。
最终，推荐系统会将融合后的商品列表展示给用户。完整的交互逻辑如下，你可以看看。

制定预期目标#

最后就是制定电商推荐系统的预期目标了，这个目标是根据业务的实际情况而设定的。有了目标就要有衡量目标的指标， 虽然大多数推荐系统的衡量指标都是 CTR，但我建议你从业务的建设阶段来设定衡量指标，就像我上节课讲的那样。这里，因为我们的业务发展属于成熟阶段，所以设定的衡量指标为 CVR。

总的来说，产品经理要能够清晰地设计需求，需求定义要明确需求背景、描述交互逻辑，以及制定预期目标，那么如何做才是清晰的设计需求呢？我为你准备了一份推荐系统需求模板，你可以作为参考。

数据准备#

在推荐系统中，如果用户在某个环境下对某个商品做了某种操作，我们就认为这个操作表达了用户对这个商品的兴趣偏好。推荐系统要做的就是挖掘这个偏好，然后给这个用户推荐相同偏好的其他商品。

**这些数据的来源一般包含三类：业务数据、埋点日志和外部数据。**并且每个来源的数据都有着详细的数据分类，这些数据会应用于机器学习的离线预估模型训练和实时模型预估计算。

像是“用户数据”、“商品数据”和“上下文环境数据”本来就是存在于数据库中的，产品经理只需告诉算法同学数据源在哪里即可，后续算法同学会自行抽数。

我们唯一提前要进行收集的就是用户的前端埋点日志，如果系统之前没有做过埋点，那么势必会影响推荐系统的准确性。

!!!warning

在搭建推荐系统之前，我们要通过埋点尽可能地收集用户的前端行为日志。

!!!

我们都需要埋哪些数据，把它们埋在哪些页面呢？这需要产品经理根据自己对业务的理解，整理出一套页面埋点文档，为算法同学提供数据支持。

虽然根据业务的不同，具体的埋点策略会有差别，但我还是根据经验梳理出了一些用户行为与商品信息的数据埋点字段。

首先是用户行为数据埋点字段：

然后是商品信息数据埋点字段：

有了数据之后，算法同学就可以根据数据建立特征工程，然后我们就可以进入到模型构建的环节了。

技术实现#

从项目管控上来看，在推荐系统的项目建设过程中会涉及两波技术团队，分别是算法团队和工程团队，他们是并行进行的。

算法工程师在构建模型的同时，研发工程师也在进行系统功能的开发，最终系统工程与算法模型会通过 API 接口进行通信，这需要双方提前约定好接口协议。

因此作为产品经理，我们除了要关注算法同学的模型构建，同时也要关注推荐系统工程的整体设计。

对于系统工程的整体设计，产品经理要关注推荐系统进行一次完整推荐会涉及哪些系统模块，它们和算法模型是怎么交互的，数据流向什么样，产品的关键逻辑是在哪个模块中实现的。

下面，我们就来看下工程系统和算法模型的数据架构图，图中的箭头都是数据流向，方向是从左往右。

从架构图中，我们可以看到工程系统在进行推荐的时候，先后经过3个模块分别是召回模块、排序模块和调整模块，每个模块都调用了算法模型对应训练好的机器模型提供的服务。

召回模块#

实时召回：(用于用户召回信息计算；秒级)

实时召回模型根据历史的用户行为数据，集合当前用户实时的浏览行为，计算并更新用户召回商品的列表信息。
实时召回的计算是秒级运算，比如你在京东 App 上搜索华为手机后，Feed 流就会推荐给你很多其他品牌手机。

离线召回：（用于用户偏好信息、热度榜单计算；定时脚本；存储到数据库）

每天通过定时脚本触发模型的计算，如全量更新用户的偏好信息，计算热度榜单等等不要求实时性的数据，这些数据会被存储到数据库中。
当工程系统调用某个用户的召回商品列表的时候，推荐系统直接查询数据库就能得到，不需要再计算一遍，从而提高了系统性能。

排序模块#

推荐系统会直接调用模型提供的排序服务。这

里我们需要注意的是，在系统工程中排序服务可以通过规则（如加权平均、CTR 动态加权平均）的方式实现，也可以基于机器学习模型的 CTR 预估方式实现。

调整模块#

调整模块是对排好序的商品列表进行运营策略上的调整，它和业务规则强相关。

最后，推荐系统会把最终的商品列表返回给产品客户端。

!!!tip

在实际情况下，技术同学还需要考虑很多非功能性的需求，比如系统响应时长、系统稳定性等等，但产品经理的重点还是要放在“召回”、“排序”和“调整”上面。

!!!

评价标准#

产品经理可以通过 AB 测试的方式进行评估，推荐系统要想做 AB 测试，有三点我们必须要注意：

!!!tip

第一，推荐系统的工程代码要提前准备两套实现方案，一套千人一面，一套千人千面；
第二，推荐系统要能进行 AB 测试的切量配置，也就是多少流量流向改造前的系统，多少流量流向改造后的系统，当然这个功能要让系统工程研发同学给予支持；
第三，为了查看 AB 测试的效果，对比 CTR、UCTR、转化率等指标，我们要生成最终的效果统计报表。
- 但在 AB 测试切量的时候，我们要注意打上流量标志位，标识是哪种方案。
- 这样在统计报表的时候，我们才能分别计算指标，进而比较推荐系统在原有系统之上做到了多少提升。

!!!

实际的难点在于产品经理对指标的分析过程，以及最终给出的迭代计划，下面我们就来详细讲讲。

因为我们的业务比较成熟，并且业务方的 PKI 是 GMV（Gross Merchandise Volume，成交总额），所以我们选用了 CVR 作为推荐系统的衡量标准。

CVR的计算方式是转化数/点击数，也就是最终点击商品并且购买的转化率，它通常在广告领域用的比较多。

下表就是推荐指标的汇总，我们按照 0~~3、3~~6、6~9 对商品进行了分段。

“传统方式”的 0~3 分的长尾商品没有曝光，这是因为我们之前一味地追求 GMV，所以运营同学对于低评分的长尾商品不做展示，把所有资源都倾向于头部品牌商的商品，让中小商家在平台上无法生存。因此，从长远的角度来看，一味的追求GMV并不健康。

在对于推荐系统的迭代计划中，产品经理至少还要对不同人群、不同位置设置不同的评价指标，最后再综合所有的评估指标来优化整体数据指标。

整理#

产品经理需要关注的内容可以从三方面概括，分别是能力、技术和岗位。

能力#

能力可以总结为三点：

第一，我们要能够清晰地设计需求：需求定义要明确需求背景、功能描述，以及预期的收益。
第二，我们要能够理解数据：在推荐系统的数据准备阶段，产品经理要关注用户前端的埋点日志，提前设计埋点，以及给研发工程师提需求收集行为日志。
第三，我们要能够对通过 AB 测试来评估推荐系统的效果，然后做出分析再给予持续的迭代计划。

技术#

我们要重点掌握推荐系统中召回和排序模块的策略。

这不仅包括我们这节课说的，工程系统进行一次完整推荐的时候各个系统模块的工作原理、交互逻辑，还有我们上节课讲的常用协同过滤算法和相似度算法的原理。

岗位#

冷启动#

冷启动是指系统（如推荐系统、广告系统、用户增长等）在缺乏足够历史数据时，无法有效个性化推荐或决策的问题。在推荐系统中，冷启动主要分为三类：

类型	定义	例子
用户冷启动	新用户无历史行为数据，难以个性化推荐	OPPO应用商店的新注册用户
物品（内容）冷启动	新上架的商品/内容无曝光或互动数据	应用商店新发布的游戏
系统冷启动	全新平台或业务，无任何用户或内容数据	OPPO新推出的车机推荐系统

用户冷启动：无法准确预测兴趣，可能导致推荐不相关，影响留存率。
物品冷启动：新内容曝光少，难以进入推荐池，导致“马太效应”（热门更热，冷门更冷）。
系统冷启动：完全无数据，需依赖人工规则或外部数据。

解决方案#

总的来说主流冷启动策略可分为以下几类：

基于规则的冷启动#

由于数据缺乏，个性化推荐引擎无法有效工作，自然可以让系统回退到“前推荐系统”时代，采用基于规则的方法。

基于规则的冷启动方法更多依赖的是领域专家对业务的洞察。在制定冷启动规则时，需充分了解公司的业务特点，充分利用已有数据，才能让冷启动规则合理且高效。

丰富冷启动过程中获得的用户和物品特征#

在历史数据特征缺失的情况下，推荐系统仍然可以凭借用户和物品的属性特征完成较粗粒度的推荐。这类属性特征包括以下几类：

1.用户的注册信息

2.第三方DMP（Data Management Platform,数据管理平台）提供的用户信息

3.物品的内容特征（元数据）

4.引导用户输入的冷启动特征

“探索和利用机制”#

探索和利用是在**“探索新数据”和“利用旧数据”之间进行平衡，使系统既能利用旧数据（捞鱼），又能高效地探索冷启动物品是否是优质物品（放鱼苗）。**

这里以最经典的探索与利用方法UCB（Upper Confidence Bound，置信区间上界）为例说明探索与利用的原理。

使用UCB方法计算每个物品的得分的公式如下：

$UCB(j) = \overline{x_{j}} + \sqrt{\frac{2ln\ n}{n_{j}}}$

其中 $x_{j}$ 为观测到的第j个物品的平均回报（这里平均回报可以是点击率、转化率、播放率等）， $n_{j}$ 目前为止向用户曝光第 $j$ 个物品的次数， $n$ 为到目前为止曝光所有物品的次数之和。

通过简单的计算可知，**当物品的平均回报高时，UCB的得分会高；同时，当物品的曝光次数低时，UCB的得分也会高。**也就是说，使用UCB方法进行推荐，推荐系统会倾向于推荐“效果好”或者“冷启动”的物品。

AB试验#

定义#

A/B实验，又称为对照实验或随机实验，是一种在实验设计中常用的方法，用于比较两个或多个样本（通常是A和B）之间的差异。AB测试的目的是评估不同变量对特定指标（转化率）的影响，并确定哪个变量在给定条件下表现更好。

现实业务使用中，我认为AB test就是保证2组或多组根据条件限制划分的用户在只有1个变量条件情况下，对分组用户的各项数据指标进行汇总，对比指标变化涨幅来确定试验好坏，并且伴随数据分析去发现问题，解决问题的一个过程；

在AB测试中，参与者被随机分配到不同的组，每个组展示不同的变量。

统计功效组是对照组，通常是现有产品或设计的标准版本（如A），而其他组是实验组，展示不同产品或设计的其他版本（如B）。

通过在实验组和对照组之间比较特定指标**（如点击率、转化率、用户满意度等）**，可以评估不同版本之间的差异。

应用领域#

互联网#

**内容推荐系统：**流媒体平台可以使用AB实验来优化推荐算法。
- 例如，一个推荐系统可能基于用户的历史观看记录（A组），而另一个则基于社交网络数据（B组）。通过比较两组用户的观看时长和满意度评分，可以确定哪种推荐方法更有效。
**优化店铺网页设计：**在电子商务网站中，AB实验可以测试不同的网页布局、按钮颜色、导航栏设置等。
- 例如，A组使用现有的网页设计，B组使用修改后的版本，通过比较两组用户的购买率和页面停留时间来评估设计改进的有效性。

广告#

优化广告图文效果：AB实验可以用于测试不同广告文案、图像或视频的效果。
- 一个版本的广告可能侧重于折扣信息（A组），而另一个版本则侧重于产品质量（B组）。通过比较两个广告版本的点击率和转化率，营销人员可以找到最能吸引目标受众的广告内容。
**广告播放策略： ** 媒体公司可以测试不同的广告播放频率和时长，A组用户可能看到较少的长广告，而B组看到较多的短广告。
- 通过观察用户的离开率和互动率，可以找出最佳的广告播放策略。

政府#

公共政策研究中，AB实验用于评估不同政策措施的效果。

例如，一组城市可能实施新的交通法规（A组），而另一组城市继续使用旧法规（B组）。通过比较两组城市的交通事故率和市民满意度，可以评估新法规的有效性。

A/B实验流程#

1、分析现状，建立假设：分析业务，确定最高优先级的改进点，作出假设，提出优化建议。

2、设定指标：设置主要指标来衡量版本的优劣；设置辅助指标来评估其他影响。

3、设计与开发：设计优化版本的原型并完成开发。

4、确定测试时长：确定测试进行的时长。

5、确定分流方案：确定每个测试版本的分流比例及其他分流细节。

6、采集并分析数据：收集实验数据，进行有效性和效果判断。

7、给出结论：①确定发布新版本；②调整分流比例继续测试；③优化迭代方案重新开发，回到步骤1。

注意#

1. 测试时长： 测试的时长不宜过短，否则参与试验的用户几乎都是产品的高频用户。

2. 分流（或者说抽样）：应该保证样本的同时性、同质性、唯一性、均匀性。

①同时性： 分流应该是同时的，测试的进行也应该是同时的。

②同质性：也可以说是相似性，是要求分出的用户群，在各维度的特征都相似。

可以基于用户的设备特征（例如手机机型、操作系统版本号、手机语言等）和用户的其他标签（例如性别、年龄、新老用户、会员等级等）进行分群，每一个A/B测试试验都可以选定特定的用户群进行试验。

思考：如何判断是不是真的同质？可以采用AAB测试。抽出两份流量进行A版本的测试，进行AA测试，并分别与B版本进行AB测试。通过考察A1和A2组是否存在显著性差异，就可以确定试验的分流是否同质了。

③唯一性：即要求用户不被重复计入测试。

④均匀性：要求各组流量是均匀的。

Hash算法。现在一般由专用的A/B测试工具负责。也有看到一篇文章写了python实现，大体的思路是对用户id添加Salt值，对其散列，并据此算出一个0-1之间的浮点数，同设定好的阈值比大小，从而分组。

有兴趣的可以看看，该作者的思路很清晰：随机分配里的Why and How。（统计学原理上，我没有找到均匀性这一要求的依据，其实双样本的假设检验并不要求两个样本的数量相等或相近。当然从直观上是可以理解，希望分出的用户组越相近越好，包括人数的相近。）

3. A/B测试只能有两个版本么？

A/B test不是只能A方案和B方案，实际上一个测试可以包含A/B/C/D/E/……多个版本，但是要保证单变量，比如按钮的颜色赤/橙/黄/绿/青/蓝/紫，那么这七个方案是可以做A/B测试的。

但如果某方案在旁边新增了另一个按钮，即便实验结果产生了显著差异，我们也无法判断这种差异的成因究竟是谁。

4. 同一段时间内可以做不同的A/B测试么？

比如一个test抽取总体20%的流量做按钮颜色的实验，另一个test也抽取总体20%的流量做布局样式的实验。是否可行？

我认为是可行的。但要求**多个方案并行测试，同层互斥。**如果从总体里，先后两次随机抽取20%流量，则很有可能会有重叠的用户，既无法满足控制单变量，又影响了用户的使用体验。

同层指的是在同一流量层中创建实验，在此层中创建的实验共享此层中的100%流量。
互斥指的是在此层中，一个设备有且只能分配到此层多个实验中的某一个实验。

AB测试用法#

业务中的生效逻辑#

AB试验，既可以做客户端试验，也可以做服务端试验，下面就根据客户端和推荐服务端和AB试验平台的试验流程来讲一下其中的区别和生效逻辑：

客户端试验（左图），主要是说用户请求推荐时，客户端主动带着用户信息（app版本号、渠道号、新老用户、用户onlyid）去AB试验平台上获取用户的试验配置，试验平台会根据用户的onlyid进行哈希分流（这个下面有讲到）。

然后将用户分进对应的试验组，客户端会把用户的试验信息存在本地，每次用户打开app时会再去拉取一次配置，然后带着用户配置请求推荐接口，推荐会根据用户的试验配置返回对应的推荐列表。

服务端试验（右图），则是将客户端请求试验平台变成了服务端请求试验平台获取用户试验配置，再返回对应的推荐列表。

客户端：不需要再经过服务端获取用户配置就能直接请求AB试验平台，逻辑上相对简单些，但是缺点是客户端依赖版本更新，版本迭代较慢，试验全量起来比较慢，不好控制。
服务端： 需要在逻辑上多加一层去请求AB试验平台获取用户配置，但发版较快且不受客户端版本更新限制，试验全量比较好控制。

业务指标建设#

通常，我们做AB试验的时候，都会根据当下试验新增几个试验指标，当然，所有的试验都会带上大盘指标。根据公司业务和规划的差异，各公司的大盘指标都会存在差异。

业务指标建设的时候，主要会根据这个试验的初衷来设置，比如，我这个试验的目的是想提升点击率，那么，点击率的指标就是我此次试验的核心指标；如果试验是为了提升转化率，那么从开始到结束的每一步转化率指标，就是我们试验的核心指标。

一般都会关注的大盘指标就是留存，留存又分进组留存和活跃留存。

电商类产品多关注点击率、成交率、留存以及GMV等指标。
视频类产品多关注渗透率（完播率）、转化率等。
资讯类产品多关注点击率、转化率、留存等。

并非所有的试验都需要大盘数据增长才是好试验，而一些代码重构，或换系统等试验，多数需要保证大盘指标数据无下降即可。

用户进组设置#

试验平台是怎么将用户分配到某个试验组中的？简单来说就是桶位算法。

可以理解为将用户流量分为了100个桶位（现实中会分成1000个桶位或更多），假设我们要开一个10%流量的试验，需要对用户onlyid进行哈希取余，如果余数落在前10个桶位，用户就命中这10%的流量，否则就不命中实验，用户也就不会进这个实验组。

试验层流量控制#

AB试验可以单层，也可以多层，通常根据产品的用户量来决定是否采取多层试验**，用户量较大，业务较多时，需要做的试验也越多**，就需要通过多层试验模式去进行AB，实现流量最大化利用。

（1）单层试验

单层试验上，流量100%，每个试验的流量是互斥的。举例，试验1的用户，命中试验1，就不会再进同一个试验层上的试验2或试验3，在单层试验上，用户只能进一个试验的一个组，即便是对照组流量，也是如此。

每个试验的流量至少会分成2组，也有多组试验，有试验组和对照组，每个试验中的各试验组的流量分配可以均匀分配，也可以自定义分配。

（2）多试验层——分层流量

多层试验，可以理解是多个单层试验的组合，每个试验层就是上面说的单层试验，而试验层与试验层之间的流量是正交的，也就是说，在召回层的试验1和试验2的2个用户，在召回层是互斥的，但在粗排层，很有可能在一个试验中，而在其他层，可能又会中其他的试验，业务越复杂，试验层越多。

当两个试验处于不同层时，需要保证试验内容互不相关，也就是相同的试验配置需要开在一个单层试验层上互斥，否则将会干扰试验数据。通常，用户量大一些的公司，都会采取多试验层，这样试验流量也多，且各试验之间互不干扰。

AB test数据控制#

原理-假设检验#

1.给出零假设和备择假设：

零假设和备择假设是参数空间的真子集，且不能相交。

常把没有把握不能轻易肯定的命题作为备择假设 H1 ，而把没有充分理由不能轻易否定的命题作为零假设 H0 。

或者说我们将希望通过实验结果推翻的假设记为零假设H0 。

2.根据备择假设确定检验方向：

备择假设含≠则为双尾；含<或>则为单尾，含<为左尾，含>为右尾。

3.判断抽样分布类型：

主要判断抽样分布是否近似正态分布

4.确定检验类型及检验统计量：

在判断用什么检验的时候，首要考虑的条件是样本量，其次是总体服从的分布。

样本容量大时（统计学上一般认为n≥30），总体的均值和标准差未知，不要求总体近似服从正态分布。根据中心极限定理，样本容量大，则样本均值的抽样分布服从正态分布，总体标准差可以用样本标准差来估计，可用Z检验；
当样本容量小于30，且满足总体近似服从正态分布时，如果总体标准差已知，可用Z检验；
当样本容量小于30，且满足总体近似服从正态分布时，如果总体标准差未知，可以用样本标准差去估计总体标准差，由此可用T检验；
当样本容量小于30，且不满足总体近似服从正态分布，不能用Z检验和T检验。

简单地说其实就是，总体标准差怎么估计的问题。检验类型确定了，检验统计量也就确定了。

（不过现在的很多软件简化了上述步骤，改为，若总体标准差已知（无论样本大小）都用Z检验；若总体标准差未知，都用T检验。不过当样本量够大的时候，T分布也近似于Z分布了，所以最后的结果不会差很多。T分布其实是小样本的Z分布。一个样本的自由度越大，样本方差就越接近总体方差，T分布也就越接近Z分布。因此T分布的形状随自由度的变化而变化，自由度越大，越接近正态分布。）

5.给定显著性水平α：

α常取0.1、0.05、0.01，后文会再谈到显著性水平与两类错误。

推荐系统入门#

推荐系统的必要条件#

推荐系统的三个步骤#

召回#

排序#

调整#

产品经理的工作职责#

背景#

召回阶段#

基于用户行为的协同过滤召回算法#

基于内容标签的召回策略#

优缺点#

排序阶段#

加权平均法#

CTR 动态加权平均法#

CTR 预估加权平均法#

推荐系统的评估#

实战项目#

需求定义#

构建需求背景#

描述交互逻辑#

制定预期目标#

数据准备#

技术实现#

召回模块#

排序模块#

调整模块#

评价标准#

整理#

能力#

技术#

岗位#

冷启动#

解决方案#

基于规则的冷启动#

丰富冷启动过程中获得的用户和物品特征#

“探索和利用机制”#

AB试验#

定义#

应用领域#

互联网#

广告#

政府#

A/B实验流程#

注意#

AB测试用法#

业务中的生效逻辑#

业务指标建设#

用户进组设置#

试验层流量控制#

AB test数据控制#

原理-假设检验#