最后更新于 2026年8月28日 21:01
如何使用本指南
本指南适用于效果营销人员、电商运营人员、分析师、开发人员,以及需要审核代理商、插件、应用或内部方案所安装跟踪代码的团队。请在预发布环境中测试,或使用可以取消和退款的测试订单。不要反复使用真实客户订单进行测试。
完成本指南后,您应该能够
- 区分代码存在、标签触发、请求发送、平台接收,以及转化是否符合出价条件。
- 验证订单ID、收入、币种、产品ID和事件ID等关键字段。
- 诊断重复购买、购买事件缺失、零价值转化、跨域归因丢失和同意配置问题。
- 针对Shopify、WordPress、WooCommerce或自定义电商技术栈选择正确的诊断方法。
- 为营销、开发、分析或管理团队生成清晰的诊断报告。
为什么已经安装的跟踪代码仍可能产生不可靠的数据
当独立电商网站开始在Google Ads、Meta Ads、Microsoft Ads或TikTok Ads上投放广告时,每个平台都会要求安装跟踪标签或像素。仅在页面源代码中找到这些代码,并不能证明转化跟踪运行正常。
- 广告平台将标签显示为未验证、未启用或近期无活动。
- GA4记录了订单,但Google Ads没有显示转化。
- 商店后台只有一个订单,广告平台却报告了两次购买。
- 转化次数看起来合理,但收入、币种或产品数据不正确。
- 首页能检测到像素,但在结账流程或订单确认页面中消失。
- 浏览器和服务器事件都已发送,但没有正确去重。
- 广告跟踪未按照访客的同意选择运行:在营销同意为denied后,广告存储仍被写入或读取,或者广告标识符或用户数据仍被发送。在高级同意模式下,即使ad_storage或analytics_storage为denied,也仍可发送无 Cookie 的同意 ping;仅出现这种行为并不代表实施失败。
- 访客授予同意后,标签没有恢复运行。
完整的审核不能止步于“代码是否存在?”还要确认每项真实业务操作都以正确的事件名称、参数、价值、币种和订单ID到达正确的平台,并且浏览器端和服务器端的发送在去重后归并为一次逻辑转化。
1. 广告跟踪诊断实际检查什么
广告跟踪可以从五个层级进行评估。只有五个层级全部通过,数据才适合用于效果分析、ROAS计算和自动出价。
| 诊断层级 | 需要回答的问题 | 常见问题 |
|---|---|---|
| 代码加载 | 基础标签是否在所有必要页面加载? | 未安装、ID错误、脚本被阻止 |
| 事件触发 | 事件是否在用户完成操作后触发? | 触发条件错误、触发前发生重定向 |
| 参数发送 | 价值、币种和订单ID是否正确? | 变量为空、格式错误、重复使用订单ID |
| 平台接收 | 目标平台是否确实收到了该事件? | 请求被阻止、同意限制、请求错误 |
| 广告应用 | 该事件是否用于报告和出价? | Secondary操作、目标重复、广告系列未使用该目标 |
GTM中的“标签已触发”消息只能证明触发条件已满足,不能证明转化数据准确。请继续检查数据层、网络请求、平台测试工具和对应的后台订单。
2. 先制定电商事件跟踪方案
在排查问题之前,先确定网站真正需要衡量的客户行为。典型的电商实施至少应涵盖查看产品、加入购物车、开始结账和购买。
| 客户行为 | 建议的GA4事件 | 常用Meta事件 | TikTok标准事件 | Microsoft Ads |
|---|---|---|---|---|
| 查看产品 | view_item | ViewContent | ViewContent | 页面事件或自定义事件 |
| 加入购物车 | add_to_cart | AddToCart | AddToCart | 自定义事件 |
| 开始结账 | begin_checkout | InitiateCheckout | InitiateCheckout | 自定义事件 |
| 完成购买 | purchase | Purchase | Purchase | 采用可变收入的转化目标 |
| 提交潜在客户表单 | generate_lead | Lead | Lead | 自定义事件 |
在本指南的2026年8月版本中,TikTok使用Purchase作为标准电商purchase事件,并使用Lead表示潜在客户提交。CompletePayment和SubmitForm是分别映射到Purchase和Lead的兼容旧名称;没有迁移计划时,不要重命名正在正常运行的旧版实施。仅在确有联系行为时使用Contact。GA4使用purchase,并建议提供transaction_id、value、currency和items数组等参数。
purchase事件所需的最低数据要求
| 参数 | 示例 | 需要验证的内容 |
|---|---|---|
| 订单ID | ORD-10086 | 每个订单必须唯一,刷新页面后保持不变 |
| 转化价值 | 129.90 | 必须是数值,而不是$129.90之类的格式化字符串 |
| 币种 | USD | 正确的三字母ISO币种代码 |
| 产品ID | SKU-001 | 最好与商品目录或Merchant Center Feed保持一致 |
| 数量 | 2 | items数组中完整且准确的产品数量 |
| 浏览器端/服务器端去重ID(因平台而异) | evt_ORD-10086 | Meta和TikTok使用匹配的event_id,并为浏览器端/服务器端去重采用相同的事件名称或类型。GA4和Google Ads的购买去重使用transaction_id。 |
3. 准备诊断测试
不要将真实客户订单作为主要测试。创建一个可以取消或退款的测试订单,并在开始前记录以下信息。
| 测试字段 | 示例 |
|---|---|
| 测试时间 | 2026-08-27 10:35 |
| 浏览器 | Chrome无痕模式 |
| 设备 | Windows桌面设备 |
| 同意状态 | 已接受分析和营销Cookie |
| 测试订单ID | TEST-ORD-001 |
| 预期价值 | 49.90 |
| 预期币种 | USD |
| 测试路径 | 首页 -> 产品 -> 购物车 -> 结账 -> 支付成功 |
进行主要实施测试时,请禁用浏览器的广告拦截扩展程序,但不要禁用网站的同意横幅。广告拦截测试和同意测试应分开进行,否则无法判断究竟是浏览器扩展程序还是同意配置阻止了标签。
至少测试三种同意场景
- 尚未选择Cookie设置的新访客。
- 接受所有相关Cookie的访客。
- 拒绝营销Cookie的访客。
对于Google 同意模式,请在相关标签运行前设置默认同意状态,并在访客作出选择后于同一页面及时更新。请分别验证ad_storage、analytics_storage、ad_user_data和ad_personalization。高级同意模式可能在存储状态为denied时发送无Cookie的ping;请确认没有违反访客选择而发送广告存储、广告标识符或用户数据。
诊断工具集
1. Google Tag Assistant和GTM Preview
Google Tag Manager预览会显示页面事件、已触发和未触发的标签、触发条件、变量以及同意状态。它回答两个关键问题:网站上发生了什么,以及GTM为何触发或未能触发标签?

