程序化广告投放层级与定向配置：Campaign 层级模型、定向继承与缺省语义

本文属于 Bidder 竞价服务架构 系列（配置面一篇）。

总览把 Bidder 拆成七级漏斗，解析篇把原始请求变成带 deadline 的内部对象 BidContext。紧接着 Bidder 就要拿它去和「广告的定向条件」做匹配——但这份定向条件本身从哪来？它不在在线链路里，而是广告主在投放后台维护的一棵配置树。本篇把视角从「在线执行」切到「离线配置」：讲 Campaign 层级模型、每层挂什么、定向如何跨层合并、缺省语义，以及这份配置如何被编译、下发给 Bidder。它与讲运行时匹配的定向过滤篇互为表里——本篇定义规则，那篇执行规则。

读者与前置：面向对程序化投放有基础认知的工程师 / 产品。读过本系列总览与解析篇会更顺，但非必需——本篇自成一体，可当作 DSP 配置面的独立入门。

解析篇把原始请求变成了带 deadline 的 BidContext；再往下，Bidder 就要拿它去和「广告的定向条件」求交（这一步的运行时执行，是定向过滤篇的主题）。而这里要问的是更前一步：Bidder 拿来匹配的那份「广告定向条件」是怎么来的？ 它不是凭空出现的，而是一套被人配出来的、有层级结构的东西。广告主在投放后台里从来不是「配一个广告」这么简单，而是维护一棵四层的配置树：一个账户下有多个推广计划，一个计划下有多个广告组，一个广告组下挂多条创意。定向、预算、出价、频控这些约束分别挂在不同层级上，运行时看到的「某条广告的定向条件」，其实是这棵树从根到叶逐层合并出来的结果。

四层对象模型：广告主 → 推广计划 → 广告组 / 订单项 → 创意，每层 1:N。目标与预算在上、定向与出价在中、素材在下——越往下越具体。定向的「主战场」是中间的广告组 / 订单项层（橙色）。

TL;DR

• 投放配置是一棵四层树：广告主（Advertiser）→ 推广计划（Campaign）→ 广告组 / 订单项（Ad Group / Line Item）→ 创意（Creative）。每层 1:N，职责自上而下从「目标 / 预算」过渡到「定向 / 出价」再到「素材」。
• 配置项各归其层：营销目标与总预算在 Campaign；定向、出价、频控、Pacing 在广告组 / 订单项（定向的主战场）；素材与落地页在创意；结算主体与全局品牌安全在广告主。放错层会造成重复配置、口径打架。
• 定向跨层是「逐维求交」，不是「覆盖」：子层只能在父层基础上收窄、不能放宽——同维度跨层取交集（AND）、排除项向下累加。子层若超出父层范围，交集为空 → 这条广告投不出去。注意求交只针对集合型定向维度；出价 / 预算 / Pacing 这类标量值不「合并」，只谈归哪一层。
• 「定向放几层」是要显式拍板的设计决定：多层定向 + 求交更灵活，却招来继承 / 空集这一整类坑；单层定向（只在广告组）更难配错，共性靠模板复用。别默认「当然多层求交」（见 4.5）。
• 出价分两种：手动出价下出价数值归广告组；自动出价（tCPA / 最大转化）下广告组只放目标、真正的 bid 是运行时逐请求算出的产物。
• 最贵的坑是缺省语义：与运行时同源——「子层某维度没设 = 继承父层 / 全不限 / 全不通」必须后台展示、编译、运行时三方对齐。配错不报错，只是悄悄错投或欠投（详见 5.2）。
• 配置不是直接喂给 Bidder 的：投放后台的树先存进元数据库，再经近线编译摊平成「可投快照」、下发到 Bidder，运行时只做只读匹配。这条链路另有专篇（见配置落地篇）。
• 与运行时的边界：本篇讲配置怎么组织、怎么合并（配置面）；定向过滤篇讲这份规则在毫秒内怎么被执行（运行时）。

Table of contents

一、为什么需要层级：不是「一个广告」，而是一棵配置树

新手常把「投一个广告」想成一件扁平的事：选个素材、设个定向、给个预算就完事。但真实的程序化投放里，一个广告主往往要同时跑几十上百条投放线——不同市场、不同人群、不同素材、不同出价策略并行。如果每一条都从零平铺配置，会立刻撞上三个问题：

