Meta Ads 和 GA4 转化对不上，怎么让 Muse 帮你查清口径

01｜先把“数字对不上”拆成一张表

广告后台显示的购买量，GA4 的 purchase，以及店铺实际订单，常常回答着不同的问题。先别让 Muse 判哪一边错了。第一轮要的结果是一张差异表，能看到每个数字从哪份报表来、怎么算、还有哪些资料没拿到。

9月21日，@korzhov_dm 分享过让 Muse 检查广告花费的画面。我对照了 Google Analytics 的归因、数据处理和交易编号说明，下面按这些材料整理核对流程。原图明确写着“via Ryze”，属于作者接入的第三方路线；帖文里声称的省钱和修复结果，没有作为本文的效果承诺。

图里连 placement breakdown 都遇到了返回限制。遇到某一层明细读不到，就在表里保留这个缺口。只收到一份总额，不能当作已经查完所有广告。

02｜只接需要的账户，没接入就交报表

Meta 9月29日公告写了 Muse 可以连接 Meta 广告账户。先在你自己的连接器页面检查入口与权限，确认广告账户 ID、店铺和 GA4 property 没选串。原生广告入口、第三方 Ryze 和 GA4 数据来源要分别核对，不能从一张作者截图推断你的账户全都能读。

这轮只查数据，暂不要求改预算、暂停广告、修网站或补历史事件。读取不到 GA4 时，可以自己导出有权使用的报表，把列名和导出条件一起交给 Muse。保留活动或广告 ID，删掉用不上的客户姓名、邮箱等信息。

让它先列一份资料清单，写清已取得哪些表、各自覆盖的日期和更新时间，缺哪一列。空白、权限不足和报表里的真实零值分别标记。拿不到的数字不用猜。

03｜对齐日期和金额，先查完整的一周

选一个已经结束的日期段，把起止日和时区明确写下来。两份报表都叫“上周”，仍可能切出不同边界。尤其跨午夜的订单，先看各自采用的时区，再做逐日比较。

Google 说明 GA4 数据处理可能需要24到48小时，期间报表会变化；关键事件的归因分配还可能在记录后继续调整。刚过午夜就拿昨天的数做最终对账，很容易追着暂时差异跑。给每份导出表记录提取时间，稍后复查时仍用同一日期范围。

金额也单独列口径。广告花费使用什么货币，purchase value 是否含运费与税，店铺表是否扣了退款，都要写在表头。总销售额除以广告费得到的数，不自动等于某条广告的 ROAS，更不能代表利润。

04｜先问比较的是哪一种“转化”

在 Ads Manager 查看当前报表列与采用的归因设置，把实际点击或观看窗口原样记下来。如果通过 API 或第三方工具取数，要求同时提供请求条件。Meta 官方 SDK 把 action_attribution_windows 和 action_report_time 分成不同参数，日期范围本身不能交代全部统计条件。

GA4 这边记下具体事件，比如 purchase，以及用的是事件次数、交易数还是被分配给某个来源的关键事件。再查看当前 reporting attribution model 和 lookback window。只抄“转化”这一个中文列名，后面很难判断你到底在比什么。

可以让 Muse 把两边条件并排写，再指出哪些能对齐、哪些仍然不同。不要为了让数字看起来接近，顺手改正式账户的归因设置。这次先保存当前状态和差异解释。

05｜GA4 的来源列也要看前缀

First user source、Session source 和不带前缀的事件范围 Source，分别涉及首次获客、这次访问和事件归因。Google 明确说明，修改 reporting attribution model 会影响使用事件范围来源维度的报表；用户与会话范围维度不随这个设置变化。

所以别拿一张 Session source 的表去证明某条广告最后获得了多少购买归因。让 Muse 在每行写出维度的完整名字、范围和事件，再核对当前报表。使用数据驱动归因时，部分关键事件会呈现小数份额；这类份额也不能当作实际订单编号的数量。

06｜怀疑追踪坏了，再拿证据查事件

把异常定位到具体日期或活动之后，再看落地页最后收到的 UTM。Google 的手动标记说明列出了 utm_source、utm_medium、utm_campaign 等字段。让有权限的人沿实际广告链接检查跳转，记录参数有没有保留；只在聊天里看到一个带 UTM 的链接，不能证明最终网页收到的是同一个链接。

怀疑 purchase 重复时，给 Muse 一小份脱敏记录，保留交易编号、事件名、时间、数据流和金额，圈出疑似重复的行。Google 说明交易编号去重用于网页数据流，编号要对应独立订单，不能为空，也不应含个人识别信息。相同编号不要跨不同客户重复使用。

这些检查只是排查线索。不要让它把 GA4 的 transaction_id 和其他平台的事件去重字段混为一谈，也不要直接删报表里的重复行再宣称追踪修好了。源代码或采集配置要改时，另开一项有负责人、有验证方法的任务。

07｜把结果分成已解释、待排查和缺资料

可以这样给 Muse 任务。只使用我提供的报表，对齐账户、已结束的日期段、时区和货币。逐项列出指标原名、来源表与筛选条件。把差异分成口径已解释、采集异常候选和缺资料，附对应行或报表链接；不要修改账户、预算、追踪代码，也不要补传历史事件。

拿到结果后，先抽几行回原表核对。它说“某活动没有购买”，就打开那条活动的同口径报表；它说“重复订单”，就核对是不是同一订单重发事件，还是本来就不同的交易。结论旁边应当能找到支持它的记录。

差值超过某个百分比，不自动说明埋点坏了。未对齐的窗口、资料缺失和真实采集故障需要不同处理；这一页不设一个万能的10%红线。

08｜复查时沿用原条件，再考虑广告动作

把本次日期范围、导出时间、字段和归因设置保存成核对单。需要等数据处理的，就在约定时间用原条件重新拉同一段数据，记录哪些差异缩小、哪些还在。若确认采集异常，交给网站或分析负责人处理，并在受控验证后检查新事件。

停广告、改预算、上线代码和补传数据分别是新的动作，必须看清对象和具体变更。原帖的一次分析，不能替你批准这些操作。先完成这一轮对账，手里应该留下原报表、差异表和待办负责人。

想把结果接进每周经营复盘，可以继续看 <a href="/guides/muse-small-business-weekly-brief/">商家周报教程</a>。长期观察某个异常时，按 <a href="/guides/muse-ongoing-task-progress/">持续任务进度教程</a> 设定复查时间与停止条件。