纯文字版教程展开阅读
第四阶段 市场与数据
检查客户与员工通知、发件邮箱、品牌、模板变量、收件人和语言，逐封发送测试，并验证订单、发货、取消和退款触发。
Settings > Notifications75分钟
第四阶段 市场与数据
这一课为什么要先做
后台显示模板存在，不代表客户真的能收到。发件域名、垃圾箱、模板变量、语言、员工收件人和订单状态都会影响结果。新手常只点 Send test email，看起来正常就结束，但真实订单的商品、折扣、追踪和退款变量没有被验证。必须把模板预览和真实触发分开测试。
做完以后要留下什么
一份通知矩阵，列出每封客户和员工通知的触发、收件人、From、Reply-To、语言、测试结果、截图和负责人。
开始前准备
- 域名、企业邮箱和 Sender email 已配置。
- 准备 Gmail、Outlook 等不同邮箱测试收件。
- 有一笔可取消、可发货和可退款的测试订单。
跟着英文后台一步一步做
每做完一步就刷新页面或从前台验证一次。后台显示已保存，不代表客户看到的结果一定正确。
建立通知矩阵
进入 Settings > Notifications，先列出 Order confirmation、Shipping confirmation、Shipping update、Cancelled、Refund、Customer account 和 Staff notifications。每封写触发条件和责任人。
核对 Sender email 和品牌
确认 From 与 Reply-To 能进入真实客服，logo、颜色和店铺名称与 Brand 一致。发件地址已显示 authenticated 才能算完成，仍要实际检查送达。
先发模板测试
逐封使用 Send test email，检查标题、预览文字、logo、按钮、页脚、政策链接和移动端排版。模板测试主要看样式和固定文案，不证明真实变量。
检查 Liquid 变量和自定义
如需要修改模板，先复制原代码，尽量做小改动。检查 order、line_items、discount、tracking 和 refund 等变量是否在当前模板可用。不要直接粘贴来源不明的大段代码。
用真实测试订单触发
下测试订单后依次触发确认、发货、追踪更新、取消或退款，检查邮件中的商品、金额、地址、追踪和政策。员工通知也要确认正确人员收到，不要发到离职邮箱。
检查送达和建立变更规则
在不同邮箱查看 Inbox、Promotions 和 Spam，测试 Reply-To。记录最终截图和 Message ID 等可用证据。任何模板修改都要重新走测试矩阵，并保留回滚副本。
North & Pine 案例怎么设置
North & Pine 用 Gmail 和 Outlook 测试 Order confirmation、Shipping confirmation、Cancelled 和 Refund。模板测试通过后，再用同一笔订单真实触发。邮件里的 Tan 变体、39 美元、12 美元运费、追踪链接和 support Reply-To 全部正确，员工通知只发给运营与客服。
这一课需要做出的决定
| 项目 | 推荐设置 | 为什么 |
|---|---|---|
| Sender email | support 品牌邮箱 | 客户可直接回复 |
| 模板改动 | 小范围并保留原版 | 降低 Liquid 错误和升级风险 |
| 测试 | 模板加真实触发 | 样式和业务变量都要验 |
| 员工收件人 | 按工作职责 | 不把敏感订单发给无关人员 |
这些地方先不要乱动
- 不要只测试一封 Order confirmation。
- 不要直接粘贴无法解释的 Liquid 模板代码。
- 不要把员工通知留在离职人员或个人邮箱。
完成标准
下面每一项都能拿出证据，这一课才算完成。只说我看过了，不算验收。
- 所有关键通知都进入矩阵。
- Sender、Reply-To、品牌和认证状态正确。
- 模板测试和真实触发测试都通过。
- 员工收件人按职责最小化。
- 变更、复测和回滚规则已建立。
常见问题和处理方式
| 现象 | 怎么处理 |
|---|---|
| 测试邮件正常，真实邮件变量为空 | 检查真实订单状态、模板变量作用域和自定义代码，用原版模板对比复现。 |
| 客户回复到了无人邮箱 | 修正 Sender 或 Reply-To，发送新测试并从外部邮箱实际回复，确认工单或收件箱收到。 |
| 发货邮件没有 tracking | 确认 fulfillment 已添加 tracking number、carrier 和通知客户选项，再检查模板变量。 |
把英文后台截图变成验收记录
本课的截图不是装饰，也不等于设置完成。以 Settings > Notifications 为例，先确认左侧导航和页面标题，再看当前选中的标签、开关、状态或记录。截图需要保留完整页面外壳和必要上下文，不能只截一个按钮。这样回看时能回答两个问题：当时在哪个页面，页面当时到底显示了什么。
North & Pine 在本课要处理的是订单、发货、退款和客户邮件模板。本课案例的验收重点是逐封检查邮件收件人、变量、链接和实际触发时机。按钮显示可点击，只证明下一步存在，不代表审核、同步、保存或前台结果已经通过。如果画面出现 pending、review、unavailable、错误提示或空状态，就把它记录为待确认，不要把它写成已经完成。
先看路径，再看设置
打开英文截图时，先读出左侧导航、页面标题、当前标签和可见状态，再去读字段值。截图说明同时写下页面路径、要验证的事实、负责人和下次复核时间。页面较长时可以用全页截图或两张连续截图，但每张都要保留路径和标题。
发布前仍要做隐私检查。即使使用 dev store，也要遮住邮箱、电话、地址、客户姓名、订单号、域名、App 标识、API key、二维码和浏览器 Cookie。优先使用不透明遮罩或重新裁切。英文版保留后台原文，中文版在图片下增加一行中文说明。
一项设置对应三层证据
对订单、发货、退款和客户邮件模板，把验收拆成配置、行为和记录。配置证据说明后台值已经保存，行为证据说明店面、订单或相关结果确实发生，记录证据说明谁在什么时候复核过。只拿到一层时，不能把整项写成通过。把截图文件名、检查日期、操作者、结论和待处理事项放进复盘表。
- 配置层：记录字段、开关、选项和保存后的状态，不要把默认值当成业务决定。
- 行为层：从前台、订单、通知或下一处关联设置回看结果，确认设置真的影响了流程。
- 证据层：给每个结论关联一张完整截图或连续截图，不用局部按钮图替代页面上下文。
- 边界层：写清地区、套餐、权限、审核、测试模式或第三方服务造成的例外。
出现分支时先暂停
Shopify 后台会因为经营地区、套餐、用户权限、测试数据、销售渠道和审核状态而显示不同选项。缺少按钮不一定是故障，也不一定说明功能关闭。先检查权限、适用地区、套餐和测试状态，再回到官方来源核对。若只能证明一部分，就标记部分完成并说明缺口。支付、税务、域名和客户数据不能用一张测试截图冒充真实上线结果。
本课复盘表
把下面的表复制到团队任务记录中。可证明什么只描述截图确实支持的结论，还不能证明什么用来防止过度解读。
| 检查对象 | 截图中要读什么 | 可证明什么 | 还不能证明什么 |
|---|---|---|---|
| 订单、发货、退款和客户邮件模板 | 路径、标题、当前状态和关键值 | 本次后台检查看到的配置事实 | 前台或第三方服务已经完成全部处理 |
| 关联结果 | 前台、订单、通知或相关设置的返回结果 | 设置对当前测试流程产生的影响 | 所有市场和未来订单都会得到同样结果 |
| 责任记录 | 日期、操作者、文件名和结论 | 谁完成了哪一步，以及证据在哪里 | 审核机构已经替团队做出最终决定 |
| 例外边界 | 权限、地区、套餐、审核或待处理提示 | 当前结果适用的前提 | 可以跳过条件复制到生产店铺 |
课后自测
- 能说出本课的后台路径、当前目标和一项不能由截图单独证明的事情。
- 能指出完整截图中的页面标题、关键字段、状态和对应的实际结果。
- 能把配置、行为和记录三层证据分别写进复盘表，而不是只写已完成。
- 能根据证据决定下一步Customer privacy 与 Events，或者明确写下阻塞条件和负责人。
完成本课不等于把所有按钮点成绿色。完成标准是当前判断有足够证据、边界写得清楚、下一步有人负责。如果任何一层证据缺失，就保留待确认状态，不要为了赶进度推进到Customer privacy 与 Events。
常见问题
Send test email 通过就够了吗？
不够。它主要验证模板外观和固定文案，真实订单里的商品、折扣、地址、追踪、退款等变量需要用测试订单触发。
可以修改 Shopify 通知模板吗？
可以，但要先备份，尽量小改，并确认 Liquid 变量和 HTML 不破坏移动端、可访问性或邮件客户端兼容。
订单通知和营销邮件是同一个系统吗？
不是同一目的。订单通知是交易服务信息，营销邮件需要相应同意和退订管理。两者的发件与送达仍可能共享域名信誉，需要分别治理。
官方来源
后台名称和规则会更新。本课以这些官方页面作为维护基线，截图时也要按当前英文后台重新核对。