• 重复配置：同一个品牌安全黑名单、同一套转化归因口径，要在几百个投放单元里各填一遍，改一次要改几百处。
• 口径打不齐：这条投放单元的「欧盟」含不含英国（英国已脱欧）、那条又按另一套算，同一个广告主内部就先自相矛盾。
• 预算算不清：广告主关心的是「这个季度这个品牌总共花多少」，而不是几百条投放线各自的零头之和。

层级化配置就是为解决这三件事而生：把共性上提到父层复用，把个性下沉到子层细化。于是自然形成一棵树——共性在上、个性在下。这与 Bidder 总览里「漏斗」是两个正交的视角：漏斗是请求在运行时被逐级过滤的路径，层级树是广告被配置时的组织结构；后者定义了前者要匹配的规则。

二、四层对象模型：各层的职责边界

不同 DSP 的命名不完全一致（Google DV360 叫 Insertion Order / Line Item，The Trade Desk 叫 Campaign / Ad Group，国内平台多叫推广计划 / 广告组），但抽象出来几乎都是这四层：

一条贯穿全篇的直觉：越往上越「抽象、共享、关乎钱与目标」，越往下越「具体、独有、关乎怎么投与投什么」。

2.1 广告主 / 账户：全局口径的锚点

广告主层不参与「这次曝光投不投」的判断，但它定义了一整套全局口径：谁来付钱、哪些媒体永不投（品牌安全黑名单）、一次「转化」到底怎么算（归因窗口、转化事件定义）、可用的人群包与转化数据资产。这些东西一旦下沉到每条投放线各配一份，就必然打架——所以它们必须在最高层定义一次、向下全局生效。这也呼应定向过滤篇 3.2 节的黑白名单：品牌安全黑名单天然是账户级的全局约束。

2.2 推广计划：目标与预算的容器

Campaign 回答的是「这次营销活动要达成什么、总共花多少、投多久」。它承载三样东西：

• 营销目标 / 优化目标：是冲曝光、要点击，还是要转化 / 激活？这直接决定下游 Bidder 出价时用哪把尺子——CPC 目标只需 CTR，CPA / CPI 目标才要乘 CVR（见 Bidder 出价一节）。
• 总预算：广告主真正关心的钱袋子口径。日预算、总预算通常在这一层设定，再向下分配。
• 投放排期：整个活动的起止时间。它是一切下层投放的时间边界。

2.3 广告组 / 订单项：定向的主战场

这是信息密度最高的一层，也是本篇的重点。绝大多数「怎么投」的决策都落在这里：

• 定向条件：地域、时段、设备、媒体 / 版位、人群包、上下文——这一层是定向维度的主要落点（详见第四、五节）。
• 出价：这条投放线愿意为一次曝光 / 点击 / 转化出多少。
• 预算分配与 Pacing：从 Campaign 总预算里切给这条线多少、以什么节奏消耗（Pacing 的运行时机制见 Bidder 预算篇）。
• 频次控制：同一用户在这条线上最多看几次（频控的层级归属见第七节）。

为什么定向集中在这一层而不是创意层？因为**「投给谁」通常和「用哪张素材」是两件正交的事**：同一套定向（加州 + 纽约州 + iOS + 高价值人群）往往要用多张创意做 A/B，把定向配在广告组、创意只管素材，才能避免「每换一张图就要重配一遍定向」。

2.4 创意：被展示的素材

创意层是叶子节点，只关心被展示的东西本身：素材文件、尺寸格式、落地页、审核状态。定向在这一层通常只保留与素材强绑定的少量维度——比如某尺寸只能投某类版位、某语言素材只投某语言环境。把大部分定向留在广告组、只把「素材决定的约束」留在创意，是职责最清晰的切法。

不过「广告组 → 创意」这条边不只是「挂素材」这么静态——一个广告组下往往挂多条创意，投放时要在它们之间选一条：轮播（均匀轮转）、择优（按 CTR / CVR 动态倾斜到表现好的）、或按权重分配。这一步（创意选择 / 优化）是层级在服务期的真实行为，发生在「这条广告组已经赢得竞价之后」（呼应总览的填充阶段），与「投给谁」的定向判定是两件事。本篇聚焦配置组织，创意优化本身另属一个话题。

