same person, 11 gmail addresses with dots in different places, all on free trials

Normalise for detection, not for blocking. Store the address they typed - always send to that one - plus a normalised column where you strip dots and anything after a plus, for the providers where that's documented behaviour. Then you can see the pattern without breaking anyone.

Blocking on it will eventually catch a real person who typed their address slightly differently on two occasions, and you'll never hear from them again because your error message will sound accusatory. Flag it, look at it weekly, act on the ones that matter.

Middle path that worked for me: no block, but new accounts start on a lower quota that unlocks with either a card on file or a domain that isn't a free mail provider. Serial trialists get a usable but thin version, real evaluators barely notice.

Also worth logging a loose device signature - same IP plus same screen size plus same timezone across eleven accounts is a much stronger signal than email shape, and it doesn't depend on a provider's aliasing rules staying the same forever.

You have a value problem, not an identity problem. Someone doing this eleven times over four months is getting real use out of your product and has decided not to pay. Work out which kind of person that is - if it's a student who'd never pay, ignore it. If it's a business, the fix is making the trial limit bite on something they need rather than on time.

Disagreeing with the effort level here in general. Eleven trials over four months at small compute cost is maybe a few dollars of harm, and it has already consumed more of your attention than it cost you.

The version worth engineering is when a single trial can burn real API spend - that's when you need a card or a hard cap. Otherwise put a rate limit on signups per IP per day and go back to building.

One thing from doing this last month: check your database constraints before you change anything. Mine had a unique index on email as typed, so those eleven rows already existed, and when I added a unique index on the normalised column the migration failed on the existing duplicates and I hadn't planned what to do with them.

Ended up making it non-unique and just indexing it for lookups, which is what I should have done from the start.