一、总览：什么是一个完整的DSP

一个全球可用的DSP系统，本质上是：

连接 广告主（买方） 与 流量平台（SSP/媒体） 的程序化投放平台，
在毫秒级时间内完成广告决策（出价/选择创意/发送响应）
同时支撑 实时投放控制 + 数据监控 + 归因回传 + 策略优化

所以整个DSP通常由 四大层级组成（资源管理系统、竞价系统、策略系统、DMP数据平台），每一层有不同的目标和技术重点，接下来这篇文章就从0到1完整梳理一套成熟的DSP广告系统架构与技术方案。

注：本文都是我在工作中负责过的项目记录下来的，有些产品模块我规划到《DSPMVP产品路线图》的第二阶段或者第三阶段，所以我没有将这个DSP产品跟进到底，有些地方的技术方案，你们产品经理可能要和技术团队共同探讨一下，按你们公司的需求来定。

二、从0到1的MVP功能边界（3–4个月可上线）

1、先解释什么是 “MVP功能边界”

  • MVP = 最小可用产品：就是你用最小成本、最短时间搭建出能上线运行的DSP骨架，拿来接真实流量、跑广告、服务客户。
  • 在 3–4 个月内，我们不追求完美，只追求：流量来了能投、广告主能下单、能看到效果、账算得清楚。

2、必须具备：

  1. 通道：接1–2家主流SSP/AdX（OpenRTB 2.x，沙箱+生产），支持展示/原生/视频至少一种格式。
  2. 竞价主链：
    • OpenRTB解析 → 同意/隐私判定（TCF/US Privacy/ATT）
    • 验签/限流/去重/超时（tmax护栏；统一UTC&USD）
    • 授权校验（ads.txt/app-ads.txt、schain）+ 简单反作弊初筛
    • 生成IR → 交策略系统 → 构造BidResponse（含NURL/BRURL）
  3. 策略系统：规则过滤（白名单/排期/媒体/尺寸/人群）、频控、预算+日内pacing、固定/目标eCPI出价、创意可投校验。
  4. DMP与报表：采集曝光/点击/Win/Loss、接MMP回传（Install/注册等），准实时报表（≤2min）+日结。
  5. 资源管理：广告主建计划/单元/创意、定向&预算、PMP/Deal、账号/充值/对账、创意合规审核。
  6. SLO：端到端RTB ≤100ms（内部决策≤30ms）、可用性≥99.9%、数据延迟≤2分钟。
不做：复杂ML、海量渠道、DCO/多维优化、托管运营工具。这些留到MVP+。

三、极简四层骨架DSP

一条主链路：

【流量进来】→【竞价系统】标准化→合规→富化→生成IR →【策略系统】过滤→pacing→出价→构建BidResponse → SSP回执Win/Imp/Click/Conv →【DMP】存储&统计 →【资源管理】给广告主报表&操作

在3–4个月里，带团队优先做这些最关键的：

  1. 跑通 OpenRTB流量 → 出价响应 → 广告展示 → 回执记录 整个主链路；
  2. 能让广告主在平台上 下广告、看到数据、设置预算和出价；
  3. 能准确 采集曝光/点击/转化，并且通过报表看到效果；
  4. 不踩隐私/合规雷：同意管理/SPO检查必须有；
  5. 系统稳定、数据一致、对账合理，广告主敢花钱。

四、四层详细拆解（做什么、为什么、怎么做）

现在我们就来看看，构建DSP平台的4层结构：资源管理系统、竞价系统、策略系统、DMP数据平台都是什么。

五、资源管理系统：目标与作用

资源管理系统是广告主投放广告的入口。它要解决三件关键事：

  1. 广告主能方便地配置广告计划、素材、定向、预算
  2. 能够管理与审核这些资源是否合规、安全
  3. 能通过数据看见效果、并控制资金使用和对账

简单理解：这个系统就是广告主的“控制台”和你方的“营运中台”。

1、媒介管理（媒介关系管理）

