诊断决策 / 增强型转化验证
Enhanced Conversions 已开启，为什么仍不能算验收通过
开关状态只证明配置意图。基础转化、用户数据来源、规范化、同意状态、匹配诊断与报表变化都要单独验证。
TL;DR
先把本篇问题写成一句话，再确认它影响的是流量、Feed、页面、结账、EDM 还是数据复盘。
验证流程
围绕事件触发、参数、去重、Consent、归因和平台回读留下证据；执行前核对当前规则。
直接判断：Enhanced Conversions 是基础转化信号的补充匹配层，不是“丢数修复”按钮。 如果 purchase 本身触发错误、订单键不稳定、价值字段失真或同意逻辑不合规，增强层只会把有问题的事件更容易匹配回广告，而不会修正业务语义。
先做判断
先确认为什么要启用：是改善跨设备与 cookie 损失下的匹配，还是为线索业务连接后续离线结果？这两类用途的数据出现时机和验证证据不同。目标不清时，很容易在结账完成页抓到一个看似有值的字段，却无法证明它来自用户主动提供、经过正确同意，并与最终业务事件相连。
“已开启”“标签已触发”“诊断显示活跃”是三个不同状态；“活跃”也不等于匹配质量足够，更不等于新增归因全部可信。验收需要同时满足基础事件可靠、数据来源合法明确、传输前规范化正确、平台能处理、长期趋势可解释。
诊断框架
按五个问题检查健康度：
- 基础事件是否合格：先用漏记诊断确认成功条件、唯一键、价值和币种。
- 用户数据从哪里来：字段应来自明确的结账或表单输入，不从页面上模糊自动抓取，也不在日志与截图中暴露明文。
- 规范化与散列由谁负责：浏览器标签与 API 流程的责任不同。验证应看发送负载是否符合当前官方要求，而不是自行假定某层一定会处理。
- 同意状态是否允许：采集、用于广告测量和个性化是不同问题，应与Consent 信号顺序诊断共同验收。
- 平台回读是否稳定：等待正常处理后查看诊断、错误和趋势；把自然波动、季节和其他标签变更从影响中隔离。
最后把开关、触发、负载、接收、诊断与趋势证据串进转化追踪验收证据链，才能声称“已验证”，不能只说“已安装”。
常见误判
- “数据会散列，所以任何采集都合规。”散列不消除告知、同意、用途限制和数据治理责任。
- “匹配率越高越好。”异常升高也可能来自错误字段、重复事件或样本变化，需要结合业务事实判断。
- “增强型转化会补回所有漏记。”无法产生基础事件、没有可用标识或不允许处理的场景，不会被魔法恢复。
- “诊断绿灯就是业务验收。”绿灯通常只证明平台看到可处理信号，不证明价值、去重和 Primary 选择正确。
- “开启后转化上涨就是增量增长。”它可能只是归因可见性变化，订单事实没有变化。
验证清单
- 基础转化事件已独立通过触发、去重、价值与币种验证。
- 用户数据字段来源、使用目的、保存与访问边界已记录。
- 同意状态变化下的发送行为符合当前政策与内部要求。
- 未在调试截图、日志或文章中暴露明文个人数据。
- 平台诊断、错误状态和处理等待期已回读。
- 上线前后只解释归因可见性变化，不把它冒充业务增量。
适用边界
本文适用于已经有稳定网站转化或离线回传基础、准备验证 Enhanced Conversions 的团队。具体可用字段、规范化要求、散列责任、诊断状态、地区政策和产品命名都可能变化，实施前必须核对当前 Google 官方文档、CMP 规则和适用法律。本文不提供按钮步骤，也不构成隐私或法律意见。