黑五网一销售亏损的首要原因不是优惠力度不足。而是一个在购物车中显示正确价格，然后在结账时失效的折扣，或在Shop Pay、Apple Pay和Google Pay等加速结账中静默失效，恰好在流量达到峰值时。客户看到一个总计，结账收费是另一个，您要么是放弃利润，要么是失去销售。解决方案不是更大的折扣。而是在Shopify自己的结账内的服务器端计算的折扣、您在高峰之前测试的日程安排，以及在数秒内暂停任何活动销售的能力。
本指南涵盖了为什么折扣应用程序在高峰负荷下失败，您可以在本周运行的BFCM前检查清单，当天运行手册，以及一个完整的BFCM周末时间表，以便您可以准确看到事情在哪里出故障以及如何防止。
为什么BFCM销售在结账时亏损？
因为在许多折扣设置中，购物车页面和结账是两个不同的系统，以两种不同的方式进行数学计算。
许多折扣应用程序使用购物车页面上的JavaScript或主题小部件在浏览器中计算堆叠总计。该预览看起来很完美。然后客户点击结账，Shopify的结账（不运行您的主题JavaScript）使用自己的规则重新计算订单。当两者不同意时，客户在购物车中看到一个数字，在最终收费时看到另一个数字。默默偷偷地亏损利润。过度收费会彻底杀死销售，在BFCM上您没有第二次机会获得该客户。
它随着加速结账而恶化。Shop Pay、Apple Pay和Google Pay让买家完全跳过购物车页面并直接跳入Shopify的结账。任何存在于您主题中的折扣逻辑永远不会为这些买家运行，因此折扣对您拥有的转化率最快、意图最高的购物者静默失效。这不是罕见的边缘情况。在Shopify论坛和应用程序评论中，"在购物车中显示但在结账时不应用"和"快速结账跳过了折扣"是商家关于折扣应用程序的两个最具破坏性的投诉报告，并且它们在BFCM期间飙升，因为那是加速结账和流量都飙升的时候。
BFCM上最昂贵的故障不是从未启动的销售。而是一个看起来运行正常并且在任何人注意到之前数小时内悄悄收费错误总计的销售。
为什么折扣应用程序在高峰负荷下失败？
这些故障不是随机的。它们追溯到少数几个架构捷径，这些捷径在安静的星期二保持，但在一年中最繁忙的日子崩溃。
客户端价格技巧
某些应用程序在浏览器中计算折扣并使用JavaScript改写显示的价格。购物车看起来打折了，但真实的结账总计由Shopify单独计算，不是由应用程序计算。在高峰负荷下、在慢速移动连接上、或在广告拦截器或隐私扩展阻挡的情况下，该JavaScript可能无法运行，而视觉价格保持打折。客户看到销售价格并被收取全价，或反之亦然。因为浏览器脚本在您的快速办公室连接上的每次测试都"有效"，这类错误在真实设备上的真实流量击中它之前是无形的。
草稿订单结账
其他应用程序通过草稿订单路由购物车以应用自定义定价，这是先于现代Shopify工具的解决方法。草稿订单位于正常结账流程之外。它们可能会破坏原生折扣代码，扭曲订单分析，并添加另一个在流量激增时精确失败的移动部分。"添加到购物车"和"订单已下达"之间的每个额外系统都是可能在负荷下超时的另一个事物。
未分批负荷且没有暂停按钮
高峰流量暴露任何在高峰负荷下做每请求工作的东西应该已经做过一次。但更安静的故障是操作性的，而不是技术性的：无法停止的销售。商家一再报告从未实际开始的预定活动，以及无法暂停而不删除整个活动并丧失其设置的活动销售。当在销售中途发现价格错误时，一键暂停和"删除并重建活动"之间的区别可能是周末期间数小时的低价订单，当您的团队不完全配员时。
多年商家投诉的主线是一致的：商店不会因为缺少功能而流失。它们会因为可靠性、结账正确性和信任而流失。在BFCM上，这三个是整个游戏。
图像占位符（图像1）：折扣在哪里中断
建议的视觉：白色背景上的干净16:9图表，从左到右追踪购买路径，有三个标记为"购物车页面"、"结账"和"加速结账(Shop Pay / Apple Pay / Google Pay)"的节点。在路径上方，一个红色"主题JavaScript"层仅触及购物车节点，在结账和加速结账上有红色X标记显示它不运行的位置。在路径下方，一个绿色"服务器端Function"层均匀跨越所有三个节点。最小平面矢量风格，品牌颜色紫罗兰和金色，无衬线标签，无摄影。
什么使折扣在负荷下可靠？
一个计算，在一个地方运行，对所有买家，在每个结账表面。
Shopify Functions是这个机制。根据Shopify的开发人员文档，Shopify Functions"通过在结账过程中运行自定义代码，使您能够自定义Shopify的后端逻辑。"Discount Function API，根据Shopify，"将此逻辑集成到结账流程中"，其中单个函数可以立即跨所有三个折扣类别、产品、订单和运费应用节省。计算发生在Shopify的服务器上，在结账管道内，而不是在购物者的浏览器中。
这是在BFCM上很重要的属性。因为折扣在Shopify自己的结账中的服务器端计算，相同的计算运行无论买家是在购物车页面、结账页面还是加速结账，因为加速结账通过相同的Shopify结账路由。没有可以静默跳过的主题脚本。购物车预览和最终收费不能分开，因为它们是相同的计算。Shopify Functions也设计成纯的：它们不能进行网络调用或到达其沙箱之外，这消除了整个类别的"第三方服务在负荷下超时"故障。
可靠性这里不是任何人都可以在营销标题中向您承诺的百分比。这是一套可验证的细节，您可以自己测试：
- 购物车中显示的总计与结账时收费的总计相同。
- 该总计在Shop Pay、Apple Pay和Google Pay中再次相同。
- 日程表由Shopify在折扣本身上强制执行，服务器端，不是由某人在午夜翻转开关。
- 实时活动可以暂停，暂停在大约60秒内迅速生效且全店面。
每个都是您可以在信任它与真实BFCM流量之前通过测试订单验证的东西。这就是可靠性优先方法的全部要点：您不是希望它保持不变，您是确认它会。
BFCM前可靠性检查清单
在BFCM之前的几周运行这个，而不是前一个晚上。每个项目都存在于它仍然便宜修复的情况下捕捉静默故障。
1. 在高峰之前安排每个活动
在BFCM周之前设置确切的开始和结束日期和时间，以便没有什么取决于一个人在他们也在监视流量仪表板时手动翻转活动。折扣上的日程表由Shopify本身强制执行：discountAutomaticAppUpdate突变设置一个startsAt和endsAt在折扣节点上，Shopify在日程表上激活和过期它，服务器端，无需任何人需要在线。使用商店自己的时区，并在每个开始和结束时间上仔细检查上午/下午。设置为在"12:00"结束的销售，您指的是午夜，但由于中午触发是经典的自我造成的BFCM伤口。
如果您在周末运行等级，例如早期访问15％折扣，然后25％主要活动折扣，请将它们背靠背安排，以便第二个在第一个结束的时刻开始。这消除了两个都可能同时适用或两个都不适用的任何窗口。
2. 使用模拟器在真实购物车上测试，包括一个不应该触发的
在活动上线之前，通过模拟器运行示例购物车，并确认合并总计恰好是您期望的，结账将运行的相同计算。然后做每个人跳过的部分：构建一个应该只获得某些优惠的购物车，并确认其他的正确地保持关闭。
静默故障两边切割。从不触发的折扣从不抛出错误，不应该触发但触发的折扣也从不抛出错误。仅测试快乐路径购物车告诉您有关您的BFCM百分比意外与现有代码堆叠并低价订单的情况。测试应该触发和应该不触发的购物车，并逐行阅读两者的结账摘要。
3. 明确验证加速结账
接受您真实的测试购物车一直通过Shop Pay。然后，如果可以，通过Apple Pay和Google Pay。这是主题的折扣逻辑泄露自己的地方，因为加速路径跳过该逻辑所在的购物车页面。基于服务器端Functions的折扣将在这里显示与购物车中显示的相同总计。任何依赖于浏览器脚本的东西都是您在您的客户之前捕捉购物车与结账不匹配的地方，而不是之后。
4. 确认您可以一键暂停
在周末之前，准确知道您将如何停止实时活动，并确认暂停全店面传播而不仅仅在下一个页面加载。您从未测试的暂停不是安全网。discountAutomaticDeactivate突变停用折扣服务器端，一个好的应用程序将其作为一个单个切换呈现，保存活动的设置，以便您可以在问题修复后恢复。在压力下删除和重建活动是五分钟价格修复变成两小时停机的方式。
5. 检查您的堆叠和限制
确认哪些优惠应该合并，哪些不应该，并记住Shopify的上限，以便您不设计无法工作的促销。折扣仅跨三个类别、产品、订单和运费合并，从不在同一类别内，Shopify只保留最高价值的。您可以激活每个商店最多25个基于函数的自动折扣，每个购物车行默认应用一个产品折扣，结账每个订单最多接受5个产品或订单代码加1个运费代码。在这些限制内现在规划您的BFCM优惠，同时您有时间重构。
图像占位符（图像2）：BFCM前检查清单
建议的视觉：浅色背景上的16:9检查清单卡插图，标题为"BFCM前可靠性检查清单。"五行，每行都有复选框和短标签："提前安排活动"、"模拟应该触发和应该不触发的购物车"、"验证Shop Pay / Apple Pay / Google Pay"、"确认一键暂停"、"检查堆叠和限制。"干净平面设计，紫罗兰复选标记和金色口音标题，大量白色空间，无衬线，无摄影。
BFCM当天运行手册
前期工作是可靠性赢得的地方。当天运行手册刻意简短，因为如果您进行了检查清单，周末应该很无聊。
- 在大门打开之前，通过标准结账和Shop Pay在您的真实商店上下一个最终实时测试订单，并确认总计精确到分。然后让活动独自一人。它们已经安排好了；让日程表完成它的工作。
- 看订单总计，而不仅仅是订单数，在每个等级上线的第一个小时。您在寻找一件事：一个订单，其中收费总计与该购物车应产生的不匹配。如果第一个小时内的每个总计在真实流量下都正确，它将保持正确。
- 如果某些看起来不对，先暂停，其次诊断。使用一键暂停，在数秒内全店面传播，安全的做法是立即停止流血，在测试购物车上确认问题，修复设置，并恢复。活动的配置保持保存，所以暂停只花费它关闭的分钟。
- 当一个等级结束时，确认下一个是实时且以前的折扣已停止应用。背靠背日程表自动处理这个，但在每个交接处的十秒检查是便宜的保险。
- 保持变更日志。使用时间戳记录每个暂停、恢复或编辑。如果稍后总计看起来不对，您想准确知道改变了什么以及何时改变。
运行手册的目标是您花费BFCM观看销售增长，而不是救火您的折扣引擎。
一个完整的BFCM周末：可靠的样子是小时对小时
这里是一个具体的两等级周末以及可靠性优先设置在每个步骤的行为方式。商店运行早期访问15％关闭，然后25％关闭主要活动，加上免费运费超过阈值，全部提前安排。
两件事使这个时间表平静而不是混乱。首先，折扣数学是相同的计算随处可见，所以周四测试订单是周五流量的真正排练。其次，12:20am的惊吓是六分钟暂停而不是数小时停机，因为暂停是一键，不会摧毁活动。
现在对比失败版本：一个主题脚本折扣，在办公室wifi上测试很好，静默跳过Shop Pay对于周五买家的一个块，并且不能暂停而不删除活动。提议是相同的。结果不是。
在Stackable上运行您的BFCM销售
如果您宁愿不手动审计每个结账路径并希望您的折扣应用程序在负荷下保持不变，这正是问题Stackable被构建来解决的，并且它在可验证的具体内容中而不是无一个无人可以检查的正常运行时间号中对可靠性致力。
- 每个折扣在Shopify的结账本身内通过计算Shopify Functions。没有客户端价格改写也没有草稿订单解决方法，所以购物车、结账和每个加速结账Shop Pay、Apple Pay和Google Pay，从一个服务器端计算计算相同的总计。
- 计划销售在由Shopify在折扣上强制的准确时间开始和结束，所以设置为午夜的活动在午夜开始，没有任何人在线，并且背靠背等级交接无重叠窗口。
- 暂停实时活动需要一键，并在大约60秒内全店面传播，活动的设置保持保存，以便您可以在问题修复后立即恢复。
- 购物车模拟器在您上线之前通过每个活跃优惠运行示例购物车，并显示准确的逐行总计，包括哪些优惠触发，哪些没有，所以您可以在数秒内测试应该触发和应该不触发的购物车。
- Stackable永远不会改变您的产品价格。折扣仅作为结账调整存在，所以如果您在活动中途卸载，没有什么要恢复的。
免费安装 Stackable，赶在 BFCM 之前确认购物车、结账和 Shop Pay 的金额分毫不差。usestackable.com/pricing 🚀
图像占位符（图像3）：一个总计，随处可见
建议的视觉：一个16:9插图，显示并排三个结账表面，购物车页面、标准结账和Shop Pay快速表单，每个显示相同的总计"2.00"，带有一个小绿色检查。一个单个服务器图标标记为"Shopify Function"坐在下方，有三条线连接到三个表面以显示一个计算给所有人提供。平面矢量风格、品牌颜色紫罗兰和金色、干净和最小、无摄影。
底线
- BFCM销售亏损的首要原因是在购物车中显示的折扣，但在结账时失效，或在Shop Pay、Apple Pay和Google Pay等加速结账中在高峰负荷下静默失效。
- 这些故障是架构性的：静默失败的客户端价格技巧、增加脆弱步骤的草稿订单解决方法，以及当出错时无法暂停的销售。
- 可靠性来自一个服务器端计算。Shopify Functions在Shopify的结账内运行折扣，所以购物车、结账和加速结账都产生相同的总计。
- 在高峰之前做工作：提前安排每个活动、模拟应该触发和应该不触发的购物车、验证加速结账，并确认您可以一键暂停。
- 通过您可以测试的可验证具体内容判断可靠性，相同的总计跨越每个结账表面和迅速生效的暂停，而不是无一个无人可以检查的正常运行时间百分比。
- 当天运行手册刻意简短：最终测试订单、观看第一个小时每个等级的总计、先暂停其次诊断、并确认每个等级交接。
- 永远不要让应用程序改写您真实的产品价格，所以如果您在活动中途卸载，没有什么要恢复的。
相关文章
- BFCM可靠性指南：为什么折扣应用程序在高峰中断，以及防止它的可验证承诺。
- 您可以暂停的计划销售：准时开始活动并暂停任何实时销售全店面在大约60秒内。
- 折扣堆叠，做对：三个按类别合并开关，由服务器端计算，所以购物车和结账一致。
- Stackable定价：计划、免费等级和每个包含什么。
- 折扣堆叠如何在Shopify中工作：为什么原生仅应用最高折扣，以及如何正确合并。
- Shopify Scripts正在结束：不需要开发人员迁移：在下一个大销售之前将基于规则的折扣逻辑移到Functions。
