Shopify 今日动态：Collection Sources API 重构商品运营模型，Sign in with Shop 向店面应用开放
今天的内容覆盖了平台 API 的重大更新、合作伙伴基础设施的简化，以及多项值得关注的合作案例。最值得开发者注意的是新的 Collection Sources API 和 Sign in with Shop 的通用化——两者都直接改变了应用与店面交互的方式。
全新 Collection Sources API：更灵活的商品运营模型
告别智能/自定义二分法
Shopify 集合功能长期分为自定义集合（手动选择）与智能集合（条件自动填充）两种模式。新模型打破了这一限制，引入"来源"（source）概念——来源将产品或变体添加到集合中，可组合使用。
新模型支持五类来源：自动化条件、手动选择、排除项、其他集合引用，以及应用创建的可共享来源。商家可以先用条件生成集合，再手动精修，排除特定产品或集合，无需维护多个独立列表。
变体级定位
集合现在可以精准指定到特定变体，而非仅限整个产品。这对时尚、服饰类商家的价值尤为直接：情人节集合可以只包含红色变体，加大码促销可以只定位 XS 和 XXL 变体。对店面、搜索、筛选类应用的开发者而言，变体感知的集合为更精准的页面体验创造了空间。
应用来源的贡献途径
评论应用知道哪些产品评价高，订阅应用知道哪些产品符合订阅资格——但此前应用缺乏将这些信号注入原生集合的干净途径。
新模型下，应用可以创建和更新可共享来源，商家决定在何处使用，并可以与自己维护的条件、手动选择、排除项组合。Shopify 会在目录数据变化时自动评估组合后的来源，应用无需不断重写商家拥有的产品列表。
迁移要点
新模型已在 GraphQL Admin API 2026-07 中可用。现有的自定义集合和智能集合继续工作。重要提醒：2026-07 之前的 API 版本无法表示新模型的集合，这些集合会被过滤掉。 如果你的应用读取、写入、渲染、同步或检查集合成员关系，需要更新到 2026-07。
Sign in with Shop 向店面应用开放
身份识别层的通用化
Sign in with Shop 此前仅用于潜在客户信息捕获和客户账户，现在已成为任何需要识别买家身份的店面应用（心愿单、缺货提醒、忠诚度计划、评论等）的即插即用认证组件。
三个组成部分：
- 开发者后台自助 OAuth 客户端设置——Shop API 与 Storefront API 和 Admin API 并列，使用相同凭证
- 即插即用 SDK——嵌入店面应用 UI，处理登录流程、用户同意和会话创建
- 可路由的识别信号——读取 Shop 是否已识别该商店的某位买家，显示"以 [姓名] 身份继续"按钮而非完整登录流程
设计逻辑：会话复利
Shop 会话的积累有复利效应：每次集成捕获一个 Shop 会话，都会提高后续所有交互界面（包括结账）的买家识别率。同一商店中第一个合作伙伴应用完成认证后即创建会话，其他应用无需再次提示，仅需为新增权限触发用户同意。
集成建议
官方给出四条经验法则：
- 增量方案，而非替代方案——对已使用 Shop 的购物者，Sign in with Shop 转化率更高；但仍有大量买家偏好邮箱登录
- 不要在首页加载时自动触发——在买家需要已知身份的操作时再显示按钮
- 为共享会话做规划——处理买家已通过其他应用登录的情况，只请求增量权限
- 测试未认证路径——确保应用能优雅降级回退到现有流程
官方估计大多数团队一个 sprint 内可完成集成。
合作伙伴组织与 RBAC 全面上线
三项联动功能
- Partner Organizations：Partner 组织采用与商户相同的组织模型——一名 Organization Owner、多名 Organization Admins，Dev Dashboard 新增 Organization Settings
- 基于角色的访问控制（RBAC）：七个系统角色覆盖构建者组织的典型结构，支持自定义角色，同一用户可分配多个角色（权限叠加）
- Dev Dashboard 统一管理：开发商店、客户转让商店和协作者商店全部收录于 Dev Dashboard，无需切换仪表板
七大系统角色速览
| 角色 | 范围 |
|---|---|
| Organization Owner | 完全控制权，每组织仅限一名，可转让所有权 |
| Organization Admin | 与 Owner 权限相同，但不能转让组织 |
| Organization User Admin | 管理团队成员，不能创建或编辑角色 |
| Store Admin | 对开发商店或客户转让商店有完全构建权限 |
| Store User Admin | 管理特定商店的用户 |
| App Developer | Dev Dashboard 访问权限，用于应用构建和测试 |
| Collaborator Store Access | 访问商户授权的协作者商店 |
迁移预期
无需任何操作，3 月 30 日起自动迁移。现有多个所有者中主要所有者保留该角色，其余自动转为 Organization Admin。所有待处理的用户邀请将被取消，需要手动重新添加。
Partner Dashboard 的付款、应用分发、主题和推荐等功能保持不变。
2026 Shopify Build Award 获奖者揭晓
四个类别，七组获奖者
店面类：Human NYC（Wendywin 眼镜品牌，杂志式阅读体验）、Commerce UI（Lupine 店面，原生 Liquid 构建 B2B 功能）、Unlikely（Yse 无头构建，追求移动端原生质感）
应用类：Smile（忠诚度应用，构建了面向其他开发者的公开 API）、Discount Kit（折扣应用，折扣叠加逻辑原生构建于 Shopify Functions）、Easyteam（员工管理工具，从在线店铺切入实体 POS）
社区类：Zapiet 联合创始人 Emili Horncastle（首任社区奖得主，组织全球合作伙伴聚会）
商家影响力类：Elephant Room 与 Prosper Digital 联合获奖（帮助 Lioness 五年内线上收入提升约 140 倍，六周内总销售额提升 113%）
Ask Phill 的多品牌整合方法论
统一代码库，逻辑层解耦
Ask Phill 的核心方案是集中式 Shopify 代码库为多个品牌店面提供动力，通过专有的"逻辑层"（logic layer）处理品牌间差异——需求差异通过配置而非独立代码分支解决。
成果数据：开发效率提升 40-70%，缺陷减少 30-50%，新品牌上线从数月缩短至数周。已实施案例包括 Obey Clothing（3 品牌）、ID&T（8+ 品牌）、North Action Sports Group（4 品牌）。
80/20 框架：80% 共享基础设施（核心电商功能、技术架构、运营流程），20% 品牌专属定制（市场定位、视觉形象、专门功能）。
Built for Shopify：Seguno 的增长实证
认证带来的可量化结果
Seguno 旗下全部应用通过 Built for Shopify 认证后：整体安装量提升 14%，认证后六天内搜索排名跃升至第一页。
关键实践：全程使用 Polaris 组件库构建原生体验；满足 LCP 性能指标是最大挑战之一，Seguno 为此构建了自定义性能指标插件并使用 Sentry 追踪。Shopify 现已提供 Web Vitals 实时监控工具。
Bloomreach 与 Shopify：AI 个性化的企业级落地
客户数据透视
Bloomreach 与 Shopify 整合后取得的平均效果：访客平均收入提升 50%（其中客单价提高 24%），转化率提升 21%，自动化流程收入增长 310%。
核心整合产品是 Bloomreach Discovery（GenAI 搜索）与 Bloomreach Engagement（营销自动化），均由 Loomi AI 引擎驱动。英国女装品牌 Lovall 的案例：自动化流程收入增长 310%，弃购转化率提高 30%，平均订单价值提升 15%，CRM 收入增加 51%。
播客全文
女：Hello 大家好，欢迎收听XunbuOS Podcast，我是小雅。
男：大家好，我是老冯。
女：今天这期节目内容挺丰富的，从Build Award获奖者到API更新，再到企业级合作，信息量不小。老冯，你知道DotDev大会上刚颁发了2026年的Build Award吗？
男：知道，这个奖还挺有分量的。它不是颁给规模最大的公司，而是表彰那些给商家解决实际问题的合作伙伴。今年分了四个类别，应用、店面、商家影响力和社区。
女：我看到获奖者来自七个国家。有个细节挺有意思，有的获奖者是从一间空房间起步的，还有一对搭档以前在必胜客共事。
男：对，Mike Rossi和Bill Curtis，就是Smile的联合创始人。他们最初是多平台电商代理商，后来全力押注Shopify。当时客户需要忠诚度计划，他们决定做一个对涌入Shopify的小企业完全免费的应用。十年后成了生态里最大的忠诚度应用之一。
女：从必胜客到Shopify最大忠诚度应用之一，这跨度挺大的。
男：确实是。而且他们做得聪明的地方在于，没有只做一个封闭应用，而是提供了一个公开API给其他开发者接入，又保持了和平台本身的深度融合。Mike有句话说得挺到位——现在商家可以在一周内通过“氛围编程”就能打造一个完整应用，你怎么实现差异化？答案是在一个主题上深入下去，和商家建立紧密联系。
女：说起深度，Discount Kit那个案例也挺有意思。创始人在必胜客认识，十多年一直合作。他们做折扣方案，商家敢于在多个黑色星期五依赖它。这个应用是原生构建在Shopify Functions之上的。
男：这个确实是平台能力的展示。折扣叠加逻辑原生构建在Functions上，和商家的促销运营方式紧密交织，店铺甚至会围绕它来规划营销活动。团队也很克制，核心团队很小，但支持服务分布在全球各大洲。
女：这次还有店面类别的几个获奖者。Human NYC做了高端眼镜品牌Wendywin的店面，体验更偏杂志风格，视频和动画贯穿购物全程。还有Commerce UI，用Liquid原生构建了Lupine的店面，带交互式功能和B2B能力，第二次拿Build Award了。
男：Commerce UI那两位对细节的执着确实让人印象深刻。他们说团队讨论过无数次，是否应该把动画绑定到滚动事件上，或者布局会不会闪烁。这种对细节的追求，在电商领域其实很稀缺。
女：对了，今年还新增了社区奖，颁给了Zapiet的Emili Horncastle。她这个经历也挺传奇的，疫情爆发时Zapiet是少数提供自提和配送服务的应用，Shopify做了专题推介，团队在不到两个月里从6人扩到33人，甚至拉来母亲和朋友帮忙分流支持请求。
男：那段时期确实很特殊。后来她还在世界各地组织合作伙伴聚会、演讲、分享经验。她说因为Shopify，她在世界各地都有了朋友，还去参加了婚礼。
女：很温暖的故事。那咱们接下来聊点更技术向的。最近Sign in with Shop开放给店面应用了，这个消息你关注了吗？
男：关注了，这个变化其实挺关键的。之前Sign in with Shop只用在潜在客户信息捕获和客户账户功能，现在只要是店面里需要识别买家身份的应用都能用了。心愿单、缺货提醒、忠诚度计划、评论，这些场景都可以。
女：从商家角度看，这意味着什么？
男：核心是解决身份识别的问题。你看，以前任何店面应用要跟买家互动，都得自己搞一套登录。用户要填邮箱，很多人瞎填或者填完就忘了，应用拿到的是未经验证的数据。商家那边就更头疼了，要跟六七个合作伙伴数据库拼凑客户画像，拼出来的还支离破碎。
女：那现在这个方案是怎么解决的？
男：它是一个跨应用的统一登录层。有个设计逻辑叫“复利累积”——每次集成捕获一个Shop会话，都会提高后续所有交互界面的买家识别率。而且是一次登录，全店通用。第一个合作伙伴应用完成认证后就创建了会话，同一商店的其他应用不需要再提示了。
女：权限这块怎么处理？
男：权限范围是可叠加的。第二个应用只需要为它需要的新增权限触发用户同意就行。用的是同一个开发者后台，跟Storefront API和Admin API并列，不需要新的入驻流程。SDK是个即插即用的Web组件，嵌入店面应用的UI就行，平台负责处理身份验证、用户同意、会话生命周期这些困难的部分。
女：听起来集成门槛不高？
男：对，大多数团队一个sprint就能做完。但真正的考验在上线之后。他们给了一些最佳实践，比如不要把它当成替代方案而是增量方案，不要在首页加载时自动触发，而是等买家做需要已知身份的操作时再显示。还有，你应用可能不是商店里第一个完成认证的，所以得处理买家已登录的情况。
女：那如果买家拒绝登录呢？
男：那就需要优雅降级，回退到现有的流程。不过从长期看，这个方案的价值在于——买家获得的会话覆盖整个商店的合作伙伴应用，不需要每个应用都单独登录，这对转化率的提升是很可观的。
女：这次还发了一个新的Collection Sources API，这个你深入看了吗？
男：这是GraphQL Admin API 2026-07版本里的。改动挺大的。你知道Shopify集合以前分两种模式：自定义集合，手动选产品；智能集合，用条件自动填充。这个模式帮数百万商家管理目录，但逼着他们做取舍——你要么全自动，要么全手动。
女：但实际上商家两个都想要，对吧？
男：对。商家想结合自动化和人工策划。而现在这个新模式，集合可以组合多种来源：带自动化条件的产品、手动选择、排除项、其他集合，还有应用创建的可共享来源。比如一个“六月促销”集合，可以包含有促销价的产品，排除某个品类，再手动加入几个特定产品。
女：这个对活动运营来说确实灵活多了。
男：还有一个对开发者很有意义的变化——变体定位。以前集合只能定位到整个产品，现在可以精准到特定变体。这对店面体验影响很大，情人节集合可以只包含红色变体，加大码促销可以只定位XS和XXL。对店面、搜索、筛选和主题合作伙伴来说，变体感知的集合让集合页面更准确了。
女：我听说应用还可以发布可共享来源？
男：对，这是给合作伙伴的另一条路径。评论应用知道哪些产品评价高，订阅应用知道哪些产品符合订阅省资格——以前这些智能没有干净的位置放进原生集合。现在应用可以创建和更新可共享来源，商家决定在哪些集合里使用。Shopify会在目录数据变化时自动评估组合的来源、排除项、集合引用和变体定位，应用不用不断重写产品列表了。
女：那迁移成本呢？现有应用需要做什么？
男：有个重要提醒——2026-07之前的API版本无法表示新模型的集合，这些集合会被过滤掉。如果你的应用读取、写入、渲染、同步或检查集合成员关系，必须更新到2026-07，不然商家以后创建的集合你根本看不到。现有自定义集合和智能集合可以继续工作，应用可以增量迁移，但这个版本更新是躲不掉的。
女：Breaking change，确实挺头疼的。咱们再聊聊合作伙伴组织这块，最近也改了不少东西。
男：对，这个改动是面向合作伙伴组织的结构性调整。现在Partner组织有了正式结构——一个Organization Owner，多个Organization Admins，还有Organization Settings可以管理整个团队。核心是引入了基于角色的访问控制，七个系统角色覆盖了大多数场景，也可以自定义角色。
女：七个角色都覆盖了哪些场景？
男：Organization Owner，完全控制权，每组织仅限一名；Organization Admin，权限跟Owner一样但不能转让组织；Organization User Admin，负责管理团队成员；Store Admin，对开发商店或客户转让商店有完全构建权限；Store User Admin，管理特定商店的用户；App Developer，有Dev Dashboard访问权限；还有Collaborator Store Access，访问商户已授予协作者关系的商店。
女：那迁移是怎么做的？
男：他们说了，自3月30日起自动迁移，根据团队当前访问权限分配相应角色。有个点需要注意——待处理的用户邀请全被取消了，需要重新添加。Organization Owner如果有多名，主要所有者保留，其他人自动转为Organization Admin，权限不变但不能转让所有权。
女：Dev Dashboard这块也有变化？
男：对，现在开发商店、客户转让商店和协作者商店全都在Dev Dashboard里了，不用再切换仪表板。但Partner Dashboard没变，付款、应用分发、主题和推荐这些还在原来地方。核心思路是让Dev Dashboard成为Shopify构建的主场。
女：聊完了这些偏开发者向的话题，咱们看看面向企业端的。这次有几个大合作案例，Deloitte Digital和Bloomreach都来了。
男：对，Deloitte Digital那边有个“下一代零售商务加速器”，是可组合商务解决方案，帮助企业把Shopify跟ERP、PIM、CRM系统，甚至Oracle的Unity CDP无缝集成。核心价值是让客户降低成本和项目周期，而且可以根据业务需求灵活选择要实施的组件。
女：Bloomreach那个合作数据挺惊人的。他们说整合后访客平均收入提升50%，转化率提升21%，自动化流程收入增长310%。
男：这些数据确实很亮眼。核心是他们的GenAI搜索工具Bloomreach Discovery，用先进语言模型理解自然语言查询。比如客户在Shopify网站上直接输入“帮我找一条春季半正式场合的婚礼宾客连衣裙”，系统能识别意图、匹配最相关商品，还随着互动持续优化。
女：这个对商家来说意味着什么？以前搜索是关键词匹配，现在变成理解意图了？
男：对，本质上是搜索从关键词匹配变成意图理解。对Shopify商家来说，45%的收入源自搜索栏，这个入口的改进影响面非常大。而且他们跟Shopify的集成是产品驱动的，不是简单的API对接——如果客户先做平台迁移，Shopify主导；如果要先换搜索或营销自动化，Bloomreach介入。
女：还有ThirdLove这个案例挺有意思。他们的CMO说，一位55岁的女性和一位16岁女孩买胸罩时体验完全相同——浏览同样的页面、产品和路径，但身材完全不同。这个洞察很打动我。
男：这个确实是Shopify本身做不到的。Shopify擅长构建强大电商站点，体验流畅、速度快捷，但如果你要每个用户都拥有个体化体验，那就是Bloomreach的切入点了。基于位置、购买历史、生活方式偏好来调整体验。比如养金毛贵宾犬的客户可能需要更多的吸尘耗材，这种偏好能从数据里捕捉到。
女：那咱们再聊一个更实际的话题——多品牌电商。Ask Phill那个案例你看了吗？
男：看了，这个方案挺有想法。每收购或发布一个品牌，技术复杂性就成倍增加，这是多品牌公司面临的隐性增长壁垒。Ask Phill做了一个“逻辑层”，每个品牌连接到共享代码库，但不复制代码。当一个品牌需要产品捆绑功能而另一个不需要时，通过配置来处理差异，而不是搞独立的代码分支。
女：效果怎么样？
男：他们说开发效率提升40-70%，新品牌上线从数月或数季度缩短到数周，缺陷减少30-50%。最关键的可能是——功能一次构建，全品牌部署，不用每个品牌都重新造轮子。还有个80/20框架，80%共享基础设施，20%品牌专属定制。
女：这个模式我觉得挺符合商业逻辑的。你既需要共享效率，又需要品牌差异化，这本质上是个平衡问题。
男：对，他们有个案例，Superstruct/ID&T集团整合了8个以上品牌。以前每个品牌有自己的代码库、逻辑和限制，很多工具集成度不高，部分工作流要人工操作。现在通过一个共享代码库，改进和功能一次构建，所有品牌自动受益。对技术团队来说，这意味着从维护转向创新。
女：说到“从维护转向创新”，今天还有一个案例特别适合这个话题——Seguno做邮件营销工具的，他们通过了Built for Shopify认证。
男：这个算是BFS认证的直接商业价值示范。他们的应用套件整体安装量提升了14%，认证后仅六天搜索排名就跳到第一页，还拿了2024年的Build Award。他们从第一天起就决定用Polaris组件库，让应用看起来就像Shopify后台的一部分。
女：这个策略挺清晰的。
男：对，他们的CEO说目标是“尽可能贴近电商平台，以至于真正融入其中”。认证过程也不是一帆风顺，最难的是后台性能标准，特别是LCP指标。他们当时自己构建了自定义性能监控，用Sentry做追踪。现在Shopify提供了现成的Web Vitals工具，开发者不用踩他们当时踩过的坑了。
女：那咱们来总结一下今天聊的话题？从Build Award获奖者的故事，到Sign in with Shop的开放，再到Collection Sources API、合作伙伴组织，以及企业级合作和多品牌方案。
男：今天内容确实很密集。我印象最深的是Smile创始人那句话——现在做一个应用的门槛很低，真正的差异化在于对一个主题的深入理解和与商家的紧密联系。不管是大企业还是个人开发者，这个原则其实通用。
女：还有一点很触动我——Emili Horncastle说“因为Shopify，我在世界各地都有了朋友”。这让我觉得这个生态不只是一个商业平台，更像一个有温度社区。
男：是啊，从空房间到Build Award，从必胜客同事到联合创始人，从一人客服到全球团队。这个生态确实给了好点子和愿意持续构建的人很大的空间。
女：好了，今天的节目就到这里。如果你喜欢这期内容，记得订阅XunbuOS Podcast，我们会持续关注Shopify生态的动态。不管是API更新、商家案例还是合作伙伴故事，我们都会第一时间给你解读。
男：对，那我们下期见！
女：下期见！
参考链接
- Meet the 2026 Shopify Build Award winners
- Sign in with Shop opens to storefront apps
- Introducing the new Collection Sources API: a more flexible model for merchandising
- Build More, Manage Less: Teams, Stores, and Roles Simplified
- The Multi-Brand Blueprint: How Ask Phill Scales Multi-Brand Commerce on Shopify
- How Seguno propelled their success on the Shopify App Store with 'Built for Shopify'
- How partnering with Shopify has helped Bloomreach achieve yearly double-digit growth
- Bloomreach partners with Shopify to deliver AI-powered personalization, helping enterprises increase revenue by over 300%
- Deloitte Digital and Shopify Collaborate to Help Brands Achieve Unified Commerce
- Join Today
迅步科技专注Shopify独立站，Shopify应用及无头网站开发，为您的品牌提供快速、灵活、个性化的电商体验，提升用户转化率与运营效率。欢迎咨询合作。