Home/Research

Measurement note

Cost per order is wrong by exactly the confirmation rate

In cash-on-delivery retail, dividing advertising spend by orders placed gives a figure that is smaller than the real one by a factor you can know in advance. We published the optimistic version first and were corrected.

Published 2026-08-28

An order placed is not an order

In cash-on-delivery retail, submitting the form on the website does not end the sale. Support telephones the customer to confirm the order. A substantial share are cancelled at that call and never enter fulfilment at all. Nothing is picked, nothing is packed, nothing is dispatched.

A second loss follows later, at the door. The customer sees the parcel and refuses it. In this business roughly 13% of parcels are refused on delivery. That is a separate leak with its own denominator, and it is not the subject of this article.

So a per-order cost can be built on orders placed, on orders that entered fulfilment, or on orders delivered. These are different populations. Orders placed is the default because it is the number the shop platform reports and the number the advertising platform can be reconciled against, not because it is the number the business is buying.

One store, one day

One store, one complete day. Orders placed on the website: 182. Orders that actually entered fulfilment for the same day: 121.

The fulfilment count breaks down by state as 109 processed, 8 already in transit, 3 cancelled and 1 on hold. The states sum to the total, so the figure is auditable rather than asserted. Anyone can check the addition without access to our systems.

The missing 61 were cancelled at the confirmation call. That is consistent with the confirmation rate at cash on delivery, which runs at about 66% for this business. Roughly a third of what the website records as an order never becomes work in the warehouse.

The error is exactly the confirmation rate

Divide the same advertising spend by 182 instead of 121 and you get a cost per order that is about two thirds of the real one. This is not a coincidence and not an approximation. The numerator is identical; only the denominator changed. The ratio between the wrong figure and the right one is the confirmation rate.

That has a useful consequence. The size of the error is knowable in advance, without recomputing anything. A team that knows its confirmation rate knows precisely how wrong every per-order cost it has ever published against placed orders is, and can correct the entire published history.

The same logic extends further. If you want cost per delivered order, the refusal rate applies on top of the confirmation rate, on the same principle: same numerator, narrower denominator. We have not computed that figure here.

Same campaign, same day, opposite decision

The optimistic figure showed comfortable headroom above break-even. Read on its own terms it carried an obvious instruction: spend more, the campaign has room.

The corrected figure showed a modest margin instead. Same campaign, same day, same spend, and the opposite decision.

That is why the denominator is worth an article. The error was not a rounding difference in a report nobody acts on. It changed a verdict that money follows.

Where we were wrong

We published the optimistic figure first. The owner corrected it.

The mistake was not arithmetic. The division was right, the spend was right, the order count from the shop platform was right for what it counts. The mistake was using a denominator that counts an event — someone submitted a form — rather than the event the business is actually buying, which is an order that will be picked, packed and dispatched.

The assumption that failed was that the shop platform's order count and the business's order count are the same number. In a market with a confirmation call they are not, and the gap is large enough to invert a decision. Any measurement that crosses a system boundary deserves the same suspicion: the two systems are counting, but they may not be counting the same thing.

How to run the same check

Pick one store and one complete day. Count the orders in the shop platform. Count the orders in the fulfilment system for the same local day. Divide one by the other.

Details decide whether the result means anything. The timezone first: a day boundary taken in the wrong zone moves orders between days and manufactures a difference that looks like a confirmation gap but is a clock error. Then the state breakdown: check that the states sum to the total, so the number is auditable rather than asserted.

If the two counts differ, every per-order cost you have published is wrong by that factor, and you can correct the whole history without recomputing anything. If they match, you have confirmed that they match, which is also worth knowing.

Limitations

This is one store on one complete day, in a market where cash on delivery dominates and a confirmation call before dispatch is standard practice. A single day can sit above or below the usual pattern, and one store is not a portfolio.

The confirmation rate of about 66% and the refusal rate of roughly 13% are this business's numbers, not constants. Where payment is taken up front, the gap between orders placed and orders that enter fulfilment largely disappears, and the correction described here is close to a no-op.

What generalises is not the rates but the arithmetic that links them to the size of the error. Same numerator, different denominator, ratio equal to the pass-through rate between the two populations. That holds wherever a funnel step sits between the count you report and the event you are paying for.

Questions and answers

Why is cost per order misleading for cash-on-delivery stores?

Cost per order is misleading for cash-on-delivery stores when advertising spend is divided by orders placed, because many orders are cancelled at the confirmation call and never enter fulfilment. On one store and one complete day, 182 orders were placed but 121 entered fulfilment. The confirmation rate for that business runs at about 66%, so the cost per placed order was understated by exactly that factor.

How do I correct cost per order for the confirmation rate?

Correcting cost per order for the confirmation rate needs no recomputation. The numerator stays the same and only the denominator narrows, so the ratio between the wrong figure and the right one is the confirmation rate itself. A team that knows its confirmation rate can correct every per-order cost it has published against placed orders. Cost per delivered order applies the refusal rate on top, on the same principle.

How can I check whether my shop platform and fulfilment system count the same orders?

Checking whether a shop platform and a fulfilment system count the same orders takes one store and one complete day. Count the orders in each system for the same local day and divide one count by the other. Take the day boundary in the correct timezone, or a clock error will look like a confirmation gap, and check that the fulfilment states sum to the total.

Is a parcel refused on delivery the same loss as a cancelled order?

A parcel refused on delivery is a separate loss from an order cancelled at the confirmation call. Cancellations happen before fulfilment, so nothing is picked, packed or dispatched. Refusals happen later, at the door, and roughly 13% of parcels are refused on delivery in the business described. Each loss has its own denominator, so cost per placed, fulfilled and delivered order are different figures.

Does the confirmation-rate correction apply to prepaid online stores?

The confirmation-rate correction is close to a no-op for stores where payment is taken up front, because the gap between orders placed and orders entering fulfilment largely disappears. The confirmation and refusal rates quoted for cash on delivery belong to one business and are not constants. What generalises is the arithmetic: wherever a funnel step sits between the reported count and the event being paid for, the error equals the pass-through rate.

All research