Shopify 结账页同源服务端追踪限制与混合路由配置方案

核心要点

• 同源追踪适用于 Shopify 店面页面，但结账页面的执行环境和可用 API 有所不同，往往需要单独配置。

• 在 Shopify 结账流程中，URL 属于同一域名并不意味着请求就真正符合同源策略。

• 当 fetch 或 XHR 请求指向自有域名时，Shopify 的 Web Pixel 沙盒会直接将其拦截。

• 在 fetch 和 XHR 因沙盒限制而失效的情况下，Image 和 beacon 请求或许依然可行。

• Service worker 无法稳定绕过 Shopify 结账页面的追踪限制。

• 最稳妥的 Shopify 配置是采用混合模式：店面使用同源域名，结账环节则切换为子域名。

• 结账页面的追踪需要借助路由逻辑，动态切换追踪端点。

同源方案通过主站自身域名转发服务端追踪请求，而无需单独设置追踪子域名。 

同源策略界定了两个 URL 何时属于同一个 Web 源。一个源包含三部分：协议（scheme）（https:// 或 http://）、主机名（hostname）（如 shop.example.com）以及端口号（port）（例如 HTTPS 的 443）。

URL 路径是独立的组成部分，并不参与源的判定。例如，以下两个 URL 即属同源，即便后一个带有路径：

• https://shop.example.com/

• https://shop.example.com/metrics

同源方案非常适合服务端追踪配置，因为请求全部经由网站自身域名转发，有助于维持第一方 Cookie 的有效性，同时减轻浏览器隐私限制带来的影响。 

然而，URL 层面上的同源并不代表所有浏览器环境或平台都会放行发往该端点的请求——本指南将深入探讨的 Shopify 结账页面就是典型例子。

与店面相比，Shopify 结账页面的追踪脚本运行在一个受限严格的环境中。根据具体的结账实现方式，脚本在发起网络请求、调用浏览器 API 以及跨源交互时，都可能会受到限制。 

这些限制既约束了结账沙盒内的追踪部署，也左右着各类追踪方案的实际运作机制。

追踪人员最常遇到的一个限制是：在测试配置时，默认无法在 GTM 预览模式中看到结账事件。这是因为 GTM 容器代码被加载到了结账沙盒中，导致 GTM 预览模式无法定位容器。若想在结账流程中启用 GTM 调试，必须在当前浏览器会话的父级页面中加载追踪代码。借助 Stape GTM Helper Chrome 扩展程序，只需点几下即可完成该设置。

GTM 预览受限只是 Shopify 结账环境区别于店面页面的一个缩影。在底层，沙盒限制还会影响浏览器处理跨域通信的方式，进而波及基于同源域名的追踪方案。

Shopify 结账页面中的同源域名问题

同源端点在店面追踪中表现良好，但在 Shopify 结账流程中却会受到限制。

当 Shopify 结账像素试图向同源端点发送请求时（例如格式为 https://shop.stapedesk.com/metrics/g/collect 的 GA4 事件），浏览器控制台可能会弹出类似于下图的报错：

在我们的测试中，该请求因报错 RestrictedUrlError 失败。这表明结账像素试图向店面所在的同源域名发送 XHR/fetch 请求，但在浏览器实际发出该请求之前，就被 Shopify 像素运行时直接拦截了。 

Shopify 官方文档对此怎么说？

Shopify 社区中已有关于该错误的反馈，但截至目前，Shopify 文档并未明确说明具体是哪条规则阻止了结账阶段的同源请求。

不过，从 Shopify 披露的底层架构信息中，我们可以找到原因。如前文所述，根据 Shopify 关于 Web Pixels 的文档，Shopify 会在访客浏览器的沙盒环境中加载 Web Pixels。

这意味着，结账像素的执行权限与直接注入 Shopify 主题的普通脚本并不相同。该像素在受 Shopify 控制的运行时中运行，而这个环境会对浏览器 API 和网络请求施加限制。

因此，Web Pixel 发出的请求会根据像素所在沙盒环境的规则进行校验，而不仅仅是看目标 URL（接收请求的网址）。

