从0到10，让你彻底理解【信息流投放系统】

点击上方"蓝字"

发现更多精彩！

信息流产品的内容分发方式包括：推荐、投放、push、订阅等，其中的"推荐"是最为主流/熟知的分发方式。但在实际的信息流产品中，通常是多种分发方式同时并存，共同打造内容生态，共同提升用户体验。

• 本文将以“投放”为主线，从：为什么要投放、投放是什么、怎么做投放，三个方面，对一般性的信息流投放系统，展开详细阐述。并结合实践经验，给出个人的所思所想，将包括设计概要、实现细节、挖坑爬坑，等诸多方面。
• 本文尽可能以通俗浅显的语言来描述一些技术问题，以及背后的业务思考，以期让大家通过快速阅读此文，从0到1到10，彻底理解投放系统，若能如此，则不胜荣幸(写不出段子的工程师的代码，是没有灵魂的?)
• 如果看完全文，你还是没懂，那一定是我的问题，欢迎线下交流/指正

• 1.1 推荐系统的遗留问题
  • 1.1.1 C侧用户：人之惰性
  • 1.1.2 B侧作者：挣钱是硬道理
  • 1.1.3 推荐平台方：无辜的中间人
• 1.2 人工干预的必要性
  • 1.2.1 内部运营干预
  • 1.2.2 B侧号主干预
• 1.3 为什么不是推送Push分发
• 1.4 为什么不是订阅分发
• 2.1 生活中的投放
• 2.2 广告投放
• 2.3 信息流投放
• 3.1 投放系统架构
• 3.2 需求方平台(DSP)
  • 3.2.1 需求接入
  • 3.2.2 需求管理
• 3.3 投放中介(TFX)
  • 3.3.1 离线子系统
  • 3.3.2 在线子系统
• 3.4 供应方平台(SSP)
• 3.5 投放系统透视图
• 4 总结与展望
• 5 最后的废话

一 为什么需要投放系统

要证明世上没有鬼是很难的，但如果要证明有，却很简单，举例说明即可。同理，要证明为什么需要xxx，只需要说明：没有xxx，不行即可。

因此，“为什么要投放”，可转化为：“推荐系统在内容分发场景中有什么不足”，以此来进行具体分析。

1.1 推荐系统的遗留问题

推荐系统的一个最大遗留问题是马太效应”。一套虚拟系统，就是现实社会的一个映射，因此，在现实社会中存在的问题，在推荐系统同样存在，如上图所示：

• 在内容侧，数百万级的内容池中，可能Top20%的一级分类内容数量占了整个内容池的80%左右（哦，2/8？3/7？请不用太过纠结，仅随意构造用于示例说明，下同）；
• 在用户消费侧，每天总内容消费量近xxx亿级，可能其中80%消费内容也集中在Top20%左右的一级分类。

这和20%的人掌握了全世界80%以上财富的现象、及原因，本质是一样的。推荐系统，本质也是市场经济体系：供应方(B侧作者)，消费方(C侧用户)，市场（推荐平台）。

因此，当该体系(推荐系统)出现“马太效应”这种合理、但并非合适的现象时，作为该体系中的每一方，当然都有逃脱不了的干系。

1.1.1 C侧用户：人之惰性

人，食五谷杂粮者，非要练就金刚不坏之身，确实是有些难为了。我当然知道，我应该看些有思想/有深度的文章/视频，但如果你天天给我推荐大长腿 大胸妹妹，我能不看吗？？

我看下也就算了，推荐系统还非要认为是我自己想看的，然后继续给我推更长的腿 更大的胸，于是乎，我只能沦陷在此“温柔乡”了。可我知道，这并非我所愿...

1.1.2 B侧作者：挣钱是硬道理

有需求，就杀害：对于作者而言，写诗歌/散文，情怀固然重要，但在现实/钱面前，情怀不过是扯淡。

既然，消费内容的80% ，都是短/贫/快的无脑娱乐化图文/视频，那么对于真正的优质账号作者自然是致命的：没有生存的环境/土壤，只能是肥的拖瘦，瘦的拖死（要么逃，要么死）。从而使得内容池的2/8分化趋势进一步加剧，当然也会加剧消费情况的2/8趋势...

