How do you handle disposable or unconfirmed accounts after launch?
by•
We launched a SaaS recently and noticed a cluster of accounts created within minutes of each other that never confirmed email or returned after signup. We want to keep our user table healthy without accidentally deleting real users.
Curious what other founders do in practice, more specifically:
Do you auto-delete accounts after X days without email confirmation? If so, what timeframe worked for you?
Do you keep soft-deleted rows for analytics or GDPR reasons? Any retention windows you recommend?
If you have automated detection, what signals did you use (IP clusters; identical metadata; signup rate spikes)?
Cheers!
96 views
Replies
i'd start with manual reviews before building automation. it's easier to understand the patterns first.
@vincentbanzpk4Â absolutely, sometimes we overengineer things we're not so sure about yet. Thanks for the reminder!
A possible counterpoint: instead of cleaning up later, we try to stop the cluster forming. In the project I'm working on we put authentication and email verification behind an external provider (WorkOS), so an account only reaches our table once it is verified - the disposable and unconfirmed ones never land on our side. So we do not auto-delete, and we keep the table minimal. Happy to explain any of it in more detail if useful.
@alieksia Thanks Anastasiia, that looks like a solid approach. In my specific case I intentionally keep the auth layer minimal and avoid external providers because of the privacy guarantees I offer (no user-agent, no fingerprintable metadata, no third‑party auth logs, etc.).
But the idea of preventing unverified accounts from ever touching the main table is interesting. I might explore a lightweight variant of that pattern. Anyway, thanks for the idea - it'll probably fit other products on the roadmap!
@pedromlsreis That's a fair trade-off, and a stricter privacy line than most take. Makes sense that external auth does not fit your privacy promises. For a future lightweight version, a self-hosted auth tool could be a middle path - you still verify before anything reaches your DB, without sharing data with an outside provider.
@alieksia @pedromlsreis You can implement some simple checks yourself. Starting with a honeypot on your forms (fields that are not visible to users but will be filled by most bots). Email verification is easy to implement in your project too. While these won't prevent all bots (and in some case there are people creating fake accounts) it will, for sure, minimize the impact.
@alieksia @artk The honeypots idea sounds actually pretty clever to deal at least with the lower-grade bots, thanks for the suggestion!
The only hesitation that comes to my mind is that password managers or other browser extensions might inject data into those hidden fields, which can create false positives. Not really a deal-breaker, but something I would consider slightly risky and need to guard against.
And yeah, they don't really help with human-created fake accounts, but as a small extra signal they still seem worth trying!
One thing I'd push back on gently: auto-deleting unconfirmed accounts on a short timer is the part that bites people, because late-confirmers exist and you can't get them back. We soft-delete (flag + deleted_at) and just exclude unconfirmed from active counts, then purge much later. For detection, identical metadata + signup-rate spikes beat raw IP clustering for us — shared networks made IP too noisy. What did the cluster's user-agents look like?
@mincheol_kim appreciate the pushback, that’s a good point. Right now I don't auto-delete anything. Soft-deletion as a data retention policy sounds like the right long-term approach, so thanks for the hint! As for the clusters, my product is actually a privacy-based one, so I intentionally don't log user-agent or other fingerprintable metadata, The only signal I had was a burst of unconfirmed signups in a very tight window, all with no follow-up activity. That's why I suspected they weren't real users, but I couldn't go deeper than these timing patterns.
But you got me curious, how long is your retention window before you purge soft‑deleted accounts?
We have a 1 year inactivity account deletion with 6, 3 and 1 month notices. This also helps with GDPR compliance.
Analytics should be separate and not rely on your "working" records. This way you can safely change or delete users but retain analytics. Just make sure to anonymize data to not fall under unjustified PII retention.
Great question! This is a common pain point and something we also dealt with.
We auto-delete unconfirmed accounts after 7 days. It's a good balance: enough time for real users to notice and confirm, but not long enough to bloat your user table with dead entries.
We also keep soft-deleted rows with a reason tag ("email_confirmation_failed", "disposable_email", etc.), which helps us spot patterns and avoid re-adding the same bad signups later.
For detection, we use a simple combo:
Disposable email domain bloclist
IP Clustering
Email delivery failures
One thing we learned: don't auto-delete if the user did anything meaningful (like starting a trial or uploading data), even if they didn't confirm. That's a real user, just lazy or distracted. 😅
Hope this helps!
@wasil_abdal Thanks for going through the specifics. Unconfirmed accounts lasting seven days feels like a decent middle ground, especially if pair it with soft‑delete + your reason tags.
My setup is a bit different since I don't log IPs or use disposable‑email detection (privacy-first product), so timing patterns are basically my only signal.
Did you ever run into cases where someone returned after the 7‑day window and needed their account restored? If so, does that require manual data modification in your database, or how do you tackle it?
@pedromlsreis We keep soft-deleted rows with a deleted_at timestamp. If someone tries to sign up again with the same email within 30 days, we just restore the old row and resend the confirmation email. No manual DB edits needed.
For cases beyond 30 days, we treat it as a new signup but keep the old record for analytics.
Works well without any manual intervention.
@wasil_abdal cool, that makes a lot more sense now. Thanks for sharing!
I’d be careful with hard deletes too early. For unconfirmed accounts, I’d probably mark them inactive after 7–14 days, send one reminder, then soft-delete after 30 days. IP clusters, repeated domains, same user-agent/device info, and signup bursts are good signals, but I’d still avoid deleting anything that has billing, activity, or support history.
Clockk
The advice out there is to reduce friction on sign-up so that it's as easy as possible to create an account. We did the opposite. At Clockk added just a little bit of friction - a second screen that asks for your company name. Bot signups dropped to basically zero.
We tried auto cleanup and it backfired a bit. Some users just ignore emails or it lands in spam and they come back later confused. Now we keep everything for at least thirty days and only mark them inactive instead of removing them. It feels safer for early stage products.
@nafees_ahamad yeah, sounds like that's the common go-to practice around here, soft-deleting the users / marking them inactive. Thanks for your insights!