运营位投放系统：站内自有流量的内容投放、触达与权益发放

App 首页的 banner、金刚区、弹窗、浮层、feed 中的卡片位，不卖给外部广告主，而是分给公司内部的活动、产品、内容。 决定"这个位置今天给哪类用户展示什么"的系统，业内也叫"投放系统"。理财通投放系统属于这一类： 首页的基金推荐卡片、热门板块、直播预告、指数估值，都由它按运营配置的规则投放。

这类系统没有竞价、没有计费，本质是个性化的内容配置与展示系统。广告领域的投放系统 （媒体竞价、品牌合约、程序化交易、搜索广告、广告主买量）见 广告投放系统.md。

1. 共同抽象

运营位投放回答的问题是：在某个位置，给某个人，在某个时间，按某种规则，展示某个内容。

维度 含义 运营位系统里的叫法
WHERE 流量出现在哪 页面 + 投放位
WHO 给谁看 用户标签、用户包、AB 实验分组
WHEN 什么时候看 生效时间、交易日、时间段
HOW 按什么规则 优先级、限量、频控
WHAT 看到什么 内容 / 物料 + 展示模板

同一个位置、同一个人有多个候选时，谁赢由决策方式决定：

决策方式 谁赢 典型系统
规则 + 优先级 运营配置的优先级最高、且通过所有过滤的那一条 理财通投放、电商资源位、App 弹窗
模型排序 预估目标（点击、转化、停留）最高的 推荐系统、智能运营位

规则型系统的核心是过滤链和配置管理。

2. 站内自有流量的几类系统

flowchart LR
    subgraph 站内["站内自有流量"]
        OPS[运营位投放<br/>理财通投放 / 电商资源位]
        REC[推荐系统]
        PUSH[触达系统<br/>Push / 短信 / 站内信]
    end
    MKT[权益发放 / 营销中台]
    PUB[App / H5 页面]
    USER[用户]

    OPS -- 用户打开页面时拉取 --> PUB
    REC --> PUB
    PUSH -- 主动推送 --> USER
    PUB --> USER
    USER -- 点击活动入口 --> MKT
领域 典型系统 谁在用 目的 决策方式
站内运营位投放 理财通投放系统、电商首页资源位、App banner / 弹窗 / 浮层 运营 把自有流量分给活动、产品、内容，完成业务目标 规则 + 优先级，部分引入模型
推荐系统 信息流、商品推荐 算法 最大化用户消费（点击、时长、成交） 模型排序
营销触达 Push、短信、站内信、企微、营销自动化（MA） 运营、CRM 主动把消息推到用户面前，拉活、召回 圈人 + 调度 + 频控
权益 / 优惠券发放 营销中台、券平台 运营 发放红包、券、积分，控制预算和风险 规则 + 限量 + 风控

同目录的理财通投放系统属于第一类，营销中台属于最后一类。推荐系统不在本文展开。

3. 站内运营位投放

3.1 目的

目标是完成业务 KPI（申购、开户、活动参与、内容阅读），同时控制对用户的打扰。 运营配置"什么位置、什么时间、对什么人、展示什么内容"，系统按规则过滤后返回。

3.2 架构

以同目录 投放中台概要设计V1.2.doc 的设计为例，它把投放拆成 WHERE / WHO / WHEN+HOW / WHAT 四个子系统：

flowchart TB
    FE[前端页面] --> BIZ[业务 CGI<br/>校验用户登录态]
    BIZ --> GW[投放中台网关<br/>鉴权、限流、协议转换]
    GW --> ENGINE[投放引擎<br/>编排整个投放流程]

    ENGINE --> WHERE[位置系统 WHERE<br/>页面 → 投放位]
    ENGINE --> PLAN[计划系统 WHEN+HOW<br/>时间规则、限量规则、优先级]
    ENGINE --> WHAT[内容系统 WHAT<br/>商品、模板、内容过滤]
    ENGINE --> WHO[用户匹配系统 WHO<br/>规则 / 用户包 / AB 实验]

    WHO --> RULE[规则引擎]
    WHO --> TAG[标签服务<br/>BI 离线标签 + 实时业务标签]
    WHO --> AB[AB 实验平台]
    WHAT --> PROVIDER[内容数据提供服务<br/>收益率、剩余额度、直播观看数、文章阅读数]

    ADMIN[投放管理端] --> DB[(投放库<br/>页面 / 位置 / 计划 / 限量 / 内容 / 模板)]
    DB --> WHERE & PLAN & WHAT
    FE -- 曝光 / 点击 / 关闭上报 --> LIMIT[限量计数]
    LIMIT --> PLAN
    FE -- 埋点 --> BI[BI 分析] --> ADMIN

一次投放请求的处理顺序：

