Shopify Checkout Extensibility 2026 — 15秒快速解析

• 截止日期已过：2025年8月28日。旧版 checkout.liquid 系统已废弃。

• 当前受损功能（2026年4月）：“谢谢”和“订单状态”页面上的 Pixel 和分析、未迁移的 Additional Scripts，以及所有 checkout.liquid 自定义设置。

• 自2026年1月起自动升级：Shopify 一直在自动迁移商店，无需确认。您的商店可能已经启用了新系统。

• 谁需要采取行动：每个未确认启用 Checkout Extensibility 的 Plus 商店。每个带有未迁移 Scripts 的商店。每个在购买后页面上带有自定义 Pixel 的商店。

• Scripts 截止日期还剩62天：Shopify Scripts 将于2026年6月30日停用。如果您还没有开始迁移，这是您目前最紧迫的待办事项。

Shopify checkout extensibility 自2025年8月以来一直在暗中损坏商家的追踪系统——无声无息，且代价高昂，在您深入研究 Events Manager 之前，这看起来就像是广告表现不佳。现在是2026年4月，这仍然是 Plus 商店中最常见且未被诊断的收入问题。

您的 GA4 显示的 ROAS 毫无逻辑。您没动过的广告系列转化率仅为一年前的一小部分。代理商说素材没有问题。账户里什么都没变。预算完全相同。

实际情况是：迁移任务一直堆积在您的积压工作中，2025年8月的截止日期过了，Shopify 在某个时间点自动升级了您的商店。您的 Pixel 仍在触发——但由于缺少 PII，您的广告平台无法将转化归因到具体用户。

一家年销售额数百万美元的 DTC 服装品牌在单个季度内，Facebook ROAS 从 4.2x 降至 1x 以下。广告没有变。追踪变了。完成迁移三周后，ROAS 重新回到了 3x 以上。

本指南涵盖了全貌：2025年8月截止日期后损坏了什么、自动升级如何运作、确切的迁移步骤，以及2026年6月30日 Scripts 停用前还需要做些什么。

Checkout Extensibility 时间线（简版）

Shopify 的 Checkout Extensibility 推广分为两个已完成的阶段，还有一个仍在进行中的截止日期——Shopify Scripts——距离现在还有62天。 以下是2026年4月对 Plus 商店至关重要的每个里程碑：

2025年8月的截止日期导致大多数商店的追踪失效。2026年6月30日的 Scripts 截止日期将使任何仍在运行基于 Script 规则的 Plus 商店的折扣和运费逻辑失效——还剩62天，这需要您现在立即关注。

2025年8月截止日期之后发生了什么变化

2025年8月截止日期一到，有三样东西立即失效或被锁定，这三者都会直接或通过报告影响收入。

您的 Additional Scripts 字段被锁定。 打开 Settings → Checkout。在旧版结账页面上，Additional Scripts 字段可见但为只读。截止日期到来时那里的任何 Pixel 和脚本都被冻结——您能看到它们，但无法修改。

PIO 被旧版追踪切断。 Shopify 停止向旧版“谢谢”和“订单状态”页面上的追踪脚本传递个人身份信息（邮箱、电话、姓名、地址）。您的 Pixel 仍在 checkout_completed 上触发——但没有 PII，广告平台无法将转化与用户匹配。Meta CAPI 无法对其进行归因。GA4 将其记录为匿名会话。转化确实发生了，但归因消失了。

checkout.liquid 自定义停止工作。 任何在 checkout.liquid 中构建的视觉变化——品牌元素、自定义进度指示器、追加销售板块——都已失效。如果 Shopify 的自动升级已经应用到您的商店，您的结账页面可能已经变成了默认样式。

Shopify 谢谢页面自动升级（2026年1月）

自2026年1月以来，Shopify 一直在自动将仍在使用旧版结账页面的商店迁移到 Checkout Extensibility——会发送通知，但无法选择退出。 您会收到一封带有排期窗口的电子邮件。您无法阻止它。

自动升级是一种“尽力而为”的迁移。官方 Shopify 渠道应用集成会保留。自定义 Pixel、GTM 容器和 checkout.liquid 逻辑则不会保留。

自动升级处理的内容：

• 将“谢谢”和“订单状态”页面切换到 Extensibility 系统

• 迁移支持新系统的官方 Shopify 应用集成

• 为您的商店启用 Checkout Editor

自动升级不处理的内容：

• 自定义 Pixel 逻辑——需在 Settings → Customer Events 中重建

• GTM 容器——与新的沙盒不兼容

• 来自 checkout.liquid 的视觉自定义

• 依赖直接 DOM 访问的第三方脚本

注意： 自动升级后，PII 会恢复。您的 checkout_completed Pixel 事件将再次包含客户邮箱、电话和地址——通过 Web Pixel API 传递。目标是在不产生数据空白的情况下顺利过渡到该阶段。

