What free trial abuse costs you, and how to stop it

What counts as abuse, and what is just a returning customer

Four behaviours get grouped under one name, and they need different answers. Serial trialling is the common one: the same person starts a new trial each time the last one ends. Multi-accounting runs several accounts at once, often to stay inside a free tier that was priced per account. Ban evasion comes back after you removed someone deliberately. Referral farming invents the friend who supposedly invited them.

None of these look like fraud in the payments sense. Nobody is using a stolen card. That is exactly what makes the problem awkward: the person is real, their intent is ordinary, and your fraud stack was built to spot something else entirely.

It also means the honest cases sit right next to the abuse. Two colleagues on one office network, a household sharing a laptop, someone who genuinely forgot they signed up in 2024. Any system worth installing has to tell those apart from the person on their fourth trial this quarter.

The cost is rarely the lost subscription

The obvious line is revenue: a trial that should have converted, taken again for free. For most products that is the smallest part.

Compute is usually bigger. If your trial includes model inference, video encoding, builds, crawling or anything else you pay for per unit, every repeat trial is a direct bill with no revenue behind it. Products with expensive trials are the ones abusers find first, and the ones where a hundred repeat trials a month is a real number on a real invoice.

Then your metrics stop meaning anything. Signups go up, trial to paid conversion goes down, and you cannot tell whether the product got worse or the traffic did. Teams have rebuilt onboarding to fix a conversion rate that was never broken.

Stripe, looking at first-party fraud across its own customers, reported that 7.4% of signups at AI companies were implicated in suspected multi-account abuse. Whether your own share is higher or lower, the point is that it is not a rounding error, and until you measure it you are guessing.

What actually catches it

Three ideas do the work. The first is that no single signal decides anything. A repeat device, a canonicalized address that matches an old account, a subnet that already spent a trial: each one is weak evidence with an innocent explanation, and the interesting question is how many independent kinds of evidence point at the same person.

The second is linking. Accounts that share something identifying belong to one cluster, and the cluster carries history the individual signup does not. A brand new address with no record of its own is a different proposition once you know it shares a card fingerprint with an account that consumed a trial last month.

The third is decay. Evidence gets weaker with age. A trial consumed eighteen months ago should not condemn someone today, and a system that never forgets will eventually refuse a large share of your honest returning users.

Put together, those three turn a pile of hints into one answer per signup: watch a real decision assemble if you want to see the shape of it.

Answer with a challenge, not only a block

Most systems offer two answers and both are expensive when wrong. A third answer fixes most of it: ask for one proof. A card that is only authorised, an email link, or a captcha where a bot is the actual suspicion. A real customer clears it in a few seconds and carries on. Someone on their fourth trial usually does not bother, because the whole point was that it should be free and instant.

Whatever the answer, the visitor should never be told which signal gave them away. Publishing your reasoning teaches the next attempt exactly what to change.

How to turn it on without losing customers

Run it in shadow first. Score every signup, record what would have happened, and let your app carry on allowing everyone. After a week you are reading your own traffic rather than a vendor's promise, and you can see whether the decisions match the judgement you would have made by hand.

{ "decision": "allow", "shadow": true, "wouldBe": "deny", "score": 81 }

Then move the thresholds rather than the code. Start by challenging where you would have denied, and only deny once the evidence in your own feed convinces you. Add a rule for anything true of your product and nobody else's, like never challenging your own staff domain.

Keep a way to be wrong gracefully. Mark a decision as a false positive, let the person through, and make sure the same signature does not keep costing you the same customer.