GA4 系列 / 第 2 课
GA4 设置的完成标准，是一份可复制、可复查的安装验收记录
不要把 GA4 设置理解成复制一段代码。对独立站来说，真正要交付的是唯一安装路径、测试订单证据、内部流量边界、隐私状态和可回滚记录。
本课产出
GA4 安装验收记录
核心判断
Realtime 有人不等于安装完成
下一课
事件命名、参数设计与埋点验收
第一屏先看交付物
Account / Property / Data stream
记录主账号、媒体资源名称、主域名、Measurement ID、时区、货币和管理员。
唯一安装路径
写清主路径、备选路径、发布负责人、版本记录和回滚方式。
电商事件链
用 DebugView、测试订单和次日报表证明事件顺序、参数和订单号可信。
隐私、过滤和广告连接
记录 Customer privacy、内部流量规则、Google Ads 关联和转化导入状态；Consent Mode 只作为下一课前置提醒。
从数据分工走到安装验收
上一课用一笔 Google Ads 进入、支付 $48 的 20oz 保温杯订单分清了四层证据：GA4 解释行为和路径，Shopify 核对订单事实，广告后台记录归因信号，利润表判断钱有没有留下来。
那个判断只说明该去哪个系统找证据，还没有证明你现在打开的 Property、Web data stream 和安装路径会完整、唯一地收到这笔订单的事件与参数。即使 Realtime 出现一个用户，也可能是错媒体资源、重复安装或不完整事件。
所以这课先不解释报表。你要确定唯一安装路径，记录 Property、数据流、Measurement ID、时区和负责人，再用同一台测试设备与一笔 Shopify 测试订单验收事件顺序、purchase 参数、同意状态和内部流量边界。验收记录没过，后面的事件、漏斗、受众和广告导入都先暂停。
安装的文字主干
先画清数据从哪里来，再碰任何开关
安装不是“把 Measurement ID 粘贴成功”，而是让一个明确的发送方把一组明确的事件送进一个明确的数据流，并能用订单证据验收。下面先把机制和完整案例讲清楚。
读者、任务和结束能力
这篇课写给已经完成“数据分工”判断、现在需要证明 GA4 能否被信任的人。你可以不知道 Google tag 的实现细节，但要能进入 GA4 Admin、Shopify Settings，并知道谁有权限发布应用、像素或 GTM。新术语包括 Account、Property、Web data stream、Measurement ID、发送路径、测试设备、DebugView 和回滚点。
本篇决策不是选“最先进”的安装方式，而是为当前店铺选出唯一主路径，然后证明商品浏览、加购、结账和购买只发送到目标 Property 一次。结束时，你要交付一份别人可以复查的验收记录：位置、版本、负责人、测试订单、事件与参数、同意状态、过滤器状态、失败动作和回滚方式都能被重新找到。
Account
管理组织和访问权限。它回答谁能管理，不证明店铺事件已经进入正确位置。
Property
承载这家生产店的分析设置、时区和货币。选错 Property，Realtime 仍可能有人，但证据属于另一套数据。
Web data stream
把主域名与 Measurement ID 绑定到一个 Web 输入。它是事件进入 Property 的入口，不是事件质量保证。
发送路径
Shopify 应用、app pixel、custom pixel、GTM 或主题代码中的实际发送方。多条路径同时发送 purchase 会造成重复。
固定案例：把上一课的订单变成安装验收订单
店铺仍然销售美国市场的 20oz 防漏保温杯，GA4 Property 时区为 America/New_York。上一课抽样的交易 ID 是 TMB-1048；在 Shopify 后台，这次教学测试显示为订单 #1008，支付金额 48 美元，币种 USD，商品 ID 为 TMB-20-OZ。这里明确把 transaction_id 与后台订单显示号分开记录，避免团队口头说“订单号”却指向两个字段。
本店选择 Shopify Google & YouTube 应用作为 GA4 主路径。GTM 可以继续承担其他经批准的标签，但不发送本案例的 purchase；旧主题脚本和 custom pixel 对这条购买事件保持停用。这个选择不是普遍答案，只是本店当前所有权、结账边界和维护能力下最容易验收与回滚的路径。
| 位置 | 操作 | 检查证据 | 通过条件 | 失败动作 |
|---|---|---|---|---|
| GA4 Admin | 确认生产 Property、时区、货币和 Web stream | Property 名、主域名、Measurement ID、负责人截图或记录 | 所有人使用同一生产入口 | 停止发布，先纠正 Property / stream |
| Shopify Customer events | 列出 app pixel、custom pixel 与旧脚本 | 每个发送方的状态、版本、所有者和 purchase 责任 | 只有一条路径负责 purchase | 暂停重复路径，不用过滤器掩盖双发 |
| Tag Assistant / DebugView | 用同一测试设备走完整购买路径 | view_item → add_to_cart → begin_checkout → purchase 的时间顺序 | 事件顺序合理，purchase 只出现一次 | 回到缺失或重复的发送入口修复 |
| Shopify Orders | 核对 #1008 与 TMB-1048 | 支付状态、$48、USD、TMB-20-OZ 与 GA4 参数 | ID、金额、币种和 items 可解释地一致 | 不导入 Ads，不读取收入趋势 |
| 次日标准报表 | 用相同日期与时区复查 purchase | 处理完成后的 purchase 与交易 ID 证据 | 测试记录进入可复查报表 | 先查处理延迟、过滤器和日期，再判断漏发 |
一笔订单为什么还不够
测试订单能证明某个设备、某种同意状态和某次发布版本下的链路工作，却不能证明所有浏览器、市场、支付方式和真实顾客都不会失败。它也不能证明标准报表已经完成处理，更不能授权广告系统立即用 purchase 出价。因此，DebugView 通过后还要做次日报表复核，并在七天稳定期里观察重复率、缺失率和订单对账差异。
Consent 在本篇只是安装输入：分别记录拒绝与同意测试的状态和可见事件，不在这里解释法律义务，也不把数据更少写成故障。内部流量过滤器先保持 testing；如果直接 active，误排的数据无法在处理后补回。任何证据缺失时，停止漏斗、受众和 Ads 导入；证据齐全后，下一课再判断事件名称和参数语义是否适合分析。
后台目的表
先说清楚：每个后台点进去，是为了确认什么
不要把 GA4 设置理解成“找到一个 ID，然后到处粘贴”。每个后台位置都只确认一件事：数据进哪一个入口、事件有没有发、订单能不能对上、同意状态和广告导入是否安全。下面这块可以点，先选你现在卡住的后台位置。
后台不是按顺序全部打开，而是根据尚未取得的证据选择。若 Property、域名与 Measurement ID 还没对齐，就先停在 GA4 Admin；若 purchase 双发，就直接去 Shopify Customer events 和 GTM 查发送方。打开更多页面不能弥补问题定义不清。
默认选择 Shopify Customer events / pixels，因为本案例已经选定 Shopify 应用为主路径。点击其他位置前，先写下“为什么打开、期望证据、不能证明、失败后去哪里”四句，右侧卡片只用来校准。
默认状态的静态结论是：在 Shopify Settings → Customer events 记录 app pixel、custom pixel、旧主题代码和 GTM 的状态与负责人；通过条件是只有一条路径负责 purchase，并且其他入口明确不再发送。这里只能证明发送责任清楚，不能证明事件参数已经正确。
如果没人能说清主路径，先暂停新发布并建立发送方清单；如果责任已经唯一，再进入 DebugView 和订单对账。不要用删除历史代码作为第一动作，先保留版本和回滚点。
纠正误判
Realtime 有人，只说明 GA4 收到了一些数据
安装完成的标准不是看到一个在线用户，而是能用测试订单和 DebugView 证明事件顺序、参数、订单号和金额可信。
Account / Property / Data stream
Account 是公司或品牌的容器，Property 是一个主要报表空间，Data stream 是网站或 App 把数据送进 GA4 的入口。
出错时会怎样
多个团队各建一个 Property，会让用户路径、受众和广告导入被拆碎。
唯一安装路径
安装路径是 GA4 标签从哪里进入网站：Google tag、GTM、Shopify Google & YouTube 应用，或 Customer events。
出错时会怎样
同一个 GA4 同时出现在主题、GTM、应用和自定义像素里，purchase 很容易重复。
电商事件链
事件链是买家从看商品到下单的动作顺序：view_item、add_to_cart、begin_checkout、purchase。
出错时会怎样
Realtime 有用户不等于 purchase、transaction_id、value、currency 和 items 都正确。
隐私、过滤和广告连接
这层决定哪些数据能被采集、哪些内部流量要标记，以及 GA4 是否能把可信关键事件交给 Google Ads。
出错时会怎样
隐私状态、内部测试和广告导入混在一起，后面所有报表差异都难解释。
安装证据线
GA4 装好之前，先对齐四条证据线
这四条证据线把安装从技术动作变成经营证据。证据没对齐时，后续广告、漏斗、受众和利润分析都会被错误数据带偏。
唯一主路径证据线
同一套 GA4 事件只能有一条主发送路径，否则 Realtime 看起来热闹，purchase 可能已经双发。
通过标准
能说清 Google tag、GTM、Shopify 应用、Customer events 和旧主题代码中哪一个负责主事件链。
暂停条件
如果没人能解释 page_view 或 purchase 从哪里发出，先停在重复安装排查。
测试订单证据线
电商设置的核心不是访问量，而是一个真实结账路径能否只生成一次可信 purchase。
通过标准
20oz 保温杯测试订单能在 Shopify、DebugView 和次日报表里对上 transaction_id、value、currency 和 items。
暂停条件
purchase 没有订单号、金额或商品数组时，先不要导入 Google Ads，也不要做漏斗判断。
内部流量证据线
上线前测试、代理商访问和开发环境会污染小样本，尤其会误导新站第一周判断。
通过标准
内部流量已识别，过滤器先保持测试状态，确认没有误伤真实买家后再启用。
暂停条件
如果测试订单、员工访问和真实买家混在一起，先不要用当天数据做转化率判断。
隐私与广告证据线
Shopify Customer privacy、同意状态和 Google Ads 导入决定哪些信号能被采集、建模或用于出价。
通过标准
已记录同意前/同意后事件行为、Google Ads 关联状态、key event 导入状态和不能用于出价的数据边界。
暂停条件
如果 consent 状态和广告导入没验清，不要把 Ads / GA4 差异归因到广告质量。
安装验收分流
先选当前卡住的验收点，再决定回到哪一步修
这一步请主动点选一个最像你当前状态的卡点。右侧会告诉你先打开哪个后台、必须拿到什么证据、失败时回到哪一课，以及现在绝对不要做什么。
分流的输入应是一条可观察失败，而不是“GA4 感觉不对”。例如：测试设备不进 DebugView、purchase 缺参数、Shopify 订单找不到对应 transaction_id，或 Ads link 在事件验收前已经导入。把症状写具体，才能把修复限制在一个表面。
默认卡点从数据流和标签入口开始，因为入口错误会让后面所有证据失效。选择前先预测失败路线和被禁止动作，再用右侧结果检查是否越权扩大修复范围。
默认静态路线是：先在 GA4 Admin 确认 Property、Web stream、Measurement ID 和域名，再在实际发送方确认同一个 ID。若不一致，修入口并重新跑测试设备；在通过前禁止解释漏斗、建立受众或导入 Ads purchase。
切换到参数、订单对账或 Ads/consent 卡点时，只改变当前必需证据和失败路线。分流结果不能证明整个安装完成；它只决定下一处最小修复。
Consent Mode 边界
这里先只提醒 Consent Mode：同意状态会改变数据能见度
这篇课不展开 CMP、地区法规或高级模式，只保留一个安装验收提醒：用户同意或拒绝后，GA4 和 Ads 能看到的数据会变。具体隐私测量放到第 4 课继续讲。
同意横幅或 CMP
记录用的是 Shopify Customer privacy、第三方 CMP，还是自定义横幅。
没说清会怎样：没人知道同意状态从哪里来，后续 Ads / GA4 差异会变成猜测。
同意前事件
拒绝 cookies 后走一次商品页、加购、结账入口，观察 GA4 是否仍有必要的匿名或受限信号。
没说清会怎样：团队以为数据丢了，其实是 consent 边界不同。
同意后事件
同意 cookies 后再走同一条路径，比较 DebugView、purchase 参数和 Google Ads 导入状态。
没说清会怎样：广告系统可能学习到不完整或不一致的转化。
出价边界
写清哪些 key event 可以导入 Google Ads，哪些还只能用于追踪验收。
没说清会怎样：purchase 未验清就进入出价，会把错误事件喂给系统。
路径选择器
先选唯一主路径，再谈代码怎么贴
Google 官方设置文档会告诉你怎么创建属性和数据流；电商团队还要补上「这条路径为什么适合我们、如何验收、哪里可能重复」。
路径选择受店铺所有权和结账边界约束。应用路径通常更容易维护标准电商集成；GTM 适合已有容器治理、事件规范和发布审查的团队；custom pixel 只在明确缺口与负责人存在时使用。没有治理能力时，“更灵活”往往意味着更难验收。
默认选中 Shopify 应用路径。判断它是否适合本店，要看 purchase 能否覆盖结账边界、团队是否能取得必要参数、旧脚本能否停用，以及失败时能否恢复上一版本，而不是只看安装速度。
先看店铺状态
刚开始做 Shopify GA4，团队没有专门维护 GTM
更适合：优先 Shopify Google & YouTube 应用或官方 app pixel
对新手最少改代码，也最容易把结账和订单状态页放进 Shopify 当前像素模型里验收。
不要同时在主题代码、GTM 和 Customer events 里再发同一套 purchase。
先看店铺状态
团队已经有 GTM 版本管理，而且多个渠道标签都从 GTM 发布
更适合：可以用 GTM 做主路径，但要先确认变量、触发器和发布负责人
GTM 适合统一管理，但它不是默认更简单，配置能力越强，重复触发和口径错误也越容易发生。
不要因为看见 GTM 容器就绕过 Shopify Customer events 和测试订单对账。
先看店铺状态
需要自定义 checkout、Customer events 或 custom pixel
更适合：把 Customer events 当成验收重点，先证明 sandbox、同意状态和 purchase 去重
Shopify 的 checkout 边界不能只靠主题代码想象，必须用当前像素模型和订单号验收。
不要让旧 Additional scripts、旧 theme 像素和新 custom pixel 一起保留。
先看店铺状态
历史网站已经粘过 Google tag 或旧 UA 代码
更适合：先做重复安装排查，再决定保留哪一条主路径
旧代码最容易让 Realtime 看起来正常，但 purchase、value 或 items 实际双发。
不要在没查旧入口前继续新增标签。
当前选择
Shopify Customer events / pixels
验收证据
Customer events 里能看到 app pixel 或 custom pixel，pixel sandbox 和 Customer privacy 边界清楚，purchase 能和 Shopify 测试订单对上。
主要风险
Sandbox、Customer privacy 和旧 theme 代码迁移没有验清，会导致漏采、重复或同意状态错位。
默认静态选择是 Shopify Google & YouTube 应用负责 GA4，GTM 不发送 purchase，旧主题代码和 custom pixel 对 purchase 停用。验收证据必须是 DebugView 中一次 purchase 与 Shopify #1008 / TMB-1048 对账，而不是“应用显示已连接”。
改选 GTM 或 custom pixel 时，必须同时改写负责人、发布版本、重复入口清单、验收证据和回滚动作。仅切换按钮不会让新路径成为有效设计。
安装矩阵与迁移记录
先把迁移记录留全，再让有权限的人一次只改一条路径
Shopify Google & YouTube、GTM、第三方应用和自定义像素不是四个可以并行粘贴 Measurement ID 的入口。它们是四类可能发送方。先把现有入口、同意条件、测试订单和回滚边界写清，才能安全地判断下一次实际读回。
本地迁移准备
选择、勾选和填写只形成当前浏览器记录
它不会安装应用、发布 GTM、改主题、停用像素、改变同意、导入广告转化或创建测试订单。需要实际账户改动时，带着这份记录由有权限的人做同一目标读回。
当前安装路径假设
Shopify Google & YouTube 应用
适合希望在 Shopify 当前像素模型中维护标准 Google 集成的店铺。先在 Customer events 中读回实际显示的应用或 app pixel，而不是假设应用连接就覆盖了所有事件。
迁移顺序
先列出主题、GTM、Additional scripts、Customer events 和第三方应用中的现有发送方。保存基线后，再由获授权发布者逐一隔离旧路径。
重复追踪风险
最大风险是应用已经发送 purchase，而旧主题、GTM 或 custom pixel 仍在发送同一订单。绿色连接状态不能排除双发。
Consent 分支
把 Customer privacy、同意横幅状态和测试设备的同意条件单独记下。它们说明可见性边界，不替代地区合规判断。
先看什么证据
用同一测试订单核对 Customer events、DebugView、transaction_id、value、currency、items 和一次 purchase，再在次日报表复查。
重复追踪找错练习
把看见的症状先变成读回顺序。这里不会停用像素、修改同意或导入转换，只帮助你避免用多个同时改动掩盖原因。
先读回
先对照每条事件的来源、时间、transaction_id、容器或像素线索，再回到主题、GTM、Customer events、应用和 Additional scripts 清单。
先保留什么
保留基线和重复证据，暂停把 purchase 导入广告或解释收入。不要为了“试试”同时停用多条路径。
怎样隔离复测
由获授权发布者隔离一条发送方后，换一个新的测试引用，重新读回一次 purchase 和对应 Shopify 订单。
迁移复查关卡
勾选表示这项已经写进本地记录，不代表实际标签、像素、同意、广告或应用已经得到修改许可。
安装路径找错题
同一笔测试订单有两次 purchase，且旧主题代码、GTM 和 Customer events 都还在清单里。哪一种处理既保留证据，也不制造新的生产改动？
可填写迁移记录
只写课堂别名或已获授权的测试引用。真实买家、支付、地址、后台截图和访问凭证只应保留在获授权的工作环境中。
迁移参考边界
官方页面检查日期：2026-07-26。它们用于核对当前产品边界和验证顺序，不替代本店账户、像素、同意、订单或广告读回。
后台证据记录
不要只说装好了，留下 5 类可复查后台记录
真正能保护后续分析的不是一句“GA4 已安装”，而是一组下周还能复查的后台路径、字段和记录 ID。点击已经整理好的记录，右侧会告诉你它能证明什么、什么情况不能放行。
勾选代表证据已经被保存并能重新打开，不代表你“看过”那个页面。每条记录至少要有后台路径、对象或 ID、测试时间、发布版本、负责人和结论。没有这些字段，下周无法判断页面变化来自新版本还是旧配置。
初始状态是 0/5，这是一种诚实状态。先完成 data stream 与发送方记录，再做测试订单与过滤器/Ads 边界；不要为了让进度变绿而勾选尚未取得的证据。
静态完成标准是 5/5：Property/stream、Tag Assistant/DebugView、Shopify Customer events、测试订单参数、内部流量与 Ads link 都有记录。任一缺失时，记录应显示未完成，并明确哪项下游动作被暂停。
5/5 只说明安装证据包齐全。它仍不证明事件命名合理、报表不存在阈值，或 Ads 转化具有增量价值；这些问题分别交给后续课程。
30 分钟设置验收脚本
按五段脚本完成 GA4 设置验收
这五段把账户、主路径、测试订单、隐私边界和 release/stop 结论串起来；下面的四步 testOrderSteps 仍是保留的测试订单执行路径，二者互补。
0-6 分钟
验收焦点先确认账户结构：Account、Property、Web data stream、Measurement ID、主域名、时区、货币和管理员权限是否属于同一条主路径。
证据直接读回 GA4 Admin 的账户/Property/数据流页面和权限记录，不用一串 Measurement ID 代替结构证据。
动作 / 输出把账户结构、负责人和最后核验日期写入 setup evidence record；缺任一锚点就暂停后续验收。
6-12 分钟
验收焦点确认唯一主发送路径：对照旧 theme、GTM、Shopify Google & YouTube 应用、Customer events / custom pixel 和第三方脚本，命名谁发送 GA4。
证据记录每个入口的启用状态、版本、负责事件和停用权限；用 Tag Assistant / DebugView 证明不是“应该没发”。
动作 / 输出输出唯一主路径、重复路径和隔离动作；路径未定前不进入事件、广告或漏斗判断。
12-22 分钟
验收焦点用一笔 20oz 保温杯测试订单跑完整路径，确认 DebugView 的事件顺序、purchase 参数和 Shopify order ID 可以对账。
证据保存测试设备、view_item / add_to_cart / begin_checkout / purchase、transaction_id、value、currency、items、订单号和支付状态。
动作 / 输出输出“一次 purchase 且字段完整 / 先修事件或参数 / 订单与 GA4 不可对账”的结论；没有订单证据就不放行。
22-27 分钟
验收焦点验隐私和内部流量边界：Customer privacy、Consent reminder、internal traffic filter 和开发/测试环境不能混成真实买家读数。
证据读回同意前/后事件差异、Customer privacy / CMP 路径、filter testing / active 状态、测试订单和发布环境。
动作 / 输出输出哪些信号可观测、哪些只能建模或不可见，并保持过滤器在确认无误前的安全状态；未验清时暂停报表解释。
27-30 分钟
验收焦点给设置一个明确的 release / stop 结论：可以放行、只进入事件修复、只做方向判断，还是暂停 Google Ads import。
证据复核账户结构、唯一主路径、测试订单、隐私/内部流量边界、负责人、回滚方式和次日/7 天复盘日期。
动作 / 输出把 status、暂停动作和下一次读回写入 setup evidence record；这五段验收脚本补充下面保留的四步 testOrderSteps，不改名也不替代它。
20oz 保温杯测试订单
用一笔测试订单验 GA4，而不是用感觉验
测试订单不是形式。它要证明 Shopify 订单、GA4 DebugView、次日报表和未来 Google Ads 导入看到的是同一条购买证据。
步骤 1
准备测试环境
打开 DebugView，确认测试设备进入调试流，并记录浏览器、市场、币种和是否同意 cookies。
测试设备没有进入 DebugView，团队却用 Realtime 在线人数当验收证据。
先修 debug 参数、Tag Assistant、GTM preview 或 Shopify pixel 状态。
步骤 2
走完整购物路径
用 20oz 保温杯从商品页到加购、结账、支付成功走一遍，并录下每一步对应事件。
view_item 和 add_to_cart 正常，但 begin_checkout 或 purchase 在 Shopify 结账边界丢失。
先检查 Customer events / pixels、Google & YouTube 应用、checkout extensibility 和旧脚本迁移。
步骤 3
对齐订单号和金额
purchase 只出现一次，transaction_id 对上 Shopify 订单号，value、currency、items 与订单明细合理一致。
purchase 双发，或者 GA4 value 把税费、运费、折扣口径混在一起没人解释。
先暂停重复路径，写清 revenue 口径，再决定是否修参数或只在财务课处理利润。
步骤 4
次日复核标准报表
第二天在 GA4 标准报表或探索里能找到同一笔测试订单的 purchase 证据。
DebugView 有事件，但标准报表没有；团队马上判断数据丢了。
先确认处理延迟、过滤器、日期窗口、身份阈值和报表维度，再判断是否漏发。
重复安装守门
上线前先查 4 个入口，全部通过才继续
这一步是主动操作。每勾一个入口，都代表你已经知道 GA4 数据从哪里来、哪里不会再发一遍。
重复安装最容易被误判成“数据很好，因为 purchase 变多了”。真正的守门方法是把每个可能发送入口逐一列出，并给出正面证据：它负责什么事件、当前是否启用、版本是什么、谁能停用。没有证据的“应该没发”不能勾选。
初始 0/4 会保持停止状态。按 Shopify 应用、Customer events/custom pixel、GTM 和旧主题/结账脚本逐项检查；勾满以后仍要用测试订单证明 purchase 只出现一次。
静态规则很简单：0–3/4 时不导入 Ads，也不使用数据优化投放；4/4 时只获得进入 DebugView 与测试订单的资格。若测试 purchase 出现两次，立即回到入口清单，暂停重复发送方，并用同一订单重跑。
守门结果必须写入验收记录，不能只停留在当前浏览器状态。刷新页面会清空勾选，但版本、负责人和停用证据应该仍能被团队找到。
验收证据链
DebugView 不是看热闹，是看事件顺序和参数
测试顺序要像真实买家一样走：访问页面、看商品、加购、开始结账、完成测试订单，然后次日核对标准报表。
采集范围与电商事件边界
先判断你看到的信号属于哪一层
Enhanced Measurement 可以补充页面和内容行为，但它不是电商订单实现。点选一层，分别看它收集什么、能用来做什么、不能代替什么，以及应怎样验收。
增强型衡量（Enhanced Measurement）：页面与内容行为
它收集什么
在 Web data stream 中开启的相应功能可以自动收集 page_view、scroll、outbound click、site search、video engagement、file download 和 form interaction 等页面与内容行为。
不能替代什么
它不替代 view_item、add_to_cart、begin_checkout、purchase、refund 或 items 商品数组。page_view 或 scroll 不能证明商品被看过、订单完成或收入已经对账。
用来做什么
用它观察页面和内容如何被使用，例如滚动、外链点击或站内搜索；先确认数据流里的开关范围和实际事件。
怎样验收
在数据流里读回 Enhanced Measurement 的开关和范围，再用 DebugView 看行为事件；这一步补充页面/内容证据，不能代替测试订单验收。
内部流量过滤要谨慎。GA4 的排除过滤一旦启用，会永久影响处理后的数据；更稳的做法是先识别内部流量，让过滤器保持测试状态，确认没有误伤后再启用。
复制笔记总结
最后交付的不是 Measurement ID，而是 GA4 安装验收记录
GA4 设置一定会被后续广告、漏斗和利润分析反复引用。笔记越清楚，之后越少把追踪问题误判成业务问题。
复制按钮汇总当前选择，但动态文本不是唯一交付物。即使不点击，也应先写出固定事实：生产 Property 与 stream、主发送路径、测试订单 #1008 / TMB-1048、$48 USD、purchase 一次、同意与过滤器状态、负责人和回滚动作。
“已复制”只证明浏览器完成了一次反馈，不证明记录已经进入任务系统，也不证明证据齐全。复制后仍要由负责人复核空字段、保存链接或截图，并写下次日与七天复查日期。
当前可复制版本
先选主路径，再勾选入口检查；下面这份笔记会把你的选择写进去。复制后可以放进任务、复盘或下一课事件 QA。
尚未复制：复制反馈不等于 GA4 设置验收。
当前压力：入口检查未完成，先不要导入 Google Ads 转化或用这套数据优化投放。
当前卡点：Data stream / Measurement ID 卡住。当前卡点：Data stream / Measurement ID。先补主 Property、主数据流、Measurement ID、负责人和最后核验日期，再继续事件验收。
测试订单四步：同一测试设备进入 DebugView，依次完成商品页、加购、结账和 purchase，再用 Shopify 订单号核对 transaction_id、value、currency 和 items。
主路径：Shopify Customer events / pixels。验收证据：Customer events 里能看到 app pixel 或 custom pixel，pixel sandbox 和 Customer privacy 边界清楚，purchase 能和 Shopify 测试订单对上。
迁移候选：Shopify Google & YouTube 应用。先保留所有发送方清单和基线，再由获授权发布者一次隔离一条路径。
证据记录：0/5。尚未勾选后台证据记录。
迁移复查：0/7。先完成迁移关卡和找错题，不把选择器当成配置已生效。
Consent Mode：本课只记录同意状态会影响 GA4 和 Ads 能看到的数据，CMP、地区边界和高级模式放到第 4 课深讲。
最小放行线：唯一主路径、DebugView 事件顺序、一笔 purchase、transaction_id/value/currency/items 完整、Shopify 订单对上、内部流量过滤器状态、Consent/Ads 导入边界、负责人、回滚方式和复盘日期都清楚。
已检查入口：0/4。尚未勾选入口。
本周动作：完成测试订单、次日标准报表复核、内部流量测试过滤器和 Google Ads 关联状态记录。
暂停动作：purchase、items、transaction_id 或 consent 状态未验清前，暂停广告导入和漏斗判断。
负责人：GA4 设置负责人 + Shopify / GTM 发布负责人。复盘窗口：次日报表、7 天稳定期、下一课事件 QA。
主路径
Shopify Google & YouTube 应用负责 GA4；GTM 不发送 purchase。
后续排查重复或漏发时，先知道唯一主路径。
测试订单证据
订单 #1008，2026-06-05 10:42，purchase 在 DebugView 出现一次。
没有订单证据，收入和广告导入都只能算试运行。
内部流量规则
办公室 IP 标记为 internal，过滤器先保持测试状态。
GA4 排除过滤一旦生效会永久影响处理后的数据，先测试再启用。
回滚方式
如果 purchase 双发，先停用 Customer events 自定义像素，保留应用路径。
安装不是一次性动作，出错时要能暂停和恢复上一版。
把下面内容写进 GA4 安装验收记录：“Shopify Google & YouTube 应用为 GA4 主路径；GTM、旧主题脚本和 custom pixel 不发送 purchase。订单 #1008 / transaction_id TMB-1048 支付 $48 USD，DebugView 中 purchase 只出现一次，value、currency、items 已与 Shopify 核对。内部流量过滤器保持 testing；事件 QA 完成前，不导入 Ads。”
如果其中任一事实没有证据，就标为“未验收”，并保持对应的广告导入或报表解释暂停。字段齐全后，把“链路已唯一且可对账”的结论交给下一课，再继续判断事件语义与参数质量。
先回到 GA4 Hub，再把安装验收交给正确的下一课
本篇负责确认唯一主路径、测试订单和事件进入 GA4；数据分工不清时回到入门，事件字段不清时进入事件 QA。
本课最小放行线与暂停 / 继续规则
最小放行线是：唯一主路径、DebugView 事件顺序、一笔 purchase、transaction_id/value/currency/items 完整、Shopify 订单对上、内部流量过滤器 testing 或 active 状态清楚、Consent/Ads 导入边界清楚，并写下负责人、回滚方式和复盘日期。如果缺任何一项，就先暂停解释 GA4 报表；如果这些证据齐了，再进入事件命名、漏斗和广告导入。这里的 Consent 只作为安装验收提醒，完整的 CMP、地区和高级模式放到第 4 课。
下一步：进入事件命名和参数设计
如果 purchase、items 或 transaction_id 还没有验清，先别看漏斗。下一课把事件 QA 做扎实。