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

本文是 广告配置与索引 系列的第 1 篇（层级与定向）。 全系列 3 篇：

1. 程序化广告投放层级与定向配置
2. 配置落地：从投放后台到索引快照
3. 手把手走一遍定位式位图倒排

一句话定位：本文从离线配置视角剖析程序化投放的四层对象模型，讲清各层职责边界、定向跨层合并的逐维求交机制以及极易踩坑的缺省语义。

读者与前置：面向对程序化投放有基础认知的工程师与产品经理。建议先阅读 买侧竞价链路 的 总览 与 解析篇，但本篇亦可作为需求方平台（DSP）配置面的独立入门指南。

在程序化广告的真实投放场景中，解析篇已经将原始请求转化为了带有 deadline 的 BidContext。紧接着，Bidder 需要将其与广告的定向条件进行匹配。然而，这份至关重要的定向条件究竟从何而来？事实上，它并不在在线链路中凭空产生，而是由广告主（Advertiser）在投放后台精心维护的一棵四层配置树。广告主在投放后台绝非仅仅「配置一个广告」，而是需要统筹管理多个推广计划、广告组与海量创意。定向、预算、出价以及频次控制等约束条件分别挂载于不同层级之上，我们在运行时所看到的「某条广告的定向条件」，本质上是这棵配置树从根节点到叶子节点逐层合并的最终产物。

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

TL;DR

• 四层配置树模型：投放配置由广告主（Advertiser）→ 推广计划（Campaign）→ 广告组 / 订单项（Ad Group / Line Item）→ 创意（Creative）构成。每层呈现一对多的关系，职责自上而下从「目标与预算」平滑过渡至「定向与出价」，最终落实到「素材」。
• 配置项各归其层：营销目标与总预算归属于推广计划；定向、出价、频控与 Pacing 落在广告组（即定向的主战场）；素材与落地页绑定于创意；而结算主体与全局品牌安全则由广告主层统领。配置错位会导致规则冲突与管理混乱。
• 定向跨层合并为逐维求交：子层只能在父层基础上收窄而不能放宽，同维度跨层取交集（AND），排除项则向下累加。需要强调的是，若子层超出父层范围，交集将为空，导致该广告无法获得任何曝光。
• 定向层级设计的权衡：采用多层定向与求交机制虽然灵活，却容易引发继承与空集陷阱；而单层定向（仅在广告组配置）则更为稳健，共性配置可通过模板复用实现。系统设计时必须显式拍板，切忌盲目默认多层架构。
• 出价机制的差异化处理：在手动出价模式下，出价数值直接归属于广告组；而在自动出价（如 tCPA 或最大转化）场景中，广告组仅设定优化目标，真正的 bid 是运行时逐请求动态计算的产物。
• 缺省语义的隐蔽陷阱：配置面最昂贵的代价往往源于缺省语义的不一致。「子层某维度未设」究竟代表继承父层、全不限还是全不通，必须在后台展示、近线编译与运行时三端严格对齐，否则极易引发悄无声息的错投或欠投。
• 配置落地与运行时边界：投放后台的配置树需先存入元数据库，经近线编译摊平为「可投快照」并下发至 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）的核心使命是明确「本次营销活动的最终目标、总预算额度以及投放周期」。它主要承载以下三个维度的配置：

• 营销目标与优化目标：决定了本次活动是追求广告曝光（Impression）、点击率（CTR）还是深度的转化激活。这直接影响下游 Bidder 在出价时采用的计算模型——CPC 目标仅依赖预估 CTR，而 CPA 或 CPI 目标则必须引入预估 CVR（详见 Bidder 出价一节）。
• 总预算：这是广告主最为核心的资金管控口径。日预算与总预算通常在这一层级设定，随后再向下级节点进行合理分配。
• 投放排期：定义了整个营销活动的起止时间，构成了所有下层投放线不可逾越的时间边界。

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

作为配置树中信息密度最高的层级，广告组（Ad Group）是绝大多数「如何投放」决策的最终落脚点：

• 定向条件：涵盖地域、时段、设备、媒体版位、人群包以及上下文环境。这一层是定向维度最为集中的区域（详见第四、五节）。
• 出价：定义了该投放线愿意为一次广告曝光、点击或转化支付的最高价格。
• 预算分配与 Pacing：决定了如何从推广计划的总预算中划拨资金，并控制其消耗节奏（Pacing 的运行时机制可参考 Bidder 预算篇）。
• 频次控制：限制同一用户在该投放线上最多可见的广告次数（频控的层级归属将在第七节深入探讨）。

