先说我踩过的坑：312 单 vs 487 单 vs 269 单
去年 11 月，我接了个宠物智能用品独立站，Shopify + Meta + Google Ads，月预算 1.2 万美元，Meta 8000，Google 4000。老板甩给我三张截图：Shopify 后台 312 单，Meta Ads 显示 487 单，GA4 显示 269 单。他问我，到底谁在撒谎？我第一反应是归因窗口，Meta 默认 7 天点击 + 1 天浏览，GA4 默认 30 天？不对，GA4 广告归因路径更绕。后来我们花了 90 天，把 GTM 服务器端容器、Meta CAPI、GA4 Measurement Protocol、BigQuery 导出全接上，差异从 38% 压到 6%-9%。不是 0，永远不是 0。跨设备、浏览器限制、广告拦截、iOS ATT 同意率只有 20%-30%，这些都会吃掉数据。
第一步不是上工具，是先对账
我一开始也犯傻，直接去改 GA4 归因模型，结果越改越乱。正确顺序是：导出 Shopify 订单 CSV，拿 order_id、created_at、total_price、currency、financial_status；再导 GA4 的 transaction_id、purchase_revenue、currency；再导 Meta 的 purchase event，看 event_id、value、currency。用 order_id 左连接，先查时区。Shopify 店铺时区是 UTC，GA4 媒体资源是 America/Los_Angeles，Meta 广告账户是 Asia/Shanghai，Google Ads 是 America/New_York。光时区错位，就影响了 11% 的周末订单。还有退款，退款率 8.3%，Meta 和 GA4 默认不一定扣掉。测试订单、员工订单、重复 purchase，先删掉。对账表里必须有一列：差异原因。时区、币种、退款、重复、未同意、跨设备、广告拦截。
UTM 别乱写，ad_id 比 utm_content 重要
很多教程让你把 {{ad.name}} 塞进 utm_content，我建议别这么干。UTM 参数值在 GA4 里超过 100 字符会被截断，动态名称又长又容易变。我的做法是：utm_source=facebook，utm_medium=paid_social，utm_campaign={{campaign.name}}，utm_content={{ad.name}}，然后单独加 ad_id={{ad.id}}、adset_id={{adset.id}}、campaign_id={{campaign.id}}。在 GA4 里注册自定义维度 ad_id、campaign_id。这样你在 Looker Studio 里能把广告花费表和 GA4 事件表按 ad_id 连接，而不是靠广告名称猜。注意：UTM 会覆盖 session 来源，别在站内链接乱加 UTM。还有，Meta 的 fbc、fbp、GA4 的 client_id、session_id 都要在服务器端事件里带上，否则匹配率会掉。我们实测，带上 fbc/fbp 后，Meta CAPI 的事件匹配率从 42% 提到 68% 左右。
服务器端追踪不是银弹，先做 4 个事件
我们只上了 4 个服务器端事件：purchase、lead、add_to_cart、initiate_checkout。别一上来全量，维护不过来。GTM 服务器端容器跑在 Google Cloud Run，低流量每月 5-15 美元，Stape 每月 20 美元起。Meta CAPI 参数：event_name、event_time、event_id、action_source=website、user_data（em、ph、fbc、fbp）、custom_data（value、currency、content_ids、num_items）。GA4 Measurement Protocol 用 api_secret + measurement_id + client_id。去重是关键：event_id 用 order_id + event_name，Meta 像素端和 CAPI 端必须一致；GA4 的 transaction_id 用 order_id。第一周我们忘了去重，Meta 收到双倍 purchase，ROAS 看起来从 2.3 涨到 4.1，老板差点加预算。后来加了 event_id，数据才正常。Cloud Run 冷启动 1-3 秒，设最小实例 1，不然事件会延迟。
我的独立观点：小团队别做全漏斗归因，做可对账的中间层
市面上都在吹 CDP、全漏斗归因、数据驱动模型。但 Google Ads 的数据驱动归因要求过去 30 天至少 3000 次点击和 300 次转化，小账户根本不够，最后给你的是噪声。我的观点是：归因不是算法问题，是数据工程和财务对账问题。先搭一个可对账的中间层：订单号、event_id、UTC 时间戳、原始 UTM、ad_id、成本表。用 BigQuery 导出 GA4 每天 100 万事件免费额度，建一张订单对账表，每天跑一次。差异超过 15% 就报警，别等月底。平台数据用来优化素材和受众，GA4 用来看站内行为，财务数据用来算真实 iROAS：收入 - 退款 - 运费 - 税费 - COGS，再除以广告花费。最后一句，别追求 100% 准确，追求可重复的决策规则。能让你少亏钱的数据，就是好数据。