1.1.3 推荐平台方：无辜的中间人

那么上述的“马太效应”，应该由这场交易的中间方（推荐平台）来背锅吗？当然不能！推荐平台，恰恰只不过是做了它本来该做的事，而已。

既然，推荐系统已经做了它该做的事情，为何结果却并不理想呢？下面从两方面分析：推荐系统是什么？ 推荐系统有什么问题？

1.1.3.1 推荐系统是什么

上图，是一个基本&通用的推荐系统架构。

• 最简单的描述： 将用户喜欢的内容推荐给用户。
• 详细描述：根据用户的过往行为历史，来尝试识别用户的兴趣，然后从全体内容池中，筛选出和该画像匹配程度最高的内容，推荐给用户，并收集用户对此的反馈数据，来迭代用户的兴趣画像...，如此不断循环迭代...

1.1.3.2 推荐系统有什么问题

推荐系统诞生的初衷，是为了解决海量用户 vs 海量内容的信息过载问题，注重规模效应。本质是以人(消费者)找内容，并且侧重为其中的人服务。也即是说，看似公平的中间人，实际是被消费者牵着在走，而忽略了内容生产方。注重开发利用，而忽略生态环境建设。

两个关键点：

• 推荐系统认为的“用户喜欢”，不一定等于，用户真的喜欢（案例：大长腿 大胸妹）。用户就像你的女朋友：你很难知道她真的喜欢什么，因她自己都不知道，但你又不得不去尝试知道，因为她是你女票：她的错，不是她的错，是你的错。
• 就算用户真的喜欢，那就一定要满足用户需求吗？整个系统，包括多方：供应方(B侧号主)，消费方(C侧用户)，市场（推荐平台）。一套系统，是一个利益平衡问题，过度侧重其中一方的利益，必然会损害他方利益，进而影响整个系统的健康发展。

总结：

• C侧：小众用户兴趣难以满足!!
• B侧：影响内容生态!!

1.2 人工干预的必要性

在市场经济体系中，市场当然是至关重要，但市场本身是有缺陷的(贪婪/唯利)，因此人为的宏观调控也是必须的。

同样，在信息流分发体系中，推荐当然是至关重要，但推荐本身是有缺陷的(伪喜欢/唯消费者)，因此人工干预也是必须的。

1.2.1 内部运营干预

你隔壁运营组同学的需求：

• 比如一些重大新闻，这当然应该成为头条内容
• “阿里里因垄断被罚182亿”，这等热点内容，运营同学当然也不会错过
• 对于BD耗费人力物力引进的大V账号，当然也不能因为用户似乎“不太喜欢”而不给曝光机会 ...

总之，运营需要一个可以人工干预的内容分发渠道，来满足他们的各种日常需求。

1.2.2 B侧号主干预

对于内容生产方的号主，同样有类似上面运营同学的需求。只不过，号主运营的是自己的多篇内容，而运营同学运营的是多个号主的内容。比如：

• 号主需要通过购买平台的流量，来扶持自己的账号
• 号主需要相对集中的流量，扶持自己的某一篇文章，以打造爆款
• 号主需要把自己的某一篇文章，定向曝光/投放给满足指定条件的用户群体，比如：一篇深圳健身房的软广，当然不应该曝光给上海的用户 ... 显然，这些需求都是从内容侧发起的，是推荐系统难以解决的需求。

1.3 为什么不是推送Push分发

以内容找人，粗略等于一个内容发起的Push动作（推荐的人找内容，近似用户发起的Pull动作）。

Push分发，在一个产品的初期是很重要的一种分发方式，是拉新的基本手段，比如你常讨厌的红点推送。但由于Push操作过于强/硬，影响体验，容易导致用户反弹，因此，不适合长期/大规模发力。

1.4 为什么不是订阅分发

订阅分发，如同共产主义，是美好、而不可达到，但可以无限逼近的？如果：

• 所有的用户：都能订阅到适量的、真正喜欢的账号
• 所有账号：都能被足够多的，忠诚的粉丝用户所订阅 那么：什么推荐、投放、push...都不再需要了？大同时代已经到来！

但，目前确实还没到来...

二 投放系统是什么