为什么损坏的追踪会让你损失资金

损坏的结账追踪不仅会产生错误的数据，还会导致每一个下游决策出错。 预算分配、素材测试、受众定位、LTV 建模：所有这些都依赖转化数据。当 Pixel 无法归因转化时，您的广告平台就会朝着错误的信号进行优化。

在每月5万美元的广告预算下，30天的数据追踪空白不是分析上的不便支持，而是实际的资金损失。危险之处在于它的隐蔽性：广告系列仍在运行，费用一直在花，而唯一表明有问题的信号就是与实际不符的 ROAS 数据。

如何迁移到 Checkout Extensibility（分步指南）

迁移需要1天到1周的时间，具体取决于您运行的自定义 Pixel 和脚本数量。 以下顺序可确保在此过程中您的数据保持清洁：

1. 检查您的状态。 Settings → Checkout。“Upgrade”按钮 = 旧版。Checkout Editor 可见 = 已迁移。

2. 首先记录您的 Additional Scripts 字段。 将所有内容复制到文本文件中——每个 Pixel ID、每个 GTM 容器 ID、每个自定义脚本。这是您的迁移清单。在动任何东西之前先做好这一步。

3. 安装官方渠道应用。 Google Analytics → Google & YouTube 应用。Meta Pixel → Facebook & Instagram 应用。这些可以替代 Additional Scripts 里的原生集成，立即恢复 PII 传递。

4. 将剩余的 Pixel 重建为 Custom Pixels。 Settings → Customer Events → Add custom pixel。通过 Web Pixel API 获取 checkout_completed、payment_info_submitted 和其他标准事件。对于任何没有官方 Shopify 应用的平台，使用此方法。

5. 
   

6. 在 Checkout Editor 中重建视觉自定义。 Online Store → Checkout。拖放区块、品牌颜色、Logo、字体印刷。对于大多数 Plus 商店，这涵盖了 checkout.liquid 原来处理的 80% 的视觉内容。

7. 执行升级。 Settings → Checkout → Upgrade。您的追踪已经重建——没有任何数据中断。

8. 运行测试交易。 在每个 Pixel 后台中验证 checkout_completed 是否伴随 PII 触发。在确认完成之前，检查 GA4 和 Meta Events Manager。

提示： 在周中进行迁移，千万不要选在周五。如果发生损坏，您需要团队在当天就能解决问题。

Google Tag Manager 与 Checkout Extensibility

标准 GTM 容器在 Checkout Extensibility 环境里无法工作。 新的结账页面在沙盒化的 iframe 中运行，这会阻止 GTM 依赖的 DOM 访问——来自 checkout.liquid 脚本的自定义 HTML 标签、可见性触发器和 dataLayer 推送都会静默失败。

替代方案：

• Google & YouTube 应用 —— GA4 和 Google Ads 的直接路径，无需 GTM

• 服务端代码管理 —— Elevar、Analyzify 或 Stape 将结账事件路由到服务端，完全绕过沙盒

• Custom pixels —— 在 Settings → Customer Events 中使用 Web Pixel API 重建关键的 GTM 触发器

服务端是最复杂的选项，但能在整个漏斗中提供更好的归因，而不仅仅是结账阶段。

什么可以替代 Additional Scripts、GTM 和自定义代码

迁移后的结账页面品牌与自定义设置

Checkout Editor 涵盖了 checkout.liquid 在视觉上提供的大部分功能——且无需代码。 对迁移最常见的反对意见是“我们会失去自定义的结账外观”，在18个月前这确实是个合理的担忧。但在2026年4月，Checkout Editor 原生就能满足绝大多数标准 Plus 品牌的需求。

无需代码即可控制的内容：

• 在所有结账步骤中自定义 Logo、Favicon 和品牌颜色

• 标题和正文的排版（字体系列、大小、字重）

• 结账容器的背景颜色和图片

• 原生结账各部分之间的自定义内容块——文本、横幅以及由应用支持的 UI

• “谢谢”页面上的确认信息和追加销售板块

仍需要 Checkout UI Extension（开发工作）的内容：

• 与您自己的后端绑定的自定义输入字段

• 基于购物车内容的复杂条件逻辑

• 结账过程中的深度第三方集成

对于大多数 Plus 商店，Checkout Editor 涵盖了 checkout.liquid 80% 的使用场景。剩下的 20% 需要 Extension 扩展，通常需要开发人员2-3天的时间。

Shopify Markets 与国际结账

运行 Shopify Markets 的商家需要按市场逐一测试其迁移。 新系统原生支持国际化，但仍需针对每个活跃区域分别验证特定市场的 Pixel 配置和合规性要求。

针对 Markets 商家需要检查的关键事项：