（1）做什么：

  • 管理广告位（媒体侧资源）
  • 渠道对接（SSP、ADX等）
  • 品牌安全（黑白名单）控制
  • 审核创意内容是否合规、清晰、规范

（2）为什么要做：

  • 你买的是媒体的流量，所以对接越多媒体越强
  • 品牌安全防止买到色情赌博等低质流量
  • 有些国家法律会强制要求创意审核（GDPR、广告法）

（3）怎么做（建议）：

  • 广告位管理模块：可视化广告位信息（size、支持格式、价格段）
  • 渠道对接：支持SSP配置，接入OpenRTB endpoint（或Header Bidding）
  • 审核机制：支持人工与自动审核，支持VAST/MRAID检测工具
  • 黑白名单模块：支持媒体域名、App、Bundle ID层级配置

2、数据监控与报表（运营反馈与告警）

（1）做什么：

  • 实时监控（QPS、消耗、胜率）
  • 报表（客户、资源）
  • MMP归因回传（点击 → 安装 → 注册）
  • 异常告警（流量异常、超预算、消耗突增）

（2）为什么要做：

  • 广告主投放没有效果时第一反应就是来看报表
  • 异常数据需要立刻告警，否则影响投放结果甚至预算浪费

（3）怎么做（建议）：

  • 消耗明细：按 campaign/adgroup/creative 维度粒度展示
  • 接入 MMP（如 Appsflyer、Adjust）进行事件归因（建议做 server-to-server）
  • 告警：建议基于规则（阈值触发）+周期比较（同比/环比），钉钉或邮件通知
  • 支持导出CSV、下载PDF

3、财务管理（结算与扣费）

（1）做什么：

  • 自动扣费与充值
  • Win/Loss 汇率换算
  • 汇总对账
  • 设置溢价规则（比如某流量加价30%）

（2）为什么要做：

  • 钱从广告主口袋里出，必须账务清晰且可信
  • Win是投中但没扣钱，Loss是没投中但参与
  • 支持跨币种结算（如人民币和美元）

（3）怎么做（建议）：

  • 建议预付机制（如阿里妈妈）、也可支持授信（大客户）
  • 充值接口支持支付宝、Stripe、PayPal、银行卡
  • 汇率与时区统一成 USD/UTC（报表和实际成本一体）
  • 对账中心：支持查账单、账单导出、按日/月聚合查询

4、客户管理（权限与账号体系）

（1）做什么：

  • 客户资料管理（公司名、行业、联系人）
  • 上传资质（如工商信息、网站备案、授权书等）
  • 账号权限（多角色协同、广告主与代理商）
  • 权限控制：限制客户能操作的计划/预算等

（2）为什么要做：

  • 广告投放是商业行为，必须合规登记
  • 支持客户多人协同（如：投放人员+财务+老板）
  • 有些代理商帮多个客户操作，需要清晰分层

（3）怎么做（建议）：

  • 角色系统：如 Admin、Finance、Operator、Analyst
  • 支持 SSO（OAuth2、企业微信登录）
  • 支持权限树：哪个人可以控制哪个计划、看哪些报表
  • 资质上传建议支持PDF/图片格式、带审核机制

5、广告主界面操作（投放路径设计）

（1）做什么：

广告主的投放流程通常是：

  1. 建立投放计划（Campaign）
  2. 建立广告单元（AdGroup） → 设置定向
  3. 上传创意（素材+落地页）
  4. 设置出价方式（CPC/eCPI）、预算方式（日预算/总预算）
  5. 提交计划，系统审核后进入竞价系统

（2）为什么要做：

  • 操作流顺畅直接决定客户体验
  • 模块设计好能提升客户上手率与活跃度

（3）怎么做（建议）：

  • 流程式建计划界面（向导式UI）
  • 允许拖拽上传、批量创建创意
  • 预算设置应支持小时级（方便控制节奏）
  • 提交审核前加一个“预览&检查”模块
  • 审核失败要提示原因+修复建议

总结：资源管理系统 = “广告主看得见的后台 + 平台看得见的内控”

