EN
Shopify 知识库 · 指南

Shopify 订单追踪页面配方

从 page template type 出发,说明订单追踪说明页如何引导顾客使用订单状态页、发货邮件与 Shop app 查询发货状态,处理无追踪号与延迟,划清主题与结账的边界,并对订单号加邮箱查询的隐私风险标注合规确认。

订单追踪页面的任务是让已经下单的顾客知道“我的包裹现在到哪了、去哪里查、查不到怎么办”。顾客进入时已有订单,但可能找不到订单状态页链接,或收到的邮件里没有追踪信息。本文的落点是 page template type 的追踪说明页:一页说明入口与预期,把顾客送到真正显示状态的地方。逐单的状态不是页面静态内容,也不由主题模板渲染。

追踪发生在哪里

官方订单追踪页写明,顾客可通过三处追踪:订单状态页、通知邮件、Shop app。三者都依赖发货时录入的追踪号。

渠道官方页面所写页面的作用
订单状态页顾客可通过账户登录、发货确认邮件里的链接,或订单号加邮箱或手机验证进入;显示配送更新与追踪信息,受支持承运商可显示实时位置说明有哪几种进入方式
通知邮件订单确认、发货确认与发货更新三种邮件模板可带订单状态页链接;自定义过的模板需手动加入 {{ order_status_url }};短信模板也含链接说明去邮箱找什么邮件
Shop appTrack with Shop 默认对所有店铺启用;商家须提供有效追踪号与承运商;订单状态页与邮件中可出现追踪按钮;顾客可用 Shop app 追踪任何有效追踪号只作可选入口,不写成必须安装

订单状态页与结账不属于主题模板。官方模板类型表没有订单状态与结账;订单状态页通过 checkout and accounts editor 定制;开发侧的 Customer account UI extensions 提供 customer-account.order-status.* 目标,能在订单状态页渲染内容。因此改订单状态页的外观不走 Theme Editor,见 Template type 与 alternate template与购买旅程。本页只是主题里的 Page,承载说明与入口。

页面内容清单

类别优先级页面内容回答的问题来源边界
编辑核心去哪里查用哪个链接或邮件查询上表三个渠道中店铺实际启用的
编辑核心什么时候能查到下单后多久有追踪信息处理时间与运输时间分开,见配送信息;预估不写成承诺
编辑核心状态含义每个状态代表什么平台状态名与含义,见下文,不自造状态
编辑核心查不到或延迟怎么办没有追踪号、久未更新怎么办店铺真实处理规则,含联系入口
编辑可选拆分发货说明一单几个包裹怎么看每个包裹各有追踪号才成立,见下文
编辑可选联系入口找谁、需要提供什么客服渠道
编辑可选追踪相关 FAQ改地址、丢件等重复问题FAQ子集
运行时由平台页面显示具体订单的状态与追踪号我这一单现在怎样订单状态页、邮件、Shop app;本页不复制、不缓存

状态名以官方订单状态概览为准:Confirmed(已下单未发货)、On its way(已标记履约)、Out for delivery、Delivered、Attempted delivery(承运商投递失败)。页面用店铺自己的语言解释,但不新增平台没有的状态。

页面组合

顺序是待验证假设,不是必备清单。

序模块回答的问题缺失时
1页首入口说明去哪里查、需要什么不可缺;只写店铺实际可用的入口
2状态含义看到的状态是什么意思无自定义解释时链接官方术语,不留空表
3无追踪号与延迟处理查不到怎么办不可缺;写具体条件与下一步
4拆分发货说明多个包裹怎样看店铺从不拆分发货时删除
5联系入口找谁、提供什么页脚已有入口时只放一条链接
6FAQ 子集重复问题无真实高频问题时删除

最小成立组合:页首入口说明 → 无追踪号与延迟处理 → 联系入口。

不应默认出现:静态的“预计 X 天送达”承诺、编造的实时进度条、替代订单状态页的假查询框、与追踪无关的促销与推荐商品。

没有追踪号或延迟时的退化:官方页面写明,没有追踪号的订单会一直停留在“On its way”,直到商家手动标记已送达;使用不受支持的承运商时,订单状态页显示指向承运商网站的追踪号,而不是 Shopify 上的实时状态。页面应据此写清:哪些服务不带追踪、状态长时间不变时可联系客服、需要提供订单号。至少包含一个可用联系入口,超时后由谁跟进要与客服渠道一致。

内容 × 展现形式