需要思考的是，为什么定向条件要集中在广告组而非创意层？原因在于，「目标受众」与「展示素材」在业务逻辑上是完全正交的两个维度。同一套定向策略（例如加州、纽约州、iOS 设备及高价值人群）往往需要搭配多套创意进行 A/B 测试。将定向收拢在广告组，而创意层仅负责素材管理，能够有效避免「每更换一张素材就必须重配一遍定向」的冗余操作。

2.4 创意：被展示的素材

作为配置树的叶子节点，创意层仅关注最终展示给用户的实体内容：包括素材文件、尺寸格式、落地页以及审核状态。在这一层级，定向条件通常只保留与素材强绑定的少数维度，例如特定尺寸仅适配特定版位，或特定语言的素材仅投放于对应的语言环境。将核心定向保留在广告组，仅将「由素材决定的物理约束」下沉至创意层，是职责划分最为清晰的架构设计。

需要补充的是，「广告组至创意」的映射关系并非静态的挂载。一个广告组下通常会关联多条创意，在实际投放时系统需要动态决策：是采用均匀轮播、按 CTR / CVR 择优倾斜，还是基于特定权重进行分配。这种创意选择与优化机制发生在「该广告组赢得实时竞价之后」（呼应总览中的填充阶段），与前置的定向判定属于两个独立的业务流程。本文重点聚焦于配置的组织结构，创意优化策略则另有专篇论述。

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

四层配置树描述的是系统的「稳态配置」，但在真实的程序化投放中，A/B 实验几乎是不可或缺的环节。针对同一条广告组，系统可能需要同时运行「定向 A 搭配出价 A」与「定向 B 搭配出价 B」两个版本以对比效果。需要强调的是，实验通常并不构成树的第五层，而是作为叠加在广告组或创意层之上的一个正交维度：系统根据流量比例将用户分桶，不同桶内的流量命中不同的配置版本。这提醒我们：层级树仅仅是「配置的组织形式」，并不等同于「投放的全部结构」；实验、版本与灰度发布都是横切这棵树的独立维度（这与后文提到的频控机制异曲同工）。

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

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

将配置项准确归入对应层级，本质上是为了界定该约束条件的「作用范围」。作用于全局账户的配置应置于广告主层，作用于单次活动的归入推广计划，作用于具体投放线的落在广告组，而仅作用于单一素材的则下沉至创意层。配置错位往往会导致两类严重问题：层级过高会丧失局部调优的灵活性，层级过低则会引发重复劳动并增加配置冲突的风险。

层级设计的初衷并非追求结构的对称美，而是确保每个约束条件仅在其生效范围内被精准配置一次。就近落层，是配置架构最核心的指导原则。

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

跨层级合并是配置面最容易滋生 Bug、同时也最考验系统设计功底的环节。既然定向条件可以分布在推广计划、广告组以及创意等多个层级，那么在运行时，系统必须通过多层合并来推导出「该广告最终的有效定向」。这里的合并语义绝非简单的「下层覆盖上层」，而是严格遵循「逐维求交、只能收窄」的逻辑。

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

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

在默认情况下，子层会自动继承父层的定向条件。例如，当推广计划设定了「地域为美国、排除赌博类目」时，其下属的所有广告组即使未做任何显式配置，也会自动受到这两条规则的约束。这种继承机制的优势显而易见：共性规则被有效上提，实现了一处配置、全局生效的高效管理。

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

跨层合并的核心约束在于：子层对某一维度的设定，必须是父层设定的子集。广告组可以将「美国」进一步收窄为「加州与纽约州」，但绝不能将其放宽至「全球」。在工程实现上，正向定向的合并语义被严格固定为同一维度跨层取交集：

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

与之相对，排除定向则遵循跨层累加（并集）的逻辑：只要任意一层排除了特定媒体或类目，合并后的最终结果就会将其永久排除。正向求交与排除累加在方向上截然相反，因此在底层实现时必须分开表达（这与定向过滤篇 5.2 节中「正向集合与排除集合分开存」的理念一脉相承）。

4.3 冲突：交集为空即意味着零投放

