ShieldLabs
Anonymous visitor detection and fraud prevention
Spent this week reading every thread I could find where a founder asks how to stop one person from opening many accounts. r/nextjs, r/SaaS, r/webdev, r/laravel, some going back years.
The pattern is consistent and a little maddening. Someone writes "I don't want a single user to have multiple accounts." The top answer, almost every time, is a disposable email blocklist. Sometimes OAuth. Occasionally a phone number.
None of those answer the question that was asked.
A blocklist stops throwaway domains. It does nothing against one person with five real Gmail addresses, which takes about a minute to set up. OAuth proves the account exists, not that the person lacks four others. Phone numbers raise the cost, but there is a liquid market in numbers, so it is a speed bump rather than a wall.
The reason is structural: email is a claim, not an identity, and claims are free and unlimited.
What actually changes the math
The useful frame is not "how do I block this" but "what does one more account cost them, and can I make it cost more than it earns." Ranked by cost imposed on the other side:
Residential proxies. The biggest line item, and it scales linearly with account count. Datacenter IP is nearly free, residential is not.
Anti-detect browsers. Serious operations do not run raw Chrome. These are paid subscriptions with isolated profiles where timezone, locale, declared OS and rendering characteristics are set deliberately per profile. If your stack only reads user agent and screen size, this layer costs them nothing.
Device-level identification. An identifier computed from the device rather than stored in the browser survives cleared cookies, incognito and IP rotation.
Delayed payout or delayed credit. Underrated. Everything above is a one-time cost per account. Delay ties up working capital across the entire farm at once.
The cheapest thing you can do this week
Log a device-level identifier at signup and do nothing with it for a month. Then run one query: how many accounts share a machine.
That query is what ShieldLabs was built around, and it is also why the free tier is 5,000 identifications with no expiry instead of a two-week trial. The number only starts meaning something after you have watched your own traffic for a while, and two weeks is not a while.
Most founders are surprised in one direction or the other, and it tells you whether this is worth building anything for at all. I would rather someone run that query and learn they do not have a problem than buy a tool they do not need.
9 Comments
Anonymous visitor tracking is powerful. Are customers mainly using this for sales outreach or fraud prevention?
Fraud and abuse prevention. The sales outreach use case is a genuinely different product, and separating them is worth doing, because "anonymous visitor identification" gets used for both and that is why the category reads as vague.
Sales outreach needs person or company level resolution: matching a visitor to a real record so someone can reach out. That works by matching against purchased or partnered identity data, match rates are lower than the marketing suggests, and the privacy exposure is real.
What we do is device level. Recognising that this is the same device or browser as before, without knowing who the person is. No name, no email, no PII at all, just technical signals and IP. Enough to see one person running twenty accounts, nowhere near enough to email them.
That distinction is really important — those two use cases get conflated way too often.
Device-level without identity is a much clearer story, especially from a privacy standpoint.
The interesting challenge is usually proving effectiveness without the ‘visible identity’ anchor — how are you helping users trust what they’re seeing?
Good question, and it is the right one to ask about anything that scores you without showing its work.
Three things, and none of them are "trust us".
The score is decomposable. You do not get a number, you get the number plus the named signals that produced it. Anti-detect browser, timezone mismatch against the IP location, datacenter range, and so on. So the thing you are evaluating is not our confidence, it is whether those individual findings are true about that visit, and most of them you can sanity-check yourself.
Patterns show the linkage rather than asserting it. When the dashboard says these accounts are connected, it is telling you which device or connection they share and over what window. That is a claim you can take back into your own database and verify against what you already know about those accounts.
And the validation that actually convinces people is against their own ground truth. Most teams already have a set of accounts they banned manually, chargebacks they ate, or support tickets from obvious abuse. Run detection in observation mode for a couple of weeks without acting on it, then check what it flagged against that list. That is why the free tier is 5,000 identifications with no card and no expiry rather than a 14-day trial: two weeks is not long enough to accumulate the comparison, and the comparison is the whole point.
The honest limit is that this measures agreement with what you already caught, not what you missed. Nobody can hand you a false negative rate on your own traffic, ours included. What you can measure is the false positive side, and that is the number that decides whether you can switch it on at all.
One thing I enjoyed here is that you reframed the problem from identification to economics.
A lot of abuse prevention conversations become "Can we stop this?" when the more durable question is "Can we make it no longer worth doing?" That shift changes how you evaluate almost every solution.
That is the half I care about most, and it has a practical consequence I did not fit into the post.
It gives you a stopping rule. "Can we stop this" has no natural end, so teams keep stacking layers and keep breaking things for real users. "Is it still worth doing for them" has an answer, and once the answer is no, you can stop building.
It also reorders the work. Rank interventions by cost imposed on the other side rather than by how many cases they catch, and the list changes shape. Delayed payouts usually beat better detection, because detection is a one-time cost per account while a delay ties up their working capital across the whole operation.
The uncomfortable part is that it makes false positives a first-class cost rather than an acceptable side effect. If a control is cheap for them to route around and expensive for your real users, the economics say drop it, even when it does catch things.
I appreciate you taking the time to explain your thinking.
I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
Sure, you'll find the contact email on the official ShieldLabs website. Glad to keep the conversation going there.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.