sequenceDiagram
    participant FE as 前端
    participant E as 投放引擎
    participant W as 位置系统
    participant P as 计划系统
    participant C as 内容系统
    participant U as 用户匹配
    FE->>E: 渠道 + 页面 + 用户
    E->>W: 页面 → 投放位列表
    E->>P: 投放位 → 投放计划列表
    P->>P: 过滤：生效状态、审核状态、时间规则、交易日、限量（用户 / 位置 / 计划维度）
    E->>C: 内容过滤（如基金已售罄）
    E->>U: 用户过滤（规则 / 用户包 / 实验分组）
    E->>E: 按优先级排序，每个位置取第一条
    E->>C: 取内容详情 + 展示模板 + 动态数据
    E-->>FE: 每个位置的投放内容和模板
    FE->>E: 曝光 / 点击 / 关闭上报（用于限量）

过滤顺序是一个性能取舍：先做本地、便宜的过滤（时间、状态、限量），再做需要调用外部服务的过滤（标签查询、实验分组）， 候选集越往后越小，外部调用越少。

3.3 核心问题

问题 说明
配置模型 页面、位置、计划、内容的关系：一个位置挂多个计划按优先级竞争；计划能否跨位置（多对多）是设计中反复讨论的点，多对多更灵活，但配置和查询都更复杂
用户匹配 三种方式：标签规则（资产 > 10万 AND 近30天未申购）、用户包（离线圈好的 ID 集合）、AB 实验分组。规则引擎只做表达式计算，不理解业务
动态内容 "剩余额度 21%""7 日年化 2.3%""3.2 万人在看"这类数据来自交易、行情、直播等下游，由内容数据提供服务按 provider 聚合，非个性化数据启动时缓存
限量 / 频控 按用户（每人每天最多看 3 次、关闭后不再出）、按位置、按计划计数；依赖前端上报，存在丢失和延迟
兜底 所有计划都被过滤掉时，位置不能开天窗，要有兜底计划或默认内容
合规 金融产品展示受监管约束：适当性（风险等级匹配）、收益率展示口径、售罄不可推荐。"推荐产品与对比产品有一个不可买，这一条就不能推荐"就是这类规则
可用性 首页请求量大，投放服务故障不能让首页白屏：前端缓存上次结果、服务端降级返回兜底内容、下游超时直接跳过该过滤或该动态字段

4. 营销触达系统（Push / 短信 / 站内信）

运营位投放是拉（pull）：用户打开页面，系统决定展示什么。触达系统是推（push）： 系统在某个时刻主动把消息发给一批用户。

flowchart LR
    SEG[圈人<br/>标签规则 / 人群包 / 实时事件] --> TASK[任务<br/>定时 / 周期 / 事件触发]
    TASK --> SCHED[调度<br/>分批、错峰、限速]
    SCHED --> FATIGUE[疲劳度控制<br/>每人每天最多 N 条<br/>跨通道统一计数]
    FATIGUE --> CH{通道}
    CH --> PUSH[厂商 Push]
    CH --> SMS[短信]
    CH --> INBOX[站内信 / 公众号模板消息]
    PUSH & SMS & INBOX --> RECEIPT[回执：送达 / 点击 / 退订]
    RECEIPT --> ANALYSIS[效果分析]
核心问题 说明
大批量发送 一次任务几千万用户，要分批、限速，避免打垮下游通道和落地页
事件触发 "用户赎回后 10 分钟发一条推荐"，依赖实时事件流（Kafka + 流计算）和延时任务
疲劳度 跨任务、跨通道统一计数，避免同一个人一天收到 10 条
成本 短信按条收费，需要预算控制和优先级
合规 退订、夜间免打扰、营销类短信需用户授权

5. 权益发放 / 营销中台

投放系统决定"展示什么"，用户点击后参与活动、领红包、领券，由营销中台完成。同目录的 营销中台架构设计文档.docx 描述的就是这一层：接入网关、活动管理、物品（奖品）管理、限量服务、风控代理、熔断服务、对账。

两者的关系：

flowchart LR
    TF[投放系统<br/>展示活动入口] -- 用户点击 --> ACT[活动页]
    ACT --> MKT[营销中台<br/>资格校验 → 限量扣减 → 风控 → 发奖]
    MKT --> STOCK[券 / 红包 / 积分发货]
    MKT --> RECON[对账：活动预算、商户号收支]

投放系统出错的后果是展示错了内容；营销中台出错的后果是钱发多了。因此营销中台的重点是 预算限量的强一致、防并发重复发奖、自然人防刷、熔断和对账，而投放系统的重点是配置灵活和高并发读。

6. 横向对比

维度 站内运营位 触达系统 营销中台
谁出钱 无（自有流量） 通道成本 活动预算
谁决策 运营规则 + 优先级 运营圈人 + 调度 规则 + 限量
在线延迟要求 几十到百毫秒 分钟级可接受 百毫秒级
QPS 特征 高（跟随页面 PV） 突发（大任务） 峰值突发（活动开始）
一致性要求 限量允许少量误差 疲劳度允许少量误差 预算限量强一致
核心模块 配置、过滤链、用户匹配、动态内容 圈人、调度、疲劳度、通道 限量、风控、熔断、对账
数据闭环周期 天级（人工） 天级 活动周期

