精准投放能力揭秘，实现业务更多可能性

在过去的近一年时间里，围绕淘系营销导购的投放能力建设，在“一个淘系、一套体系”的原则下，通过整合原天猫、淘宝、聚划算等的投放系统，使得技术层面可以站在更高的角度，面向新零售进行投放域的支撑与保障，在各个垂直能力建设上做深做强，并服务于集团更为广泛的业务方。

定向投放（后文简称“定投”）的能力建设，在大的投放技术体系内，“一心一役”与各核心应用深度融合与协同，完成了较大的技术升级，服务了淘系（淘宝、天猫、大聚划算）、天猫进出口、天猫超市、AE等业务，帮助业务实现了更多的可能性。

业务形态与技术匹配

在介绍具体的技术架构之前，我觉得应当先对技术所服务的业务进行简要的介绍，会场业务形态是营销活动的重要阵地，应该说伴随着大促一路成长，经历了从粗放式会场组织到精细化运营的演进。

以双11为例，我们看到，拉新进入会场的人群有特殊的货品承接、互动向会场导流后有专门的任务模块引导消费者完成会场浏览、平台与商家之间通过特定版头与楼层在会场完成了商业化的资源置换、越来越多的商品或服务基于地理位置的匹配触达到了消费者，这一切背后的思考脉络都围绕着会场效率的提升。

回到操作面上，个人总结了一个会场业务的本质公式： 页面 = 楼层结构 + 数据。

楼层结构是整个页面的架子，排期召回的数据则填充了页面的内容。运营同学的主要抓手就是楼层结构的规划和楼层内商品、店铺或权益的数据投放策略。

定投能力的建设，技术层面通过梳理业务的共性诉求，集成了 “区域”、“人群”、“时间”、“请求标识” 四个领域的规则判断能力，并围绕 “页 面”、“楼层”、“排期” 三个业务关键词，构建与业务相匹配的三个技术支撑维度（即页面级定投、楼层级定投和排期级定投），形成了覆盖领域及支撑维度日趋完备的“四纵三横”定投技术架构。

纵向领域能力集成

以定投规则所依赖领域能力的编排作为基础，从设置端到消费者链路完成规则创建、更新与预热的管理，以及规则的判定执行。

规则编排

不管做哪个维度的定投，基础都是对不同请求的识别能力，我们分析得出业务的定投需求主要集中在 “区域”、“人群”、“时间”、“请求标识” 四个领域。我们将各个能力封装为对应的判定处理器 Processor，并提出了结构化的定投规则 DSL 规范（支持两层“与或非”的组合逻辑关系），以支持 Processor 的逻辑编排，依据该规范完成对定投规则的描述与解析执行。

规则创建、更新与预热

规则的创建与更新过程涉及DSL描述的持久化，存储包括 DB 和 OSS 两部分，其中 DB 用于设置端的增删改查，OSS 则对所有定投规则的当前及历史各版本进行存储，依托阿里云的 OSS 传输加速（通过网络协议优化，加速 Bucket 远距离访问）和 CDN 全球加速能力，使得部署在任何机房的定投 SDK 都可以快速获取所需的定投规则描述。

与此同时，为应对消费者侧业务（特别是大促会场）对服务端接口响应的 RT 的严格要求，定投二方包内部基于 Guava 还有一层本地缓存，使得投放应用集群能够大概率在本地读取到热点定投规则。

针对双11大促等重保场景，我们还加入了规则预热的功能，二方包在接收到指令后，会主动向 CDN 拉取指定的定投规则，完成0点前的提前预热。

规则判定执行

定投规则的执行分为两步：预处理和并行判定。往往一次请求对应多个定投规则需要进行判定，预处理主要针对有远程调用的判定，以区域判定为例，在将请求中携带的IP、经纬度等信息提取出来后，预先请求相关服务获取用户的地理位置，后续每条定投规则的判定过程，就可以直接拿预处理获取的地理位置做判断，而不用重复请求地理服务。

横向投放体系协同

前面介绍的纵向领域能力集成，从规则的描述与编排到创建、更新与预热，主要围绕定投规则展开。在完成了纵向能力建设之后，定投应用于实际投放场景还要回答一个关键的问题：如何与现有投放体系融合？ 这就引出了横向投放系统协同的话题。

经过多年的发展，技术和业务有其“变与不变”，就像 页面 = 楼层结构 + 数据 这个公式，它似乎是不变的，但公式背后的技术迭代早已沧海桑田。