2.5 树之外：实验 / 版本是叠加上去的正交一维

四层树描述的是「稳态配置」，但真实投放几乎都要做 A/B 实验——对同一条广告组，同时跑「定向 A / 出价 A」和「定向 B / 出价 B」两个版本比效果。实验通常不是树里的第五层，而是叠加在某一层（多为广告组 / 创意）之上的一个正交维度：按流量比例把用户分桶，不同桶走不同配置版本。它的存在提醒一件事——层级树是「配置的组织」，不等于「投放的全部结构」；实验、版本、灰度都是横切这棵树的另一套维度（与后文频控「用户维度横切树」异曲同工）。本篇聚焦稳态层级，实验体系另属一个话题。

层级树是纵向的配置组织；实验 / 版本、频次控制是横切整棵树的正交维度——前者按流量分桶、后者按用户聚合计数，都不属于树的任何一层。

三、每层挂什么：配置项为什么各归其层

把配置项放对层级，本质是回答一个问题：这个约束的「作用范围」有多大？ 作用于整个账户的放广告主层，作用于一次活动的放 Campaign，作用于一条投放线的放广告组，作用于一张素材的放创意。放错层会同时踩两个坑——放太高则失去灵活性（想给某条线单独调却调不了），放太低则重复劳动（每条线都要配一遍还容易配歪）。

一句话：层级不是为了好看，而是让每个约束只在它该生效的范围里配置一次。归层原则就一句——按作用范围就近落层。

四、定向的跨层级合并：继承、收窄与冲突

这是配置面最容易出错、也最能体现层级设计功力的地方。既然定向可以配在 Campaign、广告组、创意多层，那么运行时「这条广告到底定向了什么」就必须由多层合并得出。合并的语义不是「覆盖」，而是「逐维求交、只能收窄」。

定向合并 = 逐维求交 + 排除累加。CA-NY-iOS-HighValue 的地域 [CA, NY] 与父层 [US] 求交仍是 [CA, NY]（收窄成功）；Tokyo-Retarget 的地域 [Tokyo] 与父层 [US] 求交为空——子层超出父层范围时交集为空，这条线一条流量都投不出去。这类「配了却投不出」的问题不报错，极难第一时间发现。这张图正是下文「一个完整例子」那棵示例树的图解。

4.1 继承：父层的约束向下自动生效

子层默认继承父层的定向：Campaign 设了「地域=美国、排除赌博类目」，其下所有广告组即便自己没设，也自动带上这两条。继承的好处与第一节一致——共性上提、一处配置全局生效。

4.2 收窄：子层只能更严，不能更宽

关键约束：子层对某维度的设定，只能是父层的子集。广告组可以把「美国」收窄成「加州 + 纽约州」，但不能把它放宽成「全球」。工程上，合并的语义固定为同一维度跨层取交集：

有效地域 = Campaign.地域 ∩ 广告组.地域 ∩ 创意.地域
有效设备 = Campaign.设备 ∩ 广告组.设备 ∩ 创意.设备
...每个维度独立求交...

排除定向则相反——排除项跨层累加（并集）：任一层排除了某媒体 / 类目，合并后就一直排除。正向求交、排除累加，二者方向相反，实现时必须分开表达（与定向过滤篇 5.2 节「正向集合与排除集合分开存」同源）。

4.3 冲突：交集为空 = 这条线投不出去

收窄语义带来一个隐蔽后果：如果子层设的值落在父层范围之外，求交结果为空，这条投放线就一条流量都匹配不到。上图广告组 B 设「东京」、父层是「美国」，交集为空——广告主在后台明明「配了定向」，线上却零曝光，且系统不报错。这类问题的排查成本极高，好的投放后台应当在保存配置时就做跨层校验、提示「该定向与上层冲突，将无法投放」，而不是等上线后靠零消耗才发现。

一个完整例子：从配置树到有效定向

把 4.1–4.3 串起来。下面是一棵极简配置树（YAML 示意，只保留定向相关字段）：