相对于我们耳熟能详的推荐系统，投放系统似乎更为陌生？其实，并不然。可以通过下图直观感受下投放的含义：

2.1 生活中的投放

投放的字面意思：把某物品投掷出去， 并放置于某处。

• 例1：快递小哥把外卖送给一楼前台妹子

三方：商家(外卖) -> 快递小哥 -> 前台妹子(消费者)其中，连接中介是快递小哥，连接的是商家和消费者

• 例2：投放系统把一个小视频投放给一楼前台妹子

三方：作者(小视频) ->  投放系统 -> 前台妹子(消费者)其中，连接中介是投放系统，连接的是文章背后的作者和消费者

一个关键点：不管是射箭的妹子，还是骑手小哥，还是传书飞鸽，他们的起点/出发点都是物品侧。

2.2 广告投放

在互联网领域，最早的、最常见的就是广告投放了。电梯、公交、地铁、移动App...，无处不在，无孔不入，所以我们无时无刻不是消费者，无时无刻不是在被消费。

广告投放的本质，是将平台流量，售卖 给有广告需求的商家。当然，在具体实施时，是一个反向过程：将商家的广告，投放给平台流量(消费者)。

所以，在这场活动中，投放平台方，服务的是商家(广告主)，而C侧用户只是可以售卖交易的流量而已。

2.3 信息流投放

信息流投放，本质上和广告投放是一致的。只是投放的物品有所区别而已，信息流投放的物品，包括图文、视频、广告等多种形态。

在具体实施过程中，也是以内容找人，和推荐系统的以人找内容相反。投放强调的是：从 B侧->C侧的过程，和推荐系统以C侧需求为出发点相反。更加关注底层的内容生态健康，而非一切为C侧消费者服务。

当然，在产品/业务的发展初期，处于快速跑马圈地阶段，我们往往忽略（应该是来不及关注？）生态的健康问题。但，随着产品/业务逐步发展壮大时，曾经重要但不紧急的生态问题，就会变得重要而急迫了，因为这通常会关系到产品的生死存亡。比如随着市场经济迅猛发展的阿里粑粑，一不小心就可能被宏观调控了。

这也是为什么在信息流产品的生命周期里，一开始就必须要一套强大的推荐系统，而投放系统通常在中期阶段才出现的一大原因。

三 如何设计与实现投放系统

到此，终于将为什么，是什么，这两个基本的&&重要的背景问题讲完了。名正，则言顺，因此接下来的不过是具体实施细节，也就变得相对简单了。

3.1 投放系统架构

如前所述，投放是连接B侧作者，和C侧用户的中介。因此，一套广义/完整的投放系统，至少/主要包括以下3部分：

• 需求方平台(DSP):  投放主要是为B侧服务，因此，DSP平台是对接内部运营和外部号主的一个需求管理平台。
• 投放中介(TFX)：这部分是DSP与SSP的连接中介，是完成DSP投放需求和确保投放效果的核心模块，也是狭义上的投放系统。
• 供应方平台(SSP)：投放通过DSP，将流量售卖给作者。因此，供应，指的是平台流量，即C侧用户。这部分主要是对接C侧用户请求，为投放提供流量输入。
• 效果管理平台(TMP)：这部分是一个辅助设施，用于优化投放效果，比如ab实验系统等。本文暂不详细分析该模块。

• 需求方平台(DSP)：对接B侧，主要是离线系统；
• 供应方平台(SSP)：对接C侧，是在线系统；
• 投放中介(TFX)：位于二者之间，其中离线和在线的子模块均有涉及。

下文，将按照需求/物品流向，即DSP -> TFX -> SSP的顺序，对各子模块的设计和实现进行具体分析。

3.2 需求方平台(DSP)

DSP主要包括需求(投放任务)的接入和管理两部分，是整个投放系统的入口和触发点。

3.2.1 需求接入

投放需求的来源通常是多方面的，比如：

• 内部运营同学：如热点事件运营、BD账号内容扶持等；
• B侧号主：号主可通过"购买"等方式获得平台流量，然后配置投放任务来支配这些流量，从而能够自主把控账号内容的分发曝光情况，可助力内容冷启动。
• C侧用户：运营/号主，都是基于先验证信息来下达的投放需求，用户未必为这些内容买单。所以，也需要为C侧用户提供一个对内容的流量加持渠道，让用户直接帮助号主/运营来筛选内容。这种方式，有利于打造爆款内容。

