交叉销售与追加购买模块：推荐、搭配与加购
交叉销售与追加购买模块在商品页、购物车或结账后，向顾客提出“还可以配什么、有没有更合适的、一起买是否更合适”，并把提议直接变成可执行的加购动作。它与相关商品的分工是：相关商品是内容类型，规定关系怎样确立、依据是什么；本模块是页面语境与交易动作，规定在哪里、以什么方式提出，以及加购之后购物车怎样保持一致。
模块 = 信息来源 × 展现或交互 × 页面语境：交叉销售与追加购买 = 推荐关系及其依据 × 商品卡与加购动作 × 商品页、购物车或结账后
先确定模块在完成什么任务
四种提议回答不同问题，不能混成一个“猜你喜欢”：
| 类型 | 顾客问题 | 关系 | 常见位置 |
|---|---|---|---|
| 搭配（cross-sell） | 还需要配什么 | 补充购买、配件、耗材 | 商品页、购物车 |
| 升级（upsell） | 有没有更高配置的版本 | 同一用途的更高规格 | 商品页、购买区旁 |
| 捆绑 | 一起买是否合并成一件 | 固定组合，有独立价格或库存 | 商品页 |
| 追加 | 订单之外再加一件 | 与已下单商品相关的补充 | 购物车、结账后 |
对象层级要写清：推荐的是商品还是具体变体。加购动作只能作用于一个已确定的变体（颜色、尺寸都选定），否则要先让顾客选择，见商品与变体。进入前已知的信息：当前商品与变体、购物车内容，结账后还包括刚完成的订单。
升级不是选型：在几个候选间做比较属于商品选型；本模块只提出“更高配置”这一项，并说明差异。
信息来源与输入
| 输入 | 来源 | 最低要求 |
|---|---|---|
| 关系与理由 | 相关商品的关系类型、一句话理由、来源、复核日期 | 每条关系有类型；搭配与补充购买还需要兼容条件 |
| 推荐依据 | 手动搭配、购买历史、商品相似 | 记录依据与优先级，标题措辞与依据一致 |
| 商品状态 | 商品与变体资源（运行时） | 当前市场下可售、价格大于 0、已发布；不写成静态文案 |
| 购物车状态 | 购物车（运行时） | 已在购物车中的商品不再作为推荐 |
| 加购动作 | 交易动作 | 指向明确变体与数量，结果以平台返回为准 |
| 价格与优惠 | 促销与折扣内容与平台折扣 | 捆绑价、节省额来自同一份促销规则，不在前端自行计算 |
包装清单里的物品与另售配件必须分开：写在包装清单里的属于已包含，推荐区里的都需要另行购买。
推荐依据必须可解释
| 依据 | 适合的说法 | 不适合的说法 |
|---|---|---|
| 手动搭配 | “常与它搭配使用”，并给出一句话理由 | “为你推荐”（并非个性化） |
| 购买历史 | “经常一起购买”，前提是有足够销售记录 | 暗示对当前顾客个性化，除非确实如此 |
| 商品相似 | “类似商品”，属于替代而非搭配 | 放在“搭配使用”标题下 |
人工与自动结果并用时，要事先规定优先级与去重。主推商品若只是运营意愿，就写成“推荐”或“主推”之类的编辑说法，而不是借用“大家都买”这类看似客观的依据。
状态与退化
| 状态 | 处理 |
|---|---|
| 零项 | 隐藏整个模块，不用随机商品填补 |
| 一项 | 可以展示，标题不用“更多推荐”这类暗示数量的说法 |
| 多项 | 限制数量（购物车内 1 到 3 项即可），按关系类型分组并说明排序 |
| 加载 | 预留空间，不阻塞主购买按钮；加载失败时安静隐藏 |
| 错误（加购失败） | 保留当前页面与购物车，说明失败原因并可重试，不显示成功 |
| 过期 | 商品在浏览期间售罄或下架时，刷新后移除；不在前端缓存库存 |
| 不可用 | 不兼容当前变体、不可售、当前市场不可购买的商品不显示，不以“暂时缺货”留在推荐位 |
| 跨市场差异 | 价格、可售与推荐范围按当前市场重新计算；人工关系在下次复核时按市场修订 |
| 顾客拒绝 | 关闭或忽略提议后不重复打断同一流程 |
加购后购物车一致性
加购成功后，页面上所有购物车入口必须一致：图标数量、抽屉或购物车页的行项目、小计与折扣。这些都应由平台返回的最新购物车渲染，不由前端自行叠加（与促销兑现一致）。加购后仍要处理：数量超过库存、同一变体已存在、购物车里已含该商品时推荐位是否隐藏、以及捆绑商品在订单与退货中被拆成单项的情况（见下节）。购物车本身的展现要求见购物车摘要模块与 Horizon 购物车；该模块指出抽屉不适合塞入完整的推荐列表，与本文“购物车内只放 1 到 3 项”一致。
不得使用暗黑模式
- 预勾选：搭配品的勾选框默认不选中，顾客主动选择才加入。
- 拒绝路径：拒绝入口清晰可见、可用，视觉权重可以低于接受按钮，但不得隐藏或改成难以理解的措辞。
- 价格：接受前显示该商品的完整价格与是否立即产生费用，不在结算时才出现新增费用。
- 措辞与压力：不使用暗示订单状态不确定、把追加说成必需的语言，不使用倒计时制造紧迫感。
依据：FTC 2022 年新闻稿将预勾选框、限时倒计时列为暗黑模式示例，并称这类设计可能违法（FTC 新闻稿，核验于 2026-09-29）。该稿是美国监管机构的说明，本站面向的各市场适用哪些具体要求，需要法务/合规确认，本文不给出法律结论。Shopify 对结账后商品优惠的 UX 要求见下节。
可选展现与交互
- 商品页搭配：数量少且需要看图时用 Cards，数量多用 Grid，横向空间不足时可用 Carousel，但首屏关键推荐不藏在滚动区里。
- 购物车内：放在购物车行项目之后的一两行，使用 Drawer 或购物车页的紧凑列表。
- 捆绑：用卡片显示每个组成项、合计价和节省依据，并允许查看组成项而不必接受整包。
- 加购按钮：按钮名称包含商品名；需要选变体时先选后加，主商品的购买动作见购买区模块。加购成功的短提示可参考 Toast，但提示消失后购物车入口的数量仍要保持可见。
- 禁用条件：不用弹窗打断主购买流程，除非顾客主动展开；同一位置不放超过一类提议；不用倒计时。
页面组合中的位置
商品页里，推荐放在购买区之后，不抢主购买动作，先交代当前商品再谈搭配；购物车里，放在行项目之后、结账按钮之前，数量少；结账后属于平台流程（见下节）。不应出现的语境：首页与内容页（应使用特色商品，起点是页面任务而不是当前商品）、支付信息填写过程中。页面组合规则见页面组合。
无障碍与性能
- 推荐区异步加载时预留高度，不造成布局跳动，也不让读屏软件反复播报。
- 加购成功要有不抢焦点的状态文字。WCAG 2.2 SC 4.1.3 Status Messages（AA）要求状态消息可被辅助技术识别而不获得焦点；该说明页的技术建议中
role="status"用于操作成功等状态，role="alert"或 aria-live 用于错误与警告（Understanding SC 4.1.3，核验于 2026-09-29）。 - 每个商品卡的加购按钮名称写明商品，不只叫“加入”；选项状态不只靠颜色。
- 推荐请求不阻塞主购买按钮；失败时不显示错误块，直接隐藏。
映射到 Shopify
以下核验于 2026-09-29，来源为 shopify.dev 与 help.shopify.com 官方页面；推荐相关内容与相关商品「平台落点」一节保持一致。
- 推荐类型：官方区分 complementary（经常一起购买的补充商品）与 related（相似商品）。每个商品最多手动选择 10 个 complementary 与 10 个 related；related 由 Shopify 自动生成，依据为购买历史、商品描述（仅英文店面）与相关集合，生成结果经常变化；complementary 需要在 Search & Discovery 中手动设置。展示资格包括未售罄、非 Unlisted、价格高于 0、非礼品卡、已发布到 Online Store、状态为 Active，且不在访客当前购物车中。官方说明推荐要求主题包含相应板块。帮助中心只讨论商品页，购物车与其他页面的展示未核验。
- 推荐 API：Ajax 接口
/recommendations/products.json（或返回渲染分区的/recommendations/products，需要section_id）的product_id必填，intent取related或complementary（默认related），limit为 1 到 10（默认 10）；缺少product_id返回 422，商品未在 Online Store 发布返回 404，非法intent返回 422。Storefront API 的productRecommendations接受productId或productHandle与intent（RELATED默认，COMPLEMENTARY），最多返回 10 个商品。官方页面没有明确说明结果为空时的返回，本文只建议“为空时不渲染”。 - 加购动作（Cart API）：
POST /cart/add.js接受 JSONitems数组，每项含变体id与quantity，可带properties、selling_plan、parent_id，并可用sections请求渲染分区；成功返回所添加的行项目。价格、属性或 selling plan 不同的同一变体会拆成独立行项目。库存不足或已售罄时返回 422，页面给出Cart Error及对应描述。页面对已在购物车中的同一项目的quantity语义有描述，究竟是累加还是覆盖未经实测核实；多个items中某一项失败时其余项是否成功，页面未说明，未核验。 - 捆绑（捆绑的资格与注意事项）：捆绑库存由各组成项库存除以所需数量后取最小整数决定；与购买选项（订阅、预售、try-before-you-buy）、自定义商品不兼容，捆绑不能包含其他捆绑；要求已升级的结账；订单中捆绑显示为嵌套的行项目，但拆分发货、退货换货等场景会按单项处理。
- 结账前后商品优惠（商品优惠）：结账信息、配送、支付步骤中的 pre-purchase 优惠使用 checkout UI 扩展，页面写明这些扩展仅适用于 Shopify Plus；post-purchase 优惠出现在订单确认之后、感谢页之前，页面写明处于 beta，开发店可使用，正式店需申请。限制包括每次结账最多接受 3 个 post-purchase 优惠、订单金额需达到 0.50（页面以美元表述）、部分支付方式不显示、订单需经 Online Store 渠道。
- Shopify 对 post-purchase 的 UX 要求（UX 页）：费用透明；提供清晰的接受或拒绝选项；最多连续显示三个追加优惠；商品标题与价格须与店面一致；拒绝按钮文字须为
Decline upsell offer，位于接受按钮下方且视觉权重较低；提示语不使用感叹号，也不使用让追加显得必须或让订单状态存疑的措辞。 - 主题层面：加购提交与数量约束见 Horizon 购买流程，购物车展示见 Horizon 购物车。推荐区块的固定版本实现见Dawn 商品推荐、Horizon 商品推荐：Dawn 内置 related-products 区块与商品页 complementary 区块，购物车页与抽屉无推荐区块；Horizon 的推荐只在商品页。
- 未核验：不同 Markets 下的推荐范围、推荐在购物车的展示条件、Plus 以外店铺的结账内追加方式。
验证一次交叉销售与追加购买
- 选定一个有手动搭配、一个只有自动推荐、一个没有推荐的商品，确认三种情况下模块的显示与隐藏。
- 把一个被推荐商品设为售罄、下架或换成不兼容变体，确认它从推荐中消失；记录购物车已含该商品时是否仍出现。
- 从推荐位加购：确认页面图标、抽屉或购物车页、小计一致；再故意加购到超过库存，确认错误信息与购物车状态。
- 检查搭配品未被预勾选，拒绝路径可见，捆绑合计价与逐项价格核对一致。
- 更换市场、币种与语言，核对推荐、价格与可售。
- 只用键盘与读屏软件完成一次加购，确认成功状态被播报且焦点未跳走。
平台正文
该机制的权威平台说明见 Search & Discovery；本文只写在当前内容或页面语境下的用法。
待继续完善
- 缺少真实店铺的推荐结果与加购流程实测；
- 各法域对预勾选、限时提示与追加销售的具体要求尚待合规确认；
- 推荐位对决策的实际帮助没有可靠指标，需要与真实订单数据对照。