Advertiser: Acme                     # 全局约束
  exclude_category: [adult]          # 品牌安全，向下累加
  Campaign: Q3-Brand-US              # 一次活动的硬边界
    geo: [US]                        # 正向定向：美国
    exclude_category: [gambling]     # 再排除赌博
    AdGroup: CA-NY-iOS-HighValue     # 收窄成功的一条线
      geo: [California, New York]    # ⊂ US，收窄
      device: [iOS]
      audience: [high_value]
    AdGroup: Tokyo-Retarget          # 越界的一条线
      geo: [Tokyo]                   # ⊄ US，越出父层
      device: [Android]

逐维合并（正向求交、排除累加）后，运行时真正拿去匹配的有效定向是：

两条线的排除项都自动带上了 adult（广告主级）+ gambling（计划级）——排除累加与正向求交方向相反。Tokyo-Retarget 的地域求交为空，是 4.3 那类「配了却投不出」的典型：广告主看到「我明明配了东京」，却不知道它早被父层的美国边界求交没了。

4.4 覆盖式 vs 求交式：只针对定向维度，别把标量值也算进来

并非所有平台的所有定向维度都用「求交」。有的维度采用覆盖式（子层设了就以子层为准、无视父层）。两种语义都自洽，但必须逐维明确、统一、且和后台展示一致：

• 求交式（更常见、更安全）：子层永远不能突破父层，适合地域、类目排除等「父层是硬边界」的集合型维度。
• 覆盖式：子层完全接管该维度，适合某些「下层就该说了算」的集合型维度（如部分平台的版位选择）。

混淆二者是配置面 bug 的高发区。把上面示例树里的 Tokyo-Retarget 拿来对照最直观——同一条 geo = [Tokyo]、父层 geo = [US] 的配置，两种语义结果完全相反：

正因如此，地域、类目排除这类「父层是硬边界」的维度几乎总用求交式：宁可让子层越界时「投不出」（显性、可校验），也不要它「悄悄投出界」（隐性、上线才发现）。父层的约束一旦能被子层覆盖架空，品牌安全与合规边界就形同虚设。

还要澄清一个边界：出价、预算、Pacing 这类「标量值」不在本节讨论范围内。它们不是集合型定向，没有「跨层求交 / 覆盖」的合并语义，只是「某个值归属于某一层」（见第六节）。把标量值和定向维度塞进同一张「合并规则」表本身就是概念混淆——定向维度谈「怎么合并」，标量值只谈「归哪一层」。

一张「按维度锁死合并语义」的速查（示例口径，具体以平台约定为准）：

4.5 定向该放几层：单层 vs 多层，是要显式拍板的设计决定

回头看 4.1–4.3：继承、收窄、交集为空——这一整套复杂度，其实都源自一个设计选择：允许定向出现在多个层级、并跨层求交。它不是唯一解，甚至不是最常见的解。现实中很多 DSP 采用定向单层化：定向只存在于广告组 / 订单项一层，计划层根本不放定向，于是「跨层合并」这件事压根不发生。两种设计的权衡很清楚：

• 多层定向 + 求交：更灵活——可以在计划层设「这次活动全公司都投美国」的硬边界，各广告组再各自收窄。代价是引入继承 / 收窄 / 缺省 / 交集为空这一整类语义与 bug——4.3 那个「配了却零投放、还不报错」正是这个设计自己招来的。
• 单层定向（只在广告组）：更简单、更难配错——没有跨层合并就没有空集陷阱，缺省语义也从「层级 + 运行时两维」退化成「运行时一维」。代价是共性定向要在每条广告组里重复配置（用模板 / 批量操作缓解）。

没有绝对优劣，但这是设计层级时第一个要显式拍板的决定，而不是默认「当然是多层求交」。一个务实的折中：正向定向只放广告组（单层），把真正需要全局硬边界的少数维度（品牌安全、合规地域）以「排除型硬闸」上提到广告主 / 计划层——排除项跨层累加（并集）永远只会让范围更小、不会产生空集，恰好避开了多层正向定向最危险的那部分（见 4.2 正向求交 vs 排除累加的方向差异）。