在技术实现层面，由于需求来源很多，包括运营系统、创作者中心、C侧客户端等，因此在投放任务(需求)接入时，需要注意通用性方面的考虑，便于灵活快速的接入多端/多场景的各类投放需求。

3.2.2 需求管理

投放需求(或投放任务，下同)的管理模块，和常规类CMS系统等，并无太大差异，主要就是增/删/查/改等操作(好吧，应该是我自己太肤浅了!)。

3.2.2.1 任务熔断

除CURD常规操作外，DSP的一个特殊模块是任务熔断。

投放，是一次交易活动的具体执行过程，那么这个执行过程到什么时候结束呢？这里涉及到的就是熔断策略问题，例如：

• 时间：时间熔断，是最基础/直接的策略和保障。一个投放任务，总是有时间限制的（一场交易，总有截至时间），比如号主购买100w的流量包，要求必须在48小时内完成。截至时间达到后，就应该立即停止投放 / 终止交易，否则对平台方会造成流量损失（这部分流量，号主并不买单）。
• 流量：投放动作，本质是兑现流量的售卖协议。因此，如果曝光量达到了协议指定值，就完成了这笔交易，即应立刻熔断任务。
• 效果：除了有保量要求外，投放也必须关注投放效果。如果只关心保量目标，而忽略效果，就会影响C侧用户体验，进而影响平台方利益，同时也会影响B侧号主体验。因此，对于一些效果很差（用户不喜欢）的投放任务，会根据一些列规则（如点击率）进行适时熔断。

简单的说，熔断的基本原则就是，要求在规定的时间内，保质，保量 的完成B侧下发的投放任务。

当然，保质、保量，本身就是一对矛盾体，因此，这里是一个平衡问题。在实际进行中，如何提升投放效果，保证投放完成率，同时兼顾三方利益，一直是我们追求的优化目标。道阻且长，吾欣然往之。

3.3 投放中介(TFX)

连接B侧和C侧的投放中介，也就是狭义上所说的投放系统， 是整个投放体系的关键部分，也是一次投放交易的决策和兑现机构。一次投放任务的下发-执行的主要流程如下：

投放中介，可分为对接B侧的离线，和对接C侧的在线，两个子系统。以下将对两部分进行具体分析。

3.3.1 离线子系统

离线子系统，是直接和需求方平台(DSP)对接的，为DSP提供投放任务的排期决策服务。如前所述，投放系统通常需要接入来自运营/号主等多方的各类投放任务。如此多的投放任务(50w级)，如何保质保量的完成，这不仅是在线兑现的模块的问题，还必须依赖离线的排期决策。

3.3.1.1 任务排期

任务排期，即在投放任务的生成阶段，对该任务进行排期。简单说：相当于货(流量)仓调度员，当有人来谈生意(下发投放任务)时，需要根据自己手上的货物，进行实时的评估，然后决定要不要/能不能承接这一单生意，并为后面的兑现环节做好必要的准备!!。

排期的主要作用/目的：

• 防止流量超卖：确保不会出现流量超卖的情况，即不要随便答应你做不到的事，否则，最终会无法兑现，从未导致违约，损坏号主方利益，进而影响平台口碑等。所以，如果确定不能兑现的任务，需要尽早拒绝。
• 实现平台方利益最大化：做生意嘛，无非挣钱。因此，在不出现超卖的同时，需要充分利用流量库存，避免流量浪费。同时，不同的号主会对同一流量出不同的价格，那么这个流量卖给谁呢？如此这些，都是需要考虑的问题（ 本文暂不做具体阐述，后续会有专文介绍 ）
• 指导在线的执行兑现：离线的排期，不仅决定了任务能否下发，还需要为在线的具体执行提供参考/指导。否则，离线和在线会出现完全脱节，从而导致给出的承诺最后无法兑现。

任务排期的几个关键步骤依次如下：

回顾一下，你带女朋友去超市买雪糕的场景即可：

