How to prevent free trial abuse without blocking real users
Why people restart your free trial with new accounts, the signals that link those accounts together, and a decision flow that stops repeat trials while honest users keep a card-free trial.
What free trial abuse actually looks like
Free trial abuse is one person starting your trial again and again with new accounts, so they never have to pay. It rarely looks like an attack. There is no flood of traffic and no stolen card. What you see is a steady trickle of accounts that each look fine on their own:
- A fresh disposable inbox. A temporary address from one of tens of thousands of throwaway domains, used once to confirm the account and never again.
- The same Gmail, written another way.
jane.doe@gmail.com,janedoe+2@gmail.comandj.a.n.e.doe@gmail.comall land in the same inbox. - The same laptop and the same home connection. The browser, the screen, the fonts and the IP address are identical to an account that was created a month ago.
Each of these accounts passes e-mail verification, so a simple “confirm your e-mail” step does nothing. The question you need to answer at signup is not “is this a real e-mail?” but “have we seen this person before?”.
Why the usual fixes hurt more than they help
Requiring a credit card for every trial
A card wall stops most repeat trials, but it also stops a large share of honest visitors who just want to try the product first. You trade an abuse problem for a conversion problem. Cards can also be reused across accounts, so on its own a card does not prove a new person either.
Blocking by e-mail domain only
A disposable-domain blocklist catches the laziest abusers. It misses Gmail aliases entirely, and a list copied into your code goes stale quickly because new throwaway domains appear constantly. We cover this in detail in How to block disposable email addresses at signup.
Blocking by IP address
IP blocks are the bluntest tool. Whole offices, universities and mobile carriers share addresses, and a determined abuser switches networks in seconds. An IP address is a useful signal in a score, not a reason to reject on its own.
The signals that link a new account to an old one
Instead of one hard rule, look at several weak signals and add them up. No single one should decide, but together they make repeat trials obvious.
| Signal | What it catches | False-positive risk |
|---|---|---|
| Normalized mailbox already exists | Gmail dot and plus variants of an existing account | Low: it is literally the same inbox |
| Disposable domain | Throwaway inboxes created for one signup | Low, if the list is current |
| Domain cannot receive mail | Typos and made-up domains | Low |
| Same device as an existing account | The same browser creating a second account | Medium: families and shared computers |
| Many signups from one IP today | Bursts from one network | Medium: offices, campuses, carrier NAT |
| Datacenter or Tor address | Scripts running on servers, anonymized traffic | Medium: some VPN users |
The pattern is clear: the signals with low false-positive risk can carry a lot of weight, and the ones that also hit honest users should only push a score up a little.
A decision flow that keeps honest users happy
The most effective setups we see don't block much. They give a card-free trial to almost everyone and add friction only when the score is high:
- Score the signup on the server, after the form is submitted and before the trial starts.
- Allow (low score): start the normal trial. This should be the vast majority.
- Review (middle score): start the trial but ask for something that costs an abuser more than it costs a real user — a card, a phone number, or a smaller allowance until they verify.
- Block (high score): don't start a trial. Offer the paid plan or a contact link instead of a dead end, because scores are probabilities, not proof.
Rule of thumb: a person sharing a laptop with a sibling should never be blocked by that fact alone. Only stack shared-device signals with something stronger, like a matching mailbox.
How to wire it into your signup
You need two things: something on the signup page that can recognize the browser, and a server-side check before you grant the trial. With Attrelix that is one script tag and one API call:
<!-- signup page --> <script src="https://attrelix.com/v1.js" data-key="pk_live_…" async></script>
# server, before starting the trial (Python) r = requests.post("https://attrelix.com/v1/check", timeout=3, headers={"Authorization": f"Bearer {SECRET}"}, json={"email": email, "ip": ip, "visitor": form["attrelix_visitor"]}) decision = r.json().get("decision", "allow") if r.ok else "allow" if decision == "allow": start_trial(user) elif decision == "review": start_trial(user, require_card=True) else: offer_paid_plan(user)
Note the fallback: if the check times out, the user is allowed. A fraud check should never become the reason your signup is down.
Measure it before you tighten it
Start in observe-only mode: record the decision for a week or two without acting on it, then look at the accounts that would have been sent to review. If they are mostly repeat trials, turn the consequence on. If you see honest users in there, raise the threshold or lower the weight of the signal that put them there. Tune on your own data, not on someone else's defaults.
Summary
- Repeat trials look clean one account at a time. Look for links to earlier accounts instead.
- Normalize e-mail addresses, check disposable domains, and recognize the device.
- Add signals into a score; let only strong signals decide on their own.
- Add friction on review instead of blocking, and always fail open.