模块

做什么

为什么

技术要点

媒介管理

广告位/模板/审核

遵守合规，控制内容

模板管理 + 内容审核引擎

数据监控与报表

投放效果看板

广告主需要透明数据

Flink + ClickHouse

财务管理

充值/扣费/对账

商业闭环，提升信任

USD/UTC标准化

客户管理

账户/权限/资质

安全控制，多人协作

RBAC权限模型

广告主操作流程

建计划、设策略

操作闭环支撑策略系统

向导式前端 + 审核联动

推荐 MVP 功能上线计划（3~4个月）

Sprint

内容

说明

第1月

广告计划/单元/创意配置功能

广告主能上传创意并建好结构

第2月

定向 + 出价 + 预算模块

可配地域、设备、人群等

第3月

报表系统（基础消耗、点击） + 审核功能（人工）

广告主可实时看到效果

第4月

支付与财务模块（充值+扣费）

初步上线，支持单币种

六、竞价系统架构

竞价系统是DSP系统区别于其他系统的核心部件，它的作用是帮助需求方在RTB市场上进行广告流量精准竞价采买和展示。这些决策是毫秒级的，并且每秒需要处理的流量数以万计。

在RTB的竞价背景下，需求方需要决策的，不再是“是否购买某月某日，某APP的广告位”，而是要决策“某某设备，在今天19:30:10打开了APP，APP的首页有一个广告展示机会，尺寸大小为700*400，这个设备的用户可能是一个游戏爱好者，这次展示的最低价格为0.02元，是否购买，出价多少。”

1、上层：流量来源

SSP / ADX / SDK / HeaderBidding
   ↓
API接口

这表示 DSP 会从多个流量来源接收 广告请求（BidRequest），可能来源于：

  • 程序化媒体（如：Google AdX）
  • 聚合平台（如：Smart、Pubmatic、Mintegral）
  • SDK直连（如游戏厂商的自研SDK）
  • Header Bidding（如网页RTB）

这些来源都会通过标准化API，向DSP发送请求。

2、中层：通道适配器层

这层的作用是把不同来源的 BidRequest 统一格式化成一种内部结构，便于后面处理。

模块

作用

举例

ADX Adapter

接 Google AdX

接收 AdX 的 JSON BidRequest

Google Authorized Buyers

针对 GAB 结构适配

Deal流量、YouTube流量

PMP/Deal Adapter

支持私有交易dealid场景

比如你买了AppLovin的保量包

自营媒体资源适配器

如果你对接了App内置广告位

自家App调用你SDK发送请求

重点是统一成一份标准格式的“内部请求（IR）”，方便后续策略判断

3、下层：广告请求处理链路（这是系统的“肺”）

这里的模块就是一个个“过滤网”和“数据补丁”

（1）协议适配（OpenRTB）

  • 不同SSP支持的OpenRTB版本不同（2.3、2.5等），字段可能不一致
  • 需要写一个“协议兼容层”，统一字段名称和结构

例如：

"device.ext.ifa" => 统一转换为 "device.ifa"

（2）隐私/同意校验（TCF / US Privacy / ATT）

为什么要做？因为合规问题，没同意就不能个性化投放！

  • 欧洲：TCF 2.x（“COwxyz”开头的 consent string）
  • 美国加州：US Privacy string（“1YNN”表示是否同意）
  • iOS 14+：Apple 的 ATT 框架授权情况（authorized/denied）

✅ 如果未授权，则只能做上下文定向广告（不能用ID、不能跨App）

（3）验签/限流/去重/超时

子模块

说明

重要性

验签

确认请求合法（防伪造）

可选

限流

控制每秒请求量

必须

去重

避免重复计价

必须

超时判断（tmax）

每次投放通常 <120ms，你最多用100ms响应

必须！

例如：

BidRequest.tmax = 120ms
你的系统必须在 ≤100ms 内构造 BidResponse

（4）授权校验（ads.txt / app-ads.txt / schain）

为什么？

