Shopify 感谢页截止日期：8 月 26 日前完成审计

2026 年 8 月 26 日是使用非 Plus 版 Shopify 套餐的商店，将现有感谢页和订单状态页升级到新版本的截止日期。Shopify 面向非 Plus 商店的升级指南指出，商家执行升级后，现有页面及其自定义内容会被替换。对于不兼容的应用、脚本、像素和页面自定义项，都需要逐一审查，并在仍有必要时改用受支持的替代方案。

这两页都属于结账完成后的页面。Shopify 将感谢页定义为用户成功完成结账后仅显示一次的页面，而订单状态页则是订单创建后，客户可反复访问的页面。根据商店配置不同，这些页面还可能包含追踪代码，以及由应用提供的内容，例如问卷、下载链接、会员积分或推荐邀请、加购推荐、配送信息、退货工具和客服链接等。

对于 Shopify 商家、电商负责人、代理商和 IT 团队来说，这个截止日期应被视为一次迁移与数据衡量审计项目。目标不只是把新页面发布上线，更重要的是确认在变更之后，营收数据、售后体验以及内部运营交接流程依然能够正常运作。

Shopify 官方文档明确了什么

这个截止日期适用于结账后的感谢页和订单状态页。Shopify 已发布的指引并没有说明 8 月 26 日会发生整个结账流程的全面停用。官方要求非 Plus 商店在该日期前完成这两个页面的升级，并说明升级后，现有页面及其自定义内容会被替换。但这并不意味着未经测试的商店配置就一定不会出问题。

Shopify 还单独说明，若符合条件的商店使用了临时回退选项，但在 8 月 26 日前没有再次完成升级，系统将自动为其升级。这个说法出现在回退条件说明中，不应被泛化理解为适用于所有非 Plus 商店的统一结果。

由于 Shopify 要求替换不兼容的追踪方案和页面自定义项，商家在迁移后应逐项验证每个关键功能，而不是默认原有脚本或应用行为会自动延续到新页面中。

具体会发生哪些变化？

Shopify 正在用新版本页面替换旧版结账后页面。新版本基于 checkout and accounts editor、app blocks、checkout UI extensions 以及 Shopify 的像素框架构建。商家升级后，现有的感谢页、订单状态页及其当前自定义内容都会被新页面替换。

替换路径会因旧自定义内容的用途不同而有所区别：

• 页面上可见的内容，应迁移到 Shopify 内置功能、兼容的应用区块，或自定义 checkout UI extension。
• 追踪与分析功能，应迁移到应用像素；如确有必要，再使用经过审查的自定义像素。
• 仍依赖旧版不兼容机制的应用，需要等待供应商更新，或直接更换替代方案。
• 依赖 DOM 抓取，或试图通过像素渲染界面元素的代码，无法原样迁移到 Shopify 的像素沙盒中，必须改用受支持的替代实现。

Shopify 的开发者文档列出了受支持的扩展场景，例如问卷、评价邀请、加购优惠、社交分享和下载链接等。文档也明确区分了仅显示一次的感谢页，以及可重复访问、且在订单创建后可读取订单数据的订单状态页。

为什么这不只是页面迁移，更是一次追踪审计项目

Additional Scripts 既可能用于追踪和分析，也可能用于页面自定义。Shopify 的个性化升级指南会识别现有脚本，并按用途分类，例如身份验证、订单追踪等。商家应记录每个脚本的具体作用、数据发送到哪个平台，以及该功能是否仍然需要保留。

Shopify 明确表示，新页面不支持 Additional Scripts。对于追踪需求，Shopify 推荐使用应用像素；如果没有合适的应用满足需求，也允许使用自定义像素。页面上可见的自定义内容，则应通过兼容区块或其他受支持功能重新实现。

Shopify 提醒，如果在停用 Additional Script 之前就先连接应用像素，短时间内可能会产生重复事件；但如果先停用旧脚本，又可能导致切换期间事件追踪中断。官方建议的顺序是：先连接并测试替代像素，确认目标平台已收到事件，再停用旧脚本，以避免后续继续产生重复数据。

第 1 步：打开 Shopify 的个性化升级指南

先进入 Shopify 后台的 Settings > Checkout。在 Configurations 区域中，展开标题为“Upgrade Thank You and Order Status pages by August 26, 2026”的提示，然后点击 Review customizations。

Shopify 会生成一份针对该商店的专属报告，列出现有自定义项，并区分兼容与不兼容的应用、追踪与分析设置、页面自定义内容以及 Additional Scripts。你可以把它作为初始清单，再对照市场团队、财务、客服、运营以及外部代理商实际使用的系统逐一核对。

完成标准：由一位明确负责人整理升级指南中的所有项目，并确保每一项都有对应责任人、用途说明、替代方案和测试状态。

第 2 步：建立完整的售后页面依赖清单

