程序化广告强调“把广告展示给合适的人”，但广告链路里的每个平台都有自己的用户标识。
同一个用户访问媒体网站时，SSP、AdX、DSP、DMP 或身份解决方案可能分别识别到不同 ID。若这些 ID 之间没有对应关系，DSP 就很难知道：竞价请求中的用户，是否正是自己要重定向、控制频次或排除的那个人。
Cookie Mapping（也称 Cookie Sync、ID Mapping）就是为解决这个问题而出现的机制。
它的核心不是共享 Cookie，而是让两个平台建立一条关系：
AdX 的用户 ID
A123= DSP 的用户 IDD456
建立映射后，AdX 在后续竞价请求中便可以向 DSP 传递可识别的用户标识或匹配数据；DSP 则能在自己的系统中找到对应的人群、频次和投放记录。
Cookie Mapping 解决什么问题？
在 Web 程序化广告中，常见参与方包括：
- 媒体网站（Publisher）
- SSP 或 AdX
- DSP
- DMP、CDP 或第三方受众平台
- 广告主网站与再营销标签
- 第三方监测、可视度或品牌安全服务商
每个平台都有自己的第一方 ID 或 Cookie。例如：
| 平台 | 平台本地 ID 示例 |
|---|---|
| DSP | dsp_user_6z14131 |
| AdX | exchange_user_7831 |
| 媒体或 SSP | publisher_uid_123 |
这些 ID 即使对应同一个浏览器，也不会天然相同。
原因在于浏览器的同源策略：dsp.example 不能直接读取 adx.example 下的 Cookie，反过来也一样。它们只能识别自己域名下的浏览器标识。
Cookie Mapping 的作用，就是在用户浏览器参与的请求链路中，让双方各自拿到属于对方域名的 ID，并将这对 ID 保存为映射关系。
Cookie Mapping 是什么？
Cookie Mapping 是广告技术平台之间建立用户 ID 对应关系的过程。
例如，DSP 保存一张 Match Table：
| AdX 用户 ID | DSP 用户 ID | 最近同步时间 |
|---|---|---|
| adx_7831 | dsp_6z14131 | 2026-08-11 |
| adx_9824 | dsp_5f89210 | 2026-08-09 |
当 DSP 收到竞价请求，并看到 adx_7831 时，就能查到对应的 dsp_6z14131，进而读取该用户是否属于再营销人群、已被展示多少次、是否已经转化等信息。
在 OpenRTB 中，交易平台的用户 ID 与买方已匹配的数据通常会通过用户相关字段传递。例如，Google 的 Real-time Bidding 文档中，user.id 可代表交易平台用户 ID，buyeruid 可承载已托管的买方匹配数据。
Cookie Mapping 可以支持的典型能力包括：
- 再营销
- 人群定向
- 频次控制
- 排除已转化用户
- 出价优化
- 曝光、点击和转化的辅助归因
但要注意：ID 已映射，不代表平台一定拥有完整用户画像，也不代表跨平台归因一定准确。 映射只是让平台能够识别“这是同一个浏览器或同一个可识别用户”的基础条件之一。
Cookie Mapping 的三个关键问题
| 问题 | 实际含义 |
|---|---|
| 谁发起同步？ | DSP、SSP、AdX、DMP 或身份服务商都可能发起，取决于合作模式和接口能力。 |
| 为什么要跳转到对方域名？ | 浏览器只有访问某个平台域名时，才可能携带该平台自己的 Cookie。 |
| 谁保存 Match Table？ | 可以由 DSP 保存、交易平台托管，或由双方各自保存。 |
Google 的 Cookie Matching 服务就支持两种模式：买方维护自己的 Match Table，或由 Google 托管买方匹配数据。托管模式可减少买方在竞价时查询和维护映射表的负担。
常见Mapping组合
| Mapping 组合 | 是否常见 | 说明 |
|---|---|---|
| DSP ↔ AdX | ⭐⭐⭐⭐⭐ | 主流方式 |
| AdX 主动发起 | ⭐⭐⭐⭐ | 大平台常见（Google, Facebook, 百度BES） |
| DSP ↔ DMP | ⭐⭐⭐ | DMP为DSP 补足用户画像 |
| PCP ↔ DMP | ⭐⭐⭐ | 媒体侧或第三方受众系统 |
| DSP ↔ PCP | ⭐⭐ | DSP使用第三方定向能力 |
Cookie Mapping 如何工作？
先看一个简化的数据流：
- 1、用户浏览网站，网站是接入广告交易平台的，判断是否符合如何要求后向ADX发起广告请请求
- 2、广告交易平台发起竞价活动，向不同的DSP发送bid request，里面会包含有访客信息
- 3、DSP根据发送的信息，去自己的用户系统，DMP查询匹配出用户的信息(如果找不到 → 触发 Cookie Mapping)，根据这些信息去出价
- 4、ADX中交易，价高者得，此高结算
- 5、返回竞得者信息给网站
- 6、网站请求广告资源素材
- 7、返回广告资源素材
在上面第3步的时候，从AdX接到的信息里面会有AdX-UID，这个是AdX专门用于Cookie Mapping的一个ID，如果DSP的系统里面找不到这个ID，那么就需要发起Cookie Mapping，如果找得到，那么直接就用找到的一些维度，用于计算该不该出价，该出多少。
我们这里只介绍三种方式：一种是是DSP和ADX，这个是主流的模式；一种是ADX主动发起的；一种是独立PCP和独立DMP的，这种是涉及独立广告服务平台的；其他按照前面的类似逻辑去处理。
第一类：DSP发起的Cookie Mapping（最主流）
这是传统 Web RTB 中最常见的模式。
接下来我们来看一下Cookie Mapping是怎么运行的，也就是没有Cookie或清除Cookie的时候：
前面的4步都是一样的
5、赢得广告展示后，由于在Match Table找不到该用户的信息，DSP发送广告素材和Match Tag（匹配标签）
匹配标签是由ADX提供的，上面会有对应的DSP的ID，Match Tag的结构如：
img src="http://cm.adx.net/pixel?dspid=1234&adx_cm
代码中的1234就是DSP的ID了。
6、将DSP发送广告素材和Match Tag发送给浏览器，如果是网站直接请求，则DSP直接到网站。
7、浏览器加载到Match Tag时，向ADX调用Cookie Match Server(所以Cookie Mapping能否实施是依赖AdX，有些AdX是需要另外申请才可以开通这个服务)
8、Cookie Mapping Server触发后，通过dpsid去获得对应DSP的接口和token，由于浏览器的限制，Cookie不能跨域访问，但ADX能通过http heeder获得在该域中下的 Cookie，将ADX的Cookie加密后生成一个openid，再将openid加到302重定向后的查询参数位置，重定向后的地址如：
http://ad.dsp.com/pixel?openid=dGhpcyBpcyBhbiBleGFtGxl&cver=1
DSP需要提供一个接口才能做跳转，假设DSP会提供如下的接口：
http://ad.dsp.com/pixel
9、浏览器加载DSP的url重定向，DSP接收到重定向请求后，从http和查询参数中解析的Cookie，重定向后跳转URL为：
http://ad.dsp.com/pixel?openid=dGhpcyBpcyBhbiBleGFtGxl&cver=1
里面openid就是加密后的ADX的的用户标识，然后在通过Http Header获取DSP的Cookie，再将映射关系存到Match Table。
10、发送一像素的图片到web页面，将映射关系种到cookie里。
至此，Cookie Mapping就完成。
如果是已经种好Cookie的，那么在第2步在Match Table里面查询到直接就用于出价的计算，赢得广告展示机会返回的就只有广告素材。
如果是双向Cookie Mapping，第10步的同时还会向ADX搭起一个携带有映射关系的请求，ADX如有对应借口则可以保存这个映射关系，实现DSP和ADX都保存有Match Table。
Cookie Mapping不是所有的成功竞价都会发起的，只有在用户系统里面找不到的时候才发起。Cookie是有有效期的，而且用户也可以主动清除Cookie，Cookie是会失效的，所以需要定期重新mapping。
对于一个新的DSP平台来说，可以预想得到的时候它的Match Tables（就是存储的匹配表）是很低，所以前期的精准度是比较低的，会发起比较多的Cookie Mapping去构建自己的Match Tables，可以选择一些已经投放比较大的平台，这类平台积累的Match Table会比较全和精准。
Cookie Mapping是精准营销的基础，但Cookie Mapping需要双方都有对应的API接口和匹配服务，不是所有的平台都会有，很多的DSP却对Cookie Mapping只是有限的支持，所以在数据打通上的能力也是有限的，特别是垂直媒体的。
第二类：AdX主动发起（大平台提供的 Mapping 方式）
ADX可以做主动的Cookie Mapping服务，以此能够扩大Cookie Matched的比例，将Cookie Matched Table上传到ADX的服务器中,ADX发起和保存的流程如下：
1、用户浏览网站，网站是接入广告交易平台的，判断是否符合如何要求后向ADX发起广告请求
2、广告交易平台根据广告请求的里的ADX的Cookie去DSP的Match Table匹配，找对应的属于DSP的Cookie，匹配后会有不同的逻辑：如匹配到就发起竞价活动；匹配不到的话，根据其他的角度判断，是否发送竞价活动，如果不发，就结束，如果发就继续。
3、 Match Table没有匹配到且发起竞价请求的情况才会有Cookie Mapping，广告交易平台发起竞价活动，向不同的DSP发送bid request，里面会包含有访客信息。
4、DSP根据发送的信息出价
5、ADX通知赢得广告展示
6、DSP发送广告素材发送给ADX
7、由于在Match Table找不到该用户的信息，ADX发起Match Tag连同广告素材发给浏览器，匹配标签是由DSP提供的，上面会有对应的ADX的ID，Match Tag的结构如：
<img src="http://cm.dsp.com/pixel?adxid=1234" />
代码中的1234就是ADX的ID了。
8、浏览器加载到Match Tag时，生成DSP的Cookie，向DSP调用Cookie Match Server
9、Cookie Mapping Server触发后，通过adxid去获得对应DSP的接口和token，由于浏览器的限制，Cookie不能跨域访问，但DSP能获得到DSP的Cookie，将DSP的Cookie加密后生成一个openid，再将openid加到302重定向后的查询参数位置，重定向后的地址如：
http://adx.network.com/pixel?openid=dGhpcyBpcyBhbiBleGFtGxl
ADX需要提供一个接口才能做跳转，假设ADX会提供如下的接口：
http://adx.network.com/pixel
10、浏览器加载ADX的url重定向，ADX接收到重定向请求后，从http查询解密参数中解析DSP的Cookie，重定向后跳转URL为：
http://adx.network.com/pixel?openid=dGhpcyBpcyBhbiBleGFtGxl
里面openid就是加密后的DSP的的用户标识，再通过http header去获取ADX的cookie，然后将映射关系存到Match Table。
11、发送一像素的图片到web页面，将映射关系种到cookie里。
至此，Cookie Mapping就完成。
目前如Google、Facebook、百度的BES都提供Match Table托管，Match Table托管有如下的优点：
- 节省流量：只发已匹配用户给DSP（Pre-targeting）
- 缩短响应时间：DSP免检索，直接获得映射后的 UID
- 提高匹配率：由AdX主动触达所有 DSP
第三类：PCP发起 → DMP Mapping（适用于独立受众平台）
独立 DMP、CDP、PCP 或第三方受众平台之间，也可能需要进行 ID 对接。
如媒体使用独立的 PCP，DSP使用独立的DMP，二者需要共享用户 ID。
下面是PCP向DMP发起的简要过程：
1、PCP在广告创意中嵌入DMP提供的 tag：，如：
<img src="http://www.dmp.com/?pcp_id=ichdata&pcp_uid=ichdat123">，
PCP需在后面拼接其pcp_id以及pcp_uid，以及接受服务。
2、由浏览器直接向DMP服务器发起cookie tag识别请求，请求会带上PCP用户cookie_id，DMP可以据此进行cookie mapping。
3、DMP识别用户标签后，由服务器后端直接向PCP API服务器发起callback请求，异步回写cookie tag数据。
Cookie Mapping与其他ID方案的区别
| 方式 | 常见环境 | 标识基础 | 主要限制 |
|---|---|---|---|
| Cookie Mapping | Web 浏览器 | 各平台 Cookie / 浏览器 ID | 第三方 Cookie 与浏览器限制 |
| 设备广告ID对接 | App | IDFA、GAID、OAID 等 | 系统授权、重置、平台政策 |
| 登录ID对接 | Web 与 App | 账户、会员 ID、邮箱哈希 | 需要用户登录与合规授权 |
| S2S ID Mapping | 平台间 | 第一方 ID、合作方 ID | 依赖合作关系、接口和数据治理 |
| Clean Room | 广告主与媒体/平台 | 受控数据匹配 | 不直接输出用户级明细 |
因此，App 不是“不需要 Mapping”，而是通常不使用传统浏览器 Cookie 同步。它更常依赖设备标识、登录 ID 或平台级受众接口。
Cookie Mapping面临的限制
第三方 Cookie 和浏览器限制
传统 Cookie Mapping 依赖跨站请求、重定向或像素标签。只要浏览器阻止第三方 Cookie，映射成功率就会下降。
在 Chrome 中，用户可以选择阻止第三方 Cookie；对于启用相关限制的环境，带有 SameSite=None 的跨站 Cookie 也可能无法使用。
因此，Cookie Mapping 已不能被视为所有 Web 用户都可用的身份识别手段。
用户同意与隐私法规
GDPR、CCPA/CPRA 等法规，以及地区性隐私要求，会影响 Cookie 写入、ID 同步和受众共享是否可以进行。
技术上“能够同步”，不代表业务上“可以同步”。平台应根据适用法规、CMP 的同意状态、合同关系和数据处理角色决定是否触发相关请求。
映射会失效
Cookie 可能被用户清除、过期或被浏览器限制；平台 ID 也可能轮换。因此，Match Table 不是永久有效的，通常需要更新和失效管理。
ID 映射不等于跨设备识别
传统 Cookie Mapping 通常识别的是同一浏览器，而不是同一个真实自然人。
用户更换设备、浏览器、无痕模式或清除网站数据后，原有映射可能失效。跨设备识别通常需要登录 ID、经授权的哈希标识或其他隐私合规的身份方案。
后Cookie环境下，应该如何理解Cookie Mapping？
Cookie Mapping 不会立刻消失，但它已从“默认可用的底层能力”变成“只在部分环境、部分用户和部分合作链路中可用的身份信号”。
更现实的做法是组合使用：
- 广告主第一方数据与登录体系；
- 服务器端事件与转化数据；
- 媒体提供的第一方受众信号；
- 隐私合规的替代 ID；
- 上下文定向；
- 数据洁净室和受控匹配；
- 浏览器提供的隐私保护广告技术。
Privacy Sandbox 的设计目标并不是逐项复制第三方 Cookie 的能力，而是为某些广告场景提供新的基础组件；部分依赖跨站用户画像的能力无法一对一复现
总结
Cookie Mapping 的本质，是让不同广告技术平台建立“你的用户 ID 对应我的用户 ID”的关系。
它让 DSP 能够在竞价请求中识别部分用户，进而支持再营销、频次控制、人群定向与出价优化。但它并不共享 Cookie，也不保证跨设备识别或完整归因。
传统浏览器端 Cookie Mapping 仍然存在于部分广告技术链路中，但会受到第三方 Cookie 限制、用户同意、ID 失效和平台接口能力的影响。对于今天的广告主和 AdTech 平台，更可靠的方向是：将它视为多种身份与数据协同方案中的一种，而不是唯一基础。