防止买到未经授权的流量

被 IAB 要求支持 ads.txt/app-ads.txt（来源可追踪）

  • ads.txt：网站层授权的媒体ID
  • app-ads.txt：移动App的授权
  • schain（supply chain object）：记录流量“代理链条”

例子：

app-ads.txt:
app.example.com
direct, 123456, RESELLER

你要验证这个ID是不是合法、是不是一级流量源。

（5）反作弊初筛（IP/UA/速率等）

先做简单规则，比如：

  • UA不合法
  • IP在黑名单
  • 请求频率异常
  • 可视率 = 0（广告不会展示出来）

✅ 后续可对接三方：IAS、DoubleVerify 等

（6）富化处理（Geo/IP映射、设备、Deal参数注入）

  • 把IP → 城市/国家（MaxMind等库）
  • 把设备UA → 型号/品牌（UA解析库）
  • 给deal流量注入优先级、底价等信息

这样策略系统可以更精准投放。

（7）生成IR（Internal Request）

这是你的“标准内部数据结构”，可以叫：

{
  "req_id": "uuid",
  "ifa": "xx",
  "country": "US",
  "bundle": "com.xxx",
  ...
}

然后发送给策略系统做判断（投不投、怎么投）

4、MVP版本怎么实现（3–4个月内能上线）

步骤

子系统

技术建议

1

支持接1–2个SSP（如Mintegral + Adx）

接OpenRTB 2.5，用RESTful接口

2

请求链路模块

Java/Go实现，处理链条控制在20ms以内

3

IR结构统一

自定义IR对象，内部结构稳定

4

授权/隐私/限流/超时模块

拆分微服务or中间件

5

异常日志收集（Kafka）

方便调试，保留失败原因

6

返回BidResponse（含NURL等）

标准RTB格式 + 透传tracking url

7

内部调用策略系统

可用HTTP调用or本地模块初期集成

5、这一步易踩的坑

❌ 错误

原因

❌ 先接十几个SSP

→ 维护量大，调试困难，先接1–2个测试即可

❌ 每次请求都走第三方API

→ 性能会崩，必须提前缓存资源与参数

❌ 不做tmax限制

→ 你的投放响应超时了，没人再理你

❌ 忽略幂等处理

→ Win/Imp/Click 会被重复记账，账单乱套

七、策略系统详解（做什么 / 为什么做 / 怎么做）

策略系统是DSP中最核心的大脑，决定是否出价、出多少钱、出给谁。

1、策略系统图包含 3 大核心部分：

（1）决策主链（左侧树状图）

这是策略系统中的主决策路径，每一个过滤器就像是一个“守门员”，不断地筛选不可投广告，留下真正符合投放条件的候选广告。

步骤

模块说明

举例

过滤器1：白名单/品牌安全/合规

不让非法、敏感广告进入系统

赌博/色情/假冒品牌类广告直接剔除

过滤器2：排期/上下线时间/时段控制

比如广告只能投放在“周末白天”

当前时间不在投放计划里，就跳过

过滤器3：媒体/广告位/尺寸匹配

比如这个广告素材是640x360，只适合视频位

当前广告位是Banner，直接跳过

过滤器4：人群定向

用户是否命中广告设置的定向条件（性别/城市/标签）

用户是北京男性，而广告定向“上海女生” → 剔除

过滤器N：频控/预算控制

每个广告每天最多100次曝光 / 不超预算

当前这个广告已经花完钱了，跳过

✅ 候选广告池生成

满足所有条件的广告集合

比如原来1000条广告只剩下20条

💡 注意：每一步的判断要快（<1ms），否则整体RTB链条会超时！

（2）策略能力模块（右侧蓝+黄+红三大区块）

这是系统的“能力库”，为决策主链提供具体功能。

🟨 算法能力
  • 召回模型：从海量广告中选出少量候选
  • 出价模型：估算出一个价格（目标eCPI/固定价/预估CTR转eCPM）
  • 投放模型：控制投放节奏（比如把预算均匀花一天）
