从0到10，靠信息流搞懂ta到底喜欢什么？

作者：alieyu 腾讯VTeam技术团队高级工程师   导语 | 信息流产品的内容分发方式包括：推荐、投放、push、订阅等，其中的"推荐"是最为主流，也是大家最为熟知的分发方式。但，在实际的信息流产品中，通常是多种分发方式相辅相成，共同打造良好内容生态，共同提升用户体验。本文将以【投放】为主线，给出个人对内容分发场景的一些浅薄思考和理解。

本篇将对如何设计与实现投放系统展开讲解，关于投放系统上篇可点击查看：把用户当作女朋友，你真的知道她喜欢什么吗？（上）

投放系统架构

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

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

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

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

需求方平台(DSP)

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

1. 需求接入

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

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

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

2. 需求管理

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

任务熔断

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

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

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

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

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

投放中介(TFX)

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

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

1. 离线子系统

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

1) 任务排期

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

排期的主要作用/目的：

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

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

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

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

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

一些具体的排期策略：

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

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

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

2) 库存管理

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

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

2. 在线子系统

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

1) 定向召回

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

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

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

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

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

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

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

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

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

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

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

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

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

2) lookalike人群扩散

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

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

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

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

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

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

供应方平台(SSP)

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

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

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

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

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

 投放系统透视图

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

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

总结与展望

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

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

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

最后：

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

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

近期热文推荐

你“在看”我吗？