跳转到主要内容

Shopify重复多买优惠:如何设置4件10英镑、8件20英镑的可重复计算优惠

By Stackable TeamPublished on July 30, 2026Discount Strategy#quantity-breaks#volume-discounts
Shopify重复多买优惠:如何设置4件10英镑、8件20英镑的可重复计算优惠

原生Shopify可以给客户一次"4件10英镑"的套装价格,但不会为每个额外套装重新触发该优惠。所以购买8件3.49英镑商品的客户不会支付20英镑。他们支付23.96英镑,因为Shopify将固定折扣应用于单个套装,其余部分按全价收费。真正的重复多买,每个完整4件套装重新定价为10英镑,需要基于Shopify Functions构建的折扣,而不是原生折扣构建器或虚假捆绑产品。

本指南解释了原生折扣对套装定价的实际作用、优惠为什么在一套后停止、商家采用的虚假捆绑产品变通方法和为什么它弊大于利、基于Functions的折扣如何为每套重新计算价格,以及完整的工作示例(4件10英镑、8件20英镑、12件30英镑)并排显示精确数学。

Shopify能原生做"4件10英镑、8件20英镑"吗?

部分可以,部分的部分就是整个问题。你可以创建一个原生折扣使4件成本10英镑。你无法原生创建的是同一个10英镑套装价格为购物车中每个额外4件组自动重复的交易。Shopify的内置折扣类型应用固定金额或百分比一定次数,而不是重复"每个完整套装重新定价为10英镑"规则。

这是一个真实、反复出现的商家问题。在Shopify社区中,一个试图跨600件产品集合运行"4件10英镑、8件20英镑"的商家报告说原生折扣只应用一次价格,所以8件来到23.96英镑而不是他们想要的20英镑,并询问如何让每个额外套装重新触发交易。他们得到的答案是原生折扣无法做重复套装定价,建议的变通方法是构建一个定价为10英镑的虚假"捆绑产品"。我们稍后会回到为什么那个变通方法是个陷阱。

简短版本:原生Shopify对固定数量的一次性套装价格很好。一旦客户购买多于一套并期望交易继续应用时,它就崩溃了。

图像占位符(图像1):一套对比每套
建议视觉效果:白色背景上清晰的16:9图表。左侧标记"原生Shopify"显示8件商品购物车,只有前4件分组用紫罗兰色框,定价10英镑,剩余4件按全价,总计23.96英镑用红色显示。右侧标记"重复多买"显示相同8件商品分成两个紫罗兰色框4件,各定价10英镑,总计20英镑用绿色显示。最小平面矢量,品牌颜色紫罗兰和金色,无衬线标签,无摄影。

什么是重复多买交易?

多买交易为一组商品设置价格而不是单件价格。"3件2件"、"2件5英镑"和"4件10英镑"都是多买交易。重复多买是一个交易,其中组价格再次应用,自动地,每次客户添加另一个完整组。4件成本10英镑,8件成本20英镑,12件成本30英镑等等,优惠为每个完成的套装重新计算。

重要的词是"按套"。客户不是从他们的订单中获得一个固定金额,也不是每件都获得百分比。他们为每个完整的套装大小包获得固定价格,任何不完成套装的剩余商品按其正常价格收费。这种按套重新计算正是原生Shopify没有的行为,也是基于Functions的折扣重新添加的行为。

为什么"按套"比看起来更难

要正确定价购物车,折扣引擎必须计数结账时购物车中有多少完整套装,对每个应用套装价格,然后决定如何处理剩余部分。6件商品购物车是一套4件10英镑加2件散品按全价。8件购物车是两套20英镑平。那个计数每次购物者调整数量时改变,它必须在服务器端重新计算,所以购物车页面上的数字是他们实际被收费的数字。原生折扣不以这种方式重新计算套装计数,这是"8件23.96英镑"惊喜的根本原因。

为什么原生Shopify只折扣一套?

原生Shopify有两种看起来可以做多买的折扣类型,两者都在不同方面不足。

商品折扣金额应用固定折扣一次

"4件10英镑"最接近的原生匹配是一个"商品折扣金额"折扣,最小数量为4,固定折扣金额校准以将4件商品降低到10英镑。根据Shopify帮助中心,商品折扣金额折扣从符合条件的商品中取固定值或百分比。麻烦的是固定值作为单一扣除应用于符合条件的行商品,而不是为每个额外套装重新触发。如果4件3.49英镑商品需要3.96英镑折扣来达到10英镑,Shopify扣除那个3.96英镑一次。再添加4件商品Shopify不会第二次扣除3.96英镑。客户获得一套价格和其后的全价。这正是8件为什么到达23.96英镑而不是20英镑的方式。

买X送Y是关于额外商品,不是套装总数