近年来，电商通过个性化技术服务消费者成为了提升用户体验的有效途径，不过这也对传统的投放技术架构产生了较大的冲击。在以往大促中一直占据核心地位的 CDN 纯静态页面，无法支持动态化内容组织的业务需求（包括楼层的定向投放）。

面对这一挑战，我们将静态的页面模板与动态的页面结构渲染（以及数据请求）进行了分离，并且以页面为视角建设了逻辑网关层，负责组织页面结构并向资源位投放系统请求所需的数据。因此，定投 SDK 需要与逻辑网关和数据投放系统进行对接，以满足页面、楼层、排期三个维度的定投需求。

逻辑网关

逻辑网关面向前端提供了服务端 JavaScript 运行容器，并支持对外部数据源进行统一封装，可以作为一种 BFF 中间层，用以完成页面结构和数据的合并请求，与终端性能秒开方案相结合，使前端在实现复杂业务需求的同时，依然可以保证页面/接口的加载速度。

基于JavaScript运行容器，逻辑网关实现了一套Handler插件机制，Handler开发者可以获取到用户请求对应的页面结构，以及经过网关统一数据源封装的数据，通过编写JavaScript代码完成业务逻辑。网关通过将定投二方包作为其数据源接入完成定投能力的对接，同时网关向内部 JavaScript 容器提供了重载新页面结构的方法，以支持页面定投的需求。

页面和楼层的定投规则经由搭建系统写入页面模板，逻辑网关收到请求后，首先会获取到页面结构，后续的Handler逻辑流程都可以对页面结构进行修改。楼层定投就是对页面结构的局部修改，而页面定投则是完全用另一个页面的页面结构覆盖当前的页面结构（重载）。

资源位投放系统

为了灵活支持业务的扩展，资源位投放系统负责根据业务场景对数据召回、排序、补全、去重进行业务串联，我们将定投能力集成到排期召回环节，以实现排期数据定投。

业务案例

页面定投

以2019年双11为例，页面定投主要承担了国内双11主会场向天猫海外主会场的分流，由于在逻辑网关中实现了页面重载，海外用户在通过https://1111.tmall.com访问主会场时，会被毫无感知地（没有白屏二跳的糟糕用户体验）分流到对应的海外地区主会场。

楼层定投

楼层定投在大促活动中支持了互动流量的承接、会场效率提升、平台与商家的资源置换等场景，这里先举几个case。

CASE 1： 双11合伙人互动玩法每天会向主会场及各行业会场导流，从互动引导进会场的用户会看到额外的“爆款必买好货”楼层，该楼层有专门圈选的商品做承接，并通过倒计时获得喵币引导用户在会场“逛起来”。该楼层利用“请求标识”进行定投。

CASE 2： 有价券在淘宝营销活动中的核销率较高，有价券模块出现在此次双11淘宝嘉年华活动的主会场、各行业分会场与神券会场，通过一天多个时间点定时上架开售的玩法吸引用户保持对会场的关注。为提升会场效率，有价券楼层只会在特定的心智时间进行展示，其余时间将空间留给下面的楼层。因此通过周期性时间定投控制展示节奏。

以上两个 case，楼层的显隐除了利用定投来控制之外，还可以由前端模块自行处理相关的逻辑，那么为什么要使用定投呢？主要有以下几点考虑：

• 在逻辑网关 Handler 层控制楼层定投，可以提前阻断楼层关联的资源位数据排期召回，减少无用的数据请求，降低 RT。
• 如果由前端处理隐藏楼层，那么该楼层中的商品虽然没有实际曝光，但依然将参与去重，这会导致这部分商品始终无法展示给消费者，而使用定投则可以解决这一问题。
• 可以使前端模块更具通用性，专注业务逻辑。

排期定投

随着本地化的业务策略持续推进，双11造势期天猫在不同城市推出“新车团购节”，在线上会场的版头位置，需要根据访问用户的区域，定向展示当地线下活动的日期和地址，如下图所示该需求利用排期数据定投的方式实现。

展望

定向投放作为一种会场的运营抓手，能够帮助业务实现投放的意志。我们也发现运营同学越来越注重数据对投放策略的指导作用，No Data No BB，再反观一次营销活动，从造势到预热再到正式售卖，特别是618、双11这样的S级大促，拉的战线是比较长的，在这类长线营销活动周期中，运营更希望在活动前期试验各种想法，通过获取数据支撑，帮助其在正式售卖阶段达成更好的效果。因此在定投之外，运营对于AB实验的需求也较为旺盛。

长远来看，如何将多种运营策略的技术工具进一步融合，封装成真正的运营策略产品赋能业务，是需要我们进一步思考的。