While many SaaS businesses have started to remove their free tiers due to abuse, we are determined to continuing to provide a free tier for our standard service. We strongly believe that people should be able to try Geocodio before having to pay for it, and we've found that this permissive policy has been helpful in growing our customer base.

But a free tier can easily be abused by creating multiple accounts. While low volumes of duplicate accounts is not a big deal, in recent years we have been hit by waves of bot traffic or high signup rates from the same actors.

A few bad actors with duplicate accounts could potentially overload the infrastructure we have set aside for free tier customers, which could degrade the experience for legitimate users or increase our infrastructure costs to a point where it is not economically feasible to sustain a free tier. This led us to rebuild and revise our abuse prevention system.

The user experience of abuse prevention

We hold the user experience in high regard, so it's important for us to make it easy to sign up for and use Geocodio. A good example of this is our spreadsheet upload tool that allows people to start geocoding a file without being asked to create an account first.

It is therefore not an option to have a lengthy signup process with all kinds of requirements, such as ID or phone number verification. We would also strongly prefer to avoid annoying hassles such as CAPTCHAs.

We also want to make sure that legitimate cases of multiple signups are supported.

Two frequent examples of this are universities that use Geocodio in their teaching and people giving workshops about geocoding. In such cases, we often see 50-300 people sign up for Geocodio at the same time from the same IP address. This might appear similar to the behavior of bad actors, but we don't want to block these signups.

Re-thinking our abuse prevention strategy

Our first stab at preventing abuse, many years ago, was rudimentary: we simply blocked multiple signups from the same IP address. If multiple people from the same company wanted to sign up, their signup was blocked, and they were shown a message prompting them to email us. We'd then manually create their accounts. But this was frustrating our users and it consumed unnecessary amounts of customer support time.

In our effort to prevent people from using $1.50 of free usage per day per account by creating multiple accounts, we were preventing legitimate customers from using Geocodio, and falling into the cognitive fallacy of loss aversion where one is more focused on the prospect of losing money than gaining a larger amount. This strict policy may have prevented bad actors, but it also led to lost business and thus costing us money on a net basis.

We abandonded the one-account-per-IP rule in 2017 and switched to requiring all users to verify their email address and using block lists for disposable email address providers, which were common among bad actors (but also some legitimate users...more on that below).

Over the years, we've built and gradually refined a more granular abuse-prevention system.

We have an intentionally-small team at Geocodio, so our current abuse prevention system has been designed to be mostly fully automatic and only require minimal human intervention. (We certainly learned our lesson from the manual account creation process mentioned above.)

Preventing abuse is, however, not as simple as just blocking bad traffic or disposable email addresses. It is a bit of a cat-and-mouse game where it is necessary to look at many factors to ensure that legitimate customers do not end up getting blocked.

We don't want to overengineer this, because in the end, there's only so much we can do to prevent bad actors from abusing our free tier. We have to accept a certain amount of abuse. It is a far better use of our time to use it improving Geocodio for legitimate users rather than trying to squash everyone who might create a handful of accounts. Someone who does not value the time it takes them to thwart our abuse-prevention system won't be a good customer for us right now, anyway. (And who knows, maybe their current client doesn't have the budget or they're a student, but someday, that might change.)

The latest version of our abuse-scoring system, created about a year ago, was developed not in response to free tier abuse, but rather a proliferation of abusive signups. Bad actors were creating accounts with other people's legitimate email addresses from major corporations, and the real account owners were reporting our account verification emails as spam—entirely understandably, as they hadn't created the account themselves! This caused issues with our sending reputation and didn't endear us to our transactional email provider.

Calculating risk scores

The core of our abuse mitigation is risk scoring. We are taking an approach of scoring signups using dozens of factors and calculating an individual risk score.

Creating the abuse-prevention system started with manual analysis of a random sample of free tier signups. There are some patterns that are easy for a human to identify, so each signup was manually classified as "likely spam," "unlikely," "abuse," or "unclear." We then created a risk-scoring system based on a variety of factors. Here's a truncated and redacted view of the scoring system:

While calculating the user risk score, we try to take many factors into account while keeping the users' privacy in mind.

Some of the things we're looking at are the browser user agent, as well as the IP address and country of origin. We also check the user's email address against a list of continuously updated domains that are known to provide disposable email addresses. (We've taken a bit of heat in the past for not allowing disposable email addresses, but unfortunately, this is one of the most common methods used by bad actors to create many accounts.)

On top of this, we also implement strict rate limiting as well as duplicate signup detection.

We also look for other patterns that we've seen with previous fraudulent signups (I am being intentionally vague here, as you can never be sure who's reading along).

We then test the risk-scoring system against our manual analysis, and refine it until the risk-scoring accurately classifies each pattern of behavior and appropriately flags possibly-suspicious signups.

Putting the risk score to good use

Now that we have a risk score for each user, we can take appropriate precautions.

High-risk signups are blocked and our team is notified via a dedicated Slack channel. Medium-risk signups might be asked to complete a CAPTCHA (boo!) or go through email address verification.

But even high-risk signups aren't entirely blocked. They're shown a message that they should reach out to our team if they think their signup has been inadvertently thwarted. We probably receive an average of one of these emails per month—a significant decline from our rudimentary system that simply blocked multiple signups from the same IP.

These measures allow us to continue providing a free tier without unnecessarily degrading the user experience when signing up unless we determine that it is warranted.

What's next

Preventing abuse is a never-ending challenge, so we continue to tweak our risk scoring when necessary and add or adjust risk factors.

With our risk factor framework, we have solid infrastructure in place to continue fighting bad signups without it taking up a significant amount of valuable time from our engineers. We also have a nice and transparent way to monitor the system via the Slack integration, so the entire team can keep tabs on what is happening.

By implementing our own abuse management system, we are able to provide a much more pleasant experience for our team and users alike, as we only require additional user verification or manual intervention when we deem that it is genuinely required.