另一个候选是"买X送Y"折扣。根据Shopify开发者文档,"买X送Y"折扣由客户购买什么(商品的前提数量)和他们然后得到什么(商品的折扣价格或免费)定义。它被构建为向购物者提供额外折扣商品,例如"买3送1免费"。它不被构建为表达"这4件商品一起成本10英镑"。你无法用买/送模型表达固定套装总数,因为模型折扣"送"商品,它不将整个组重新定价为平数。"买X送Y"也带有其他原生限制商家会遇到,包括符合条件商品的上限,我们在关于100件商品"买X送Y"限制的单独文章中涵盖。

所以原生构建器给你一个一次触发的套装价格(商品折扣金额)或无法表达套装总数的额外商品机制("买X送Y")。都不按套重新计算,那不是你可以通过配置来解决的错误。它是原生类型被设计做什么的边界。

虚假捆绑产品变通方法(以及为什么它反效果)

最常见的无应用变通方法,也是在那个社区线程中建议的,是创建一个代表该套装的新产品。你制作一个"4件装"产品,将其价格设置为10英镑,并销售它。在表面上它有效:客户添加一个"4件装"并支付10英镑,添加两个并支付20英镑。套装价格重复因为虚假产品的每个单位已经作为套装定价。

它在几个昂贵的方式中反效果。

  • 库存不同步。除非你通过Shopify的原生捆绑功能或捆绑应用将捆绑与其组件产品关联,销售一个"4件装"不会减少其内部四个真实商品的库存。你最终维护两个库存现实会分散。
  • 客户无法购买他们想要的数量。真正的多买让某人购买5件或7件并获得一套定价加散品按全价。虚假捆绑产品强制按套装大小倍数购买。想要6件?你不能,你得到4件或8件。
  • 它不能跨集合扩展。社区线程中的商家想要跨600件产品的交易和混搭套装。虚假捆绑产品需要客户可能想要的每个组合的单独SKU,这对超过少数商品的部分是不可能的。跨大型集合的混搭正是虚假捆绑产品无法表达的内容。
  • 它污染推广和分析。捆绑显示为搜索、集合和报告中的自己的产品。你的单件销售数据现在隐藏在"4件装"行项目中,客户浏览真实产品页面看到与捆绑不同的价格,这很令人困惑。
  • 变体倍增。如果底层产品有尺寸或颜色,套装内的每个变体组合需要在捆绑产品上存在,变体计数快速爆炸。

变通方法用定价问题换取库存、目录和报告问题。对于单个英雄产品没有变体它可以勉强继续。对于真实目录它不可维护。

基于Functions的折扣如何按套重新计算

运行重复多买的可靠方式是在Shopify自己的结账管道内作为代码运行的折扣,使用Shopify Functions。而不是应用一次的固定扣除,折扣在结账时读取购物车,计数存在多少套装大小的完整套装,对每个完整套装应用套装价格,并将任何剩余保留在其正常价格。因为它在每个购物车变化时重新计算并在服务器端运行,价格对每套重新计算且购物车总额匹配结账总额。

以下是"4件10英镑"交易对正常成本3.49英镑的商品的纯英文逻辑:

  1. 计数购物车中符合条件的单位。假设客户有10件。
  2. 除以4的套装大小。那是两个完整套装(8件)余2。
  3. 对两个完整套装各定价10英镑,共20英镑。
  4. 对剩余2件各定价正常3.49英镑,共6.98英镑。
  5. 购物车总额:26.98英镑,在购物车页面、结账和Shop Pay上以同一方式计算。

每步都是确定性的并随着套装计数增长而重复。12件是三套30英镑无剩余。因为计算存在于Function而不是主题JavaScript中,加速结账如Shop Pay、Apple Pay和Google Pay,它们跳过购物车页面,仍然获得相同价格。这是相同原因服务器端折扣避免我们在Shopify中折扣堆叠如何工作中涵盖的购物车对结账不匹配。

图像占位符(图像2):在结账时计数完整套装
建议视觉效果:一个16:9流程图。步骤框从左到右,用金色箭头连接:"购物车有10件"然后"除以套装大小4"然后"2个完整套装加2个剩余"然后"2套各10英镑=20英镑"然后"2件散品各3.49英镑=6.98英镑"然后一个绿色总额卡"26.98英镑,处处相同"。清晰平面矢量,紫罗兰框配金色箭头,等宽数字,白色背景,无摄影。

工作示例:4件10英镑、8件20英镑、12件30英镑

让我们用一个通常以3.49英镑销售的单一产品使差异具体化。交易是"4件10英镑",这意味着每个完整4件套装应该重新定价为10英镑,无论客户购买多少套装。要为一套4件命中10英镑(通常13.96英镑),交易需要从每个完整套装取3.96英镑。

下面的表格以三种方式显示相同购物车:无交易的全价、原生Shopify应用固定折扣一次、和为每套重新计算的重复多买。

