独立站周报接入的数据越来越多，收入、广告费和订单却未必能直接比较。这次我把增长周报 Skill 更新到 v1.2.0，补上 Meta 广告数据，改用整站 MER，并把退款、统计周期和出报前的数据核对写进流程。文末附上新项目与旧项目都能使用的任务模板。
之前我分享过一个开源的 Codex Skill，叫 `dtc-growth-data-report。它把 GA4、Google Search Console、Google Ads 和 Shopify 接起来，整理成本周与上周的增长周报，再给出广告、页面和 SEO 的优化建议。
现在，这个 Skill 更新到了 v1.2.0。
新版加入了 Meta 广告数据，也把收入怎样算、数据缺失时怎样处理、报告什么时候可以交付，写得更明确。对独立站运营来说，这些规则会直接影响下一步该查什么，以及哪些数据足以支持调整预算。
广告回报先把分母算全
新版周报连接五个数据源，各自负责不同的问题。
| 数据源 | 在报告里负责什么 |
|---|---|
| Shopify | 订单、记录收入、退款和订单来源 |
| GA4 | 全站会话、落地页行为、加购与开始结账事件 |
| Google Search Console | 自然搜索点击、曝光、CTR，以及搜索词和页面机会 |
| Google Ads | 广告账户与系列花费、点击、转化价值和 ROAS，包含 PMax |
| Meta Ads | 直接从 Meta Marketing API 获取账户与广告系列花费 |
这次需要讲清楚的一个指标是 MER，也就是收入与广告花费的比值。当前这套五源周报按下面的方式计算。
整站 MER = Shopify 收入 ÷（Google Ads 花费 + Meta Ads 花费）
** **
Google 和 Meta 的花费都要算进去。GA4 如果也导入过 Meta 成本，那份数据只用来检查差异，不能再加一遍。
MER 用来观察经营收入相对于广告投入的整体表现。它没有扣除货品、物流、支付手续费和人工等成本，也无法证明每一笔收入都由广告带来。判断利润还需要另一套成本数据，因此新版不再把这个指标叫作利润 ROI。
如果你还投了 TikTok 或其他付费渠道，这个分母就没有覆盖你全部的广告支出，需要先扩展取数与核对规则。当前模板里的“全站广告花费”，覆盖的是 Google 和 Meta 两个平台。
广告平台自己的 ROAS 仍然有用。Google Ads 的转化价值除以 Google 花费，可以帮助复盘该平台认定的投放回报。它与 MER 分开看，才能避免把平台归因收入直接当成全店经营结果。
Meta 也有一个限制。账户花费能够拿到，不代表每个广告系列都能和 GA4 的收入准确对应。系列名称、UTM 对不上时，新版会保留花费，将无法核实的系列 ROAS 显示为不可用。
Shopify 的收入，要把下单和退款分开算
周报以 Shopify 为收入和订单的数据来源，并分别统计销售额、退款和有效订单数。
新版采用的收入口径，是在订单日期记录含税的原销售金额，再按退款实际发生的日期扣除退款。已付款、部分退款和全额退款的非测试销售都需要保留原销售记录，已记录的取消订单销售也不能直接消失。
如果先把退款订单整笔从销售额里删掉，接着再减一次退款，就会重复扣减。
订单数则单独计算。当前有效订单统计的是仍为 PAID、非测试、未取消的订单。这两个口径承担不同用途，因此周报的有效订单数可能与 Shopify Analytics 的订单数不同，用收入除以这个订单数得到的客单价，也不能直接当成 Shopify 后台的 AOV。
核对后台时，要一起看税费、退款日期、订单编辑和时区。只看到两边金额接近，还不足以说明定义完全一致。
Shop、POS 或应用来源的订单也要分清。它们属于生意的一部分，应保留在经营汇总中；检查网页追踪时再单列，避免把站外销售误判成网站漏单。
每个后台都写“最近七天”，还不够
周报要比较同一段日期。
新版要求五个数据源都覆盖本期完整七天，以及此前完整七天。某个来源存在正常延迟时，整个比较窗口一起往前移，不能让 Shopify 用这一周、GSC 用上一周，再放到一张表里计算涨跌。
这里还要分清日期和时区。Shopify 的时间戳会转换到 GA4 Property 的时区后归属日期；Google Ads、Meta 和 GSC 保留各自的原生日统计口径。报告会说明差异，不能把相同的日期标签说成完全相同的一段 UTC 时间。
读取失败与零业务量也要区别处理。Meta 成功返回零花费，可以记录为零；Meta 没有读到数据，就需要停止出报，修复后重新获取。旧文件仍然躺在电脑里，并不意味着这一期抓取成功了。
汇总方法同样会影响结果。GA4 全站 Sessions 使用对应周期、不按渠道拆分的汇总值，不能直接把渠道行或落地页行相加。GSC 的总点击和总曝光使用站点级每日汇总，搜索词、页面明细只承担 SEO 分析。
这样做的意义很实际。以后发现报告与后台不同，可以先定位日期、筛选和汇总层级，再判断到底有没有取数错误。
页面数据不完整，先别据此停广告
把数据整理成周报以后，运营最关心的仍然是下周做什么。
广告系列有哪些值得进一步复盘，哪些页面需要检查加购和结账，哪些搜索词值得调整标题或补充内容，这些分析方向都会保留。但推荐动作必须对应本周的数据，也要有足够的证据。
新版先筛出本周七天的原始记录，再汇总落地页。文件名里带 `90d，只表示文件保存了九十天历史，不能拿整份历史数据来回答本周页面表现。
GA4 与广告平台的页面地址还需要规范化，去掉追踪参数，再按域名和路径匹配。没有匹配到的 GA4 页面事件，会显示为 N/A。仅凭缺失记录，不能写成页面零加购或零购买。
页面花费还有一条检查。若同一广告系列、同一周期的页面明细花费或点击加总，超过了所属广告系列，新版会隔离该系列在这段时间的页面成本贡献。受影响的页面成本显示为 N/A，并退出依赖花费排序的建议。
账户与广告系列层面的权威花费仍然保留，MER 也继续使用那些总额。程序不会为了让表格对齐，把页面花费按比例缩小，更不会凭猜测把 PMax 的系列预算分给各个产品。
此时应回到后台，分别看账户总额、广告系列总额、落地页表底汇总和可见明细。完成异常复核后，才判断报告能否交付。明细不能相加，本身也不能证明 Google 多收了广告费。
GA4 和 Shopify 的订单数接近，不能证明追踪完整
这也是新版明确收紧的地方。
GA4 purchase 数量除以 Shopify 当前已付款的 Online Store 订单数，只能作为总量差异提醒。两边数量相等，仍然可能存在漏记和重复记录互相抵消的情况。
要报告准确的购买捕获率，需要按唯一 `transaction_id 逐单匹配。除了 Shopify 有而 GA4 没有的订单，还要检查 GA4 多出来的记录、重复和空白 ID，以及金额差额。
后来发生部分或全额退款的有效网页订单，仍需要检查原购买有没有被记录，退款事件另算覆盖情况。不能因为订单后来退了款，就把原来的购买追踪问题藏掉。
这部分逐单结果由配套的 `ga4-data-analysis 生成，周报读取它的标准对账文件。报告周期、Shopify 快照、币种和 BigQuery 每日日表覆盖都符合要求，才展示对应的准确覆盖率；证据缺失时显示 N/A。
增长周报 Skill 负责读取和解释，不会通过补发 purchase 事件来让两边的数字看起来一致。
报告生成以后，还要过交付检查
新版增加了带检查的周报入口。每次重新获取五源数据，生成独立的候选报告，再核对金额、账户身份、日期覆盖和异常明细。
结果分为三个状态。
| 状态 | 接下来怎样处理 |
|---|---|
| PASS | 当前检查通过，在交付前执行 release 复核 |
| REVIEW_REQUIRED | 需要完成真实后台复核，再重新检查 |
| BLOCKED | 数据、权限或核对条件不满足，先处理具体阻塞 |
第一次使用、每月至少一次，以及账号、时区、代码变化或重要异常出现时，都需要实际核对后台。已经约定了更严格复核频率的项目，继续保留原要求。
复核要选中本期和上期的准确日期，记录账户、币种、筛选条件及对应数值。程序算术通过，并不能代替这些检查。
GSC 后台自定义日期比较，已裁去账户和站点信息；图中日期仅示范设置
交付前的 `release 会再次确认检查结果与当前文件对应。这个命令只确认允许交付的文件，不会自动发邮件或公开发布。旧报告继续保留，历史数据发生修订时，也要说明变化，不能悄悄改掉已经发出去的版本。
对一个团队而言，可以这样安排第一次试跑。运营负责人先确认账号和比较周期，由 Codex 获取数据并生成候选；投放同事核对两个广告平台的账户花费，店铺负责人检查销售和退款，数据负责人核对 GA4 与 GSC。通过以后，再从报告里选一项证据充分的页面或投放问题，安排负责人和复查日期。
这比一次接受整张行动清单更容易检查。下一次复盘时，也能分清究竟是经营指标变了，还是统计口径变了。
新项目和旧项目，分别这样开始
如果是第一次使用，可以把下面这段任务交给 Codex。
使用 $dtc-growth-data-report，为我的独立站搭建周报项目。先检查本机 Skill 版本和现有项目。核对 Shopify、GA4、GSC、Google Ads、Meta Ads 的账户身份、币种与实际时区，并列出缺少的本地配置，不要让我把密钥粘贴到聊天里。使用五个数据源共同覆盖的最近完整七天，以及此前完整七天。通过带质量检查的入口生成候选报告，按要求核对后台。重点解释 Shopify 收入和退款、Google 与 Meta 花费、整站 MER，并给出有证据支持的广告、页面与 SEO 后续动作。追踪覆盖率缺少逐单证据时显示 N/A。任何来源失败都先停止出报，说明原因。先交付本地结果，邮件和定时任务另行确认。
如果已经用旧版建过周报项目，需要明确要求升级项目。只更新 Skill 文件，不会自动替换项目里的脚本。
```text
将我的 dtc-growth-data-report Skill 和现有周报项目检查并升级到 v1.2.0。先备份并比较差异，保留本机 .env、凭据、业务数据、历史报告和已有定时任务。项目有定制代码时逐项合并，不直接覆盖。补齐新版需要的配置后，重新获取五源数据。运行项目 tests 和 quality/tests，首次升级运行完成真实后台复核，通过检查后再执行 release。保留原报告，说明新旧口径差异。不要创建重复定时任务，也不要自动发邮件。
当前带质量检查的标准周报面向 macOS/Linux 上的美元账户，执行七天对七天的比较。其他币种、Windows 或月报，需要额外适配并验证；旧的看板和探索脚本，也不能直接当成已通过新版检查的五源周报。
项目继续放在 GitHub ：
https://github.com/owensky-dev/dtc-growth-data-report
查看新版时，可以直接打开 v1.2.0 Skill 说明，先确认版本与适用范围。
已经装过旧版的朋友，可以先做上面的升级检查。让第一份新版报告把收入、退款、广告费和比较日期解释清楚，再决定哪些日常复盘工作交给它持续运行。
拓展阅读：
[独立站运营自动化：系统检查，人来决策](https://mp.weixin.qq.com/s?__biz=MzcwNDM3ODE1MQ==&mid=2247483799&idx=1&sn=b9053f8582fbe7c7526fd34ebc61bfcd&scene=21#wechat_redirect)
[原来Shopify内置AI这么强大！最新 Sidekick 实战指南](https://mp.weixin.qq.com/s?__biz=MzcwNDM3ODE1MQ==&mid=2247483829&idx=1&sn=cef794feb38b254fc1dd72b7b003842c&scene=21#wechat_redirect)
