系统集成不是多装几个 App，而是让店铺能自己跑出一条证据链
先不要急着把所有工具都连满。新手先证明四件事：订单邮件发出、付款记录存在、GA4 有 purchase、客服能查到这笔订单。之后再把权限、事件、物流、数据和自动化整理成系统联调证据表。
上一课的客服记录，为什么现在要验系统
上一课留下的是客服 SLA 与售后路由表：客服入口、首响和下一次更新时间、路由、证据位置、升级条件、自动营销状态，以及页面或系统回写位置。
它不能证明实际通知已经送达、个案已经解决、退款已经结算、承运商表现正常、客户满意，或站点已获上线批准。
只有当问题变成“哪个系统需要留存、触发、读取和复测这条记录”时，才进入本课；现在要留下的是系统联调证据表。它仍不是对真实经营结果的放行。
先证明四件事，再进入完整系统联调
这四件事不是把后面的内容删掉，而是给新手一个先后顺序。只要订单邮件、付款记录、GA4 purchase 和客服查询对不上，后面的 Flow、标签、分层和自动化都先不要放大。四件事都能解释后，再用后面的六节点证据链继续补齐库存、履约、权限、告警和复盘。
订单邮件发出
同一测试邮箱收到订单确认邮件，订单号、商品、金额、配送承诺和客服入口都正确。
后台有订单，但用户没有收到邮件，或邮件里的承诺还是旧版本。
付款记录存在
Shopify 订单、支付后台 transaction ID、金额、币种、税费和运费能解释成同一笔订单。
订单状态、支付状态或金额口径对不上时，先不要把这条支付路径接真实流量。
GA4 有 purchase
GA4 DebugView 或事件记录里能看到 purchase，并且 transaction_id、value、currency、items 能和 Shopify 对上。
purchase 缺失、重复或金额币种不一致时，先暂停广告放量和素材胜负判断。
客服能查到订单
客服能从同一订单看到支付、物流、邮件、政策边界、下一次跟进和必要的人工处理路径。
客服只能靠截图猜状态，或退款用户继续收到营销触达，就说明闭环还没接住。
先跟着一笔订单走一遍，再谈系统怎么连
小白最容易把系统集成理解成“装了哪些工具”。更准确的看法是：一个陌生用户从广告点击进来，到付款、收邮件、等发货、问客服、进入复盘，每一步都会碰到不同系统。请点击一个旅程节点，结果区会告诉你为什么要连、断了会怎样、第一证据是什么，以及写回复制笔记总结的句子。
这不是架构图。它是“用户做了什么、系统要接住什么”的顺序。先选现在最怕断的一步，再看结果区该留什么证据。
广告点击和进站
用户从 Meta、Google、自然搜索或红人链接点进来，落到首页、集合页或商品页。
UTM、广告账户、GA4、Cookie/同意状态、主题、正式域名和首屏性能。
你需要知道这个访问从哪里来、落到哪个页面、有没有被同意状态和加载速度挡住。
广告有点击但 GA4 没 session，UTM 丢失，正式域名慢，移动端首屏看不到商品承诺。
测试 URL、UTM、landing page、手机录屏、GA4 Realtime/session、广告点击记录。
写回“入口证据”：来源、URL、设备、是否进入 GA4、第一屏是否能解释商品。
先看这张验收表：每一层都要有输入、输出、负责团队、告警和回滚
账户、支付、数据、客服、履约和自动化不是六个孤立模块。它们要一起证明一件事：用户从访问到售后，每一步都能被记录、处理和复盘。
域名、导航、商品、页面、折扣和入口流量。
用户访问、浏览商品、加购和进入结账。
负责团队 / 运营
页面异常、速度下降、CTA 错链、库存不可买。
系统集成的第一原则不是加工具，而是先拆清责任
新店最容易出现工具都装了，但事件对不上、权限过大、自动化重复、异常没人收到提醒。所以本课先拆三件事：事件谁读写，权限谁能改，失败谁接住。
事件
访问、加购、购买、退款、发货、客服咨询，都要知道由哪个系统产生、写到哪里。
权限
谁能查看、修改、安装、删除、导出关键数据，必须按角色收口。
告警
支付失败、邮件失败、低库存、像素断点和高风险订单，都要有人收到并处理。
最有用的集成目标，是一条可观察的最小闭环
集成不是为了把工具数量做大，而是让一次订单和一次异常都能被追踪、解释和交接。
店铺、支付、结算、发货和邮件身份要能互相对上，不要让不同系统各自解释商家是谁。
顾客能浏览、购买、付款、收到更新、追踪配送并留下反馈；每一步都要有来源、结果和负责人。
你要知道流量来自哪里、在哪一步掉下去、钱是否到账，以及哪些客服问题会反复出现。
基础数据还没有清理前，不要先堆 app。只要有一个环节说不清，就先补证据，再考虑新增工具或自动化。
先画订单流、营销流、分析流和客服流，再决定每个工具的位置
这里要点选不同数据流，不是为了看卡片变化，而是为了判断你当前最弱的链路在哪里。点完后，这个选择会进入最后的复制笔记总结，作为本周先修哪条链路的依据。
订单流
用一笔 20oz 保温杯测试订单，把 Shopify、支付、邮件、GA4、Flow 和客服告警串起来
系统集成最容易虚假的地方，是每个后台都看起来正常，但没有围绕同一笔订单对账。这里的时间线不是让你记步骤，而是让你知道一笔真实测试订单应该在每个系统留下什么证据、哪里可能错配、错配后先停什么。
20oz 保温杯示例：先确定这笔订单属于什么场景
假设你准备在美国市场上线一款 20oz 通勤保温杯，有黑色和奶白色两个变体，首批库存 500 件。这里的测试订单不是为了证明真实经营结果，而是检查一笔订单能否在商品、支付、数据、邮件和客服之间留下同一条可解释记录。
商品与库存
应该留下：黑色和奶白色两个 SKU 在 Shopify、库存表、履约系统和商品 Feed 里命名一致。
错了会怎样：广告卖黑色杯，履约却发成奶白色；客服也无法按 SKU 查清问题。
支付与订单
应该留下：测试订单有订单号、支付状态、币种、税费、运费和退款路径。
错了会怎样：订单看似成功，但 payout、退款和财务对账无法收口。
数据与归因
应该留下：GA4 purchase、广告 Pixel/CAPI、transaction_id、value、currency 和 items 能与订单对上。
错了会怎样：广告后台说有转化，但 Shopify 订单和 GA4 对不上，后续放量判断会失真。
邮件与客服
应该留下：欢迎邮件、订单邮件、发货通知、客服查询路径和自动标签都能指向同一个测试客户。
错了会怎样：客户已经遇到履约问题，系统还在自动发促销邮件，体验和复购判断都会受影响。
按时间顺序点击节点。当前节点会写入最后的复制笔记总结，作为你本周最需要补证据的系统位置。
只用同一笔测试订单对账；把不同订单的截图拼在一起，不能形成通过证据。
Shopify 订单创建
Shopify Orders、库存、客户 profile、订单时间线。
订单号、SKU、数量、折扣、税费、运费、币种、库存扣减和客户邮箱能对上。
订单创建了，但库存没变、客户邮箱不对、折扣或运费和前台不一致。
先截图订单时间线，再继续核对支付、邮件、GA4 和 Flow，不要只凭订单成功就继续。
把时间线写回具体后台位置
看过节点还不够。把路径、字段和失败时先暂停的动作写下来，下一次数据漂移时才能沿着同一笔订单复查，而不是重新猜。
| 要复核什么 | 后台路径 | 必须记录的字段 | 不通过先暂停什么 |
|---|---|---|---|
| 订单是否是唯一来源 | Shopify Admin -> Orders -> 目标测试订单 -> Timeline | 订单号、客户邮箱、SKU、variant、折扣、税费、运费和库存调整。 | 如果这些字段对不上，先暂停用这笔订单判断广告或自动化，修正订单和库存口径。 |
| 支付和退款是否能对账 | Shopify 订单支付区 -> 支付服务商交易 / payout 记录 | transaction ID、授权/捕获状态、币种、手续费、refund ID、payout 日期和测试/真实模式。 | 先暂停真实流量、自动退款和财务结论，保留证据并人工对账。 |
| 电商事件能否解释这笔订单 | Shopify Customer events -> pixel；GA4 DebugView / Realtime / Events | transaction_id、value、currency、items、同意状态、事件时间和重复状态。 | 事件解释不清时，先暂停扩量、素材胜负判断和受众导出。 |
| 邮件和客服是否接到同一客户 | Settings -> Notifications；邮件平台 profile / flow；客服工单线程 | 模板版本、发送状态、profile ID、flow 进入/退出、ticket ID 和下一次更新时间。 | 先暂停群发邮件、复购触达和自动营销分支，避免异常客户继续被触达。 |
| Flow 是否只执行了该执行的动作 | Shopify Flow -> 目标 workflow -> run history | workflow 版本、trigger、condition、action、run ID、标签结果、告警接收人和人工兜底负责人。 | 暂停高风险自动执行，只保留提醒、草稿和人工复核。 |
| 权限是否可以撤回 | Settings -> Users and permissions；Apps and sales channels -> 目标 app | 员工角色、collaborator 权限、app scopes、安装日期、到期日或撤权负责人。 | 先暂停外部高权限、数据导出和未知 App 自动化，直到范围和撤权路径写清。 |
把一笔订单拆成六个系统节点，才知道哪里断了
测试订单时间线告诉你按什么顺序验；这张地图告诉你每个节点到底吃什么输入、吐什么输出、第一证据是什么、断了先回滚哪里。请点击当前最不稳的系统节点，结果区会变成这一节点的排查卡，并写入最后的复制笔记总结。
Shopify 订单节点
订单节点负责确认前台承诺是否真的进入 Shopify 后台。
商品、购物车、checkout、客户邮箱、SKU、折扣、税费和运费。
订单号、库存扣减、客户 profile、订单时间线和后台订单状态。
订单号、SKU/variant、数量、折扣、税费、运费、客户邮箱和库存变化。
订单存在，但库存、客户邮箱、折扣、运费或订单时间线对不上。
先冻结主题和 checkout 相关修改，恢复商品、折扣或运费配置，再保留失败截图。
用同一商品和同一邮箱再下单一次，只生成一笔干净订单，库存只变化一次。
把订单、事件、退款和重试的字段关系写成可复查记录
前面的时间线和系统地图已经说明先查哪里。这里把同一笔练习订单再缩小到字段级：订单引用、transaction_id、SKU、币种、退款状态、事件来源和应用权限分别来自哪里，又在何处被读回。它只把练习记录保存在当前浏览器，不会创建订单、退款、事件或后台改动。
已填写 0/7 项字段检查。全部完成只说明练习记录完整，仍不等于真实账户或生产链路已验证。
结账到订单身份
用一个非真实买家的练习订单，分别记录 Shopify 订单、支付记录、邮件和客服查看位置。
- order_id：写明 Shopify 订单引用，并记录每个下游系统是否保存同一引用或关联引用。
- transaction_id：写明支付或事件侧的引用来源，不假定它一定等于订单号。
- SKU / item_id：写主变体、数量和事件或 Feed 使用的商品引用。
- currency：分别记录商店、结账或事件看到的币种和金额口径。
- 客户或 profile 引用：仅用练习别名或测试引用，不输入真实姓名、邮箱、地址或支付信息。
把订单、支付、邮件、客服和数据读回串成同一笔练习订单的关联图。
能说明每个字段从哪里来、去哪、在哪个系统被看见，以及哪个关联仍未验证。
练习地图不证明真实支付、客户身份、库存、通知或订单状态，也不授予后台访问权限。
重复 purchase
同一练习订单的 transaction_id 或订单关联在两个事件来源中各出现一次，或同一来源出现两次。
读回事件来源、触发时间、transaction_id、SKU、value、currency、同意状态和已安装像素或应用。
暂停用这条 purchase 做广告放量或收入解释，先隔离重复写入路径。
用新的练习测试引用复查，预期只出现一个被说明来源的 purchase。
勾选代表你已在练习记录中写明该项，不代表真实系统已做出相同改变。
发现同一练习订单的 purchase 重复时，哪一种处理保持事实、边界和人工复查？
只记录虚构或练习测试引用。任何真实订单、客户、支付、地址和后台截图仍应留在获授权的实际工作环境中。
这些参考资料用于说明字段和重试的产品边界，但不替代你在实际账户或开发环境中的日志、权限和状态读回。
权限是系统集成的第一层，不要让所有人共用主账号
Shopify 的角色和权限要服务于责任边界。店铺控制人、运营、客服、投放、外包开发不应该拿同一套权限，更不应该项目结束后还保留高权限。
账单、支付、域名、安全、关键设置。
商品、订单、内容、营销、折扣、库存。
开发、设计、广告代理、数据顾问只拿项目所需权限。
数据系统先验核心事件，不要一开始就追复杂归因
Shopify 现在把像素和事件放在 Customer events 管理；官方建议有 app pixel 时优先用 app pixel，custom pixel 留给没有合适 app 方案的情况。新站先把 GA4 和主要广告事件验准。
数据集成按这个顺序验
先把“看见了什么”与“订单发生了什么”对上，再谈高级归因。下面每一步都要有实际事件或订单证据，不用一个绿色提示代替整条漏斗。
- 1先接 GA4先让 view_item、add_to_cart、begin_checkout 和 purchase 这些核心电商事件能在实时或调试视图里看见。
- 2再接主要广告像素只给正在使用的 Meta、Google Ads 或 TikTok 渠道接像素，不要一上来把所有渠道都装上。
- 3核对金额和币种订单金额、税费、运费、币种和 transaction_id 要能回到同一笔 Shopify 订单，先说清金额口径再比较数字。
- 4用测试订单确认平台收到不要只看页面上的触发提示；用一笔测试订单确认 GA4 和广告平台真的收到事件及其参数。
- 5高级归因放到后面基础事件没有跑通前，不要先做 server-side、CAPI 或 LTV 分层；复杂模型不能修复底层事件缺失。
开始前先回答四个问题：有人看产品吗？有人加购吗？有人开始结账吗？purchase 是否重复？如果前一层没有证据，不要跳到后一层怪支付或结账。
表单、邮件、聊天和评价要讲同一种客户语言
弹窗收集了邮箱，客服不知道客户是谁；聊天有人咨询，没人跟进；用户刚遇到物流问题，系统还发促销邮件。这些都不是工具问题，而是沟通系统没有统一状态。
负责订阅、批发申请、访客信息、标签和细分入口。
承接欢迎、弃购、发货后复购；先保证来源、标签、分组干净。
先覆盖配送、退货、时效、订单追踪这些高频问题。
最先接起来的一条客户沟通线
表单、邮件和聊天不是三个孤岛。按下面的顺序接，客服才知道客户从哪里来、现在处在什么状态、下一步该由谁处理。
- 1表单先收入口信息首页或商品页表单可以收订阅、批发申请和访客信息；同时保留来源、同意状态和后续标签。
- 2再按来源和状态打标签至少区分来源、感兴趣的商品、是否首购、复购或退款，避免客服和邮件平台各自猜客户状态。
- 3欢迎邮件只承接已知承诺欢迎邮件说明品牌主张、优惠使用方式和客服入口；先保证名单来源、标签和分组干净，再增加更多自动化。
- 4聊天先回答高频问题快捷答复先覆盖配送、退货、发货时效和订单追踪，让客户在进入工单前知道下一步。
- 5签收后再邀请评价评价邀请放在合理的签收时间窗之后；客户刚付款或刚报物流问题时，不要先发评价或促销。
这里不重复配置细节，只验支付、订单、通知、履约和退款能不能串起来
支付状态、库存、订单邮件、后台订单和金额币种同步。
tracking、发货邮件、订单状态、客服查询路径同步。
订单状态、支付后台、客户邮件、refund 事件和客服记录同步。
谁收到提醒、谁处理、怎么记录、什么时候升级，要提前写清楚。
付款到履约，按这个顺序收证据
- 1先确认支付方式可用Shopify Payments、PayPal 或第三方网关要能完成授权或付款，并能在订单里回写支付状态。
- 2再确认收款与 KYC结汇或多币种账户先完成主体信息验证，并保留 payout、手续费和对账记录，不要把“支付成功”当成“钱已到账”。
- 3让运费规则匹配市场Shipping profile、zone 和 rate 要覆盖实际销售市场、库存地点、商品重量和地址规则。
- 4确认订单通知会到下单确认、发货通知和客服入口要和同一笔测试订单对上，客户收到的政策与后台当前版本一致。
- 5最后跑一笔小额闭环用测试订单验证付款、订单、通知、库存、物流追踪、payout 和退款或人工兜底路径。
支付与收款配置，至少留下这三类证据
Shopify Payments
验证：主体、地址和银行信息一致；用测试订单核对订单状态、付款状态和 payout 行为。
边界：主体信息或 payout 口径不一致，后续收款与财务对账会断开。
PayPal / 第三方网关
验证：邮箱、主体、争议处理和退款逻辑一致；成功订单能同步回 Shopify。
边界：支付后台显示成功，但 Shopify 订单状态或退款记录没有同步。
WorldFirst / Airwallex 等收款层
验证：KYC 已完成、提现账户已准备，并用小额转账验证到账时间、手续费和汇率差。
边界：只看到支付成功，却没有 payout、手续费和汇率记录，不能完成收款复盘。
运费配置先排这四个坑
- 市场没有启用国家不属于 active market 时，运费配好也可能无法结账；先确认目标市场可售。
- Shipping profile 分错不同 profile 或库存地点组合后，结账页可能叠加运费；要用目标商品和地址实际试算。
- 没有备用运费carrier 或 app 费率短暂不可用时，备用 rate 能避免结账出现“无法配送”；它不能替代主费率排查。
- 商品重量没有维护weight-based rates 会直接算错；先补齐变体重量，再复测主市场、偏远地区和免邮门槛。
自动化先做最小、可停止、可人工兜底的 5 类
没有 Flow 也可以先上线，但必须有人工告警和订单证据能接住。Shopify Flow 的价值不在复杂，而在把每天重复、容易忘、忘了就出错的动作接住。任何自动化都要有触发条件、停止条件和人工兜底。
订单创建、国家、SKU、金额、支付方式。
自动打标签，方便客服、履约和复盘。
标签冲突、规则过期、SKU 命名变更。
允许人工改标签，并把错误规则写入复测表。
什么时候值得再加更复杂的自动化？
- 订单量已经稳定增长只有手工处理已经明显拖慢响应时，才值得用更多自动化换时间。
- 字段已经基本统一标签、来源或 SKU 命名混乱时，自动化只会把错误复制得更快。
- 触发条件说得清先写清谁触发、读哪个字段、要做什么动作和何时停止，不要为了“自动化”而自动化。
- 失败时有人能接住任何自动化都要保留人工恢复路径：谁暂停、谁处理受影响订单、谁留下复测记录。
真正的集成，要知道失败时谁会收到提醒
SKU、AOV 和 attribution 会直接影响系统能不能对账
这些词不是投放或数据团队的装饰词。系统集成里，它们是各个工具能不能识别同一件商品、同一笔订单和同一个收入口径的底层字段。
SKU 是店铺自己给商品或变体起的识别码，不是平台自动生成的订单号。
出现位置：你会在 Shopify 商品后台、库存表、订单、履约系统、客服记录和商品 Feed 里看到它。
谁会读取：库存、客服、履约、广告商品目录和财务复盘都会读取 SKU。
错了会怎样：SKU 不一致时，系统会把同一件商品看成不同商品，导致库存扣减、发货、利润和广告复盘对不上。
AOV 是平均订单金额，用总收入除以订单数。它不是利润，也不自动说明订单质量好。
出现位置：你会在 Shopify 报表、GA4、广告后台、邮件平台和周经营复盘里看到它。
谁会读取：投放、财务、邮件和商品团队会用 AOV 判断是否能承受广告成本、折扣和运费。
错了会怎样：如果不同系统把税费、运费、退款口径算得不一样，AOV 会误导预算、自动化分层和利润判断。
Attribution 是平台把订单功劳分给某个点击、广告、邮件或自然访问的规则。
出现位置：它会出现在 GA4、Google Ads、Meta、TikTok、邮件平台和内部复盘表里。
谁会读取：投放、SEO、邮件和财务都会读 attribution，但每个平台都有自己的窗口和口径。
错了会怎样：如果你把平台归因当成唯一真相，就会重复计算收入，或者把系统集成问题误判成渠道效果问题。
上线前先判断能不能继续，不要把已安装当成已集成
系统集成最危险的时刻，是团队看到工具都装好了，就开始投流、自动化、交给外包或放大预算。继续前先问：证据够不够、谁负责、出错停什么、怎么回滚、用什么复测。
准备公开投流前，团队说支付、邮件、库存和事件都已经装好。
只看 checkout 能付款就继续。
限制继续：必须用同一笔测试订单串起 Shopify、支付后台、订单邮件、库存、GA4 purchase 和客服记录。
测试订单号、支付截图、订单邮件、库存变化、GA4 DebugView、Customer events 状态。
运营负责团队收口，支付、数据、客服分别确认自己的证据。
支付或事件不稳时，暂停投流；保留测试订单证据，修复后重跑同一条链路。
第二笔测试订单也能对上 transaction_id、value、currency、items、邮件和订单状态。
告警不是终点：要知道停什么、谁处理、保留什么证据、什么时候复测
系统闭环真正上线后，问题不会按教程顺序出现。Purchase 缺失、自动化误触发、客服告警无人接、结账无运费，都需要先分级，再暂停风险动作，最后用同一条链路复测。
点选异常演练时，重点看第一暂停动作、负责团队和复测标准。最终复制笔记总结会记录你当前选中的异常场景，方便你把系统会不会坏变成可演练的流程。
Purchase 事件缺失
测试订单在 Shopify 和支付后台都成功，但 GA4 或广告平台没有 purchase。
P1：不一定影响收款，但会污染广告学习和复盘。
暂停用 purchase 数据做扩量、预算迁移或素材胜负判断。
数据负责团队用同一笔订单复核 Customer events、GA4 DebugView、广告像素和事件参数。
订单号、支付截图、GA4 DebugView、Customer events 状态、purchase 参数截图。
离开电脑 24 小时之前，像真实顾客一样跑一遍
系统集成不是把开关打开，而是证明整条链路可靠：手机访问、商品页、加购、结账、付款、收邮件、查后台、看事件、触发发货、做一次退款或售后记录。
手机访问并加购
完成测试订单
核对邮件和后台
检查事件与自动化
模拟发货通知
记录退款或售后
写下异常负责团队
安排月度复查
回归前，再逐项确认这六件事
这张清单把“像真实顾客走一遍”落到可以复查的负责人、字段和人工路径上；它不是用勾选数量替代一笔完整测试订单。
- 账户按角色拆分店铺控制人、运营和协作者有各自范围；主账号完成邮箱验证和 2FA，项目结束有撤权记录。
- 核心事件能和订单对上GA4 和主要广告像素能看到核心事件，purchase 的金额、币种和订单引用有解释。
- 表单、邮件和客服已经接上Shopify Forms、邮件和客服入口能把同一客户的来源、标签、订单和下一步接起来。
- 支付、收款和运费经过订单验证支付、KYC、运费、物流通知和 payout 至少用一笔测试订单验证过，失败时知道先停哪里。
- 至少 3–5 个提醒或自动化有负责人覆盖重复且容易出错的动作，并写清停止条件和人工兜底，不用数量替代证据。
- 关键异常有人工路径退款、发货、客服跟进、备用收款和对账都能在自动化失效时继续处理并留下记录。
订单、支付、数据、邮件对不上时，先定位哪一层断了
系统集成最怕每个后台都看起来有点对，但合起来不对。不要凭感觉重装 app，先用同一笔订单或同一个邮箱，把各系统的证据放在一起对。
后台订单和支付都成功，但 GA4 DebugView 或报表里没有 purchase。
先核对 Customer events / GA4 pixel 是否发布，测试订单是否触发正式 checkout，purchase 参数是否包含 transaction_id、value、currency 和 items。
数据层或事件发布层，不要先怀疑订单系统。
用同一笔测试订单截图 Shopify order、支付后台、GA4 DebugView，再决定是像素、同意模式还是事件参数问题。
装完工具，不等于系统集成完成
你装好了 GA4、广告像素、邮件工具和 3 个自动化，但没有权限表、失败告警，也没有测试订单证据。现在应该怎么判断？
这篇课做完，Basics 系列才算真正收口
下一步不要追复杂增长。先根据最弱的一层选择路线：数据不稳进 GA4，触达不稳进邮件生命周期，订单稳定后再进运营增长。
- 1
1. 订单证据
同一笔测试订单能对上 Shopify、支付、库存、邮件和客服记录；之后才考虑投流和复杂自动化。
- 2
2. 事件证据
purchase、refund、value、currency、items 和 transaction_id 都能解释；之后才用 GA4 或广告数据做预算判断。
- 3
3. 权限证据
协作者、App、客服、投放和运营权限都有范围、到期日和撤权负责人；之后才开放外部协作。
- 4
4. 告警证据
支付失败、低库存、邮件失败、事件断点和异常订单都有负责团队；之后才让 Flow 从提醒升级到执行动作。
把这篇教程收束成一份系统集成复制笔记总结
复制前先把当前压力、第一证据、本周动作、暂停动作、复盘窗口和下一步路线写清楚。系统清单、事件表、权限表、自动化触发条件和告警负责团队，是为了让后续增长动作不再靠感觉。
系统集成复制笔记总结 当前闭环层级：店铺 / 主题。 当前数据流：订单流。 当前自动化：订单标签。 当前告警路由：支付失败。 当前继续/暂停判断：第一笔测试订单。 当前测试订单证据节点：Shopify 订单创建 - 订单号、SKU、数量、折扣、税费、运费、币种、库存扣减和客户邮箱能对上。。 当前系统集成地图节点：Shopify 订单节点 - 订单节点负责确认前台承诺是否真的进入 Shopify 后台。。 当前真实订单旅程：广告点击和进站 - 写回“入口证据”：来源、URL、设备、是否进入 GA4、第一屏是否能解释商品。。 当前异常演练：Purchase 事件缺失。 当前信号排查：Shopify 有订单，GA4 没 purchase。 字段血缘路径：结账到订单身份。 当前故障注入：重复 purchase。 字段血缘关卡：0/7。 字段血缘判断：还没有选择。 已勾选事件：还没有勾选核心事件。 快速自测：还没有选择。 下一步路线：数据事件还不稳 - 继续进入 GA4，把事件命名、purchase 参数和报表复盘单独做好。 练习订单范围: ___ 订单和身份关联: ___ Purchase 字段地图: ___ 部分退款字段地图: ___ 故障和第一证据: ___ 先限制什么: ___ 隔离复测说明: ___ 当前压力: 写下现在最怕断掉的系统链路，例如 purchase 缺失、邮件未发、库存未扣或外部权限过大。 第一证据: 写下一条测试订单、截图、事件记录、权限表或告警记录。 本周动作: 只选一个动作：复测订单链路、补事件参数、收权限、关闭误触发 Flow 或补告警负责团队。 暂停动作: 写清在证据不足前先暂停什么：投流、自动退款、群发邮件、外部高权限或新品放量。 复盘窗口: 写下什么时候复测：修复后第二笔测试订单、24 小时后、7 天后或月度系统复查。 下一步路线: 根据最弱层级选择 GA4、邮件生命周期或运营增长，不要直接跳去复杂增长。 订单证据链地图: 系统节点、输入、输出、第一证据、失败信号、回滚和复测。 真实订单旅程: 广告点击、商品页、结账、邮件、履约、客服和复盘分别碰到哪些系统。 系统清单: Shopify、支付、物流、邮件、客服、数据、自动化工具。 事件表: 每个系统读写哪些事件、字段、订单号和标签。 权限表: 谁能查看、修改、安装、删除、导出和撤权。 告警表: 支付失败、库存低、邮件失败、数据断点、异常订单。 自动化表: 触发条件、动作、停止条件、人工兜底。 回归测试记录: 测试订单、截图、事件记录、问题负责团队、复测状态。 异常演练记录: 异常触发、严重级别、暂停动作、负责团队、证据和复测时间。 信号不一致排查: 订单、支付、GA4、邮件、Flow 对不上时，先查哪层、保留什么证据。 月度检查节奏: app 成本、速度影响、事件质量、权限回收、自动化误触发。