Shopify店铺活动日志2026改版：谁在何时改了什么，一页查清

Shopify店铺活动日志改版了什么：从250条到18个月的审计跨度

本节聚焦改版的事实边界：新版Store activity log到底记录什么、保留多久、从哪里进入。对多店铺、多员工协作的中国跨境团队来说，这是一次把“谁改了价格、谁动了折扣、谁换了主题”从口头追问变成可检索记录的基础设施升级。

根据Shopify官方公告，新版日志入口位于Settings > General > Store activity log。它把原先分散在不同页面的变更集中到一处，覆盖商品、订单、折扣、主题、应用、员工、支付与店铺设置等对象。与旧版相比，最直接的变化是保留范围：旧版仅保留最近250条事件，新版最长保留18个月的变更记录。

公告同时给出了两个容易被忽略的边界：

• 历史不是无限回溯：记录起点是各类变更“开始被记录”的时间，即本次发布前不久；此前的变更不会出现在日志中。
• 并非所有后台操作都被记录：公告明确“Not every action in the Shopify admin is recorded yet”，即覆盖范围仍在扩展中。

此外，后台多个页面（包括商品、订单、折扣、礼品卡、集合与域名）新增了View activity操作，点击后直接打开已按该对象预筛选的日志。这意味着排查某个商品被改价时，不必先进入全局日志再手动筛选。需要说明的是，公告未给出该功能的生效日期，仅给出发布日期2026年11月13日，卖家应以自己后台实际可见状态为准。

谁改了价格和折扣：操作人归属与权限门槛的实际影响

本节讨论新版日志对团队协作与权限管理的直接影响。跨境卖家常见的组织形态是运营、投放、客服、外包协作者与多个应用并存，一旦出现价格错误、折扣叠加或主题被改，追责与止损速度直接决定损失大小。

新版日志的核心能力是“每条变更归属到做出变更的主体”：员工、协作者或应用；若变更由Shopify员工操作，则归属到Shopify。公告特别提示，部分通过应用完成的变更不记录操作人，日志仅显示应用名称。这一点对中国卖家尤为关键——大量店铺安装了改价、折扣、订单同步、ERP对接类应用，当变更来自应用而非人工时，日志只能告诉你“是哪个应用做的”，无法告诉你“是谁在应用里点的”。

权限方面，公告给出的规则是：

• 新日志面向店主开放；
• 员工需同时具备Manage settings与Edit两项权限，例如Administrator与Organization administrator角色；
• 其他拥有旧日志访问权的员工，暂时继续使用旧版日志。

实操提示：若你的运营主管只能看到旧日志，问题往往不在功能未上线，而在权限组合不满足“Manage settings + Edit”。授权前应评估该权限组合带来的设置修改能力，避免为查日志而过度授权。

对多店铺矩阵卖家，建议把“谁有新版日志访问权”纳入岗位权限表，与改价、改折扣、改支付设置等高危操作权限一并复核，而不是单独开一个“能看日志”的口子。

按字段与时间筛选变更：跨境团队排查问题的实操路径

本节讲怎么用筛选与详情能力解决具体问题。公告显示，新版日志支持按操作人、操作类型、资源、变更字段与日期范围筛选；选中某一行可查看变更详情，包括在可得情况下的前后值。这组能力组合起来，才能支撑真实的排查场景。

结合中国卖家的日常运营，可以落地为以下几条路径：

• 大促前价格异常：按资源定位到具体商品，再按日期范围锁定大促前48小时，查看价格字段的前后值，确认是人工改价还是应用同步导致。
• 折扣叠加或失效：按资源与操作类型筛选折扣相关变更，核对操作人；若归属为应用，则转向该应用的执行日志排查。
• 主题或店铺设置被改：按资源筛选主题与店铺设置变更，结合操作人判断是内部成员、协作者还是应用。
• 订单与支付相关变更：公告将订单与支付列入覆盖范围，但未逐项说明记录粒度，实际排查应以后台可见记录为准。
• 从对象页直达：在商品、订单、折扣、礼品卡、集合、域名页面使用View activity，直接得到预筛选结果，减少手工筛选误差。

需要克制预期：公告明确并非所有后台操作都已被记录，且历史起点有限。因此日志适合作为“近期变更追溯与协作纠错”工具，而不能替代卖家自建的财务对账与订单核对流程。对于跨时区团队，建议统一以店铺后台时区口径沟通日期范围，避免因时区差异漏查。

把活动日志纳入店铺治理：中国卖家的应对清单

本节给出可执行的应对建议，把一次平台功能更新转化为团队治理动作。新版日志的价值不只在“查得到”，更在于让高危操作有迹可循，从而倒逼权限与流程规范化。

建议按以下顺序落地：

• 第一步，确认可见性：由店主核对自身与核心岗位是否已能看到新版日志；对仍使用旧日志的员工，评估是否需要调整权限组合，并记录调整原因。
• 第二步，划定高危操作清单：至少覆盖价格、折扣、支付设置、主题、员工权限与应用安装。对每一项明确“允许谁操作、变更后是否需要二次确认”。
• 第三步，建立周度抽查机制：利用日期范围筛选，每周抽查高危资源的变更记录，重点看归属为应用的变更是否符合预期。
• 第四步，区分人工与应用责任：对改价、折扣类应用，要求服务商或内部技术同学提供应用侧执行记录，弥补日志“只显示应用名”的缺口。
• 第五步，保留期管理：18个月是上限而非承诺的完整历史，公告明确历史起点为记录开始之时。对需要更长留存的审计需求，应自行导出或另行归档关键变更。

同时提醒两点边界：公告未说明该功能的具体生效日期与地区差异，卖家应以后台实际状态为准；公告也未承诺记录全部后台操作，因此不应把日志当作唯一审计依据。把日志、应用执行记录与内部操作规范三者结合，才是可落地的治理方案。