The dilemma of easy onboarding

All those of us who develop SaaS services know how important it is to attract the maximum number of users to our platforms so that they can test them, get to know them, become familiar with them and thus be able to start the conversion process from user to customer with some gained ground. Even letting some bad customers sign up.

The gurus of the onboarding processes have it very clear: the registration process on the platform and the steps necessary for users to start using it must be the bare minimum. Users should have the fewest number of hindrances in this process. So things like asking for company details, payment method, phone number, and even basic data such as first and last name are completely unnecessary. In theory, simply requesting the email should be enough, so that the user can start using the tool immediately.

Bad customers

In an ideal world, the user would start testing our service immediately, an account manager would contact to assist him in the process and possibly also involve the sales and pre-sales department (if the tool needs it). The user would test the service, and finally, decide if it is worth subscribing.

But in the real world, there are users who never have the intention of subscribing the service. All they want is to take advantage of the easy onboarding we provide in SaaS platforms for automatic registration. Thanks to VPNs, Tor and anonymous proxies they also browse the web covering their footprints. And they do it repeatedly. These users register with our SaaS platform over and over again. They wait for the trial period to run out and re-register with another email until the trial period expires. They are for sure bad customers.

These users are hardly going to be good customers someday, so having them during the trial period will only consume resources in our company and we will not obtain any benefit.  At a collateral damage, they will sink our conversion ratio from user to customer and we will have to take them in account when calculating our metrics.

They are users we must avoid. We have to protect our company from these users.

What are our options to avoid bad customers?

If we want our users not to abuse our services and not be bad customers we may ask them for a set of personal data and a  payment method with the promise that it will not be used if they unsubscribe before the end of the trial period.

But all this goes against the mantra ‘onboarding must be simple’. It is just the opposite: we are putting obstacles along the way to all our potential good or bad customers, not only the bad guys. We have to look for some different.

The alternative is to code in the user registration process several security measures. Thanks to Apility.io APIs it’s possible to check before registration if the user is going to be a good or malicious user. If they are identified as bad customers, the system can forbid the registration until the user provides secure data.

An example of a safer onboarding process

We believe in easy and quick onboarding processes. They have to be fast and user-friendly and put the user in front of the SaaS platform as quickly as possible so that they can test it.

In the case of Apility.io registration, only the user’s name and email address are requested. You only need to enter payment methods and billing information when you contract one of the payment plans.

However, several security checks have been implemented in the process to prevent bad customers from registering easily.

Where are the users connecting from?

At Apility.io we support users from all over the world. It is a global service where there is no discrimination by country of origin. I think it is worth remembering that there are Apility.io customers who do need to limit by country of origin for reasons of audiovisual reproduction rights, distribution agreements, and others. All these clients are able to know where their users connect from thanks to the Geolocation APIs.

However, we do limit the registration to users who connect from IP addresses that have been marked as malicious or are used from anonymous connections such as the TOR network. If a user tries to log in from one of these malicious IP addresses, the following message is displayed:

Apility.io bad customers blocked access

To add this check to your existing code is as simple as making a request to our API and check if the response was HTTP 200 – OK or HTTP 404 – NOT FOUND:

  • HTTP 200 – OK means that the IP was found in the blacklists. Hence, it’s a malicious IP.
  • HTTP 404 – NOT FOUND means that the IP was not found in the blacklists. Hence, it’s not a malicious IP.

A Sample in Python

In Python it’s just 4 lines of code:

import requests

def is_ip_malicious(origin_ip):
    response = requests.request("GET", "https://api.apility.net/badip/%s?token=YOUR_API_KEY" % origin_ip)
    return response.status_code == 200

This restriction has been applied only to the registration page. Once the user has been successfully registered we don’t restrict the access to other pages of the site.

Some smart readers will probably think that this is something they can do easily with a traditional Firewall or a Web Application Firewall. But they are oriented to allow or restrict the access to a full site, something we consider excessive: we are not against anonymity on Internet, we are against anonymity in a very specific step of the registration process where it’s mandatory to know who is signing up. Besides, even the most advanced Web Application Firewalls today has serious issues blocking access to resources inside Single Page Applications (SPA) like our Dashboard. For Single Page Applications, you have to implement this feature on the server side.

Is the user’s email valid?

Typically, when a user signs up to a new service there is a list of validations to perform on the email like:

  • is the email well-formed?
  • is there anybody registered with the same email?
  • Does the email exist? (Sending an email to confirm the registration).

First two validations are transparent to the end user and the last one needs an action from the user to confirm (Some onboarding Gurus will tell you this step is not necessary and you should allow the user to start with your service before the confirmation).

Thanks to the Apility.io Email Validation and Verification scoring API it’s possible to know in advance if:

  • the email is a Disposable Email Address.
  • the mail Inbox of the user exists or not.
  • the email has been used before for some kind of abuse or malicious activity (mostly SPAM).
  • the email service is using fraudulent services running malicious Naming (DNS) and Maling (SMTP) services.

All these tests are performed in milliseconds with almost no impact on the performance of your site. If you have signed up in Apility.io then your email has passed all these tests successfully. If you try to enter an email that does not exist or is a disposable email address then you will get this message:

Apility.io register bad customers email restriction

To add this check to your existing code is as simple as making a request to our API and check if the response was HTTP 200 – OK or HTTP 404 – NOT FOUND:

  • HTTP 200 – OK means that the email has a negative score and probably is not a good idea to let the registration continue. Hence, it’s a malicious email.
  • HTTP 404 – NOT FOUND means that the email has a neutral or positive score and the registration process can continue. It’s a good email.

Another Sample in Python

In Python again is a very simple piece of code:

import requests

def is_email_malicious(email):
    response = requests.request("GET", "https://api.apility.net/bademail/%s?token=YOUR_API_KEY" % email)
    return response.status_code == 200

The combination of several validation techniques based on custom-built algorithms scores the legitimacy of an email. After the execution of the process, the addresses have been ranked. Clean and good email addresses will have a neutral or positive score. Suspicious addresses will have a negative score. The more negative the score, more probability of being an invalid address.

Being picky

One of the most powerful features of Apility.io is how we crawl the net looking for all the public and private blacklists of IP addresses, Domains, and Email addresses. Sometimes these lists can make legit Email addresses look suspicious. This can be the case for Free Email Service Providers like GMail, Hotmail, etc… To help you avoid this inconvenience of banning these users, you can choose what lists should be used with the scoring algorithms. Again, you have to log into the Dashboard and go to Blacklists to enable and disable the lists individually.

Apility.io deselect Free Mail

Some companies do not accept emails from Free Mail Providers because the only want emails linked to domains of potential business customers. If this is your case, then you don’t need to disable the FREEMAIL check.

Activity

If you are a registered user then you have access to historical data of your requests, You can review who tried to register and from what IP addresses thanks to the Activity dashboards with historical information:

Email Verification and Validation Service

Does it worth it?

One of the reasons why I created Apility.io was exactly because of bad customers trying to abuse of a SaaS platform we had up and running in a former company I owned. We reduced the number of bad customers about 90%. You can read more about it in this interview.