Free shipping over $___ — what has to be true?

The arithmetic

For a candidate threshold T, with your margin m:

1. The cost side is measured, not modelled. It is the shipping revenue sitting in your own export, on the orders that would now get carriage for nothing. There is no assumption in it at all.
2. The uncertainty is pushed into one number you can judge. A sentence of the form "at least this share of your near-miss orders would have to top up" is a claim about your customers that you are better placed to assess than any calculator. "This will raise revenue by $1,240" is a claim nobody can assess, which is why it is not printed anywhere on this page.
3. Two readings are given, not one. The cautious one assumes a near-miss order adds the smallest amount that crosses the line. The other assumes it adds one item, priced at the median line item in your own file — because nobody adds $4.12 of something, they add a thing. The truth is between them, so the break-even is printed as a range and the cautious end is named.
4. The size of a typical added item is measured from your file, not chosen by us. It is the median of every line item price in the export. Earlier this was a percentage we picked, and a sweep of 256 shops showed that our choice, not the merchant's shop, was deciding whether any threshold had a break-even rate at all. Anything measurable must not sit in this page as a default.
5. Orders that top up are assumed to be a random slice of the near-miss band. If in practice only the ones closest to the line top up, it is worse than shown — those are the orders that add the least.
6. A break-even extra order is valued at your average order value × margin, with no shipping revenue, on the basis that an order attracted by free shipping qualifies for it. That is the smaller of the plausible values, so the order count it produces is the harder one to clear.
7. Both hurdles use the same measured cost, so they are two readings of one number, not two separate bills.

Why this does not just tell you a number

The usual advice is to set the threshold 15–30% above your average order value. That is wrong twice over, and both failures are the reason this page is shaped the way it is.

• Your past distribution cannot predict your future distribution. Changing the threshold changes the shape of the orders — that is what a threshold is for. Using the old histogram to forecast revenue under a new rule assumes the thing you are changing stays still. That is an invented elasticity, and no amount of arithmetic on this file can produce one.
• A threshold you already have contaminates the evidence for the next one. If you run "free over $50" today, the orders just above $50 are your policy's own footprint. Reading them as customer demand for a $50 line, and concluding $50 is about right, is circular. This page checks for that and stops rather than answering.

How the circularity check works, and what it is not

A free-shipping rule leaves an exact fingerprint that has nothing to do with guesswork: orders above the line stop paying carriage. So the check looks for the order value that best splits your file into "almost always paid shipping" below and "almost never paid shipping" above. If it finds one, this page will not rank thresholds, because every figure it could produce would be a reading of your current policy.

The obvious alternative — looking for a spike in the order-value histogram just above a round number — was built, measured against a store with a known $50 rule and a store with none, and thrown away. It ranked $85 as the strongest "threshold" in both files and never found the real $50 one. Order values pile up at sums of your own product prices, so a catalogue with an $89 item and a $56 item makes lumps that look exactly like a threshold. A detector that fires on a shop with no rule at all is worse than no detector: it would grey out a real answer.

The top-up channel is weaker than the advice assumes — and that is not a verdict on thresholds

A near-miss order only earns its keep if the margin on what it adds beats the carriage it was already paying you: top-up × margin > carriage charged. That is a low bar for a shop with fat margins and cheap postage and an impossible one for a shop with the reverse, and the exact figure for your shop is printed next to the sliders above rather than approximated here.

How often it bites was measured rather than asserted, by sweeping order value, carriage, margin and band width — 256 combinations. Some threshold has a positive top-up gain in 75% of them, and the stronger claim that top-ups alone could cover the entire cost holds in 57%. So this is a real effect and not a universal one; a shop with a small average order, thin margins and expensive postage sits on the wrong side of it, and that is the shop that sees top-up alone: never on every row.

None of that says a threshold is a bad idea for such a shop. It says the basket-size story is not what would pay for it, and the other story — a checkout people abandon less often — is the one this page is structurally blind to, because an orders export contains only the carts that converted.

What this does not know

• It cannot see the conversion effect, which is the main reason thresholds work. Free shipping over a line mostly earns its keep by reducing abandonment at the checkout, and your orders export contains only the carts that converted. The extra-orders column is the size of that effect you would need — never a claim that you will get it.
• It does not know what shipping costs you. The cost side is the shipping revenue you gave up, which is exactly right for the profit arithmetic, but it means this page cannot tell you whether your carriage was priced above or below what the carrier charged.
• Returns are not modelled, and topped-up orders can return differently. An item added to clear a threshold is a less considered purchase than the rest of the basket. If those come back at a higher rate, the gain column is overstated and nothing in your export can say by how much.
• Cannibalisation is not modelled. Some of a top-up is a purchase the customer would have made later anyway, moved forward rather than created.
• Orders below the near-miss band are assumed unchanged. In reality a threshold pulls some of them up too, which helps, and puts some off entirely, which does not.
• Per-line discounts are not read, only an order-level discount column. If your discounting is per line item, the before-discount and after-discount readings will be closer together than they should be.
• Mixed currencies are refused, not warned about. If a currency column can be mapped and it holds more than one value, this page stops and names them. Converting them would need the exchange rate on the day of each order, which is not in your file. Where no currency column exists this cannot be checked, and then it really is a limitation: an export with mixed currencies would produce meaningless figures and nothing here could tell.

Treat this as a way of finding out what you would be betting, not as a recommendation. Nothing on this page knows your customers.

More on why it is built this way: every free-shipping threshold calculator invents one number, and ours did too — the sweep behind the measured band, and the algebraic correction that turned out to make the prediction worse.