虽然目标 URL（你的同源域名）与店面属于同一个域名，但该请求并非由普通的店面 JavaScript 发起，而是来自 Shopify 的 Web Pixel 沙盒环境。

核心在于：“同域名”并不等同于“同执行上下文”。从商家店面角度看属于同源的 URL，从 Shopify 的 Web Pixel 沙盒内访问时仍可能受到限制。

测试 Shopify 结账像素的请求限制

以下测试表明，Shopify 的 Web Pixel 沙盒并不会一刀切地封锁发往店面域名的所有请求。相反，限制主要针对编程式 HTTP 请求，例如 fetch() 和 XMLHttpRequest。

测试期间，我们在一家 Shopify 店铺的两种配置下触发了结账事件——同源端点与独立追踪子域名。不同请求类型的对比表现如下：

这解释了为什么基于图片像素的追踪方案（例如多为 GET 请求的 page_views）依然有效，而通过 fetch() 向同源端点发送数据的服务端追踪方案却会失效。 

看起来 GET 和 beacon 请求只是没有走 Shopify 对 XHR 和 fetch 封装的处理层。假设这只是官方的疏忽，未来随时可能在毫无通知的情况下被限制。当然，这也只是一种推测。

Service Worker 是一种独立于浏览器主页面运行的 JavaScript 文件，常用于实现离线支持、资源缓存以及网络请求拦截等功能。 

在 Shopify 结账追踪的场景下，它能够拦截网络请求，即使页面操作被打断也能协助处理请求。Google Analytics 4 正是利用这一方案来减少追踪请求的丢失。

但由于你无法明确控制哪些事件会通过 worker 发送，而且这也不是 GA4 推出该特性的初衷，因此不能依赖它们来跟踪 Shopify 的结账事件。你确实可能捕获到少数几个结账/购买事件，表面上看好像一切正常，但这纯粹碰巧——只要多测几次就会发现问题。 

即使 Shopify 自定义事件沙盒没有拦截同源请求，受制于 Shopify 的沙盒环境（没错，又是它），其实际收益也非常有限。 

同源方案的一大优势在于，即使在 ITP 等隐私限制环境下，也能按预设的生命周期来设置 Cookie。但在结账沙盒中，跟踪请求根本不会携带这些 Cookie；同样，通过响应来设置 Cookie 也行不通。正因如此，我们的 Data Tag 提供了 Send Common Cookies 选项，可以将 Cookie 直接写入请求有效载荷中。

结账沙盒 iframe 在配置时没有包含 allow-same-origin，因此浏览器会赋予它一个不透明源（opaque origin），导致其源始终显示为 null。哪怕这个 iframe 来自店铺自己的域名，且无论请求是否显式设置了“credentials: include”或“mode: cors”，情况都是如此。结果就是，浏览器在处理 Cookie 时会把这些请求视为跨站请求。通俗来说，就是浏览器会将相关 Cookie 视为第三方 Cookie。

对于配置了服务端跟踪的 Shopify 店铺，推荐采用混合方案：

• 在店面（storefront）使用同源方案；

• 在结账流程（checkout）使用标准子域名路由。

对店面而言，同源跟踪能带来预期的优势（优化第一方请求路由、改善 Cookie 处理并提高跟踪稳定性），因为跟踪请求是在与网站完全相同的域名环境下发出的。

然而，Shopify 结账流程存在各种限制，无法像店面那样发挥同源方案的效果。因此，使用标准的子域名路由更为合适。通过专属的跟踪子域名来路由跟踪请求，可以规避这一特定限制，确保请求顺利送达跟踪端点。

店面的同源域名配置

Shopify 店面的同源方案可以通过不同的 DNS 和基础设施服务商来实现，具体配置取决于你所使用的服务商。

例如，Cloudflare 提供了 Orange-to-Orange (O2O) 集成，允许流量同时流经商家的 Cloudflare Zone 和 Shopify 的 Cloudflare 基础架构。这样既能让你对流量处理拥有更多控制权，又能保证你的域名始终作为流量入口。