🟦 策略管理能力
  • 圈人策略：用户标签、活跃度、触达频次
  • 投放策略：兜底广告、频控、平滑投放
  • 优化策略：素材优选（点击率高优先）、首次用户识别
🟥 用户标签数据对接能力
  • 来自DMP的人群标签（如“游戏付费男用户”、“新注册未转化”）
  • 可用于做更精准的“人群定向”和“LTV出价”

（3）最后一步：出价 & 构建BidResponse

步骤

说明

Pacing调控

防止预算“早上8点全烧完”，支持按小时平滑分布

出价计算

固定价 or 根据目标eCPI/CTR推算eCPM

素材审核 & 创意检查

校验素材是否支持当前广告位（MIME类型、DCO参数是否完整）

构建BidResponse

给SSP响应：广告是哪条、出多少价、点击后跳哪儿、曝光上报URL 等

2、从0到1搭建建议（技术实现方向）

（1）必做（MVP范围）

模块

技术实现建议

规则过滤

用 Golang/Java 写一套“策略引擎”，输入请求对象 → 一步步判断

Pacing / 频控 / 预算

Redis 记录每条广告的预算、频控状态；Lua保证原子扣减

固定价 / eCPI换eCPM

简单公式：eCPI * CVR = eCPM；用默认CVR估值

Creative校验

校验素材尺寸/MIME是否符合当前请求

（2）可选（非MVP，MVP+后做）

模块

说明

CTR/LTV 模型

训练模型预估转化率、估值更精准

Bid Shading

针对First-price auction做“抑价出价”

用户标签联动

和DMP打通，支持“行为标签”定向

人群Lookalike

用付费用户做相似人群扩展

3、算法能力详解（召回模型 / 出价模型 / 投放模型）

（1）召回模型（Recall Model）

是什么？
  • 从策略过滤后剩下的可投广告池中，选出“最有可能赢得竞价，或最有价值的前N个广告”送去排序。
  • 常作为粗排或预选阶段，主要目的是快速、低延迟地缩小候选范围。
MVP 阶段怎么做？
  • 简单规则召回：
    • 例如：按近24小时CTR排序 → 取TOP 20
    • 或者只取投放状态为“激活”+预算充足的广告
后续优化方向
  • 加入内容匹配度、用户兴趣标签做交叉召回
  • 多策略召回融合（例如：兴趣匹配TOP10 + eCPM预估TOP10 + Explore随机TOP5）
举个例子：
  • 假设一个页面上能展示 3 条广告，但广告池里有 500 条可投广告，召回模型的作用就是先筛出 30 条最有希望的广告，剩下的再交给出价模块去排序。

（2）出价模型（Bidding Model）

是什么？
  • 出价模型的核心目标是：给每一个候选广告估一个合适的价格，在保证ROI（或eCPI）的基础上，以尽量低的价格赢得竞价。
常见类型

类型

描述

MVP阶段建议

固定出价

每条广告设一个固定出价（如$1.2）

首发可用

目标eCPI换算

eCPM = eCPI × CVR，CVR可设默认值

建议做

预估CTR出价

结合CTR预测模型计算 eCPM

MVP+ 可做

LTV出价

结合用户价值预测，做动态调整

成熟后期
示例换算：
目标eCPI = $2，当前人群CTR = 5%，CVR = 20%
eCPM = eCPI × CVR × CTR = 2 × 0.2 × 0.05 = 0.02 → 出价 $0.02 CPM
提示：
  • 可手动设定 CVR 初始值（如 10%），避免初期模型缺失
  • 要有一个兜底出价机制，例如 $0.5 CPM

（3）投放模型（Pacing Model）

是什么？
  • 控制广告的节奏与预算消耗，保证预算不要过早消耗或过晚无法投完。
功能目标：
  • 防止“早上烧完预算”
  • 实现均匀或策略性投放（高峰时段更多投）
  • 日预算 / 小时预算 / 展现频控分配