收窄语义不可避免地带来了一个隐蔽的副作用：如果子层设定的值完全落在父层范围之外，求交结果将为空集，导致该投放线无法匹配到任何流量。正如上图所示，广告组 B 设定了「东京」，而其父层限定为「美国」，两者交集为空。此时，广告主在后台明明完成了定向配置，线上却面临零曝光的窘境，且系统不会抛出任何异常。这类问题的排查成本极高。因此，优秀的投放后台应当在保存配置时主动进行跨层校验，并明确提示「该定向与上层冲突，将无法投放」，而不是任由其上线后通过零消耗来倒逼排查。

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

为了将继承、收窄与冲突的逻辑串联起来，我们来看一棵极简的配置树（以下 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.4 覆盖式 vs 求交式：仅针对定向维度，切勿混淆标量值

需要澄清的是，并非所有平台的所有定向维度都采用「求交」逻辑。部分维度会采用覆盖式语义（即子层一旦设定，便无视父层约束，完全以子层为准）。这两种语义在各自场景下均能自洽，但系统必须逐维明确定义、保持统一，并与后台展示逻辑严格对齐：

• 求交式（更为常见且安全）：子层永远无法突破父层的限制。这种模式非常适合地域、类目排除等将「父层作为硬边界」的集合型维度。
• 覆盖式：子层完全接管该维度的控制权。这种模式适用于某些「理应由下层主导」的集合型维度（例如部分平台中的版位选择）。

混淆这两种语义是配置面 Bug 的高发区。以前文示例树中的 Tokyo-Retarget 为例，同一条 geo = [Tokyo] 且父层 geo = [US] 的配置，在不同语义下会产生截然相反的后果：

正因如此，地域与类目排除这类涉及合规与品牌安全的维度，几乎毫无例外地采用求交式逻辑：系统宁可让子层越界时「投不出」（显性且可校验），也绝不允许其「悄悄投出界」（隐性且极具风险）。一旦父层的硬约束能够被子层轻易覆盖，品牌安全与合规边界便形同虚设。

此外，必须明确一个关键边界：出价、预算与 Pacing 这类「标量值」并不属于本节讨论的范畴。它们并非集合型定向，不存在「跨层求交或覆盖」的合并语义，仅仅涉及「该值归属于哪一层」的问题（详见第六节）。将标量值与定向维度强行塞入同一张「合并规则」表，本质上是对底层概念的严重混淆。

各维度合并语义（示例口径，具体以平台约定为准）：

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

回顾 4.1 至 4.3 节中关于继承、收窄与交集为空的复杂逻辑，我们不难发现，这一系列挑战本质上都源于一个底层设计选择：系统允许定向条件分布在多个层级，并执行跨层求交。然而，这并非唯一的解决方案，甚至在某些场景下并非最优解。现实中，许多 DSP 倾向于采用定向单层化架构：定向条件仅存在于广告组层面，推广计划层完全剥离定向功能，从而从根本上消灭了「跨层合并」的复杂性。这两种设计思路的权衡十分清晰：

• 多层定向与求交：架构更为灵活。广告主可以在计划层设定「本次活动全量投放美国」的全局硬边界，各广告组再基于此进行个性化收窄。但其代价是引入了继承、收窄以及交集为空等一系列复杂的语义陷阱。前文提到的「配了却零投放且不报错」正是这种设计带来的典型副作用。
• 单层定向（仅在广告组）：架构更为简单稳健，大幅降低了配置出错的概率。没有跨层合并，自然也就没有空集陷阱，缺省语义也从复杂的「层级与运行时二维」退化为简单的「运行时一维」。其代价在于，共性的定向条件需要在每个广告组中重复配置（通常可通过模板或批量操作来缓解这一痛点）。

这两种方案并没有绝对的优劣之分，但它是系统设计初期必须显式拍板的核心决策，切忌盲目默认「理所当然应该多层求交」。一个务实的折中方案是：正向定向仅保留在广告组层面（单层化），而将真正需要全局硬边界的少数维度（如品牌安全与合规地域）以「排除型硬闸」的形式上提至广告主或计划层。由于排除项的跨层累加（并集）只会让范围更小且永远不会产生空集，这种设计恰好完美避开了多层正向定向最危险的陷阱。

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

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

除了跨层合并的复杂性之外，单层内部的定向条件同样拥有一套严密的语义规则。这部分内容与定向过滤篇第四、五节探讨的逻辑高度同源：那篇侧重于运行时的求值机制，而本节则聚焦于配置时的准确表达。在此不作过多重复，仅点出配置面特有的核心注意事项。

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