2. GA4 DebugView
GA4 DebugView可确认GA4是否确实收到事件,并显示其参数。它有助于区分GTM实施问题与发送或GA4数据收集问题。
3. Chrome DevTools Network面板
Network面板会显示浏览器实际发送的请求。您可以按平台域名、请求类型、文件名、标签ID或衡量ID筛选。它是回答“浏览器是否发送了数据?”这一问题的关键工具。
4. 平台专用测试工具
在Meta Events Manager中使用Test Events和诊断;TikTok使用Pixel Helper、Test Events和诊断;Microsoft Advertising使用UET Tag Helper;Shopify自定义像素使用Shopify Pixel Helper。
4. 完整的广告跟踪诊断工作流程
步骤1:盘点所有跟踪实施
重复转化往往源于同一平台被安装了多次,而不是某个标签本身损坏。
- GTM在主题中安装了一次,又通过插件安装了一次。
- 官方Shopify Meta应用安装了一个像素,同时还存在单独的自定义Meta pixel。
- WordPress插件发送Purchase,而GTM又发送了相同的Purchase。
- 原生Google Ads购买操作和导入的GA4购买操作都被设为主要目标。
- Meta Pixel和Conversions API在没有有效去重的情况下发送同一笔购买。
- TikTok应用、GTM和主题代码分别安装了同一个像素。
创建一份实施清单。为便于阅读,请将安装方式、基础标签位置、购买事件来源和服务器事件状态合并到一个实施说明字段中。
| 平台 | 标签或像素ID | 实施说明 |
|---|---|---|
| GA4 | G-XXXXXXX | 通过GTM在全站加载;购买事件由数据层触发;没有服务器事件 |
| Google Ads | AW-XXXXXXX | 通过GTM加载;确认付款后触发购买转化 |
| Meta | 像素ID | 通过Shopify应用/客户事件安装;应用发送浏览器端和服务器端事件 |
| TikTok | 像素ID | 通过GTM在全站加载;购买事件由数据层触发 |
在页面源代码、GTM标签列表、WordPress插件、主题自定义代码区域、Shopify Customer Events、Shopify应用、Cloudflare Zaraz、服务器端GTM及任何自定义后端集成中搜索每个ID。
步骤2:确认基础标签正确加载
对于GTM,请勿先直接打开订单确认页面。应从首页或广告着陆页连接预览,然后按照真实客户路径依次经过产品查看、购物车、结账和付款。