MVP建议：
  • Redis + Lua 实现一个简单 日内预算均匀消耗模型
  • 每小时预算 = 总预算 / 可投小时数
  • 每次竞价前检查预算余额，动态决定是否出价
举例：
广告预算：$240 / 天
投放时间段：08:00 - 20:00（共12小时）
每小时预算：$20
→ 当前小时已花$19.5 → 可继续投
→ 已花$20 → 本小时停投，下一小时恢复

（4）最小实现建议（从0开始）

模块

MVP 实现方式

推荐技术

召回模型

广告状态过滤 + Top CTR粗排

Redis / 内存缓存 +简单排序

出价模型

固定出价 + eCPI换算

Golang/Java 实现换算模块

投放模型

日预算均匀分配 + 每小时节奏控制

Redis + Lua脚本实现扣费

（5）总结：这三者如何串起来？

  1. 召回模型筛出最值得投的广告
  2. 出价模型为每条广告算出合适价格
  3. 投放模型判断当前是否“该投”，防止烧预算太快
  4. 最终组合成：BidResponse → 返回给SSP参与竞价

4、策略管理能力

（1）模块一：圈人策略（Audience Targeting）

做什么
  • 用“用户标签”来圈定你希望投放的人群
  • 控制用户的活跃度、触达频率，确保广告有效投放
为什么
  • 不同广告目标（拉新、促活、转化）需要触达不同类型的用户
  • 过度投放会引发用户厌烦，导致 ROI 下降
怎么做

能力

含义

实现方式

用户标签

如“爱玩游戏的iOS女用户”

接 DMP，支持标签过滤

活跃度识别

最近7天内活跃用户

日志计算 + 活跃规则

触达频控

1天最多3次

结合 Redis 计数实现频控阈值
MVP阶段建议实现：
  • 用户标签：可用“性别+OS+国家” + DMP 接口初步圈选
  • 活跃度：基于曝光日志做简单活跃筛选
  • 频控：Redis 实现每用户-广告级频控（key: user_ad_id）

（2）模块二：投放策略（Delivery Strategy）

做什么
  • 控制广告的展示节奏、预算平滑度，确保“不断电”地消化预算
  • 设置兜底策略，避免没有广告投放
为什么
  • 投放系统是长期博弈，不是1天打爆——需要节奏
  • SSP会惩罚填充率低的广告主，必须保证“有货可投”
怎么做

策略

含义

实现方式

频控

控制展示频率

Redis存储计数器

平滑投放

日预算平滑到小时

pacing模块（详见前文）

兜底广告

没有竞得广告时展示默认广告

特殊Campaign +兜底逻辑
MVP阶段建议实现：
  • 频控：每用户每日3次 + 每小时1次即可
  • 平滑投放：Redis维护每小时预算，用Lua实时减扣
  • 兜底广告：新建一类“默认广告”，无定向限制，总在候选池尾部

（3）模块三：优化策略（Performance Optimization）

做什么
  • 在已有素材中选出表现最好的素材优先展示
  • 区分首次用户和回访用户投放不同素材或出价
为什么
  • 投放效率是ROI核心，不能所有素材一视同仁
  • 首次曝光/首次转化成本高，需要特殊处理
怎么做

策略

说明

实现建议

素材优选

选点击率高的素材优先出价

维护每素材的CTR统计；排序使用

首次用户识别

识别是否首曝/首转化

利用设备ID建库标记 seen/converted
MVP阶段建议实现：
  • 素材优选：每日维护素材点击率 CTR，实时热更新前5名放前面
  • 首次识别：用 Redis 存储 user_id:campaign_id 是否曝光，支持首曝策略
举个真实流程例子

假设你是一个手游广告主，你今天要投放“新游戏推广”广告，预算 $300/天，目标用户为：

  • iOS用户
  • 最近1周活跃
  • 从未看到过这款广告（首次曝光）
  • 每人每天最多2次展示