广告组层能够配置的定向维度，基本涵盖了定向过滤篇第四节中所列举的核心要素：地域、时段、设备环境、媒体版位、人群包以及上下文内容。在配置层面，系统设计者必须格外关注以下两点：

• 维度内 OR、维度间 AND：在同一个维度内选择多个值（例如加州 OR 纽约州）代表逻辑「或」，而不同维度之间（例如地域 AND 设备）则代表逻辑「且」。后台 UI 必须通过清晰的交互设计让广告主准确感知到这一差异，否则极易配出「误以为是或、实则是且」的无效定向。
• 正向与排除必须在 UI 上严格区分：针对同一维度，「仅投放 X」（Include）与「投放所有但排除 X」（Exclude）在语义上截然相反。后台应当将其设计为两种明确且独立的输入控件，绝不能试图通过单一字段的正负号来混合表达。

5.2 缺省语义：配置面最昂贵的陷阱

在定向过滤篇 5.3 节中，缺省语义被定性为「最贵的一个坑」。在配置面，这个问题显得更为棘手，因为它额外引入了层级维度：除了运行时的「未设等同于不限或全不通」之外，还叠加了「子层未设等同于继承父层」的复杂逻辑。为了确保系统稳健，以下三个层面的语义必须实现绝对对齐：

• 后台展示语义：当广告主在 UI 上看到「地域：未设置」时，他的真实预期是什么？
• 编译与合并语义：在近线编译阶段，系统究竟将「未设」解析为「继承父层」还是「空集」？
• 运行时语义：当 Bidder 执行匹配时，空的定向集合是被视为「全通」还是「全不通」？

只要这三者中存在任何一处脱节，经典的线上事故便会如期而至：广告主未设地域，满心以为会「继承父层的美国定向」；然而编译模块却将其解析为「空集」；最终运行时又将空集判定为「全不通」。其结果是，这条投放线将无法获得任何曝光，且整个过程不会触发任何系统告警。要守住这条防线，唯一的出路与运行时策略如出一辙：建立明确的语义约定，将其固化为单元测试，并通过海量真实配置的回放来进行严苛校验。

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

在众多维度中，有一个极易被误认为是「投放对象树上节点」的概念——AdExchange（ADX）或供给来源。实际上，广告层级树解决的是「投给谁、投什么」的问题，而 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 下沉至广告组：推广计划的总预算需要向下科学切分给各个广告组，随后每条投放线再依据自身的 Pacing 策略控制消耗节奏。这与 Bidder 预算篇中探讨的「本地分片」机制互为表里：配置面负责敲定「怎么切分」，而运行时则负责执行「怎么花且确保不超投」。

在此处，系统设计往往面临一个经典的业务张力：推广计划的总预算与下属广告组预算之和应当如何对齐？不同平台的处理策略存在显著差异：部分平台允许广告组预算之和大于推广计划总预算（即允许超卖），最终由 Campaign 总预算进行全局封顶——这种机制的优势在于，当某条投放线消耗乏力时，预算能够平滑地流向其他高消耗线；另一些平台则严格要求子预算之和必须小于或等于父预算；更有甚者，彻底摒弃了广告组级别的预算设定，将预算管控完全收拢在 Campaign 层，纯粹依靠 Pacing 机制向下动态分配。无论采用何种架构，只要系统中同时存在两级预算，运行时的预算闸门就必须具备同时校验广告组与 Campaign 双层余额的能力。

6.2 出价：为什么必须落在广告组

出价之所以被配置在广告组层，核心原因在于：不同的定向条件与受众人群，其蕴含的商业价值存在显著差异。广告主显然愿意为高价值人群支付更高的溢价，而对宽泛的普通流量则倾向于压低出价。将出价精准锚定在广告组，恰好能够实现「一条定向策略对应一个合理出价」的完美映射。相比之下，推广计划层通常仅设定宏观的优化目标（如 CPC、CPA 或 CPI）——这一目标决定了出价计算所采用的底层公式，而具体的出价数值则必须下沉至广告组。

