Pinterest Tag 追踪的内容

Pinterest Tag 从 s.pinimg.com/ct/core.js 加载，通过名为 _pinterest_ct_ua 的 Pinterest 专属 Cookie 识别用户，同时使用平台的 _pin_unauth Cookie 识别未登录访客。标签加载后，自动上报基础 PageVisit 事件，并随后接受 AddToCart、Checkout、Purchase、Lead、Signup、WatchVideo 及自定义事件的调用流。每个事件携带一个 JSON 载荷，可包含商品 ID、订单金额、货币及内容分类——正是这类载荷结合 Cookie 标识符，使 Pinterest 得以将转化归因到具体的 pin 曝光和广告点击。

从法规角度而言，有三点至关重要。其一，这些 Cookie 属于非必要性 Cookie——它们服务于广告归因，而非网站功能。其二，离开页面的数据在 GDPR 框架下属于个人数据，因为可与标识符相关联。其三，Pinterest 在美国设立，这意味着相关数据传输受 EU-US 数据隐私框架及其底层标准合同条款的约束。上述三个条件均将 Pinterest Tag 明确划入 EU 和 UK「须事先自由给予同意」的范畴。

Pinterest 原生隐私控制 vs 第三方 CMP

Pinterest 确实提供了一些原生隐私控制措施。广告主控制台设有针对加州流量的 Limited Data Processing 开关，标签支持在单个事件调用上传入 consent 属性，Pinterest 也记录了通过 Conversions API 实现服务器端标记的路径。但这些均不等同于一个有效运作的同意横幅。原生控制措施假定同意已在上游某处收集并以信号形式传入——它们本身不负责收集同意，也不会在缺乏同意时阻止标签触发。对于跨多个司法管辖区运营的发布商而言，切实可行的架构是由第三方 CMP 决定是否允许标签加载，而 Pinterest 的原生标志则在同意授予后用于精细化调整行为。

与第三方 CMP 的分步集成

可靠的集成模式与其他主流像素相同：阻止标签在页面加载时触发，将控制权移交给 CMP，当访客接受营销类别时由 CMP 加载并配置标签。以下是针对 Pinterest 的具体步骤。

1. 移除内联基础代码

Pinterest 提供了安装人员通常粘贴至文档 head 区域的基础代码片段。将其移除，替换为 CMP 稍后可改写的占位符——大多数 CMP 的实现方式是将 type 属性从 text/plain 改为 text/javascript，并添加 data-category="marketing" 属性。

2. 将标签映射至营销类别

Pinterest 标签同时涉及类分析事件（PageVisit）和纯广告事件（Purchase、AddToCart）。出于审计可辩护性的考量，整个代码片段应归入营销类别，而非分析类别。对 EDPB 指导意见的保守解读认为：任何向广告平台输送数据的像素，无论触发何种事件类型，均属营销范畴。

3. 配置加载回调

当访客授予营销同意时，CMP 触发一个事件。在该处理函数中，将标签占位符改写回 text/javascript，将其追加至文档并使其执行。基础代码初始化全局 pintrk 队列，随后加载核心脚本。脚本加载完成后，页面中所有已入队事件将自动批量发送。

4. 为 Limited Data Processing 路由逐事件同意

若存在加州流量，且希望对未选择加入的用户使用 Pinterest 的 Limited Data Processing 路径，请在每次事件调用时推送相应的 data_processing_options。Pinterest 接受携带国家和地区代码的 ['LDU'] 值，将该事件标记为受限用途。这不是 EU 同意要求的替代方案——它是 CCPA 专属机制——但对于在加州规则下拒绝出售或共享数据的用户，这是正确的处理模式。

5. 如同时运行 Google 标签，则桥接至 Consent Mode v2

