上一篇我们说，每次刷新背后是一场 100 毫秒的拍卖。

这篇我们做一件更具体的事：

把一份真实的 Bid Request 完整拆开，逐字段告诉你——

关于"你"的什么信息，在那 0.1 秒里被打包甩出去了。

不夸张、不渲染，全部对照 OpenRTB 2.6 规范原文。

一、一份真实 Bid Request 长这样

下面是 OpenRTB 2.6 规范 6.2.3 节给出的移动端示例（脱敏后）：

{ ”id”: ”IxexyLDIIk”, ”at”: 2, ”bcat”: [”IAB25”, ”IAB7-39”], ”badv”: [”apple.com”, ”go-text.me”], ”imp”: [{ ”id”: ”1”, ”banner”: { ”w”: 728, ”h”: 90, ”pos”: 1 }, ”instl”: 0, ”tagid”: ”agltb3B1Yi1pbmNyDQsSBFNpdGUY7fD0FAw”, ”bidfloor”: 0.5 }], ”app”: { ”id”: ”agltb3B1Yi1pbmNyDAsSA0FwcBiJkfIUDA”, ”name”: ”Yahoo Weather”, ”publisher”: { ”id”: ”agltb3B1Yi1pbmNyDAsSA0FwcBiJkfIUDA” }, ”cat”: [”IAB15”, ”IAB15-10”], ”ver”: ”1.0.2”, ”bundle”: ”12345”, ”storeurl”: ”https://apps.apple.com/us/app/yahoo-weather/id628677149” }, ”device”: { ”dnt”: 0, ”ua”: ”Mozilla/5.0 (iPhone; CPU iPhone OS 6_1 like Mac OS X)...”, ”ip”: ”123.145.167.10”, ”ifa”: ”AA000DFE74168477C70D291f574D344790E0BB11”, ”carrier”: ”VERIZON”, ”language”: ”en”, ”make”: ”Apple”, ”model”: ”iPhone”, ”os”: ”iOS”, ”osv”: ”6.1”, ”js”: 1, ”geo”: { ”country”: ”USA”, ”lat”: 35.012345, ”lon”: -115.12345, ”type”: 1 } }, ”user”: { ”id”: ”ffffffd5135596709273b3a1a07e466ea2bf4fff”, ”buyeruid”: ”545678765467876567898765678987654” }}

接下来我们按三大类拆它：设备、位置、身份。

二、设备：你拿什么手机、在哪上网

OpenRTB 2.6 的 Device 对象规定了 30 多个字段。挑实际会用的：

几个非技术人不知道的事实：

1. mccmnc 暴露 SIM 卡信息，且漫游时不变
   ——规范原文："The MCC-MNC values represent the SIM installed on the device and do not change when a device is roaming."
2. ip 字段的 IPv6 比 IPv4 更精准
   ，因为 IPv6 不会被 NAT 多人共享
3. sua（结构化 UA）是 2.6 新加的字段
   ，应对 Chrome 把 UA 字符串"冻结"后的识别需求——也就是说，浏览器在反追踪，协议在补救

三、位置：精度可以做到米级

Geo 对象的精度由两个字段决定：

lat: 35.012345 // 纬度（5 位小数）lon: -115.12345 // 经度type: 1 // 来源：1 = GPSaccuracy: 10 // 设备上报的精度，单位米

5 位小数纬度 ≈ 1 米

经纬度的精度，每多 1 位小数，定位精度提高 10 倍：

OpenRTB 2.6 没有限制小数位数。规范只在 accuracy 字段说："这是设备上报的精度，单位米。"

也就是说，如果 App 拿到了 GPS 权限并把原始数据塞进 Bid Request，你的位置就以米级精度被广播给所有 DSP。

没有 GPS 权限怎么办？还有 IP 定位兜底

Geo 对象的 type 字段（参考 AdCOM 1.0 List: Location Types）规定了来源：

• type = 1：GPS / 位置服务
• type = 2：IP 地址反查
• type = 3：用户主动填写

即使你拒绝了定位权限，IP 反查依然能定位到城市级、商圈级——这是无法关闭的。

四、身份：你是谁，要不要被记住

这是 OpenRTB 2.6 最敏感、也变化最大的部分。

几个核心 ID

多个 ID 并存这件事很关键：哪怕你清了 Cookie，eids 里来自第三方的 hash 邮箱、hash 手机号依然能把你"接回来"。这是当前隐私监管的主战场。

OpenRTB 2.6 干掉了 8 个字段（这是大新闻）

很多写隐私的文章不会讲这点。OpenRTB 2.6 规范在 Device 和 User 对象里 明确标注 DEPRECATED 的字段：

device.didsha1 // 设备 ID 的 SHA1 哈希device.didmd5 // 设备 ID 的 MD5 哈希device.dpidsha1 // 平台 DPID 的 SHA1device.dpidmd5 // 平台 DPID 的 MD5device.macsha1 // MAC 地址的 SHA1device.macmd5 // MAC 地址的 MD5user.yob // 出生年份user.gender // 性别

为什么废？两个原因：

1. MD5/SHA1 哈希过的设备 ID 也不算"匿名"
   ——可以反查、可以做指纹关联，监管不认
2. yob 和 gender 太敏感
   ——属于"特殊类别个人信息"，欧盟 GDPR、中国 PIPL 都对这类字段有更严要求

2022 年的这次"瘦身"，是 OpenRTB 历史上第一次主动减字段。在此之前，协议只加不减。

Do Not Track / Limit Ad Tracking

device.dnt = 1 // 浏览器层面 Do Not Trackdevice.lmt = 1 // 操作系统层面 Limit Ad Tracking（iOS / Android）

规范要求：当这两个标志为 1 时，DSP 应当限制对该用户的追踪。

但实际执行——它只是个"建议"。没有强制机制，也没有惩罚条款。早期 DNT 几乎被全行业忽视。直到苹果在 iOS 14.5（2021）推出 ATT（App Tracking Transparency），把开关交给用户，事情才发生改变。

五、关键问题：把这些字段去掉就匿名了吗？

不是。

哪怕把 IDFA、Cookie、yob、gender 全部去掉，剩下的字段拼起来依然能高概率唯一识别你。

这就是浏览器指纹（Browser Fingerprinting）/ 设备指纹的原理。

电子前哨基金会（EFF）2010 年的 Panopticlick 研究 给出过一个数字：

仅靠 User-Agent、屏幕分辨率、时区、字体列表、语言这几个字段，83.6% 的浏览器是可以被唯一识别的。

OpenRTB 2.6 的 Bid Request 里这些字段全都在：

device.ua, device.h, device.w, device.ppi, device.pxratio,device.language, device.os, device.osv, device.make, device.model,device.connectiontype, device.carrier, device.ip

加上 geo 对象里的城市、IP 反查地区，指纹熵值（entropy）足够区分十亿级用户。

所以"匿名广告"在技术上是一个伪命题。 协议层面去掉的 ID 字段，可以被这些"准 ID"字段在 DSP 那边重新拼回来。这就是为什么监管必须从法律层面——而不仅是协议层面——去限制。

六、谁在管这件事？四个监管的对照

ATT 的效果可以量化：Adjust 2023 年报告显示，iOS 上用户主动选择允许追踪（即返回真实 IDFA）的比例只有 25% 左右。这直接重塑了整个移动广告行业的归因模式。

七、你能做什么

读完这些，你大概率有两种身份。

如果你是普通用户

• iOS
  ：设置 → 隐私与安全性 → 跟踪 → 关闭"允许 App 请求跟踪"。这等于全局把 device.ifa 关了
• Android
  ：设置 → 隐私 → 广告 → 删除广告 ID。Android 13 以上有效
• 浏览器
  ：用 Brave / Firefox + uBlock Origin，可以同时屏蔽广告和反指纹追踪
• 手机定位
  ：给 App 设权限时，优先选**"仅在使用期间"+"模糊位置"**——后者会把 lat/lon 的精度降到约 3 公里

如果你是开发者 / 投放方

• 熟悉 regs.gdpr / regs.gpp / user.consent
  ：欧美流量必须正确处理，否则有合规风险
• device.dnt = 1 或 device.lmt = 1 的请求
  ：技术上不强制，但合规上应当尊重——降低出价或不出价
• ifa 为空的请求
  ：从纯 ID 定向转向上下文定向（Contextual Targeting）+ 概率归因
• 关注 eids 演进
  ：UID 2.0、ID5 等替代方案是后 Cookie 时代的关键

八、本文要点

• OpenRTB 2.6 规范在 Device / User 对象里定义了约 50 个字段，绝大多数会出现在每一个 Bid Request 里
• 经纬度精度可达米级，IP 反查的兜底定位无法关闭
• 设备 ID 不止一个：ifa / user.id / buyeruid / eids 多套 ID 并存
• 2.6 主动废弃了 6 个哈希设备 ID 字段 + yob + gender，是协议历史上首次"减字段"
• 即使去掉 ID 字段，剩下的"准 ID"足够做浏览器指纹，再次定位到具体个人
• 全球四大监管（GDPR、ATT、Android、PIPL）从法律层面而非协议层面收紧——这是当前广告隐私博弈的真正战场

参考资料

• OpenRTB 2.6 Final Specification（IAB Tech Lab, 2022）3.2.18 / 3.2.19 / 3.2.20 节
• EFF Panopticlick / Cover Your Tracks 浏览器指纹研究
• Adjust《iOS Mobile App Trends Report》2023
• 苹果开发者文档：App Tracking Transparency
• Google Android 13 Advertising ID changes 官方公告

下一篇我们聊 OpenRTB 协议里最反常识的一处设计：

为什么出价最高的人，反而只付第二名的价格？Google 凭什么在 2019 年一夜之间把这个用了 15 年的规则废掉？

下次见。