- 确认预览已连接到正确的域名。
- 确认页面加载时出现预期的GTM容器。
- 确认容器ID与当前启用的账号和环境一致。
- 确认基础Google tag在所有必要页面加载。
- 检查支付成功页面是否仍处于同一调试会话。
- 检查重定向或跨域跳转后会话是否中断。
- 检查Consent Initialization及任何会阻止标签的同意状态。
同时打开Chrome DevTools,在Network面板中搜索GTM容器ID、GA4衡量ID、Google Ads转化ID、Meta pixel ID、TikTok像素ID或Microsoft UET标签ID。由于请求路径可能变化,搜索实际ID比依赖固定端点更可靠。
完全没有出现请求时,先检查以下项目
- 代码缺失或配置的ID错误。
- GTM容器尚未发布,或加载了错误的环境。
- 同意设置阻止标签运行。
- 内容安全政策阻止了外部脚本或端点。
- 广告拦截器或浏览器隐私设置阻止了请求。
- 跟踪代码执行前发生JavaScript错误。
- 缓存或CDN仍在提供旧版网站代码。
步骤3:验证数据层或客户事件
数据层是电商活动与广告标签之间的桥梁。Google Tag Manager和gtag.js从这个结构化层读取事件和变量。应使用可预测的结构化数据,而不是让标签从无关的页面元素中抓取值。
一个简化的GA4风格purchase事件如下所示:
<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: "purchase",
ecommerce: {
transaction_id: "ORD-10086",
value: 129.90,
currency: "USD",
tax: 8.20,
shipping: 0,
items: [
{
item_id: "SKU-001",
item_name: "Portable Coffee Grinder",
price: 64.95,
quantity: 2
}
]
}
});
</script>对于GA4电商,事件级value通常应等于items数组中各项price乘以quantity后的总和,不应包含shipping或tax,除非您记录的报告口径和目标平台明确要求采用其他价值定义。
在Chrome控制台中使用以下命令进行初步检查:
window.dataLayer仅显示purchase事件:
window.dataLayer?.filter(item => item.event === "purchase")验证以下六点
- 事件在正确时间发生:Purchase应在订单真正成功后生成,而不是仅在客户点击“立即付款”或“提交订单”时生成。
- 订单ID唯一:页面刷新后,同一订单应保留相同ID;不同订单绝不能共用同一ID。
- 价值为数值:使用129.90,而不是“$129.90”“USD 129.90”或包含千位分隔符的字符串。
- 币种与订单一致:对于多币种商店,请对比显示币种、结算币种以及发送至平台的币种。
- items数组完整:产品ID、价格、数量和折扣应能与后台订单核对一致。
- 不保留旧值:单页应用、购物车抽屉以及AJAX结账流程可能会误用上一个事件的数据。
步骤4:检查GTM触发器和变量
在GTM Preview中完成一次真实测试路径,选择purchase事件,然后检查Tags Fired、Tags Not Fired、Variables、Data Layer和同意。