两种定向层级设计的权衡（沿用 Q3-Brand-US 那棵树）：① 多层 + 求交灵活，但正向定向跨层求交会在子层越界时产生空集（Tokyo-Retarget 投不出）；② 单层定向把正向定向收在广告组一层、只把排除型硬闸上提，从结构上消灭空集陷阱。

五、定向条件本身：维度、正向 / 排除、缺省语义与供给定向

跨层合并之外，单层内部的定向条件也有一套语义。这部分与定向过滤篇第四、五节同源——那篇讲运行时怎么求值，这里讲配置时怎么表达。不重复展开，只点出配置面特有的注意点。

5.1 定向维度：配置侧的组织

广告组层能配的定向维度大致就是定向过滤篇第四节那张表：地域、时段、设备 / 环境、媒体 / 版位、人群包 / DMP、上下文 / 内容。配置面要额外想清楚两件事：

• 维度内 OR、维度间 AND：一个维度里选多个值（加州 OR 纽约州）是「或」，多个维度之间（地域 AND 设备）是「且」。后台 UI 要让广告主清楚地感知到这个区别，否则很容易配出「以为是或、其实是且」的空定向。
• 正向 vs 排除要在 UI 上区分开：同一维度「只投 X」（include）和「投所有但排除 X」（exclude）语义相反，后台应作为两种明确的输入，而非靠一个字段的正负号混合表达。

5.2 缺省语义：配置面最贵的一个坑

定向过滤篇 5.3 节把缺省语义称为「最贵的一个坑」。在配置面它更棘手，因为多了一个维度——除了运行时的「未设 = 不限 / 全不通」，还有层级维度的「子层未设 = 继承父层」。三个语义必须同时对齐：

• 后台展示语义：广告主在 UI 上看到「地域：未设置」时，他以为的是什么？
• 编译 / 合并语义：近线编译时，「未设」被当成「继承父层」还是「空集」？
• 运行时语义：Bidder 匹配时，空的定向集合算「全通」还是「全不通」？

三者只要有一处不一致，就会出现经典事故：广告主没设地域、以为「继承父层的美国」，编译时却被当成「空集」、运行时又把空集当「全不通」——结果这条线一条都投不出去，且全程不报错。守住它的唯一办法，和运行时一样：明确约定、写进单测、用真实配置回放校验。

5.3 供给 / ADX 定向：不在树上，以定向维度接入

有一个维度容易被误当成「投放对象树上的一个节点」，其实不是——AdExchange（ADX）/ 供给来源。一句话摆正关系：广告层级树回答「投给谁、投什么」，ADX 回答「从哪买」；后者不是树上的节点，而是作为供给定向（inventory targeting）这一维度接进广告组这一层。要分清两个层面：

• 平台级接入（不在投放树、广告主碰不到）：DSP 与哪些 ADX 对接是平台全局配置——endpoint、OpenRTB 版本与方言、tmax 口径、QPS 配额、seat id、bidfloor / 币种口径、结算方式，由 DSP 运维 / 对接团队维护（对应解析篇 2.2 节的 per-ADX 适配规则）。它在运行时体现为：每个 Bid Request 天生带着来源 ADX，解析后落在 BidContext.exchange 上——流量是从某个 ADX 来的，ADX 是供给入口，不是要投的对象。
• 投放级选择（广告主配、落在广告组）：广告主能配的是「这条投放线愿意从哪些 ADX / 供给来源买量」，它就是 5.1 节「媒体 / 版位」维度的一部分（不少平台单列为「供给定向」）。账户级还可再设全局供给黑白名单（某些 ADX 全公司都不投，与 2.1 节品牌安全同源）；PMP / Deal ID 这类私有交易也在广告组层绑定，一个 Deal 关联到特定 ADX / SSP（见交易模式篇）。

一句话说清关联方式：ADX 是「供给定向」维度的取值集合，和地域 / 设备一样参与第四节的「逐维求交、只能收窄」合并。运行时落地也与其它维度一致（见定向过滤篇）——先在请求级 gating 按账户级供给黑名单一刀切（来源 ADX 命中即整请求 no-bid），再在候选级布尔匹配要求请求的 exchange 落在广告组允许的供给集合里，否则这条广告不匹配。

六、预算与出价的层级：钱袋子在上、出价在下