那么整个策略系统做的事就是：

  1. 圈人策略过滤掉 Android + 非活跃用户
  2. 首次用户识别确认是否已曝光（Redis中查）
  3. 频控策略判断今天这个用户有没有超过2次曝光
  4. 平滑投放判断今天当前小时是否还有预算
  5. 素材优选从历史数据里选点击率最高的素材去出价
  6. 生成 BidResponse，参与竞价

5、用户标签数据对接能力

DSP 策略系统中至关重要的一环 —— 用户标签数据对接能力（User Tag Ingestion & Integration）。这是从 DMP → 策略投放逻辑的桥梁，也是你 DSP 能否“智能投放”的基石之一。如果没有标签数据，你的 DSP 永远只能“广撒网”，无法“精准打击”。

（1）做什么？——定义用户标签数据对接的职责

用户标签数据对接能力，是指：

“你的DSP如何接收来自DMP或外部系统的人群标签，并将这些标签用在广告投放的策略中。”

举例：

  • DMP告诉你：这批用户是“游戏付费男用户”
  • 你的策略系统：在竞价请求中识别该用户时，就能把出价提到$8 eCPI，而不是普通的 $2 eCPI

（2）为什么重要？——它的价值和业务意义

功能

好处

举例

精准人群定向

投放“想投的人”而不是随机人

投游戏广告只投玩过类似游戏的人

LTV（生命周期价值）出价

对“高潜用户”出更高价格

育儿APP对年轻妈妈出价更高

标签分层优化

便于模型分层训练/归因

转化高的标签投放更多预算

数据闭环

与MMP/CRM/BI形成数据闭环

高ROI人群形成“私有人群”资产

（3）从0到1怎么落地实现？（MVP版本）

不需要一次性做“亿级标签体系”，我们建议从可用+可扩展的角度，先做一个 最小可行版本 MVP：

数据入口层（Tag Input）

项目

MVP实现建议

DMP同步方式

支持 S3 上传 CSV / JSON 或接口 POST

标签粒度

初期支持10~20个常用标签（性别、OS、设备价格段、游戏类型兴趣、是否付费）

用户ID匹配

支持 GAID / IDFA / PPID / 外部ID映射表
标签处理层（Tag ETL）

项目

MVP实现建议

标签标准化

每条标签 = tag_key:tag_value，例如 interest=game

标签索引

使用 Redis 或 ClickHouse 构建 user_id → 标签反查

标签存储

每个用户最多支持100个标签；用 JSON 列或 KV存储
策略系统中的应用

投放逻辑

示例

包含标签

只投 interest=finance 的人

排除标签

不投 age=under18 的人

多标签组合

interest=game + gender=male

标签分层出价

interest=game 则 bid=eCPI 6，否则 2

（4）举个例子：如何基于标签调整策略逻辑

假设你是一个教育类APP广告主，目标人群是：

  • 高活跃度
  • 最近看过教育类内容
  • 是已婚女性（来自CRM数据）

你可以定义这样一个策略：

{
  "tag_filter": ["gender=female", "married=yes", "interest=education", "activeness=high"],
  "pacing": "linear",
  "bid_strategy": {
    "base_ecpi": 3.5,
    "ecpi_boost_tag": {"interest=education": 1.5}
  }
}

这个策略逻辑最终会在竞价中体现为：

  • 如果用户命中所有标签：出价 $5.0
  • 没有标签命中：不参与投放

五、DMP数据平台

1、DMP 数据平台在 DSP 中的核心作用

DMP（Data Management Platform）是 DSP 的“大脑记忆”模块，它专注于采集、组织、存储、处理与激活用户行为数据，最终的目的就是：

  • 帮 DSP 系统实现人群定向（投放精准）
  • 提升出价策略效果（投给对的人，用合适的价格）
  • 给报表/归因/策略做数据支撑

2、模块结构详解

（1）用户行为数据源（数据入口）

这部分的数据来源分 4 类：

来源

举例说明

APP/Web SDK埋点

你的广告主或媒体接入的 SDK，如用户点击、激活、转化

第三方人群包/DMP

合作伙伴提供的标签，如“母婴人群”