触发条件过于宽泛
“页面URL包含thank-you”之类的规则,会在访客刷新、收藏或再次打开确认页面时重新触发。电商购买最好使用真实的订单完成事件和唯一订单ID。
触发条件过于严格
实际URL可能是/en/checkout/success,而触发器只允许/checkout/success。语言目录、查询字符串和备用结账路径都会使过于严格的规则失效。
自定义事件名称不匹配
数据层发送event: “checkout_completed”,但GTM监听purchase。事件名称必须完全一致,包括大小写和下划线。
标签在数据到达前触发
标签在页面加载期间运行,但value、currency和订单ID要在几百毫秒后才进入数据层。标签看似触发成功,实际却发送了空参数。
AJAX或单页应用没有产生传统页面加载
购物车抽屉、模态结账,以及React或Vue应用可能不会产生普通页面浏览。应根据业务事件触发跟踪,而不要只依赖页面加载或URL变化。
步骤5:使用Network确认请求已发送
打开Chrome DevTools -> Network,启用Preserve log,然后重复完整测试。按平台ID或域名筛选,打开匹配的请求并检查Headers和Payload。
- 验证目标平台及标签或像素ID。
- 验证事件名称、价值、币种和订单ID。
- 确认产品ID、数量和items数组均已提供。
- 确认浏览器端和服务器端事件使用平台所需的相同去重标识符:Meta和TikTok要求事件名称或类型与event_id匹配,而GA4和Google Ads的购买使用transaction_id。
- 检查请求是否被取消、阻止或返回错误。
- 检查请求发生在页面重定向之前还是之后。
观察到带有合理载荷的请求,只能证明浏览器尝试发送,或某个端点接受了请求。它不能证明平台已处理、归因、符合出价条件或业务数据准确。value为0的Purchase请求仍可能成功发送。
GTM显示标签已触发,但Network中没有请求
- 同意状态和内置同意检查。
- 广告拦截或浏览器隐私设置。
- 内容安全政策限制。
- 标签模板损坏或JavaScript运行时错误。
- 立即跳转导致请求被取消。
- Shopify Pixel Sandbox限制。
步骤6:确认各广告平台已收到事件
GA4
打开DebugView,选择测试设备,并确认事件顺序合理:
page_view
view_item
add_to_cart
begin_checkout
purchase打开purchase并验证transaction_id、value、currency和items。

Google Ads
打开Goals -> Conversions -> Summary,检查相关操作的跟踪状态。若状态为“未验证”“标签无效”或“需要处理”,请从转化操作中启动Tag Assistant。修复后账号状态可能需要一些时间才会更新,因此请使用Tag Assistant和实际请求进行即时验证。

Meta Ads
在事件管理工具中选择正确的数据源,并检查“概览”、Test Events、诊断、Event Deduplication和Event Match Quality。Test Events用于确认浏览器端和服务器端发送;诊断用于识别重复事件、无效参数或数据质量问题。
TikTok Ads
使用TikTok Pixel Helper检查浏览器标签、事件和参数;使用事件管理工具 -> Test Events检查实时接收;使用事件管理工具 -> 诊断检查持续存在的实施错误。
Microsoft Advertising
使用UET Tag Helper验证UET标签ID、页面加载事件、自定义事件、可变收入、币种和转化目标条件。Microsoft Advertising中的UET状态可能需要更多时间才会更新。如果同时使用Microsoft Advertising Conversions API,请验证其event_id,并确认浏览器端和服务器端发送不会造成重复报告。对于可变收入,请严格按照目标平台要求保留revenue_value和currency。
5. 诊断重复的Conversions和Event Deduplication
重复购买会夸大报告的ROAS,并向自动出价输入错误信号。应同时检查浏览器端、服务器端、插件、应用、GTM和导入目标,而不是只审核其中一个层级。
Google Ads去重
Google Ads建议为每笔购买发送唯一交易ID。如果刷新确认页面,并把同一订单再次发送到同一个转化操作,Google Ads可以利用相同的交易ID识别重复。交易ID不会自动对不同Purchase转化操作进行去重。
- 不同订单不得共用同一交易ID。
- 交易ID不得为空。
- 不要使用客户电子邮箱或电话号码作为订单ID。
- 浏览器标签和后端上传应为同一笔交易使用相同订单ID。
Meta Pixel和Conversions API去重
当同一个Purchase通过Meta Pixel和Conversions API发送时,浏览器端和服务器端事件必须共享同一event_name和event_id。不同订单必须使用不同的event_id值,否则一笔订单可能被计为两个事件。
- 浏览器端和服务器端事件是否使用相同的event_name?
- 同一订单的两个版本是否使用相同的event_id?
- 每笔不同订单是否都获得不同的事件ID?
- 服务器重试是否生成了新的事件ID,从而意外产生第二个事件?
- Shopify应用和自定义CAPI实施是否都在发送同一笔购买?
TikTok Pixel和Events API去重
当TikTok Pixel和Events API发送同一事件时,两端必须使用相同的事件名称或类型以及相同的event_id,TikTok才能识别这对事件并保留一个逻辑事件。
刷新订单确认页面
仅使用确认页面的页面浏览来触发Purchase风险很高。刷新、收藏或重新打开页面都可能再次触发事件。请使用唯一订单ID;在条件允许时,应由真实的订单完成事件触发,而不是依赖普通页面加载。
6. 检查转化Goals、跨域结账和归因
Primary与次要转化操作
在Google Ads中,主要转化操作通常显示在Conversions列中,并且当广告系列使用相关目标时可用于出价。Secondary操作主要用于观察,通常显示在All conversions中。不过,当次要操作被纳入广告系列正在使用的自定义目标时,也可以用于出价。
如果事件出现在账号中,但广告系列没有据此进行优化,请确认该操作是主要操作,并且广告系列正在使用对应目标。
Every与One
Purchase操作通常需要统计每笔交易。Lead表单常使用One,因为同一次广告点击产生的重复提交不一定代表多个有价值的潜在客户。对于销售,请使用唯一交易ID移除重复订单。