重点审计以下四类依赖。

1. 追踪与分析

• GA4 和 Google Ads 的购买事件
• Meta、TikTok、Pinterest 等广告像素
• 联盟营销和合作伙伴网络的转化标签
• 邮件或短信渠道的营收归因
• A/B 测试、会话录制、热力图和问卷追踪
• 自定义 data layer 事件和内部分析系统

2. 页面上可见的售后内容

• 问卷、评价邀请和推荐分享提示
• 售后加购优惠、再次购买提示和会员忠诚度信息
• 数字商品下载链接
• 配送、自提、快递柜、货到付款或付款说明
• 客服链接、联系方式、政策说明和信任背书信息

3. 订单操作与客户自助服务

• 订单追踪和多包裹发货状态
• 退货、换货、取消订单和修改订单链接
• 订阅管理或续费链接
• 再次购买和重复下单功能
• 客户账号验证以及失效订单状态链接的处理方式

4. 隐藏的技术前提

• 硬编码的感谢页 URL
• 抓取 DOM 或读取不受限制页面变量的代码
• 默认依赖特定订单号或客户标识符的脚本
• 既手动安装又通过应用安装的标签
• 客户账号域名未与在线商店根域名保持一致

第 3 步：按业务风险确定优先级

不要把所有旧版自定义项都赋予同样的紧急程度。建议按三个风险等级排序，优先保护营收和客户运营相关功能。

• 关键：该项用于记录购买、传递营收或币种数值、归因联盟销售、交付付费数字商品，或提供关键订单与配送信息。
• 重要：该项会影响客户信任、复购、评价收集、会员忠诚度、退货、订阅自助服务或客服工作量。
• 低风险：该项已过时、重复、未使用，或只是 Shopify 已在其他位置提供的信息内容。

一个实用的删除原则：如果没人能说清某段脚本由谁负责、数据发往哪个平台，或它支撑了什么业务决策，就不要默认重建，先确认是否真的有必要。

第 4 步：选择受支持的替代方案

用于追踪：优先选择应用像素，其次才是自定义像素

Shopify 的像素管理器支持通过营销和数据类应用安装的应用像素，也支持由开发者添加的自定义像素。在相应权限和沙盒规则允许的前提下，这些像素可在店铺前台、结账页、感谢页、订单状态页以及客户账号页面中加载。

在升级指南中，Shopify 推荐优先使用应用像素，以获得更好的稳定性、安全性和性能。如果没有合适的应用满足需求，才建议使用自定义像素。

用于可见内容：使用区块或 UI 扩展

可通过 checkout and accounts editor 添加兼容的应用区块。若有定制需求，可使用 checkout UI extensions，但实现方式应基于 Shopify 支持的 API，而不是简单重建过去那种不受限制的旧版 JavaScript。

新的订单状态页还提供了一些原生功能，例如 Buy Again，以及在完成配置后可用的自助退货功能。在花钱重建类似自定义逻辑之前，先确认 Shopify 是否已经原生提供了等效能力。

对于 Google Tag Manager：把它当作一个需要明确决策的方案

Shopify 关于 GTM 迁移的指引建议大多数商店使用 Google & YouTube 应用。已有 GTM 自定义像素的商家也可以更新它，但 Google 并不推荐或支持这种自定义像素方案，而且 Google Tag Assistant 也无法对其进行测试。

如果商店决定继续保留 GTM 自定义像素，请确认它已订阅 Shopify 的 checkout_completed 事件，并同时测试连接两端：一端用 Shopify Pixel Helper 检查事件是否成功发送，另一端在对应的 Google 产品中确认是否成功接收。此外，还要更新任何硬编码 URL 逻辑，因为新的感谢页路径会从 /thank_you 变为 /thank-you。

对于此前通过 Google Tag Manager 配置的非 Google 标签，Shopify 要求商家改为安装使用应用像素的替代应用。每个目标平台都应分别测试。

第 5 步：验证同意机制、域名和事件质量

一个事件成功触发，并不代表迁移就成功了。它还必须在正确的同意状态下触发，并携带正确的标识符、营收、币种以及去重逻辑。

• 同意机制：在需要征得用户同意的市场中，Shopify 表示通常包括 EEA 和英国，网页像素只有在客户授予像素配置所需权限后才会运行。
• 域名连续性：如果商店使用自定义域名，应将客户账号域名配置为在线商店域名的子域名。Shopify 表示，否则像素和 Cookie 同意机制将无法在订单状态页正常工作。
• 营收数据：在目标平台中确认金额、币种、折扣、税费、运费和订单标识符等数值是否正确。
• 去重：如果浏览器端和服务端事件都会上报购买行为，要确认平台能够识别为同一笔订单，而不是两次转化。
• 归因：作为审计建议，应在迁移前建立 Shopify 订单数与各目标平台数据之间的基线关系；如果迁移后两者关系突然变化，应及时排查。