代码语言：javascript复制

你：老板，有东北大板的雪糕卖吗？
老板：噢，我看下....有，你要几根嘛？
你：给我妹子一根就好了
老板：来....

• 1询量：即查看库存，确认是否有足够的、满足客户/号主需求的流量。如果没有，交易结束
• 2 排期：只是量够，还不够。一个任务，通常会有一些人群的定向条件，比如只能投放给20-30岁的、一线城市的、女性用户。对于带有类似附加条件的任务，如果进行排期，也是一个很大的问题(本文暂不做具体阐述，后续会有专文介绍)。
• 3 锁量: 当告诉客户，已经成功接单后，后台需要进行锁量操作。即把排期的流量进行锁定，预留给该任务，以防被二次售卖。
• 4 分发：完成上面的1/23/步之后，一个投放任务正式生成，此时即可将该任务分发到在线模块去执行，即你兑现承诺的时候到了。

一些具体的排期策略：

代码语言：javascript复制

投放任务：一个短视频要在48小时内，投放10w的曝光量

• 时间分布：在48小时投放10w，那么每个细分粒度的时间段(比每小时)应该投放多少呢？可以根据流量库存的时间分布情况，进行等比例的排期，以保证任务可以平滑的进行曝光投放。
• 二阶段策略：排期，是一个对未来的规划，实际执行肯定会出现偏差。以此，可以采取多阶段的投放策略：把48h分成两个24h，前24h结束时，对任务的实际执行情况进行一次回顾，触发二次排期补量操作。
• 多场景分配：如果存在多端多场景的用户流量，那么这10w流量到底分配到哪端哪个场景去执行，也是需要考虑的点，充分将各流量场景都利用起来，实现流量合理分配，利益最大化。

当然，具体的排期策略，在不同的产品/业务场景，或者同一产品的各阶段，都会有很多差异，这里只是列举一些基本/常用的策略，以供参考。策略，永远在优化的路上...

3.3.1.2 库存管理

库存管理是排期策略得以实施的底层支撑。库存管理，类似一个忠诚&勤劳的仓库管理员。需要对流量库存的已使用、剩余、时间分布、定向分布等了如指掌。为上层的排期决策，提供细致准确的数据信息支持。

流量库存的数据，需要从在线服务进行抽样/采集，从而得到各个业务场景的具体流量分布情况。

3.3.2 在线子系统

在线子系统，即投放任务的真正执行/兑现机构。在C端用户请求进入时，根据任务的定向条件，或者lookalike智能扩散等，召回与用户匹配的任务，曝光给该用户，即兑现一次该任务的曝光流量。

3.3.2.1 定向召回

在早期，由于投放任务量较少(1w条以下)，所以一种简单粗暴且高效的方案是，在线过滤匹配即可。当用户请求进入时，循环遍历投放任务列表，把任务的定向条件与用户画像进行匹配，由于任务量很少，耗时通常在50ms以下，完全满足需求。

当任务量不断增加，则需要建立召回索引，提高在线检索性能。

定向召回的基本流程和架构，与常规的推荐召回是一致的，包括数据源接入、数据预处理、离线索引构建、在线检索等4个主要部分。架构图如下：

值得注意的是，在具体实现上，传统的倒排索引方式，无法直接满足定向召回的需求。其根本原因在于，推荐与投放是有本质区别的：

• 推荐召回：以用户找内容，只要内容满足用户兴趣画像即可，此时用户画像可能并不满足内容的相关条件，内容处于被选择状态。如果用推荐召回来做定向召回，会出现召回结果放大的badcase，即召回的任务并不能投放给该用户。
• 定向召回：以内容/任务找用户，用户画像必要满足内容的全部定向条件，此时用户处于被选择状态。

例1（错误示范）：按推荐的传统倒排索引进行召回

例2（正确示范）：按改良后的定向索引进行召回

改良的关键点在于，补齐/显示化所有需要匹配的定向维度，以解决召回结果被放大的问题：

• 投放任务：没有指定的定向维度，即可以投放给该维度的所有用户，补齐为all
• 用户query：缺省的画像维度，补齐为empty。用户的empty维度，仅能匹配上该维度为all的投放任务