预算和出价都和钱有关，但它们归的层级不同，背后是清晰的分工。

6.1 预算：总额在 Campaign，分配与 Pacing 在广告组

• 总预算在 Campaign：因为广告主关心的是「这次活动总共花多少」，而不是几十条广告组各自的零头。
• 分配与 Pacing 在广告组：Campaign 的总预算向下切分给各广告组，每条线再按自己的节奏消耗。这与 Bidder 预算篇的「本地分片」是同一件事的两端——配置面决定「怎么切」，运行时决定「怎么花且不超投」。

这里有个常见张力：Campaign 总预算与广告组预算之和如何对齐？不同平台做法不一：有的允许广告组预算之和超过 Campaign 总预算（超卖），由 Campaign 总预算做最终封顶——某条线花不完时预算能流向其他线；有的要求子预算之和 ≤ 父预算；也有平台根本不设广告组级预算，预算只在 Campaign、由 Pacing 向下分配。无论哪种，只要存在两级预算，运行时的预算闸门就要同时校验广告组与 Campaign 两级是否还有钱。

6.2 出价：为什么在广告组

出价配在广告组，因为不同定向 / 人群，值的钱不一样：高价值人群愿意出更高价、宽泛流量出低价。把出价配在广告组，正好让「一条定向 = 一个出价」一一对应。Campaign 层通常只设优化目标（CPC / CPA / CPI）——它决定出价用哪个公式，具体出价数值则落在广告组。

但以上说的是手动出价。现代 DSP 大量使用自动出价 / 出价策略（tCPA、最大转化、目标 ROAS），此时「出价」不再是广告组上的一个常数：广告组上放的是目标（如 tCPA = 50 元），真正的 bid 由 Bidder 在运行时结合预估 CTR / CVR 与 pacing 系数逐请求算出来（见 Bidder 出价 / 预算篇）。所以更准确的说法是——手动出价时出价数值归广告组；自动出价时广告组只放目标、出价数值是运行时产物。这不改变层级归属的大框架，但提醒别把「出价」想成一个躺在广告组上的静态字段。

七、频次控制与排期的层级归属

7.1 频控：跨线去重放 Campaign，单线封顶放广告组

频次控制（限制同一用户看某广告的次数）的层级归属，取决于你要控什么：

• 广告主 / 跨计划级频控：同一用户对这个品牌 / 广告主的全部活动最多看 N 次——用于总量控频，避免用户在不同活动间被同一品牌反复轰炸。它比下面两级更难，因为要跨整棵计划树聚合同一用户的曝光。
• Campaign 级频控：同一用户对整个活动（跨所有广告组）最多看 N 次——用于品牌活动的「总曝光去重」。
• 广告组级频控：同一用户对这条投放线最多看 N 次——最细粒度。

多级可以叠加（先满足广告主级总帽、再满足 Campaign 级、最后广告组级分帽）。

这里有个容易被层级思维带偏的关键点：频控的统计口径是「用户」，天然横切整棵层级树。同一个用户的曝光计数要跨广告组 / 计划 / 广告主聚合——所以频控虽然「配置」在某一层，它的状态却不属于树上任何一个节点，而是 用户 × 层级节点 的交叉计数。这也解释了为什么它和实验维度（2.5）一样，是「横切树」而非「树的一层」。至于这些计数在运行时怎么被高效判定（哪些能前置、哪些必须查 Redis），是定向过滤篇第六节讲的运行时时机问题，与配置归层是两回事。

7.2 排期：Campaign 定边界，广告组做时段

• 投放排期（flight dates）在 Campaign：活动的起止日期是整个活动的硬边界。
• 时段定向（dayparting）在广告组：具体到「工作日 9–18 点投」这类细粒度时段，落在广告组的定向里。二者是「边界 vs 细化」的关系——广告组的时段必须落在 Campaign 排期之内（又一次收窄）。

排期与时段都绕不开一个坑——时区。「工作日 9–18 点」到底按广告主所在时区还是用户本地时区解释？跨国投放里这两者能差出十几个小时。必须显式约定按哪种时区、并在编译期把口径定型（呼应 5.2 的缺省语义定型），否则同一条「9–18 点」在不同市场的实际投放窗口全乱。这类 bug 和缺省语义同属一类——不报错，只是悄悄投错了时间。

