To set profitable Shopify quantity breaks, compare the complete ladder with your current product page on contribution profit per visitor. A three-pack can make more dollars than a one-unit order and still be a bad promotion if it discounts existing multi-unit demand or earns less profit from the same traffic.
If the model leaves you with a ladder worth testing, Kaching Quantity Breaks can publish percentage, amount-off, or fixed-price tiers and report visitor, order, and revenue data. It cannot see your COGS, payment fees, fulfillment costs, shipping, or returns. This guide builds that missing profit layer before you put the offer in front of customers.
⚡ ShopSideK Verdict
Build the ladder in a profit model before opening the app. Use Kaching Quantity Breaks to publish and test only after the candidate beats the no-offer baseline under reasonable assumptions.
- Best for: Repeat-purchase or naturally multi-unit products
- Primary metric: Contribution profit per visitor
- ShopSideK deal: 20% OFF for the first 3 months
Profit-first roadmap
- Establish the current product page’s conversion, quantity mix, and variable costs.
- Model the full tier mix instead of comparing one bundle order with one single-unit order.
- Publish one qualified ladder, then replace assumptions with observed data.
Unlock 20% OFF Kaching for your first 3 months →
Kaching supplies visitor, order, and revenue fields. Add your store’s cost inputs outside the app.
A larger multi-unit order does not prove the ladder is profitable
Suppose a product sells for $30 and costs $9. Selling three units at a discount will usually produce more contribution dollars per order than selling one unit at full price. That comparison sounds reassuring, but it answers the wrong question.
Your quantity-break widget is shown to everyone who reaches the product page. Some shoppers would have bought two or three units without an incentive. Others may switch tiers. The widget can also change the page’s overall conversion rate. The correct counterfactual is therefore the existing product page and its full order mix—not a single one-unit order.
Three metrics describe different parts of the result:
- Average order value tells you how much revenue the average order contains.
- Contribution per order removes the variable costs caused by that order.
- Contribution profit per visitor combines order economics with the percentage of visitors who buy.
AOV is useful, but it cannot tell you whether the extra revenue paid for the discount and additional costs. Contribution per order is better, but it still ignores conversion. Contribution per visitor makes the current page and candidate ladder comparable on the same traffic base.
Establish the no-offer baseline
Start with a period that reflects the traffic you expect during the test. Avoid comparing a holiday promotion with an ordinary month or paid-campaign traffic with a mostly organic baseline.
Collect these inputs for the product or eligible product group:
| Baseline input | What to record | Why it matters |
|---|---|---|
| Product-page visitors | Visitors exposed to the buying decision | Supplies the common denominator |
| Orders | Paid orders for the eligible product | Produces the baseline conversion rate |
| Quantity mix | Share of orders containing one, two, three, or more units | Shows how much multi-unit demand already exists |
| Selling price | Actual item revenue after existing discounts | Prevents list-price math from overstating revenue |
| Unit COGS | Variable product cost | Captures the cost of every additional unit |
| Payment fees | Percentage and fixed order charges | Changes with both revenue and order count |
| Fulfillment and shipping | Pick-and-pack plus quantity-sensitive carrier cost | Extra units can change parcel weight or handling even when the first unit carries most of the shipping cost |
| Returns allowance | Expected return, refund, or replacement cost | Deep tiers can change both order size and return exposure |
If your cost sheet is incomplete, the Shopify profit margin calculator and growth guide can help organize the base inputs. For this comparison, keep fixed overhead separate unless the candidate offer changes it. A new app fee or campaign-specific creative cost is incremental; the same office rent under both options is not.
Calculate the baseline in two stages:
Baseline weighted contribution per order = Σ(quantity-mix share × contribution per order at that quantity)
Baseline contribution per visitor = baseline conversion rate × baseline weighted contribution per order
This preserves an easy-to-miss fact: a customer who already buys two units at full price is not incremental two-unit demand. Discounting that order is cannibalization unless the ladder changes enough other behavior to compensate.
Calculate contribution per order for every tier
The words tiered pricing and volume pricing are sometimes used interchangeably, although Shopify distinguishes incremental tier pricing from a volume price that applies after a threshold. For a typical DTC quantity-break widget, calculate the actual revenue and variable costs produced by each selectable option.
For tier t:
Tier revenue = quantity × regular unit price × (1 − discount rate)
Contribution per order = tier revenue − product costs − payment fees − fulfillment and shipping − expected return costs − other variable costs
Use the price the customer will really pay. If the tier is “Buy 3 for $76.50,” enter $76.50 rather than reconstructing it from a rounded badge. Add costs at the level where they change: COGS normally scales per unit, the fixed part of a payment fee scales per order, and shipping may move in steps when the parcel crosses a weight band.
Do not use gross margin percentage as the only guardrail. A tier can retain an attractive percentage while creating too few contribution dollars, and a lower percentage can still be acceptable when the incremental units add enough dollars. The decision needs both the rate and the dollars.
Turn the full ladder into contribution profit per visitor
Once each tier has a contribution value, add the two behavioral inputs the per-order calculation omitted:
- Tier take rate: the share of converted orders choosing each quantity option.
- Conversion rate: the share of exposed visitors who place an eligible order.
The tier take rates must add up to 100% of the modeled orders.
Weighted contribution per order = Σ(tier take rate × contribution per order at that tier)
Contribution profit per visitor = conversion rate × weighted contribution per order
You can also calculate the minimum conversion the candidate needs to beat the current page:
Required candidate conversion = baseline contribution per visitor ÷ candidate weighted contribution per order
Before launch, conversion and take rate are unknown. That is not a reason to skip the model. Run conservative, base, and upside cases. If the ladder loses money under any reasonable assumption, reject or revise it before spending traffic. If it wins only under an implausible conversion lift, it is not ready either.
After launch, replace the ranges with observed visitor, order, and quantity data. The model is a decision scaffold, not a demand forecast.
Compare a conservative ladder with an aggressive stress test
The following example is hypothetical. It is designed to show the method, not to recommend these percentages for your product.
Assume:
- Regular unit price: $30
- Unit COGS: $9
- Payment fee: 2.9% of revenue plus $0.30 per order
- Fulfillment and shipping for one, two, three, and four units: $6.50, $7.50, $8.50, and $9.50
- Expected return allowance: 3% of revenue
- Current conversion rate: 4.0%
- Current quantity mix for one, two, and three units: 85%, 12%, and 3%
At full price, the current contribution per order is:
| Quantity | Revenue per order | Contribution per order |
|---|---|---|
| 1 | $30.00 | $12.43 |
| 2 | $60.00 | $30.66 |
| 3 | $90.00 | $48.89 |
That mix produces a baseline AOV of $35.40, weighted contribution of $15.7114 per order, and contribution of $0.628456 per visitor.
Now compare two proposed ladders:
| Quantity | Conservative discount | Conservative contribution/order | Aggressive discount | Aggressive contribution/order |
|---|---|---|---|---|
| 1 | 0% | $12.4300 | 0% | $12.4300 |
| 2 | 10% | $25.0140 | 25% | $16.5450 |
| 3 | 15% | $36.1865 | 40% | $15.0140 |
| 4 | 20% | $44.5360 | 50% | $10.6600 |
The conservative case assumes a 4.2% conversion rate and an order mix of 55% one-unit, 28% two-unit, 12% three-unit, and 5% four-unit orders. The aggressive stress test keeps conversion at 4.0% and assumes a mix of 50%, 28%, 15%, and 7%.
| Scenario | Conversion | Weighted AOV | Weighted contribution/order | Contribution/visitor | Change vs baseline |
|---|---|---|---|---|---|
| No-offer baseline | 4.0% | $35.40 | $15.7114 | $0.628456 | — |
| Conservative candidate | 4.2% | $45.60 | $20.4096 | $0.857203 | +36.40% |
| Aggressive stress test | 4.0% | $39.90 | $13.8459 | $0.553836 | −11.87% |
The aggressive ladder raises AOV by 12.71% while reducing contribution profit per visitor by 11.87%. Nothing is wrong with the arithmetic: customers spend more per order, but the discounts give away too much contribution across the new mix.
This is why screenshots of higher AOV do not establish a profitable result. The cost-adjusted traffic metric can move in the opposite direction.
Set pass/fail guardrails before launch
A candidate ladder needs more than one green number. Define the rejection rules before a live dashboard tempts you to rationalize the result.
Use at least these guardrails:
- Contribution per visitor must beat the baseline. Set a minimum lift large enough to justify implementation risk and incremental app or creative cost.
- Every promoted tier needs a contribution-dollar floor. A visually attractive option should not be allowed to create an operationally weak order.
- The ladder must survive a conservative range. Lower the assumed conversion lift, shift more orders toward the most discounted tier, and increase shipping or returns. A fragile win is useful information.
- Inventory and fulfillment must tolerate the winning mix. More units per order can change parcel size, pick time, stock coverage, and backorder risk.
- Existing full-price multi-unit demand must remain visible. The more customers already buy multiples, the larger the cannibalization burden.
- Replenishment pull-forward needs a longer view. A three-month supply may move the next two orders into today rather than create three incremental units. Watch the repeat-purchase window before treating all added revenue as lifetime gain.
These guardrails do not tell you the universal “right” discount or breakpoint. They tell you what the final ladder must accomplish. Discount depth and quantity selection deserve their own analysis because product use rate, storage burden, shipping steps, and baseline unit distribution vary by store.
Use Kaching to publish the ladder worth testing
Kaching becomes relevant after the economics produce a candidate—not before.
Its documented Quantity Break type supports a percentage or fixed amount per item, or a custom total price for the selected quantity. The current Shopify App Store listing also describes product or collection eligibility, analytics, and A/B testing. That makes it a practical execution layer for a visible DTC ladder, while a native Shopify amount-off discount with a minimum quantity may be enough when you do not need the same presentation and testing workflow.
Set up the qualified candidate in this order:
- Select the product or collection that passed the economic screen.
- Enter the exact quantities and customer prices from the model.
- Make the unit price and total price easy to compare; do not rely on a percentage badge alone.
- Confirm the cart and checkout charge the modeled amounts.
- Record the launch date, traffic scope, and baseline period before evaluating results.
Kaching’s official A/B-testing documentation says a bundle block can have up to four variants and can vary tiers, prices, layout, images, and button text. Visibility and scheduling are not variant-level test settings. For the first in-app test, compare two ladders that differ in one economically meaningful way. Keep the prelaunch no-offer baseline as a separate benchmark unless your implementation provides a true control.
If this is the implementation layer you need, you can unlock 20% OFF Kaching for your first 3 months. Use the ShopSideK form to receive the code, then verify the exact offer on your own product, cart, and checkout before sending campaign traffic.
Kaching is not the right mechanism when your main problem is component-SKU inventory, a complementary cross-sell, or deciding which product should receive a quantity offer. The model can approve an economic hypothesis; it cannot turn the wrong offer architecture into the right one.
Join Kaching’s export with your cost model
Kaching’s documented analytics export includes daily visitor, add-to-cart, eligible-order, bundle-order, conversion, revenue, AOV, and revenue-per-visitor fields by deal and A/B variant.
That is enough to establish exposure and revenue behavior. It is not a profit-and-loss statement.
| Data layer | Example fields |
|---|---|
| Kaching export | Visitors, eligible orders, bundle orders, conversion, total revenue, added revenue, AOV, revenue per visitor |
| Shopify/order data | Product quantities, discounts, refunds, order-level line items |
| Merchant cost sheet | COGS, payment fees, pick-and-pack, shipping, return/replacement allowance |
| Calculated output | Contribution/order by tier, weighted contribution/order, contribution/visitor, lift versus baseline |
Kaching describes “added revenue” as revenue above the single-item purchase in its own example. Do not rename that field added profit. Extra product cost, discounts, fulfillment, and returns still need to be deducted.
Aggregate the test over a meaningful period rather than reading daily conversion rows in isolation. Kaching notes that a visit and its paid order can land on different days, and its reporting timezone may differ from the store’s operating timezone. Use period totals with consistent filters before joining the data to costs.
Do not let a conversion-rate winner become a profit loser
Kaching’s winner documentation says its declared winner is based on conversion rate and a z-test, with at least 10 orders per variant before a variant is considered. That is useful product behavior, but ten orders is not a universal guarantee that your profit decision has enough precision.
More importantly, the conversion winner and contribution-profit winner can differ. One variant may convert more shoppers by offering a deeper discount, while another produces more contribution from each exposed visitor.
For every variant, recalculate:
Variant contribution per visitor = variant conversion × variant weighted contribution per order
Then check the range created by uncertain returns and fulfillment costs. If the apparent winner changes under small, credible cost adjustments, continue collecting data or choose the less risky ladder. Do not use the app’s winner label as a substitute for the merchant economics the app cannot see.
When quantity breaks are the wrong offer
Reject the mechanism, not just the percentages, when the customer has no credible reason to own more units.
Common non-fit cases include:
- One-time, bulky, or slow-use products where storage creates more friction than the saving resolves.
- Products with strong full-price multi-unit demand, where the offer mostly discounts existing behavior.
- Thin-margin products with steep incremental shipping, handling, replacement, or return costs.
- Products whose variants or components require inventory and fulfillment behavior that a discount widget does not provide.
- Purchases driven by complementarity rather than repetition; a related-product upsell or another of the Shopify bundle approaches may match that job better.
The honest answer can be “do not run a quantity break.” A rejected ladder protects more profit than an attractive widget attached to the wrong product.
Your quantity-break decision checklist
Before launch, confirm all of the following:
- The product is naturally bought, consumed, shared, or gifted in multiples.
- You know the current conversion rate and quantity distribution.
- Every tier includes product, payment, fulfillment, shipping, and expected return costs.
- Tier take-rate assumptions sum to 100%.
- The candidate beats baseline contribution profit per visitor in a reasonable base case.
- The result remains acceptable under a conservative sensitivity case.
- Existing full-price multi-unit orders are included in the baseline.
- Cart and checkout totals match the modeled prices.
- The reporting period and traffic scope are recorded before the test.
- App revenue and conversion fields will be joined with merchant-owned cost data.
If the model passes and you want a visible implementation and testing layer, review Kaching and claim 20% OFF for the first 3 months. If it fails, revise the ladder or choose a different offer instead of asking a deeper discount to rescue weak economics.
Frequently asked questions
Are Shopify quantity breaks profitable?
They can be, but a larger discounted order is not enough proof. Compare the ladder’s conversion rate and weighted tier contribution with the current product page using contribution profit per visitor. Product fit, existing multi-unit demand, shipping, returns, and discount depth can reverse the result.
Can AOV increase while profit falls?
Yes. In the hypothetical stress test above, AOV rises 12.71% while contribution profit per visitor falls 11.87%. The higher order value does not cover the contribution given away across the discounted tier mix.
What is a good quantity-break percentage?
There is no defensible universal percentage. Start with the maximum customer price reduction that still meets your contribution-dollar floor, then test whether the resulting ladder changes conversion and quantity mix enough to beat the no-offer baseline.
Does Kaching calculate contribution profit?
Not from the documented export fields. Kaching supplies visitors, orders, conversion, revenue, AOV, and revenue-per-visitor data. You still need to join COGS, payment fees, fulfillment, shipping, returns, and other variable costs outside the app.