读8件行。全价是27.92英镑。原生扣除单一3.96英镑套装折扣并停止,到达23.96英镑,社区商家报告的精确数字。重复多买各为一个完整套装扣除3.96英镑两次,并到达20.00英镑。在12件时差距扩大到7.92英镑,因为原生仍只应用一个套装折扣而多买已应用三个。

注意6件行对于原生和多买在16.98英镑是相同的,因为任何方式只有一个完整套装(4件套装10英镑加2件散品3.49英镑)。两种方法仅在第二套完成后分散。那是线索:如果你的推广从不在单个订单中销售多于一套,原生就足够。如果客户日常购买倍数,原生在他们跨入第二套的瞬间悄悄超收他们,每个运行这个交易的商家最终得到"为什么我的8件装不是20英镑"支持票。

如何分步设置重复多买

无论你用原生折扣做单套交易还是基于Functions的应用做真正重复交易,设置思维是相同的。以下是可靠序列。

1. 将交易写成套装大小、套装价格和剩余规则

在触及任何设置前钉死三个数字:套装大小(4)、套装价格(10英镑)和对不完成套装的剩余单位发生什么(按正常价格收费是通常且最公平的选择)。如果你无法用这些术语陈述交易,你还没有多买,你有其他东西。

2. 决定什么计作"同一产品"

多买必须知道哪些购物车单位计入一套。是一个精确变体的4件,一个产品的任何变体的4件(自由混合尺寸),或从精选相关产品组中提取的4件?这个"计数"选择是清晰交易和无法触发或触发无关商品之间的区别。Stackable叫这些per_variant、per_product和per_group计数,这是与单产品体积折扣相同的决定。

3. 诚实选择你的机制

对于单套推广,一个原生"商品折扣金额"折扣带最小数量是真正好的,且免费。对于重复交易,或跨集合混搭的交易,使用基于Shopify Functions构建的折扣应用以便价格按套重新计算。不要为虚假捆绑产品伸手除非你有单一无变体英雄产品且无意扩展它。

4. 有意设置可组合性

决定这个多买是否应该与其他东西堆叠。多买是商品类折扣,所以如果你打开组合它能与订单折扣或免费配送(不同类)组合,但它不会与同一商品上的另一个商品折扣堆叠。故意设置这个而不是在结账时发现它。

5. 测试第二套,不仅是第一套

这是捕捉原生不足的步骤。不要仅以4件购物车测试并称完成,因为4看起来在每种方法中都正确。用8和12测试,下一个草稿或测试订单,并逐行读结账摘要。如果8件总额是23.96英镑而不是20英镑,你的交易应用一次,不是按套。然后测试非倍数如6来确认剩余单位按正确价格收费。

6. 验证加速结账

通过Shop Pay运行8件购物车。原生或基于Functions折扣相同定价因为数学是服务器端。主题脚本"交易"是加速结账无声丢弃折扣的地方,所以这是你客户为你发现差距前的最后防线。

图像占位符(图像3):测试第二套
建议视觉效果:一个16:9产品截图模拟清洁Polaris样式的Shopify结账订单摘要。显示8个相同商品购物车,读"多买:4件10英镑应用x2"的行和突出显示紫罗兰的订单总额20.00英镑,带一个小绿色复选标记徽章读"按套重新计算"。参考docs/截图清单.md槽以稍后交换为真实屏幕捕捉。品牌强调紫罗兰,无摄影。

用Stackable可靠运行重复多买

如果你想要一个实际为每套重新触发的套装价格,没有虚假捆绑产品和没有手动检查测试订单,这是什么Stackable被构建做的,并且它保留在Shopify的真实规则内。

  • 多买数学在Shopify Function中运行,所以套装价格按完整套装重新计算且购物车页面、结账和Shop Pay从一个引擎计算相同总额。8件来到20英镑,不是23.96英镑,处处。
  • 你用per_variant、per_product或per_group计数选择什么计作"同一产品",所以一套可以是一个精确变体的4件、一个产品任何大小的4件、或从精选组中提取的4件,不汇集你的整个目录。
  • 重复逻辑内置,所以交易随数量增长继续应用而不是一次触发。它是与Stackable的BOGO和"买X送Y"优惠背后相同的按套重新计算。
  • Stackable从不改变你的产品价格。多买仅作为结账调整存在,所以在你的目录中没有虚假捆绑SKU,你的库存保留准确,卸载使你的产品恰好与他们之前相同。

免费安装Stackable并在购物车、结账和Shop Pay上确认你的8件20英镑交易在usestackable.com/pricing处计算20英镑。