配置怎么落到投放？ 这棵配置树如何被近线编译成可投快照（层级合并 → 口径归一 + 缺省语义定型 → 建倒排索引 + 位图 → 打版本号），是另一整篇的话题，已单独成篇：配置落地：从投放后台到索引快照。一句话闭环：广告主配置树 →（近线编译）→ 版本化索引快照 →（下发热更新）→ Bidder 运行时定向过滤——本篇讲「配置怎么组织与合并」，配置落地篇讲「怎么编译成快照、怎么触发、依赖哪些组件」，手把手篇讲「快照怎么下发装载进 Bidder」，定向过滤篇讲「快照怎么在毫秒级被匹配」。

八、生产实战：常见问题

• 定向跨层冲突导致零消耗：子层定向超出父层范围、求交为空，广告主「配了却投不出」，系统不报错。应在保存时做跨层校验并给出显式提示（见 4.3）。这类坑很大程度上是多层定向 + 求交设计自招的——若不需要全局硬边界，优先单层定向 + 排除型硬闸，从源头消灭空集（见 4.5）。
• 求交式 / 覆盖式混用：把本该求交的维度做成覆盖，子层悄悄突破父层边界（品牌安全、地域尤其危险）。每个维度的合并语义必须明确且文档化；别把出价 / Pacing 这类标量值也塞进合并规则（见 4.4）。
• 缺省语义三方不一致：后台展示、编译合并、运行时匹配对「未设」的理解不统一，造成大面积错投或欠投。用真实配置回放校验（见 5.2）。
• 把出价当静态字段：忽略自动出价，接入 tCPA / 最大转化时会对不上——此时广告组只放目标，出价是运行时产物（见 6.2）。
• 预算层级之和对不齐：广告组预算之和与 Campaign 总预算的关系没想清楚，运行时预算闸门只校验一级，导致超投或某条线饿死。存在两级预算就两级都要校验（见 6.1）。
• 时区口径不统一：dayparting / 排期按错时区（广告主 vs 用户本地），实际投放窗口全乱且不报错。编译期把时区口径定型（见 7.2）。
• 模板批量改动的连锁效应：用模板 / 批量操作给上百个广告组套同一份定向时，一次「统一收窄地域」的批改，可能把个别本就很窄的广告组求交成空集。批量操作前应预演有效定向、给出会变空的清单，再确认执行。
• 清空维度 ≠ 放开定向：运营在子层「清空」某个定向维度，本意是回退到父层继承；但若系统把「空」理解成「无此约束（全集）」而非「继承父层」，就会悄悄放宽投放。清空的语义（继承 vs 全集）必须与后台提示严格一致（呼应 5.2）。

九、速查表

• 四层树：广告主 → 推广计划 → 广告组 / 订单项 → 创意；目标 / 预算在上、定向 / 出价在中、素材在下。
• 配置项归层：按作用范围就近落层——全局的上提、独有的下沉。
• 定向合并：逐维求交 + 排除累加，子层只能收窄不能放宽；交集为空 = 投不出去。只针对集合型定向维度。
• 合并语义要明确：求交式（父层是硬边界）vs 覆盖式（下层说了算），逐维文档化；标量值（出价 / Pacing）不合并、只谈归层。
• 定向放几层要拍板：多层求交灵活但有空集陷阱；单层定向更稳、共性靠模板（见 4.5）。
• 缺省语义三方对齐：后台展示 = 编译合并 = 运行时匹配，配错不报错。
• ADX 不在树上：AdExchange 是「从哪买」的供给定向维度（选择落广告组、全局黑白名单在广告主），其接入本身是平台级配置；运行时按来源 exchange 求交（见 5.3）。
• 预算 / 出价：总预算在 Campaign、分配 / Pacing / 出价在广告组；两级预算都要校验；自动出价下出价是运行时产物。
• 横切树的维度：频控（用户维度）与实验 / 版本不是树的某一层，而是横切整棵树的正交维度。
• 落地链路（另有专篇）：配置树经近线编译（合并 / 归一 / 建索引，粒度是订单项）成版本化快照，细节见配置落地篇。
• 与运行时的边界：本篇讲配置怎么组织与合并，定向过滤篇讲规则怎么被毫秒级执行。