经过补齐后，在检索时，就会检查到任务要求的所有定向维度，从而得到正确的召回结果。

当然，补充操作会带来一些额外代价：

• 索引/空间：倒排key/value大量增加
• 检索/时间：需要遍历所有定向维度的倒排key，增加性能消耗

这些额外代价，也可以通过继续优化去缓解，比如增加二级索引等，来解决在线检索的性能消耗问题（ 具体细节，后有专文介绍 ）。

3.3.2.2 lookalike人群扩散

凡是我们知道的问题，都不是问题；问题是那些，我不知道有问题的问题。

定向投放，只能解决明确知道目标用户群体的情况。而很多时候，运营/号主，并不知道他们该把这边文章投放给什么样的用户群体。对于这种情况，就需要一种更加智能的投放方式了，比如基于lookalike的人群扩散方式。

在智能投放(自动化人群圈定)场景下， 即根据已有的少量种子用户，通过算法模型来计算其他用户 与 种子用户的相似程度，从而得到一个与种子用户群体相似的，更大的用户群体。

在投放时，即可将该“相似的，更大的用户群体”作为投放任务的目标人群，进行投放，从而解决定向条件未知的问题。

在具体实现中，这里也涉及很多方面，比如：

• 种子用户：如何构建种子用户群体
• 表征：选择什么算法模型来表征用户和任务
• 相似度：如何度量其他用户与种子用户的相似度
• 相似阈值: 如何设置相似阈值来得到一个更优的目标用户群体，在保量的同时平衡投放效果

3.4 供应方平台(SSP)

整个投放系统，供应/售卖的是C侧用户带来的流量。流量，即资产。因此，供应方平台解决的就是，如何通用灵活的接入C侧流量的问题，尤其在类似一些多端多场景的情况。

当然，如果要建设一套通用/开放的信息流投放平台，自然就需要接入更多的流量场景，并且要灵活快速的支持各场景的随时下线和新增上线等需求。

供应方平台涉及的相关技术点，主要是常见后台接入层的系列挑战，如: 一些需要考虑的基本问题：

• 高并发：对接业务场景多，上游请求量线性增加
• 请求扩散：同一个业务场景，有多个上游需要接入
• 兼容性:  由于各流量场景，通常有其独立的发展历史，导致架构 / 框架 / 协议等均不统一
• 通用性：不管流量侧如何变化，需要保证底层投放中介（TFX）的通用化
• ... ...

由于这些挑战点，与投放本身关系不大，因此就不再具体展开讨论。

3.5 投放系统透视图

到此，对一套投放系统所涉及的最主要模块进行了逐一的分析。当然，还有很多子模块，如连接离线与在线的任务分发模块，负责播放控制的Pacing调控模块，以及投放效果管理平台(TMP) 等等，这些遗留部分，后续争取找机会分享补齐(如果你相信的话)。

在此给出一张一般/通用的投放系统的完整架构图，以供参考：

四 总结与展望

沿着，为什么要投放，投放是什么，怎么做投放，这样的路线，对一般意义上的 && 通用的信息流投放系统，进行了深入浅出的 && 较为完整的 讨论(自认为如此？)。

一套完整的投放系统，所涉及的点确实很多，包括：B侧/平台/C侧， 管理端/后台/算法/客户端等诸多参与方。本文，仅根据个人在业务实践中的理解，斗胆分享一些浅薄的所思所想，以供参考。部分术语并非十分严格/准确，部分思路也未必正确，欢迎各位随时交流讨论 / 批评指正。

五 最后的废话

由于篇幅 / 时间所限( 其实还是懒)，文中抛出了诸多悬而未决的问题点。仅 "具体细节，后有专文介绍" 这种骗人鬼话，就出现了5 次，在此，有必要对看到3 次的你，表示感谢和歉意。

最后：

感谢团队里一起建设投放系统的小伙伴；

欢迎各信息流的相关团队/同学，进行更加深入的讨论和协同共建等

作者alieyu（腾讯VTeam技术团队高级工程师）公众号↑↑↑

腾讯VTeam技术团队公众号↑↑↑

你的每个赞和在看，我都喜欢！

推荐系统 大数据 信息流

0 人点赞