内容首选形式适用条件退化方式
查询入口List(有序,按渠道)有两个以上入口一段说明加链接
状态含义Table(状态、含义、你可以做什么)状态解释有店铺特有内容链接官方术语
发货到送达的阶段Timeline阶段顺序影响理解有序列表
联系入口文字加链接,或 Inline Form表单由店铺自行提供并可回复邮箱地址
无追踪信息段落加联系入口店铺有该类订单删除

状态与退化

状态页面级处理
顾客未登录或没有邮件写明可用订单号加下单邮箱或手机验证,或到邮箱找发货确认邮件
订单尚未发货说明 Confirmed 阶段没有追踪信息,并给出处理时间口径
无追踪号见上文,不承诺实时更新
拆分发货每个包裹各有追踪号才能各自追踪;官方页写明同一订单可加多个追踪号,但须同一承运商,跨承运商拆分的处理方式未核验
状态久不更新提示联系客服,不猜测原因
不支持的承运商说明将跳转承运商网站
关闭 Track with Shop 或顾客未使用 Shop app页面不把 Shop app 写成唯一入口

自建追踪页与查询表单

Shopify 官方入口已经覆盖大多数需求,优先说明它们,不自造一套。确需在 Page 之外做交互式查询时,本文只写读到的官方能力,不评价或推荐任何第三方应用:

  • 官方允许在订单状态页用 Customer account UI extensions 的 customer-account.order-status.* 目标渲染内容,在页内增加信息,而不是另建页面;
  • Admin GraphQL 的 FulfillmentTrackingInfo 提供 company、number、url,访问需要 read_orders 等订单读取范围。这类凭据属于服务端,不能写入主题或浏览器脚本;
  • 把顾客输入的订单号与邮箱提交给自有服务后回显状态,是自定义开发或应用场景。Page 模板本身不提供订单查询能力,此类方案的验证方式与数据责任要另行核验。

隐私(需要合规确认):订单号加邮箱的查询把订单信息交给不同的验证方式。官方订单状态概览写明,公开信息有限,而地址、支付方式与追踪号等敏感信息需要验证;同一浏览器、不同浏览器的免登录期限不同。是否需要在自建方案里限制错误次数、是否记录查询日志、各地区如何评估此类披露风险,未核验,需要合规确认;页面不得在错误提示里暴露“该订单存在但邮箱不匹配”一类信息,这是编辑建议,不是平台行为。

Shopify Theme 实现

层次已核验的机制 / 建议职责
资源Page 保存说明文字;具体订单数据不在 Page 里
Template官方 Page 模板页:page 模板渲染 About us、Contact us 这类信息页;默认 page.json 即可,通常不需要 alternate,规则见Template type 与 alternate template
Main Section输出 Page 标题与正文;JSON 模板中的 HTML 与 Liquid 必须放在被引用的 Section 内
Sections入口说明、状态含义、无追踪处理、联系入口分成可排序模块
Blocks单个渠道、单个状态、单个 FAQ
Settings内容选择与布局;不开放“显示实时进度”这类平台没有的开关
订单侧配置追踪号录入与邮件模板在后台,订单状态页在 checkout and accounts editor;本页不代管这些配置
数据来源逐单状态来自订单状态页与邮件;页面只放链接与文字

履约与追踪号的后台操作、部分履约与异常定位,见履约与配送;后台订单状态含义见订单与付款状态。顾客账户与后台身份的区别见客户账户。

什么时候删掉这一页

有下列情况之一,页面可以缩为页脚一条链接或整页删除:

  • 全部订单由带追踪的服务发货,且发货邮件已经含有订单状态页链接和清晰说明;
  • 顾客的追踪问题极少,FAQ 与联系页已能承接;
  • 页面只能写出“请联系我们”,没有任何店铺特有的说明。

发布检查

  • 用测试订单走完录入追踪号、发送发货邮件、点开订单状态页的流程,确认页面所写入口与实际一致;
  • 自定义过邮件模板的店铺,确认包含订单状态页链接;
  • 无追踪号订单的状态与页面说明一致;
  • 页面没有承诺实时更新或固定送达日期;
  • 联系入口可用,所需信息与客服流程一致;
  • 配送时效说法与配送信息、结账实际显示一致;
  • 若自建查询,隐私与数据保留已由负责人评估:需要合规确认。

待继续完善

  • 未在测试店铺核对订单状态页、邮件与 Shop app 的实际表现;
  • 承运商支持清单、跨承运商拆分发货的追踪、Track with Shop 的国家范围只读到摘要,未逐项核验;
  • 订单状态页免登录期限来自帮助页摘要,需以官方页当前措辞复核;
  • 缺少标注为虚构的追踪说明页样稿。