其他服务商可能通过反向代理、CDN 或自定义主机名功能提供类似的解决方案，但具体的配置步骤和支持的功能因平台而异。

结账流程的子域名配置

针对 Shopify 结账流程，请使用标准的子域名配置。

与同源配置不同，子域名配置需要添加 DNS 记录，将子域名解析到你的服务端跟踪服务商。 

GTM 标签与变量配置

配置好店面和结账流程的跟踪域名后，你还需要设置 GTM，以便将事件数据发送到服务端容器。

1. 配置 Data Tag 和 Data Client

在你的网页端 GTM 容器中，添加并配置 Data Tag 模板。该代码会将事件数据及配置好的参数发送至服务端 GTM 容器。

在服务端 GTM 容器中，安装并配置 Data Client。Data Client 负责接收并解析来自 Data Tag 的请求，这样服务端 GTM 代码就能使用传入的事件数据了。

2. 在 Data Tag 中启用“Add Common Cookies”

启用该选项后，常用的浏览器 Cookie 会随事件数据一同发送。这些 Cookie 对归因分析、用户识别和转化跟踪至关重要，尤其是在 Shopify 结账事件运行于沙箱隔离环境、无法直接访问店面数据的情况下。

请为所有需要在结账页面触发的 Data Tag 启用此选项。

3. 配置正则表达式表格（RegEx Table）变量

域名选择逻辑由网页端 GTM 容器处理，因为这一决策必须在请求发出前完成。随后，服务端容器会接收来自选定端点的请求，并通过配置好的 Client 和代码继续处理。

你可以使用正则表达式表格（RegEx Table）变量来实现这一逻辑。

3.1 配置方法：前往 web GTM 中的 Variables 板块 → 点击 New → 在变量配置中选择 RegEx Table 。

3.2 为该变量选择一个 Input Variable（输入变量）。 

具体的判断条件取决于你的 Shopify 网站流程。在我们的示例中，结账页和感谢页虽然位于同一域名下，但 Page Path 不同。 

如需详细了解如何确定适用于你 Shopify 网站的 Input Variable，请点击下方展开内容：

指定 Input Variable（在我们的示例中为 Page Path）。

3.3 输入匹配规则与对应的输出值。 

针对我们的业务流程，可以使用以下正则表达式：

^/checkouts.*

匹配以 /checkouts 开头的所有字符串，无论其后跟什么内容。

在 Output 中，填入沙箱环境中用于跟踪的子域名。

如果某个值需要在多个 GTM 实体中复用，建议先将其定义为常量变量，随后在需要的地方直接调用。

勾选 Set Default Value 复选框，并将包含同源域名的变量填入 Default Value。

变量配置示例如下：

保存更改。

4. 使用正则表达式表格变量更新代码

将代码中所有写死的同源 URL，或是包含同源 URL 的变量，统一替换为这个正则表达式表格变量。 

该变量会根据当前页面环境自动返回正确的域名，确保来自店面和结账流程的请求都能路由至对应的端点。

示例如下。请检查网页端 GTM 容器中的代码，并根据需要完成更新。

验证跟踪配置在店面和结账环境中是否均能正常运作。

如需查看调试详情，请点击下方对应的折叠面板：

Shopify 的结账跟踪一直是个难点，在服务端跟踪场景下尤为棘手。同源方案虽然能在店面页面发挥全部优势，但结账环境存在沙箱限制，导致同源方案无法直接正常生效。

目前最理想的解决方案是调整追踪架构，主动适配 Shopify 的环境：在能体现同源优势的地方保留同源配置，结账事件则改用标准的子域名方案。只要 GTM 配置得当并做好测试验证，就能确保整个用户转化链路的数据追踪依然精准。

请持续关注 Stape 的后续动态。我们一直在不断优化服务端追踪方案，紧跟 Shopify 生态的最新变化。我们深知精准追踪对您的业务至关重要，也正在积极探索更理想的应对策略，后续有了最新成果会第一时间与大家分享！