同时运行 Pinterest Tag 的大多数网店也在运行 Google Ads 和 GA4。CMP 必须在任何 Google 标签触发之前，将 v2 信号——ad_storage、analytics_storage、ad_user_data、ad_personalization——推送至 dataLayer。Pinterest 不直接使用这些信号，但 Google 会，两个技术栈之间的不一致性将在归因报告中体现为可量化的收入缺口。

Conversions API 作为服务器端替代方案

Pinterest 的 Conversions API 允许直接从服务器向 Pinterest 发送转化事件，完全绕过浏览器。这一方案的吸引力与日俱增，原因有二：其一，它在第三方 Cookie 被弃用后仍可正常运作；其二，它规避了浏览器端标签在同意方面的一些脆弱性，因为服务器对谁同意了哪些内容掌握更清晰的信息。

Conversions API 并不消除同意要求。所发送的事件仍携带个人数据，GDPR 的适用方式与请求来自浏览器还是后端服务无关。它的作用是将决策点从「标签是否在同意前触发」转移至「我方服务器是否将该事件纳入 API 载荷」——这是一个可控性更强的操作界面。对大多数网店而言，正确模式是两者并用：在同意授予时通过浏览器端标签实现实时归因，通过 Conversions API 发送经去重处理的服务器端事件——这些事件在发出前可依据存储的同意状态进行过滤。

常见误区

三类集成错误占据了我们在审计 Pinterest 安装时所发现问题的大多数。

将 PageVisit 视为分析事件

部分团队将 Purchase 和 AddToCart 置于营销同意门控之后，却允许 PageVisit 在分析类别下触发，理由是页面浏览「只是分析」。Pinterest 并不认同这一观点——PageVisit 为再营销受众构建器提供数据，这明确属于营销职能。应对整个标签实施阻断。

在标签管理器中硬编码 Pinterest 基础代码而未设置同意保护

如通过 Google Tag Manager 安装标签，Pinterest 标签模板需将 Additional Consent 字段配置为在触发前要求营销同意。若缺少该标志，GTM 将无视访客的 CMP 状态直接触发标签，同意横幅将沦为装饰性元素。

未事先核验同意即发送 Enhanced Match

Pinterest 支持 Enhanced Match，允许对可识别用户数据（电子邮件、电话号码）进行哈希处理并传递，以提升归因精度。对未授予营销同意的用户发送 Enhanced Match，是该技术栈中风险最高的操作模式——这是在缺乏合法依据的情况下，将个人数据直接传输给美国广告平台。应将 Enhanced Match 与标签其余部分设置相同的同意条件。

审计清单

针对涉及 EU、UK 或加州流量的任何 Pinterest Tag 部署，需回答以下六个具体问题。

• 标签是否等待同意？在启用严格追踪保护的隐私窗口中打开页面，确认在横幅被接受之前没有 s.pinimg.com 请求触发。
• 营销类别是否正确映射？验证 CMP 将标签归入营销类别，而非分析或功能类别。
• GTM 是否遵从同意设置？若标签通过 Google Tag Manager 安装，确认已配置 Additional Consent 选项。
• 加州流量是否路由了 Limited Data Processing？对于 CCPA 选择退出但仍在 LDP 下允许追踪的用户，确认每个事件均设置了 data_processing_options。
• Enhanced Match 是否为条件触发？确认 Enhanced Match 载荷仅在用户授予营销同意时发送。
• Conversions API 是否与浏览器同意保持一致？若两个操作面均在运行，确认服务器端路径在转发前依据存储的同意状态过滤事件。

Pinterest 在同意优先技术栈中的定位

Pinterest 在营销像素领域的体量虽小于 Meta 或 Google，但其受到的法规规制完全相同。有效的合规模式与所有主流广告平台一致：在访客接受营销类别之前将标签拒于页面之外，以 CMP 作为同意状态的唯一权威来源，并将平台自身的隐私标志（Limited Data Processing、Conversions API 的同意字段）配置为与横幅所记录的内容相一致。做到这一点的品牌，在保留 Pinterest 归因能力的同时，将审计风险压缩至默认安装方式的极小比例。