程序化投放的配置面，本质是一棵把共性上提、把个性下沉的四层树：它决定了运行时那份定向规则长什么样、怎么合并出来、缺省时算什么。理解了这棵树的分层职责、「逐维求交、只能收窄」的合并语义、以及三方对齐的缺省语义，就掌握了定向过滤篇反复强调的「与投放后台严格对齐」的另一半。配置面配得清晰，运行时才匹配得正确——这棵树是整条竞价漏斗真正的「规则之源」。

延伸阅读

• 配置落地：从投放后台到索引快照：本篇的「下一步」——这棵配置树如何被近线编译成版本化索引快照（编译前置、版本化、全量 vs 增量、触发机制与组件依赖的深挖）。
• Bidder 定向过滤（Targeting Filter）：本篇的「运行时对应物」——这份配置编译成的规则，如何在毫秒级被请求级 gating 与候选级布尔匹配执行。
• Bidder 竞价服务架构设计（总览）：配置落地所依赖的数据面原则（只读只算、状态靠回灌、原子切换）与七级漏斗全景。
• Bidder 解析层（Parse）：定向合并所依赖的字段归一化，与解析层的口径归一同源。
• 程序化广告生态全景：广告主 / DSP / ADX 的位置，理解「配置在 DSP、匹配在 Bidder」的分工背景。
• 程序化交易模式：RTB / PMP / PD / PDB：不同交易类型会改变定向与出价的配置口径。

规范与一手资料：

• IAB Tech Lab. OpenRTB 2.6 Specification：定向所匹配的曝光字段（geo、device、imp）的权威定义。
• Google. Display & Video 360 · Insertion Orders and Line Items：一个成熟 DSP 的层级模型参考（IO / Line Item）。
• RoaringBitmap. Roaring Bitmaps：有效定向倒排后做集合求交的核心数据结构（召回篇展开）。

附录：术语表

• 层级模型（campaign hierarchy）：广告主 → 推广计划 → 广告组 / 订单项 → 创意 的四层配置树。
• 广告主 / 账户（Advertiser）：结算与合规主体，承载全局品牌安全、归因口径与数据资产。
• 推广计划（Campaign）：一次营销活动的容器，承载营销目标、总预算、投放排期。
• 广告组 / 订单项（Ad Group / Line Item）：一条具体投放线，是定向、出价、预算分配、频控的主要落点。
• 创意（Creative）：被展示的素材，承载文件 / 尺寸 / 落地页 / 审核状态与少量创意级定向。
• 定向继承（inheritance）：子层默认带上父层的定向约束。
• 收窄（narrowing）：子层只能在父层范围内更严格，不能放宽；同维度跨层求交。
• 求交式 / 覆盖式合并：跨层同维度取交集 / 由子层完全接管，两种合并语义须明确区分。
• 缺省语义（default semantics）：某维度 / 某层未设定向时的约定（未设 = 继承 / 不限 / 全不通），须后台、编译、运行时三方对齐。
• 有效定向（effective targeting）：配置树逐层合并后、运行时真正用于匹配的定向集合；候选粒度通常是广告组 / 订单项，而非创意。
• 单层 / 多层定向：定向只放广告组一层 / 分布在多层并跨层合并；前者更难配错，后者更灵活（见 4.5）。
• 自动出价（auto-bidding）：广告组只设优化目标（tCPA / 最大转化 / 目标 ROAS 等），实际出价由 Bidder 在运行时按目标 + pacing 逐请求算出，而非广告组上的静态数值。
• 供给定向 / ADX 定向（inventory targeting）：选择从哪些 ADX / 供给来源买量的定向维度，选择落在广告组、全局黑白名单在广告主；ADX 的接入本身（endpoint / 协议 / seat / tmax）是平台级配置，不在投放对象树内。
• 横切维度：频控（用户维度）、实验 / 版本、灰度等——不属于层级树的任何一层，而是跨节点聚合 / 分桶的正交维度。
• 近线编译：把配置树摊平成可投快照（层级合并 → 口径归一 → 建倒排索引 + 位图）的离线 / 近线过程。