重复的主要购买目标
一个账号可能同时包含原生Google Ads Purchase、导入的GA4 Purchase,以及Shopify应用创建的Purchase。如果三者都被设为主要操作且由广告系列使用,Conversions列可能会针对一笔订单包含多个购买信号。
增强型Conversions
启用增强型Conversions后,请确认符合条件的第一方客户数据确实以要求的格式发送。基础Purchase标签正常运行,并不能证明增强型Conversions状态良好。
跨域结账和支付重定向
有些商店会将访客从主域名引导至单独的结账域名、第三方支付服务商、预订系统、表单服务、子域名或地区站点。跨域配置错误可能导致:
- 一次客户会话被拆分为多个会话。
- 原始广告来源消失。
- 支付服务商成为报告中的引荐来源。
- 点击ID在结账前丢失。
- 店面有事件,但支付成功后没有事件。
仅在您控制、且可以部署同一个GA4标签的域名之间使用GA4跨域衡量。对于无法部署该标签的第三方支付域名,请检查List unwanted referrals,避免支付服务商取代原始来源;这不能替代跨域衡量。请从着陆页开始测试完整重定向,而不是直接打开成功页面。

7. Shopify专用跟踪诊断
Shopify Customer Events像素在沙盒环境中运行。应用像素使用严格沙盒,自定义像素使用宽松沙盒,两者的功能并不完全相同。两者都应依赖Shopify Customer Events和Web Pixels API,而不是传统的DOM抓取。
1. 不要只依赖Google Tag Assistant
Google Tag Assistant与Shopify中的GTM自定义像素不兼容。请使用Shopify Pixel Helper确认客户事件进入沙盒,再验证由此产生的Network请求,以及目标平台的Test Events或诊断信息。
Shopify Pixel Helper -> 自定义像素dataLayer -> GTM标签 -> Network请求 -> 广告平台Test Events
2. 避免在沙盒内抓取DOM
Shopify Web Pixels在沙盒中运行。读取或修改店面DOM的实施可能失败或表现不一致。应优先使用Shopify Customer Events和Web Pixels API提供的数据,而不是通过CSS选择器抓取产品价格、按钮或订单详情。
- 直接监听主题按钮的点击触发器。
- 抓取页面所显示产品价格的DOM元素变量。
- 直接使用document.querySelector。
- 把沙盒URL当作店面URL使用。
- 假设GA4增强型衡量可以自动发现每次沙盒交互。
3. 检查像素是否正在等待同意
打开Shopify设置 -> 客户事件 -> 自定义像素并开始测试。如果Pixel Helper报告“像素正在等待同意”,请检查:
- 分配给自定义像素的客户隐私权限。
- 当前市场所使用的Cookie横幅配置。
- 访客是否granted了Analytics或Marketing 同意。
- 同意管理平台是否与Shopify Customer Privacy API集成。
4. 正确使用checkout_completed
Shopify checkout_completed通常在每次结账时触发一次,且经常可以在“谢谢”页面观察到。如果存在购买后加购,它可能会在第一个加购页面触发,而不会在“谢谢”页面再次触发。如果预期页面未成功加载,它也可能无法触发。
测试标准银行卡结账、Shop Pay或快捷结账、折扣订单、免费订单、购买后加购、多币种订单,以及“谢谢”页面未完全加载的情况。
8. 常见WordPress和WooCommerce诊断问题
WordPress最常见的问题并不是无法安装跟踪,而是在太多位置重复安装同一套跟踪。请按顺序检查以下位置:
- GTM安装插件。
- GA4或广告转化插件。
- 单独的Meta、TikTok或Microsoft Advertising插件。
- 主题页眉和页脚的自定义代码区域。
- 页面构建器的自定义代码。
- WooCommerce“谢谢”页面自定义内容。
- CDN、缓存、脚本合并和JavaScript延迟设置。
WooCommerce加入购物车、结账和支付流程经常被AJAX或第三方插件修改。不要假设标准按钮点击规则或默认确认页面规则仍然有效。应将真实的数据层和订单完成事件作为事实依据。
性能和缓存插件的额外检查
- 它们是否延迟GTM或像素加载?
- 合并脚本是否改变了执行顺序?
- 包含订单数据的订单确认页面是否被缓存?
- 同意更新是否发生在广告标签已运行之后?
- 第三方跟踪请求是否被阻止或错误代理?
- 问题是否只在管理员退出登录后出现?
9. 故障排查矩阵
| 症状 | 优先检查 |
|---|---|
| GTM显示已触发,但GA4中没有事件 | 衡量ID、同意状态、Network请求、广告拦截器 |
| GA4中有Purchase,但Google Ads中没有转化 | Ads转化ID/标签、导入设置、主要状态、归因 |
| One订单产生两个Purchase事件 | 插件重复、自动事件加手动事件、浏览器端/服务器端去重 |
| Purchase价值为0 | 数据层路径、变量读取时机、数值格式 |
| Every订单使用相同价值 | 硬编码的GTM变量或遗留的测试值 |
| 币种始终为USD | 多币种映射或商店默认币种 |
| 产品事件正常,但结账事件不工作 | 跨域流程、Shopify沙盒、结账页面缺少标签 |
| 支付服务商成为GA4来源 | 跨域衡量和非引荐名单 |
| 同意被拒绝后,广告存储或标识符仍继续使用 | 默认同意状态设置过晚、缺少同意检查,或违反访客选择发送广告标识符或用户数据 |
| 同意被接受后,标签没有恢复运行 | CMP未能发送同意更新,或更新发生在重定向后 |
| Meta报告的订单数约为后台订单的两倍 | 像素/CAPI去重,或Shopify应用与手动实施并存 |
| Microsoft标签处于启用状态,但收入缺失 | 目标条件、可变收入、币种参数 |
| TikTok有Page View,但没有Purchase | Purchase触发器、事件名称、必需参数 |
| Shopify Tag Assistant无法检测GTM | GTM位于自定义像素沙盒中;请使用Shopify Pixel Helper |
10. 可靠实施的验收标准
一次成功的测试购买应满足以下所有条件:
- Purchase仅在订单真正成功后触发。
- One测试订单在去重后归并为一次逻辑转化。
- 订单ID与电商后台一致。
- 转化价值符合约定口径,币种正确。
- 产品ID、价格和数量准确。
- GTM Preview显示完整事件和已填充的变量。
- Network中存在对应的请求。
- 目标平台可在其测试工具中识别该事件。
- 浏览器端和服务器端事件已去重。
- 已接受和已拒绝的同意状态均产生预期行为。
- Google Ads Primary、Secondary和计数设置正确。
- 跨域结账保留原始来源。
- 刷新确认页面不会创建另一次独立转化。
最终验收标准 One笔真实业务订单 -> 去重后一次逻辑广告转化 -> 订单ID、价值、币种和产品数据正确 -> 已在平台验证 -> 可与电商后台核对。
11. 广告跟踪诊断报告模板
使用以下结构记录审核结果。保存测试路径、Network载荷、平台Test Events和后台订单的截图,作为证据附件。
1. 网站与环境
2. 跟踪安装清单
3. 测试订单
4. 诊断结果
5. 问题与修复
6. 回归测试
完整证据链
业务操作 -> 客户事件/Data Layer -> GTM触发器 -> 广告标签 -> Network请求 -> 平台测试事件 -> 转化目标 -> 后台核对
只有这条链路的每个层级都正确,转化数据才应当用于广告系列评估、ROAS报告和自动出价。

