本文属于 Bidder 竞价服务架构 系列。
定向过滤篇第六节讲了频控放在竞价漏斗哪一级执行（哪半能前置粗筛、哪半必须后置逐条判定），但它把「运营到底能配什么」一笔带过。总览里排在第 5 篇的分布式频次控制，讲的是多实例计数的一致性（本地计数 + 异步回灌 + 容忍超投）。本篇补的是第三块拼图：配置面——运营在 DSP 后台能拧哪些旋钮，每个旋钮怎么映射到执行，以及买方侧最头疼的一件事——当设备 ID 缺失或全 0 时，频控的身份口径到底怎么定。至于这些旋钮拧下去之后，计数到底存在哪、怎么写、怎么读，是姊妹篇频次控制工程篇的主题——建议本篇建立框架后接着读。
频次控制（Frequency Capping）常被当成一句话就能说清的功能：「同一个用户，某广告一天最多看 N 次」。但真正在 DSP 后台配过的人都知道，这句话里每一个词都是一个维度：「同一个用户」是谁（身份口径）、「某广告」是哪一级（层级）、「一天」是什么窗口（时间）、「看」算什么（计数事件）、「最多 N 次」超了怎么办（硬砍还是降权）。把这五个维度拆开，才看得清频控的全貌。
而这五个维度里，最难、最容易翻车的不是「配几次」，而是「同一个用户」这个前提在程序化里根本不牢靠——ATT 之后大量流量没有 IDFA、设备 ID 是一串全 0、或者用户明确开了限制追踪。这时候频控退化成一件「尽力而为」的事，怎么设计降级口径，决定了你是把无 ID 流量白白丢掉，还是能榨出一部分可控投放。本篇最后两节专讲这个。
运营在后台配的每一条频控规则，本质都是 [层级] × [窗口] × [计数事件] × [抑制规则] × [身份口径] 的一个组合。前四维是「配置」，第五维「身份口径」才是决定频控准不准的命门。
TL;DR
- 一条频控 = 五维组合：
[层级] × [窗口] × [计数事件] × [抑制规则] × [身份口径]。前四维是后台旋钮，第五维（身份）是命门。 - 层级维度取最严：Advertiser / Campaign(IO) / AdGroup / Creative 多级 cap 同时生效，任一超限即 no-bid；素材组合并计数防「换个尺寸绕过」。
- 时间窗口：hour / day / week / lifetime；自然窗口（tumbling，TTL 对齐、省存储、边界有突刺）vs 滑动窗口（精确、要存时间戳或近似结构、贵）；外加 recency（两次曝光最小间隔）控节奏。
- 计数事件：impression / viewable impression / click；口径上还要选 Win 计（及时但高估→欠投）还是 Impression 回传计（准但延迟→并发超投），生产常「win 预扣 + imp 对账」。
- 抑制规则：点击后抑制、转化后排除、已购/已注册人群排除——本质是「频次为 0」的特例。
- 硬 cap vs 频次衰减软控：硬砍到上限不如让 bid 随曝光次数递减（
bid_n = bid_0·e^(-λ(n-1))），把边际递减的触达交给拍卖，ROI 通常更优；品牌广告还有「目标频次 / optimize for reach」这种求下限的软控。 - 身份口径是尽力而为：程序化身份碎片化，买方靠 cookie matching / UID2 / RampID / PPID 把各 exchange 的 id 归一到内部 UserID；匹配率永远 <100%。
- 全 0 / 空 ID ≠ 一个用户——这是最致命的错误：合并计数会让这个「用户」秒打满 cap，把整批无 ID 流量全部 no-bid。
- 身份越弱，频控越软：统一 ID → 设备 ID → 概率指纹 → IP 网段 → 放弃；无 ID 流量走独立命名空间，cap 放宽、bid 保守，
lmt/dnt=1不做用户级追踪。
Table of contents
Open Table of contents
一、先建立框架：运营配的是一个五维组合
打开任何一个成熟 DSP 的后台，频控从来不是一个孤零零的输入框。它散落在 campaign / ad group / creative 各层的设置页里，由若干下拉框和数字框拼成。把它们归类，本质就是五个维度：
| 维度 | 回答的问题 | 典型取值 |
|---|---|---|
| ① 层级 | 对「哪一级广告主体」限频 | Advertiser / Campaign / Ad Group / Creative |
| ② 时间窗口 | 在「多长时间」里计数 | hour / day / week / month / lifetime |
| ③ 计数事件 | 「什么行为」算一次 | impression / viewable / click |
| ④ 抑制规则 | 「超限或某事件后」怎么处理 | 硬 cap / 点击后抑制 / 转化后排除 |
| ⑤ 身份口径 | 「同一个用户」到底是谁 | 统一 ID / 设备 ID / 概率指纹 / IP 网段 |
一条完整的频控规则，就是在这五维上各取一个值的笛卡尔组合。比如：
DeviceID × Creative × (1h≤1, 1d≤3) × Impression × 信息流 → 硬 cap
UID2 × Campaign × lifetime≤20 × Viewable × 转化后排除 → 频次衰减后台里能填的，几乎都在前四维；第五维「身份口径」运营常常只能选个开关（如「跨设备 on/off」），而它背后的可靠性，才是频控准不准的真正决定因素。所以本篇的结构是：前四维快速讲透（第二五节），身份口径重点讲（第六七节），最后落到配置如何生效与常见坑。
一句话本质
频控不是「一个用户看几次」，而是「在某个身份口径下，对某一级广告主体，在某个时间窗口内，对某种事件计数，超过后怎么处理」。五个词，五个维度。
二、层级维度：cap 树与「取最严」
第一个维度是「对谁限频」。广告主体是有层级的，从上到下：Advertiser（广告主）→ Campaign / IO（订单）→ Ad Group / Line Item → Creative（素材）。后台通常允许在多个层级分别设 cap，而且它们同时生效。
多级 cap 是「与」关系，不是「或」：Advertiser、Campaign、Ad Group、Creative 各自的 cap 任一超限就 no-bid，实际触达受最严的那一层约束。
几个配置要点：
- 多级取最严（AND）：设了 Campaign 级 ≤10/天、Creative 级 ≤3/天，那么单素材最多 3 次、且该 campaign 所有素材合计最多 10 次，两个约束同时成立。运营算「实际用户能看几次」时最容易在这里出错——不是相加，是取交集。
- 素材层防疲劳：同一 campaign 往往挂多条创意。只设 campaign 级 cap，用户可能被同一批素材反复轰炸；加 Creative 级 cap 才能保证「单条素材别看腻」。
- 素材组（Creative Concept）合并计数：同一创意常有多个尺寸/版本。若按单个 creative id 计数，用户换个版位看到另一个尺寸就「重新计数」，等于绕过了 cap。成熟 DSP 支持把它们归到一个 concept 一起计。
- Advertiser 级封顶：跨该广告主所有 campaign 的总触达上限，防止同一广告主的多个 campaign 叠加起来把同一用户打爆。
映射到主流 DSP 的实际叫法：
| DSP | 频控配置位置 / 叫法 |
|---|---|
| DV360（Google） | Line Item / Insertion Order 层 Frequency cap，支持 per day/week/month/lifetime、可 cross-device |
| The Trade Desk | Ad Group 层 Frequency，可设多条 cap，另有 Impression frequency 优化 |
| Amazon DSP | Line item Frequency cap，支持多窗口 |
三、时间窗口维度：自然窗口 vs 滑动窗口
第二个维度是「在多长时间里计数」。后台里就是那个 per [Hour / Day / Week / Month / Lifetime] 下拉框。常见组合是多条并存：
至多 1 次 / 小时
至多 3 次 / 天
至多 10 次 / 周
至多 20 次 / campaign 生命周期（lifetime）lifetime cap 在品牌广告里尤其常用——控制单用户在整个投放周期内被触达的总次数，追求「触达但不骚扰」。它对存储的要求也最高（窗口跨越整个 campaign 周期）。
窗口维度真正的工程分歧，在于怎么实现这个「窗口」：
- 自然窗口（tumbling / calendar）：按自然边界清零，比如每天 0 点计数归零。实现极简——一个带 TTL 的计数器 key，
fc:{user}:{ad}:{yyyymmdd}，TTL 对齐窗口即可。代价是边界突刺：23:59 和次日 00:01 各投一次，用户体感是「连着两次」，但计数分属两天、都不超限。 - 滑动窗口（sliding）：过去 24 小时内 ≤N 次。更贴合「用户体感」，但要么存下每次曝光的时间戳列表（贵），要么用近似结构（Count-Min Sketch / 分桶计数）牺牲精度换存储。
程序化的 QPS 极高（单 DSP 常见十万到百万级），存储成本约束很硬，所以多数系统用自然窗口 + 短 TTL，只在少数高价值场景上滑动窗口。
除了「总量」，还有一个控节奏的旋钮常被忽略：
- Recency（最小间隔）：
距上次曝光至少间隔 X 分钟/小时才允许再次展示。它不限总量，只拉开两次曝光的时间距离——避免「一个用户在 5 分钟内被同一广告砸 3 次」这种即使不超日 cap 也很糟的体验。
四、计数事件维度与抑制规则
4.1 计数什么事件
第三个维度是「什么行为算一次」：
- Impression（曝光）：默认，最常见。
- Viewable Impression（可见曝光）：只有真正进入视口（viewability 达标）才计。更贴合「用户真的看到了」。
- Click（点击）：用于点击后抑制类策略。
这里藏着一个买方侧的口径难题：按 Win 计还是按 Impression 回传计？
- 按 Win 计数：赢价即 +1，及时、实现简单。但 win ≠ 真曝光（可能未渲染、未可见），会高估频次 → 实际投放不足（under-deliver）。
- 按 Impression 回传计数：真曝光回传才 +1，准。但回传有秒级延迟，并发窗口内会超投。
生产上常见折中：win 时预扣（reserve）一个名额防并发超投，impression 回传时确认对账。这套「本地计数 + 异步回灌 + 容忍少量超出」的一致性机制，和预算不超投是同一类问题，细节属于总览排的分布式频次控制那一篇。
4.2 抑制规则：频次为 0 的特例
除了正向的「最多 N 次」，运营还常配负向的「不再投」：
- 点击后抑制：用户点击后 X 天内不再展示（已经表达了兴趣/已到落地页，再投是浪费）。
- 转化后排除：已转化用户停投（已购就别再花钱触达）。通常通过接入转化像素 + suppression audience（排除人群） 实现。
- 已购 / 已注册人群排除：上传或对接人群包，加入 exclusion list。
这些本质都是「频次上限 = 0」的特例——只是触发条件从「曝光次数」换成了「发生了某个下游事件」。放进五维框架，它们属于「抑制规则」这一维。
五、策略维度：硬 cap vs 频次衰减软控
第四个维度是「超限（或接近上限）时怎么处理」。这是频控里最有优化空间、也最能体现买方水平的一维。
硬 cap 是阶跃函数（到 3 次前满价、第 4 次直接 0）；频次衰减是把出价随曝光次数连续降低，让边际递减的触达自然失去竞争力，而不是一刀切。程序化买方普遍认为后者 ROI 更优。
5.1 硬 cap
最直接：计数超过上限就 no-bid。简单、可解释、绝对可控。缺点是「一刀切」——第 3 次和第 4 次之间价值不会突然归零，硬砍会丢掉一部分本来还划算的触达。
5.2 频次衰减出价（Frequency Decay）
不硬砍，而是随该用户已曝光次数 n 增加，把 pCTR/pCVR 或 bid 打个递减折扣：
bid_n = bid_0 · e^(-λ(n-1)) # n=1 满价，之后逐次衰减，λ 控制衰减速度因为同一用户看同一广告的边际效果递减（第 5 次的转化概率远低于第 1 次），让出价跟着递减，就把「还值不值得再投」的判断交给拍卖——划算就还能赢，不划算自然输给别的流量。它比硬 cap 更平滑、更省钱、ROI 更优，代价是更难解释、更难调参。
5.3 求下限而非上限：目标频次
品牌广告有时追求的不是「别超过 N 次」，而是「有效触达至少 N 次」（如 3+ reach 才形成品牌记忆）。这时后台提供的是 Target frequency / Optimize for reach 这类开关，系统朝目标频次优化，是频控的「反向」形态。
更进一步还有序列化投放（sequential / storytelling）：控制素材出现的顺序（先看 A 品牌故事，再看 B 促销），是频控的高级形态。
六、身份口径维度：程序化频控的命门
前四维都是「配置」，第五维「身份口径」才是决定频控准不准的根本。频控的第一个字是「频」，但要计频，先得知道「这是不是同一个人」——而在程序化里，这件事天生不牢靠。
6.1 为什么难
- 身份碎片化：同一真实用户在不同 SSP/Exchange 里 id 不同（cookie 不同步）、在不同设备上 id 不同。
- ID 大面积缺失：iOS ATT 之后 IDFA 大量为空；第三方 Cookie 持续受限、可用性下降；很多流量根本不带稳定标识。
- 合规约束：用户开了限制追踪（
lmt=1/dnt=1），从合规角度就不该做用户级识别。
6.2 买方怎么把身份「归一」
买方拿到的是 bid request 里 SSP 传来的 user id，要做频控，必须先把各 exchange 的不同 id 映射到自己的内部 UserID——这就是 Cookie Matching / ID Sync。在此之上，行业转向几种统一 ID 作为更稳的 key：
- UID2（Unified ID 2.0）：以 email/phone 哈希为种子，经 Operator 加盐 + 加密，产出确定性、可跨设备的 ID；开源标准。
- RampID（LiveRamp）：基于身份图谱把「同一个人」的多源标识聚合、假名化的 people-based ID；对不同 partner 还会派生不同版本。
- PPID（Publisher Provided ID）：媒体自己生成、只在自己域内有效的第一方 ID；跨媒体无效，常作兜底。
这三种统一 ID 的生成原理（种子、加盐、加密、作用域、隐私机制）差别很大，本篇不展开——它值得单独一篇。这里只需记住：它们的价值在于把「同一个人」在不同 exchange、不同设备的请求归一到同一个频控 key，让跨域频控真正准确。
6.3 现实：匹配率永远 <100%
无论 cookie matching 还是统一 ID，匹配率都不可能到 100%。总有一部分流量身份对不上、或者根本没有可用 ID。频控因此本质是「尽力而为（best-effort）」：能精确的精确，不能精确的要有降级口径——这正是下一节的主题。
七、没有 GAID/IDFA、或全 0 设备 ID 怎么办
这是买方侧频控最现实、也最容易做错的一环。大量流量的设备 ID 要么为空、要么是 00000000-0000-0000-0000-000000000000 这种全 0、要么被 ATT/LAT 置零。处理原则是分级 fallback + 明确降级语义，绝不是简单丢弃或强行合并。
7.1 第一步：给身份「可用性」分类
拿到 bid request，先判断设备 ID 处于哪种状态——关键是不能把「全 0」当成一个真实用户：
| 状态 | 例子 | 含义 |
|---|---|---|
| 有效 ID | 正常 IDFA / GAID / OAID | 可精确频控 |
| 全 0 / 空 | 00000000-... 或字段缺失 | ATT 拒绝 / LAT 开启 / 未采集 |
| LAT 标记 | lmt=1 / dnt=1 | 用户限制追踪，合规上不应追踪 |
| 脏数据 | 全 F、测试值、明显异常重复 | 归一化异常 |
最致命的错误：把所有全 0 设备当成同一个用户去计数。这个「用户」会瞬间打满 cap，导致整批无 ID 流量全部 no-bid——而无 ID 流量在部分流量源（尤其 iOS）可占相当比例，损失巨大。全 0 必须视为「无用户身份」，绝不能合并成一个 key。
7.2 分级 fallback 身份链
按优先级从强到弱依次尝试，命中即用：
拿到请求后的身份口径决策链：统一 ID > 设备 ID > 概率指纹 > IP 网段 > 放弃。注意 lmt=1/全 0 这一支直接跳出用户级追踪，不参与计数——这是合规红线，也是避免「全 0 合并」事故的关键。
① 统一 ID：UID2 / RampID / PPID（request 里带的）——最优，跨域跨设备
② 平台 / 登录 ID：SSP 传的 hashed email、CTV 的 IFA、publisher user id
③ 设备 ID：有效 IDFA / GAID / OAID / CAID(中国)，且 lmt≠1
④ ─────── 以上都没有，进入「无稳定 ID」降级 ───────
⑤ 概率指纹：hash(IP网段 + UA + OS + 设备型号 + 屏幕 + 语言 + 时区)
⑥ 纯上下文：只剩 IP / geo → 网段级粗频控 or 放弃用户级频控7.3 无稳定 ID 时的三种降级策略
策略 A：概率指纹（Fingerprint）。 用 IP + UA + OS + 设备型号 + 屏幕 + 语言 + 时区 组合哈希成一个「准身份」。能对无 ID 流量做近似频控，但有明显弊端：NAT/公共 WiFi 下多人共享 IP 会误合并（过度限频）、IP 变化会把同一人拆开（欠限频），且在 lmt=1/GDPR 下做指纹有合规风险。缓解：IP 用 /24 网段而非精确 IP，并配更宽松的 cap。
策略 B：粗粒度上下文 cap。 放弃「精确到人」，改对更粗的实体限频：按 IP 网段（「同一 /24 每天 ≤ K 次」，K 设大）、或按 App + 版位 做 recency 节奏控制而非总量。
策略 C：下推 SSP / 媒体侧。 无 ID 流量买方本就管不好，可在 Deal 参数里声明期望频次，靠媒体侧用它的第一方 ID（PPID）执行；买方自己只做预算 pacing + 上下文定向，不承诺用户级频控。
7.4 工程实现要点
- 无 ID 流量单独命名空间，绝不和有 ID 流量混在同一 key 空间：
有效 ID: fc:uid2:{token}:{campaign}:{window}
指纹: fc:fp:{soft_id}:{campaign}:{window} # 独立前缀，cap 放宽
无身份: 不计数，走上下文 / 粗粒度分支- 身份越弱 → cap 越松、bid 越保守：频控不可信时，宁可少出价，避免过度打扰。
lmt=1/dnt=1/ 全 0 直接判为「不可追踪」：不参与用户级计数，只走上下文策略。这是合规红线。- 监控无 ID 流量占比：作为一个核心指标，帮运营理解频控报表为什么「不准」。
一句话本质
在「身份不完整 + 分布式并发 + 毫秒级延迟 + 高 QPS 成本」四重约束下，频控只能是尽力而为。做法是分级 fallback：能精确就精确，不能就降级到粗粒度、再降到只做 pacing；身份越弱，频控越软；而
全 0 / lmt=1这条线必须干净地跳出用户级追踪——既是合规，也是防止「把一堆人当成一个人」的事故。
八、配置如何落地到执行
运营在后台点的旋钮，不会直接跑在竞价关键路径上，中间隔着一条落地链路。先看一次曝光的频控生命周期需要哪些组件、它们怎么配合：
限制曝光需要的组件与配合：Bidder（身份归一 + 判定）、频次计数存储 Redis/Aerospike（关键路径读计数 + win 预扣）、Kafka（异步日志总线）、回灌聚合 Flink（真实曝光对账 +1）。读计数在关键路径、带超时降级；确认 +1 走异步回灌——这段延迟即 dead time，故容忍少量超投。
- 后台配置 → 编译成 snapshot → 下发 Bidder：频控阈值和定向规则一样，经配置中心（Nacos）热更新、原子切换生效，不必发版。缺省语义要在「后台展示 = 编译定型 = 运行时匹配」三处对齐（呼应配置落地篇）。
- 前置粗筛 vs 后置精细频控：与候选无关、可本地布尔判断的部分（用户级全局频控、已达标 campaign 的位图预排除）尽量前置到定向过滤削流量；
per-user × per-campaign的精细封顶必须在有候选之后逐条判定，常需一次带超时的 Redis 点查，随排序闸门执行。这套顺序问题定向过滤篇第六节已讲透，此处不重复。 - 分布式一致性：计数分散在多实例、真实曝光有延迟，会有少量超投——这是可接受的工程取舍，细节属于分布式频次控制那一篇。
- 存储选型与读写分离：计数用哪种 Redis 结构（String 自然日 / Hash 小时桶 / ZSet 精确滑动）、写为何走旁路异步、读为何在 bidder 关键路径就近读 + 本地缓存兜热点，是频次控制工程篇的主题——本篇的旋钮拧下去之后，就落到那套存储与链路上。
- 与 Pacing 的耦合：频控会砍掉一部分可竞价请求，直接影响预算消耗速度。cap 设太严 → 可投流量被砍太多 → 预算花不完（under-delivery）。所以调频控时要和 budget pacing 一起看，别让两者互相打架。
九、运营配置常见坑
- cap 设太严 → 预算花不完。 频控和 pacing 是一对矛盾：cap 越严，可竞价流量越少，预算越难花完。上线新 cap 后要盯 delivery。
- 多级 cap 叠加算错触达。 各级都生效、取最严，实际触达 = 最紧的那一层，不是相加。运营估「用户能看几次」时常在这里算错。
- 超投是正常的，别当 bug。 因回传延迟和并发，实际曝光常略高于 cap。看报表发现小幅超出，是分布式计数的固有现象，不是故障。
- 身份匹配率 <100%，频控只是尽力而为。 跨设备/跨 exchange 频控对匹配不上的流量会失效，报表「不准」很大程度源于此——盯无 ID 流量占比。
- lifetime cap 越长越飘。 窗口越长、身份越不稳定，长周期计数的误差越大。
- 时区 / 日型错配。 「一天」按广告主时区还是用户时区？跨国投放最容易在这里让「每天 cap」错位十几个小时（同定向篇的 dayparting 口径问题）。
- 全 0 合并成一个用户。 前面反复强调——这是最严重的事故，会让整批无 ID 流量集体 no-bid。
十、速查表
- 一条频控 = 五维组合：
[层级] × [窗口] × [计数事件] × [抑制规则] × [身份口径]。 - 层级取最严（AND）：Advertiser / Campaign / Ad Group / Creative 多级同时生效；素材组合并计数防绕过。
- 窗口：hour/day/week/lifetime；自然窗口省存储（有边界突刺）、滑动窗口准但贵；recency 控节奏。
- 计数事件：imp / viewable / click；Win 计（欠投）vs Impression 计（超投），常「win 预扣 + imp 对账」。
- 抑制 = 频次为 0：点击后抑制、转化后排除、人群排除。
- 软控优于硬砍：频次衰减
bid_n = bid_0·e^(-λ(n-1))把边际递减交给拍卖；品牌广告用目标频次求下限。 - 身份口径是命门：统一 ID（UID2/RampID/PPID）> 设备 ID > 概率指纹 > IP 网段 > 放弃。
- 全 0 / 空 ID ≠ 一个用户（最致命错误）；身份越弱频控越软；
lmt/dnt=1不做用户级追踪；无 ID 流量走独立命名空间。 - 落地：后台 → snapshot → 热更新下发；前置粗筛 + 后置精细；与 pacing 协同防花不完。
DSP 后台的频控配置，看起来是几个下拉框和数字框，本质是在五个维度上做组合：对谁（层级）、多久（窗口）、算什么（事件）、超了怎么办（抑制/软控）、以及最要命的——同一个人到底是谁（身份口径）。前四维是可以配清楚的旋钮；第五维在程序化世界里天生残缺，逼着你把频控从「精确计数」降格成「分级尽力而为」。理解了这一点——能精确就精确、不能就分级降级、全 0 绝不合并、身份越弱越软——也就理解了买方侧频控真正的难处所在。
延伸阅读
- Bidder 频次控制工程篇：多维度限频的存储选型与读写分离：本篇的工程实现姊妹篇——配置旋钮拧下去之后，计数怎么存（String / Hash / ZSet）、写为何走旁路、读为何就近 + 本地缓存兜热点。
- Bidder 定向过滤（Targeting Filter）：第六节讲频控在竞价漏斗里的位置——哪半能前置粗筛、哪半必须后置逐条判定，与本篇的「配置维度」互补。
- Bidder 竞价服务架构（总览）：第 5 篇「分布式频次控制」讲多实例计数的一致性（本地计数 + 异步回灌 + 容忍超投），是本篇未展开的执行细节。
- Bidder 预算 Pacing：PID 控制与消耗平滑：频控砍流量会影响消耗速度，cap 太严会导致预算花不完——两者必须协同。
- Pacing 目标曲线：时段消耗权重怎么设计：与 pacing 的另一半，理解频控对可竞价流量的影响如何传导到目标曲线。
- 冷启动：程序化栈每一层都在解同一个问题：新 campaign / 新用户缺乏历史时，频控与身份口径如何先保守再收敛。
- 配置如何落地成 Snapshot：后台频控阈值怎么编译定型、热更新下发到 Bidder。
- IAB TCF 与同意管理：
lmt/ consent 的合规背景——为什么lmt=1必须跳出用户级追踪。
一手资料与背景：
- IAB Tech Lab. OpenRTB 2.6 Specification：
device.ifa/device.lmt/device.dnt等字段的定义——它们决定了频控的身份口径从哪来、什么时候必须降级。 - The Trade Desk. Unified ID 2.0：UID2 的开放文档——统一 ID 作为跨域频控 key 的来源之一。
- LiveRamp. RampID：people-based 身份解析与假名化 ID 的商业方案。
附录：术语表
- 频次控制（Frequency Capping）：限制同一用户对某广告 / campaign 在某窗口内的曝光次数。
- cap 树 / 取最严：Advertiser / Campaign / Ad Group / Creative 多级 cap 同时生效，任一超限即 no-bid。
- 自然窗口（tumbling）：按自然边界（如每天 0 点）清零的计数窗口，省存储但有边界突刺。
- 滑动窗口（sliding）：过去 N 小时内计数，更精确但需存时间戳或近似结构。
- recency（最小间隔）：两次曝光之间的最小时间间隔，控节奏而非总量。
- Win 计 / Impression 计：按赢价计数（及时但高估）还是按曝光回传计数（准但延迟）。
- 频次衰减（Frequency Decay）：随曝光次数递增而降低出价的软频控，
bid_n = bid_0·e^(-λ(n-1))。 - suppression audience（排除人群）：已转化 / 已购 / 已注册用户组成的排除名单，本质是频次为 0。
- UID2 / RampID / PPID：三种统一 / 一方 ID，用作跨域或单媒体的频控 key。
- cookie matching / ID sync：把各 exchange 的用户 id 映射到买方内部 UserID 的过程。
- 概率指纹（fingerprint）：用 IP+UA+设备属性哈希出的「准身份」，无稳定 ID 时的近似口径。
- 身份可用性分类：把设备 ID 分为有效 / 全 0 空 / lmt 标记 / 脏数据，决定用哪种口径。
- 全 0 设备 ID：
00000000-...，代表无用户身份，绝不能合并成一个用户计数。