What refund rate is normal, and when it is telling you something

Two refunds landed this month and you have been thinking about them ever since. Not the money — it was about sixty pounds — but the question underneath: is that a lot? You went looking for a benchmark, found four articles quoting four different numbers with no source attached to any of them, and came away no wiser. That search is a dead end, and it is worth explaining why before you spend another evening on it.

Why the number you are looking for does not exist

Refund rates vary enormously with things that have nothing to do with quality. A £9 impulse download bought from a viral video behaves differently from a £400 course bought after a six-week email sequence. Cold traffic refunds more than warm traffic. Products bought at three in the morning refund more than products bought at lunchtime. Any single figure that claims to cover all of that is an average of incompatible things, and averaging incompatible things produces a number that describes nobody.

There is a second problem, which is that most quoted figures are self-reported by people with a reason to look good, or lifted from a platform's aggregate that includes categories you do not sell in. You cannot check them. Building a decision on a number you cannot check is worse than having no number, because it feels like evidence.

So here is the honest answer, and it is genuinely the useful one: normal is whatever your store has been doing for the last three months, measured per product. That baseline you can verify, and a departure from it means something specific about a specific thing you sell.

One number, or one number per product

Most creators, if they track this at all, track it in total: refunds this month divided by sales this month. It is a comforting number and a useless one, because the whole point is to find out which product is causing the problem.

Building a baseline you can trust

This is a monthly job that takes about fifteen minutes once the habit exists. Do it on the same day each month, because a metric you check when you are anxious is a metric you will misread.

1. 1Open analytics in your store.fan dashboard and write down buyers and revenue for each product for the month just gone.
2. 2From your Stripe dashboard, note how many refunds you issued and which product each belonged to. This is why writing the product name on every refund matters.
3. 3Work out refunds divided by buyers, per product. Ignore any product with fewer than about twenty sales in the period; below that the percentage swings wildly on one person's change of mind.
4. 4Keep the figures in one spreadsheet, one row per product per month. Export your customer list to CSV if you want purchase history alongside it — that export is available on every plan, including Free.
5. 5After three months, you have a baseline. Mark the range each product normally sits in.
6. 6From then on, only react when a product moves outside its own range two months running, or moves a long way in one month.
7. 7When something does move, read the refund messages for that product before changing anything. The reason is almost always written there in plain language.

• Refunds concentrated on one product and one traffic source: the promise made in that place does not match what arrives.
• Refunds rising after a price increase, with the page unchanged: the page is still selling the old price's product.
• Refunds requested within an hour of purchase: usually a delivery confusion rather than a quality problem, so check what the buyer sees after paying.
• Refunds requested near the end of your published window: often people using the window as designed, which is fine and is what it is for.
• The same buyer refunding repeatedly across products: a customer-list question rather than a product question.

A worked look at two products

Suppose you sell a $19 preset pack and a $120 course. Over a quarter the preset pack takes 300 sales and 6 refunds; the course takes 45 sales and 5 refunds. Store-wide that is 11 refunds on 345 sales, a figure that would probably not worry you. Split by product, the two behave completely differently, and the course is the one to look at — not because five is a large number, but because it is a large share of forty-five.

Now add traffic source. If four of the five course refunds came from one link you shared during a live stream, the finding is not that the course is bad. It is that the pitch in that stream promised something the course does not contain. That is an afternoon's work on a sales page, not a rebuild. Without per-product numbers and source data in the same place, you would probably have discounted the course instead, and made the problem worse by adding volume to a bad match.

The mistake most people make

The common mistake is responding to a refund rate by changing the price. It is the most visible lever, so it gets pulled first, and it is almost never the cause. Refunds are usually an expectation problem: the page said one thing, the product turned out to be another, and the gap between them is where the request comes from. Dropping the price narrows the gap only by making the product cheaper to be disappointed by. Fixing the page removes the gap. Read three refund messages about the same product and you will usually find they all describe the same missing sentence, which you can then add to the description, the card on your link page, and the email that sells it.

Stop hunting for the number that tells you whether you are doing badly. Build the three months of your own history that tell you whether anything has changed, and then spend your attention on the one product that moved. That is a smaller, more answerable question, and it is the one that actually leads to work worth doing. Full analytics are included from Starter upwards; the details are on pricing.