• 地址验证在不同地区是否正确运行，特别是欧盟格式

• 特定地区的 Pixel 追踪是否根据市场币种和语言正确触发

• 迁移后 GDPR 同意流程和增值税显示是否仍在运行

• 在 Shopify Scripts 中运行的任何特定市场的折扣逻辑是否已记录，以便在6月30日前迁移到 Functions

Shopify Scripts 与 Checkout Extensibility —— 两个独立的截止日期

Shopify Scripts 和 Checkout Extensibility 是两个具有不同截止日期的独立废弃路线——将它们混淆是 Plus 商店目前在规划上最昂贵的错误。

Checkout Extensibility 替代了 checkout.liquid。截止日期：2025年8月28日（已过）。 Shopify 正在积极地对未迁移的商店进行自动升级。

Shopify Scripts 代替了用于自定义折扣逻辑、运费和购物车转换的 Ruby 无服务器运行环境。截止日期：2026年6月30日（距离现在还有62天）。

如果您的商店使用 Scripts 来处理折扣组合、分级运费、B2B 定价或捆绑逻辑——该逻辑将在2026年7月1日完全停止工作。迁移路径是 Shopify Functions：打包为应用的 JavaScript 或 Rust。复杂的 Scripts 设置需要4-8周的时间来进行迁移。

警告： 如果您本周开始，62天的时间足够完成 Scripts 迁移。但如果您等到6月份才开始，那时间绝对就不够了。

有关完整的技术演练，请参阅我们的 Shopify Scripts 迁移至 Functions 指南。

迁移后的购买后订单编辑

完成 Checkout Extensibility 迁移，为在“谢谢”页面上实现更优质的购买后体验扫清了障碍。 在迁移之前，checkout.liquid 脚本和订单确认逻辑常常与购买后工作流交织在一起，这使得添加新功能变得繁琐且容易出错。

在新系统上，“谢谢”页面应用使用 Checkout UI Extensions——这意味着它们的集成不会与您的追踪设置产生冲突。由于这是 Revize 博客，我们需要指明：Revize 与 Checkout Extensibility 完全兼容。几位商家分享说，完成迁移是促使他们最终添加自助服务订单编辑的触发因素——因为“谢谢”页面足够干净，可以在上面进行构建，而不会产生由于追踪设置导致的风险。

有关迁移后订单管理变化的更多信息，请参阅 Shopify Order Management Guide 2026。

总结

Shopify checkout extensibility 迁移不是可选的，也不是未来的事情。 2025年8月的截止日期已在八个月前过去。自动升级自2026年1月起也一直在运行。现在的问题是，您是已经用上了带有干净追踪的新系统，还是仍在等待 Shopify 对您的商店发起排期升级。

对于商家： 今天就检查 Settings → Checkout。如果您还在旧版本上，在 Shopify 设定您的升级窗口之前，记录您的 Additional Scripts 字段并安装官方渠道应用。

对于开发人员和代理商： 仍在进行的截止日期是 2026年6月30日 的 Shopify Scripts。那是更难的迁移——复杂的设置需要4-8周。如果您的客户仍在运行基于 Script 的折扣或运费逻辑，上个月就应该沟通这桩迁移了。

迁移后，您的结账追踪会比以前更好：PII 原生传递，CAPI 归因得到提升，您的 Pixel 能够获取它们原来在旧版 checkout.liquid 上无法稳定访问的第一方数据。

这是本周需要做的事情：

1. Settings → Checkout → 确认您的状态

2. 如果是旧版：记录 Additional Scripts，安装 Google & YouTube 以及 Facebook & Instagram 应用，然后升级

3. 如果已经迁移：在 Meta Events Manager 和 GA4 中验证 PII 是否正常传递

4. 如果正在运行 Shopify Scripts：现在就启动 Functions 迁移——距离 6月30日 还有62天

常见问题解答

我怎么知道我的商店是否还留在旧版结账页面？

转到 Settings → Checkout —— 如果您看到“Upgrade”按钮或已排期升级的横幅，说明您仍在使用旧版。 如果能看到带有拖放板块的 Checkout Editor，说明您已经完成了迁移。Shopify 会在自动升级之前发送电子邮件通知，如果不确定，请检查您的后台通知历史记录。

为什么我的 Facebook ROAS 和 GA4 转化率在2025年8月后下降了？

因为 2025年8月的截止日期导致 Shopify 停止向旧版谢谢页面上的追踪脚本传递 PII，因此 Pixel 虽然会触发，但广告平台无法归因转化。 没有邮箱或电话，Meta CAPI 就无法将 checkout_completed 与用户画像相匹配。GA4 会将其记录为未识别的会话。购买发生了，但归因凭据消失了。迁移后，PII 重新传递，归因即可恢复。