底线

  • 原生Shopify可以将"4件10英镑"的一套定价,但它应用固定折扣一次,所以8件来到23.96英镑而不是20英镑且交易在第一套后停止。
  • "买X送Y"也无法表达套装总数;它折扣额外"送"商品而不是将整个组重新定价为平数。
  • 重复多买按套重新计算:它计数购物车中完整套装,各定价套装价格,并按正常价格收费剩余单位。
  • 虚假捆绑产品变通方法强制按倍数购买,破坏库存和分析,并无法跨集合做混搭。超出单个简单产品避免它。
  • 基于Shopify Functions构建的折扣在服务器端按套重新计算,所以购物车、结账和Shop Pay都显示相同总额。
  • 总是用两个或多套购物车测试(8和12件),不仅一套,因为单套在每种方法中看起来正确并隐藏不足。
  • 像Stackable这样的工具用per_product计数和重复逻辑在Function中运行多买,所以8件20英镑计算20英镑而不在你的目录中有虚假产品。

相关文章

常见问题

查找常见问题的答案

  • 只支持单个套装。你可以创建一个原生"商品折扣金额"优惠,使4件商品成本10英镑,但Shopify只应用一次该固定折扣,所以8件商品不会是20英镑。以一件3.49英镑的商品为例,8件会到达23.96英镑,因为只有第一套获得折扣。需要每套重新定价的优惠需要基于Shopify Functions构建。

  • 因为原生"商品折扣金额"从符合条件的商品中扣除一个固定值一次,而不是为每个额外套装重新触发。它没有计数完整套装并再次应用价格的概念。超过第一套的任何商品按全价收费,这就是为什么商家看到8件是23.96英镑而不是20英镑的原因。

  • 多买优惠为一组商品设置价格,如"4件10英镑"。重复多买为每个额外的完整组再次应用该组价格,所以4件是10英镑,8件是20英镑,12件是30英镑,任何剩余商品按正常价格收费。关键行为是优惠按套重新计算而不是应用一次。

  • 不能。Shopify的"买X送Y"优惠为客户提供额外商品,价格优惠或免费,例如"买3送1免费"。它由前提数量和奖励数量定义,所以无法表达"这4件商品一起成本10英镑"。"买X送Y"也有自己的限制,包括符合条件商品的上限,所以它不是套装定价的正确工具。

  • 对于一个简单产品勉强可行,但会产生更大的问题。除非你将其与组件库存关联,销售"4件装"不会减少真实商品的库存。它强制按套装数量购买,所以客户无法购买5件或7件。它无法跨集合表示混搭,并使搜索、推广和单项分析变得混乱。它用定价问题换取库存和目录问题。

  • 在设计良好的重复多买优惠中,它们按正常价格收费。一个有6件商品、应用"4件10英镑"优惠的购物车是一套完整套装10英镑加2件散品按全价。只有完整套装获得套装价格。这是合理且预期的行为,也是在上线前用非倍数购物车测试的特定内容。

  • 能,但不能用原生优惠或虚假捆绑产品。你需要基于Functions的优惠,让你定义哪些产品计入套装。通过组计数,套装可以从精选列表或集合中提取,所以客户可以混合产品仍然完成一套。跨多产品的这种混搭正是虚假捆绑方法无法表达的。

  • 如果折扣用Shopify Functions在服务器端计算,会匹配,因为一个引擎对购物车页面、结账和快速结账的定价相同。如果优惠依赖主题JavaScript,Shop Pay、Apple Pay和Google Pay会跳过该代码,折扣会无声失败。总是运行一个8件测试购物车通过Shop Pay来确认套装价格有效。

  • 不需要。重复多买是一个按套重新计算的单一商品类折扣,通过Shopify Functions在每个Shopify计划上运行。Shopify Plus仅在同一购物车行上堆叠两个商品折扣时需要,这是一个单独的功能。运行多买本身不需要Plus。

  • 能,如果你打开组合。多买是商品类折扣,所以能与订单类或配送类折扣组合,因为它们是不同的类。它不会与同一商品上的另一个商品折扣堆叠,除非你在Plus上使用同行堆叠。

  • 百分比体积折扣从每个符合条件的商品上取同一百分比,所以超过阈值的单价恒定。多买为一组设置固定价格并按全价收费剩余商品,所以有效单价在每个完整套装时最低,部分套装时较高。当优惠自然是"N件固定价格"交易而不是百分比时,使用多买。

  • 不需要,如果你使用基于Shopify Functions构建的折扣应用,它通过设置而不是代码为你处理按套重新计算。你只在从零开始编写自定义Shopify Function时需要开发者。原生折扣也不需要开发者,但它们无法做重复部分,所以应用是实现真正按套交易的无代码路径。

Stackable Team

The team building Stackable, the reliability-first bulk and volume discount app for Shopify. We write about discount stacking, Shopify Functions, and how to run promotions that hold up at checkout.

我们使用必要 Cookie 来运行本网站,并仅在获得你许可的情况下,使用分析 Cookie 来了解访问情况。详见我们的 Cookie 政策.