不要误判因同意机制导致的数据下降。Shopify 指出，应用像素和自定义像素上报的事件数量，可能会少于旧脚本，因为受支持的像素会遵守已配置的用户同意设置。数量下降并不自动等于迁移失败，需要结合同意设置、Shopify 订单数据以及目标平台诊断结果一起判断。

第 6 步：测试真实客户路径

仅看页面预览远远不够。你需要完成受控测试订单，并像真实客户一样重新访问订单状态页，例如通过确认邮件、短信、账号导航入口和客服链接进入。

• 桌面端和移动端的标准银行卡结账流程
• 商店正在使用的 Shop Pay 或其他快捷支付流程
• 货到付款场景，包括确认信息和配送说明
• 新订阅订单，以及订阅商品与一次性商品混合购物车
• 门店自提、本地配送或快递柜订单
• 售后加购或再次购买流程
• 带下载链接的数字商品订单
• 语言和币种都正确的国际订单
• 部分发货或拆单发货，且包含多次物流更新的订单
• 回访客户在原始会话结束后再次打开订单状态页
• 已授予和未授予营销或分析同意的客户路径

对于每一条路径，都要记录以下结果：

• 是否正确渲染了感谢页和订单状态页
• 关键应用区块是否正常显示，并且在移动端仍可用
• 购买事件是否在每个预期平台中仅到达一次
• 营收、币种、订单标识符和商品数据是否正确
• 订单链接、下载、退货、账号访问和物流追踪是否仍可正常使用
• 客服团队是否无需手动补救，就能清楚解释整个客户体验

向应用供应商和代理商要问的问题

• 你们的应用在新的感谢页和订单状态页中，使用的是 app blocks、checkout UI extensions，还是 web pixels？
• 新的实现方案替代了哪一项旧版自定义内容？
• 商家是否需要手动添加区块、连接账号、启用像素或发布配置？
• 哪些事件应该出现在 Shopify Pixel Helper 中？哪些事件应该出现在目标平台中？
• 你们如何避免迁移期间和迁移后出现重复购买事件？
• 该实现是否遵守 Shopify 的客户隐私和同意设置？
• 它是否支持自定义客户账号域名、多市场、订阅、货到付款、自提和拆单发货？
• 在 8 月 26 日前，如果出现问题，回退或支持方案是什么？

含糊其辞的回答不代表已经准备就绪。你需要对方明确提供商家侧设置步骤、支持的页面目标、事件名称、测试说明以及书面的支持路径。

迁移后要持续监控什么

• Shopify 订单数与各平台记录的购买事件数量是否一致
• 营收和币种数据是否准确
• 重复转化率以及归因是否突然发生明显变化
• 付费广告活动是否出现警告或无法解释的效果波动
• 感谢页和订单状态页区块在桌面端与移动端的渲染情况
• 订单追踪、退货、下载和账号访问是否出现失败
• 客服工单中是否出现缺少确认信息、物流信息或售后操作异常的反馈
• 应用或自定义扩展是否报告页面性能问题或错误

Progus 建议，至少在迁移后的第一周内，明确安排专人进行每日监控，以便在缺失事件或重复事件影响更长周期报表之前及时排查。

一份实用的完成检查清单

1. 已审阅升级指南。完成标准：没有任何关键项目处于无人负责或用途不明的状态。
2. 旧版脚本已处理。完成标准：每段脚本都已被替换、明确下线，或记录为无需保留。
3. 页面内容已发布。完成标准：所有必需的应用区块都出现在正确页面和正确设备上。
4. 像素已验证。完成标准：Shopify 和每个目标平台都能收到预期事件，且仅收到一次，数值正确。
5. 重复数据已清除。完成标准：在停用旧脚本后，已验证的新追踪方案仍保持正常运行。
6. 同意机制与域名已检查。完成标准：在客户账号域名下，像素对已同意和未同意路径都能按预期表现。
7. 核心路径已通过测试。完成标准：商店实际使用的支付、市场、订阅、货到付款和配送场景都能端到端正常运行。
8. 客服已准备就绪。完成标准：文档、升级处理责任人和面向客户的说明都已更新。
9. 监控已启用。完成标准：已记录负责人、基线、复查频率和告警阈值。

最后总结

8 月 26 日的截止日期表面上只涉及两个页面，但这些页面上承载的功能，往往连接着营销、分析、客服、履约和客户体验。因此，这次升级不应只是检查页面编辑器是否完成，更应包含完整的依赖清点和功能验证。

把这次迁移当作一次清理机会：移除来源不明的代码，把追踪迁移到受支持的像素方案，只重建客户真正还需要的页面元素，并通过真实订单验证结果。一次成功的升级，不只是换上新的感谢页，更意味着数据衡量可靠、订单沟通清晰，以及在旺季来临前减少运营上的意外。