广告回传

竞价成功后曝光/点击/转化等事件回流

CRM业务系统

广告主线下或站内数据，如会员注册/消费记录等

（2）数据采集模块

接收并规范化所有数据，主要涉及：

  • 采集网关：一个统一的接收接口，验证来源、数据结构
  • 同意管理：合规支持，如 TCF / GDPR / CCPA / ATT（是否允许采集）
  • ID 映射：用户标识标准化，如 GAID / IDFA / PPID / Cookie / Cross-device ID

（3）存储与标签生成模块

这里是 DMP 最关键的部分，决定后续的定向能力和策略精准度。

  • 数据清洗与标准化：去重、补全、统一格式（例如设备品牌字段标准化）
  • 事件日志库：保存曝光/点击/转化等原始行为事件
  • 标签画像库：记录每个用户的标签，比如「高活跃」「点击率高」「安卓用户」
  • 人群管理模块：将多个标签组合成“人群包”，例如：「新注册但未付费男性用户」

（4）标签/人群的对接与回流

这一部分是 DMP 输出价值的地方，它将生成的数据资产向其他系统回流：

  • 回流给策略系统：投放时判断是否命中某人群，用于策略过滤和定价
  • 回流给资源管理系统：生成广告主可视的人群报表，方便优化投放
  • 回流给归因模块：关联广告转化来源，实现广告 ROI 测量

3、举个例子：从 DMP 到 DSP 的标签使用链路

你希望支持这样一个场景：

“我只希望把广告投给最近一周内注册了但还没付费的男性手游用户。”

这就需要 DMP 和 DSP 策略系统协同，流程如下：

4、从0到1如何落地构建 DMP 平台

模块

推荐方案

数据采集

Nginx + Kafka + Flink/Beam 实时处理

存储

ClickHouse（实时查询）+ Hive/HDFS（离线归档）

标签生成

Flink + Redis/ClickHouse

用户画像

UID（或PPID）为主键的 KV 存储，存储标签字段集合

对接协议

支持 RESTful API + Kafka Topic

其实DSP的DMP还需要另外写一篇文章讲解的，这里因为文章长度和我个人事件原因，暂时先不上传了，如果你们想了解DMP的话，我可以另外开一篇文章，因为你要搭建 DMP，必须回答3个问题：

❶ 我从哪里拿到这些“用户数据”？

❷ 我怎么把这些数据“变成用户标签”？

❸ 我的 DSP 怎么用这些标签“进行广告定向”？

数据来源（DMP 的原料）可以将数据源划分为三类，根据创业阶段逐步引入：

数据类型

来源方式

举例

难度

第一方数据（1P）

你接入的 APP SDK / 媒体合作方

用户浏览页面、点击广告、注册行为

⭐⭐（最基础）

第二方数据（2P）

你和某些 APP 合作拿到的行为数据

某资讯类APP分享了“感兴趣用户行为包”

⭐⭐⭐

第三方数据（3P）

第三方 DMP/数据公司提供的人群标签

TalkingData、极光、MobTech、百度DMP

⭐⭐⭐⭐

# dsp开发
Logo
CSDN-OPC开发者社区

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。

更多推荐

cover

『低代码开发的终极形态：AI 驱动的可视化编程』

avatar CSDN-OPC开发者社区
cover

上下文工程完全指南：打造高确定性AI Agent的四大支柱（建议收藏）

avatar CSDN-OPC开发者社区

Python内存管理终极指南：优化大型数据集处理性能的5个技巧

Python内存管理在处理大型数据集时常常成为性能瓶颈，掌握有效的内存优化技巧能让你的程序运行速度提升数倍。在python-mastery课程中，我们深入探讨了如何通过不同的数据结构选择来显著降低内存使用。## 🚀 为什么Python内存管理如此重要？当处理像芝加哥公交系统数据（包含577,000多行记录）这样的大型数据集时，内存使用可能从12MB激增到50MB以上！这不仅仅是数字问题，

avatar CSDN-OPC开发者社区