然而，上述逻辑主要针对手动出价场景。在现代 DSP 广泛采用自动出价策略（如 tCPA、最大转化或目标 ROAS）的背景下，「出价」已不再是广告组上一个静态的常数。此时，广告组上配置的仅仅是优化目标（例如设定 tCPA 为 50 元），而真正参与竞价的 bid，是由 Bidder 在运行时结合预估 CTR、CVR 以及 Pacing 系数，针对每一次请求动态计算得出的产物（详见 Bidder 出价与预算篇）。因此，更为严谨的表述应当是：在手动出价模式下，出价数值直接归属于广告组；而在自动出价模式下，广告组仅承载出价目标，真实的数值则是运行时的动态产物。这一演进并未颠覆层级归属的大框架，但它深刻提醒我们：切勿将「出价」简单固化为一个躺在广告组上的静态字段。

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

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

频次控制（即限制同一用户触达特定广告的次数）的层级归属，完全取决于业务端期望管控的粒度：

• 广告主或跨计划级频控：旨在限制同一用户对该品牌或广告主旗下所有活动的总曝光次数。其核心诉求是总量控频，严防用户在不同营销活动中被同一品牌过度轰炸。这一层级的实现难度最高，因为系统必须跨越整棵计划树，实时聚合同一用户的全局曝光数据。
• Campaign 级频控：限制同一用户对整个营销活动（跨越该计划下所有广告组）的最高可见次数，主要服务于品牌活动层面的「总曝光去重」。
• 广告组级频控：限制同一用户在单一投放线上的最高可见次数，属于最细粒度的频控策略。

在实际应用中，多级频控策略往往会叠加生效（例如系统会优先校验广告主级的总帽，随后校验 Campaign 级，最后才落实验证广告组级的分帽）。

这里隐藏着一个极易被传统层级思维误导的关键点：频控的统计口径是「用户」，这一属性天然横切了整棵层级树。同一个用户的曝光计数，必须跨越广告组、推广计划甚至广告主进行全局聚合。正因如此，尽管频控规则在 UI 上被「配置」在某一层级，但其底层状态并不依附于树上的任何一个单一节点，而是表现为 用户 × 层级节点 的交叉计数矩阵。这也完美解释了为什么频控与前文提及的实验维度（2.5 节）一样，属于「横切树」的正交维度，而非树的某一层。至于这些海量计数在运行时如何被高效判定（哪些规则可以前置拦截，哪些必须穿透查询 Redis），则是定向过滤篇第六节所探讨的运行时性能优化问题，与配置面的层级归属属于两个独立的技术命题。

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

• 投放排期（Flight Dates）归属 Campaign：营销活动的起止日期构成了整个投放生命周期的绝对硬边界。
• 时段定向（Dayparting）下沉至广告组：具体到「仅在工作日 9 至 18 点投放」这类精细化的时段控制，则必须作为定向条件落在广告组层。这两者之间呈现出典型的「全局边界与局部细化」关系：广告组的时段设定必须严格落在 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 与排期若按错时区（如混淆广告主时区与用户本地时区），实际投放窗口将全面错乱且难以察觉。必须在编译期将时区口径绝对定型（详见 7.2）。
• 模板批量改动的连锁灾难：当运营人员使用模板或批量操作为上百个广告组套用同一份定向时，一次看似常规的「统一收窄地域」操作，极有可能将个别原本就很窄的广告组求交成空集。在执行批量操作前，系统必须预演有效定向，输出会变为空集的风险清单，经二次确认后再行阻断或放行。
• 清空维度 ≠ 放开定向：当运营在子层「清空」某个定向维度时，其本意往往是回退至父层继承状态；但若系统将「空」错误解析为「无此约束（即全集）」而非「继承父层」，就会悄然放宽投放边界。清空操作的底层语义（继承还是全集）必须与后台的 UI 提示保持绝对一致（呼应 5.2 节的缺省语义）。

延伸阅读

• 配置落地：从投放后台到索引快照：本文内容的「下一步」——深入探讨这棵配置树如何被近线编译为版本化的索引快照（涵盖编译前置、版本化控制、全量与增量更新、触发机制以及组件依赖的深度剖析）。
• 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（DV360）层级模型（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 等）属于平台级底层配置，并不在投放对象树的管辖范围内。
• 横切维度：如频控（基于用户维度）、实验版本、灰度发布等——它们不属于层级树的任何单一层级，而是跨越节点进行聚合或分桶的正交维度。
• 近线编译：将复杂的配置树摊平为可投快照（历经层级合并、口径归一、构建倒排索引与位图等步骤）的离线或近线处理过程。