7. 共有的工程问题

7.1 配置到在线的发布

运营位系统是"管理端写配置、在线端读配置"。配置量小、变更不频繁，常见做法是在线服务查 Redis / 本地缓存， 未命中查 MySQL；对发布安全要求高时，每次发布生成带版本号的快照，在线服务原子切换，出问题回滚到上一版本。

关键点：配置变更要能秒级生效（运营发现配错要马上下线），同时要有审核和回滚（配错一个位置可能影响千万用户）。

7.2 频控与限量计数

key = 用户ID : 计划ID : 日期     value = 曝光次数     TTL = 1 天
  • 存储：Redis 计数器，或在线服务本地计数 + 定期汇总
  • 精度：频控允许少量误差（多展示一次影响不大）；奖品库存和活动预算不允许超发，要用原子扣减或预分配（营销中台的职责）
  • 上报丢失：依赖前端上报的曝光次数偏少；服务端下发即计数则偏多。按业务容忍度选择

7.3 用户匹配

方式 数据 在线查询
人群包 离线圈好的用户 ID 集合 KV 查 用户 → 所属人群包列表，或 Bitmap（RoaringBitmap）判断成员
标签规则 用户标签（离线 BI + 实时业务） 取规则用到的标签值，交给规则引擎计算表达式
AB 实验 分流配置 按用户 ID 哈希到桶，查实验版本

7.4 高可用与降级

手段 说明
兜底内容 投放服务不可用或无结果时返回默认内容，前端不开天窗
下游超时隔离 标签服务、动态数据服务超时时，跳过该过滤或该字段，不阻塞主流程
过载保护 入口按优先级丢弃请求，保护后端
熔断 下游错误率超阈值后暂停调用，定期探测恢复
多级缓存 前端缓存、接入层缓存、服务内存缓存；非个性化结果（如基金收益率曲线）可以共享缓存

7.5 数据闭环

投放效果评估需要把"展示了什么"和"用户做了什么"连起来。关键是在投放响应里带上追踪 ID （投放 ID、实验版本、请求 ID），前端上报曝光和点击时原样带回，下游转化（申购、开户）也能关联回这次投放。 投放中台协议里的 report_info 字段就是这个用途。

8. 和广告投放系统的区别

站内运营位投放 媒体竞价广告
候选规模 一个位置同时生效的计划通常是个位数到几百 百万级广告
召回 位置 → 计划的直接映射，无需倒排检索 布尔表达式倒排 + 模型召回
排序 运营优先级 eCPM = 出价 × 预估
钱 不涉及计费；预算只在配套的权益 / 红包系统里 每次曝光 / 点击都在扣钱，计费必须准确可对账
目标 业务 KPI，由运营人工迭代 平台收入 + 广告主 ROI，由模型自动优化
数据闭环 埋点 → BI → 运营看报表 → 改配置（天级） 日志 → 训练 → 模型更新（小时级甚至实时）

站内运营位投放的演进方向是向广告系统靠拢：同一位置的多个候选不再只按人工优先级，而是按模型预估的点击率 × 业务价值排序 （相当于把"出价"换成"业务价值权重"），并引入流量分配（给每个活动保量，类似品牌合约广告）和探索（新内容冷启动）。 广告系统的这些模块见 广告投放系统.md。

9. 理财通投放系统的定位

问题 结论
属于哪一类 站内运营位投放（第 3 节），不是广告系统
流量 理财通自有页面（微信、手 Q、App）
候选内容 基金产品、产品对比、文章、直播、热门板块、指数估值、活动
决策 规则过滤 + 运营优先级；AB 实验用于比较不同投放策略
和广告系统共有的部分 WHERE / WHO / WHEN / HOW / WHAT 抽象、定向（用户包、标签规则）、频控限量、曝光点击上报、效果分析
广告系统有而它没有的部分 大规模倒排检索、CTR / CVR 预估、竞价、计费、预算 pacing
它特有的部分 金融内容的动态数据聚合（收益率、剩余额度、持仓收益）、金融合规约束（售罄、适当性）、交易日规则
投放中台化的动机 理财通、微证券、信用卡等多个业务各自维护投放逻辑，抽成统一中台后复用位置、计划、用户匹配、内容和规则引擎

理财通语境下的"投放"强调的是"运营把内容投到位置上"；广告语境下的"投放"强调的是"广告主花钱把广告投到媒体上"。 面试中介绍这个系统时，先说清它属于哪一类，再讲 WHERE / WHO / WHEN+HOW / WHAT 的拆分、过滤链顺序、 动态内容聚合和高可用降级，比泛泛对标广告系统更准确。

参考

  • 同目录内部文档：理财通6.0投放系统架构设计文档.docx、投放中台概要设计V1.2.doc、营销中台架构设计文档.docx