Shopify 的自动升级实际上对我的商店做了什么？

Shopify 的自动升级会将您的“谢谢”和“订单状态”页面切换到 Extensibility 系统，并迁移官方 App 集成——但它无法重新构建自定义 Pixel、GTM 或 checkout.liquid 逻辑。 这些需要手动在 Customer Events 和 Checkout Editor 中重建。您会在排期窗口之前收到一封电子邮件，但无法选择退出。这就是为什么按照您自己的进度手动进行迁移总是更好的选择。

自动升级后我可以回退吗？

不行 —— 一旦 Shopify 完成自动升级，就没有回退选项。 如果您的追踪在升级后失效，只能通过在 Customer Events 中重建 Pixel 来修复——无法恢复到旧版。这是在 Shopify 强制安排窗口之前自行迁移的核心依据：您可以控制时间并可以在上线前测试所有内容。

Google Tag Manager 可以在 Checkout Extensibility 中工作吗？

标准的 GTM 容器在新的结账沙盒中无法运行。 沙盒化的 iframe 会阻止 DOM 访问，因此自定义 HTML 标签、可见性触发器和由 checkout.liquid 注入的 dataLayer 推送都会静默失败。可使用 Google & YouTube 应用来处理 GA4 和 Google Ads，需要完整替代 GTM 时，可使用服务端平台 (Elevar, Analyzify, Stape)。

迁移需要多长时间？

大多数 Plus 商店会在 1-5 个工作日内完成 Checkout Extensibility 的迁移。 使用官方应用配合2-3个 Pixel 的商店，几个小时内就能完成。重度 GTM 自定义和复杂的 checkout.liquid UI 更改则需要将近一周的时间。Shopify Scripts 迁移到 Functions 属于独立路线，复杂设置需要4-8周的时间。

什么是 Web Pixel API？

Web Pixel API 是 Shopify 用于在结账和购买后页面上运行追踪和分析代码的沙盒环境。 与在页面中直接运行任意 JavaScript 的 Additional Scripts 不同，Web Pixels 在隔离的 iframe 中运行，可以访问标准 Shopify 事件（checkout_completed、payment_info_submitted 等），但限制了 DOM 访问。PII 是通过 API 显式传递，而不是抓取获取。在 Settings → Customer Events 处配置自定义 Pixel。

所有 Shopify 计划都可以使用 Checkout Extensibility 吗？

针对核心结账流程的 Checkout Extensibility 仅限 Plus 计划。 标准计划商家之前从未有权访问 checkout.liquid，所以该迁移不以同样的方式适用于他们。虽然对核心结账步骤的 Checkout Editor 依然是 Plus 专属，但“谢谢”和“订单状态”页面的 Extensibility 适用于所有计划。

Shopify Scripts 和 Checkout Extensibility 有什么区别？

它们属于独立废弃时间线上的两套不同系统，许多 Plus 商店需要将它们作为两个独立的项目来处理。 Checkout Extensibility 替代了 checkout.liquid —— 结账页面上的视觉和脚本层。Shopify Scripts 替代了用于折扣、运费和购物车逻辑的 Ruby 运行环境。Checkout Extensibility 截止日期：2025年8月28日（已过）。Scripts 截止日期：2026年6月30日（还有62天）。

6月30日之后，什么将替代 Shopify Scripts？

Shopify Functions 是直接替代方案。 Functions 在 WebAssembly 沙盒中运行，并使用 JavaScript 或 Rust（而非 Ruby）满足相同的使用场景——自定义折扣、运费、购物车转换。它们是以 App 的形式部署，而不是在后台输入的脚本。完整文档和迁移指南请查看 shopify.dev/docs/apps/build/functions。

迁移后，我的购买后 App 还能正常工作吗？

基于 Checkout UI Extensions 构建的 App 可以在新系统上正确运行。 通过 checkout.liquid 或 Additional Scripts 注入脚本的 App，则需要更新到 Extension 模式。在迁移之前，请检查您的 App 更新日志或技术支持文档以了解兼容状态——大多数主流的购买后 App 已经公开了其兼容状态。

相关文章

在您的 Shopify Checkout Extensibility 迁移完成后，以下是顺理成章的下一步：

• 如何将 Shopify Scripts 迁移到 Functions：完整代码教程 —— 6月30日的截止日期是您在此之后的下一个迁移任务

• Shopify 订单管理：2026 完整指南 —— 结账页面迁移后订单工作流发生的变化

• 如何让客户在 Shopify 上取消订单 —— 新版“谢谢”页面上的自助服务选项

• 通用商业协议 (UCP) —— 本次迁移作为其中一部分的原生平台转换

• 高级 Shopify Flow 工作流 —— 与 Shopify Checkout Extensibility 及新系统顺畅协同工作的自动化