Falsehoods programmers believe about signup pages(upollo.ai)
upollo.ai
Falsehoods programmers believe about signup pages
https://upollo.ai/blog/falsehoods-about-signup-pages
7 comments
It seems you mix “emails” as email addresses and as email messages here. It would be a little easier to read without that.
Also the W3C page about assumptions around names would be a good resource to link.
Also the W3C page about assumptions around names would be a good resource to link.
Is that this W3C page you were talking about? https://www.w3.org/International/questions/qa-personal-names
Great resource and definitely soon good things to add in for names, especially around changing them
Great resource and definitely soon good things to add in for names, especially around changing them
One that continuously comes up at places I work is email validation. Every place I've worked there's someone who want to ensure that users providing "real, valid emails", and no matter how often or clearly I explain why that's a hard problem, I've always seen the team tasked with putting something to attempt it. These days I mostly end up giving the "if you use that ad-hoc validation scheme, you'll block x% of potential signups", and let the business decide if x% is acceptable. That, or I tell them to integrate 3rd party accounts and let people user their google, facebook, or whatever login.
@cratermoon, out of interest what is the biggest negative impact you have seen from this?
I have seen a lot of people suggest blocking all free email domains or only supporting a small subset of whitelisted domains, I expect businesses to see pretty quickly that they lose a decent percent of legitimate signups.
The legitimate signups being the good measure as if you are filtering out disposable emails for instance you will lower your overall signups but should have no negative impact on revenue (potentially positive as people who would signup with disposable accounts now signup with accounts you can contact them on and they are happy to convert to paying with).
We try to make this easy be doing email validation for free at any scale and only flagging the people we are sure are not valid (disposable, unreachable domains etc.)
I have seen a lot of people suggest blocking all free email domains or only supporting a small subset of whitelisted domains, I expect businesses to see pretty quickly that they lose a decent percent of legitimate signups.
The legitimate signups being the good measure as if you are filtering out disposable emails for instance you will lower your overall signups but should have no negative impact on revenue (potentially positive as people who would signup with disposable accounts now signup with accounts you can contact them on and they are happy to convert to paying with).
We try to make this easy be doing email validation for free at any scale and only flagging the people we are sure are not valid (disposable, unreachable domains etc.)
If businesses want to pick and choose among domains for various like them being disposable email services or something, I tend not to argue, as that's not really a technical problem. The problems I highlight address technical misconceptions, like "all domains end with a 3-character TLD", or "valid email addresses are constrained to a certain character set". The only one you highlight as being "not valid" that is in fact technically wrong is "unreachable domains". There are many reasons why a domain could be unreachable in some sense but still be valid for email. If, on sending an email, it fails, then it can be blacklisted.
These days I see more providers going to a strategy of requiring the new signup hit a link sent in a confirmation email. In that case it's possible to accept nearly anything as an email address for signup, without any technical validation, because the ultimate accurate check happens: does the user get the email? Then the business is free to pick and choose and refuse certain domains without having to worry if they are tripping over some subtle aspect of RFCs 2822, 1034, or 1035.
These days I see more providers going to a strategy of requiring the new signup hit a link sent in a confirmation email. In that case it's possible to accept nearly anything as an email address for signup, without any technical validation, because the ultimate accurate check happens: does the user get the email? Then the business is free to pick and choose and refuse certain domains without having to worry if they are tripping over some subtle aspect of RFCs 2822, 1034, or 1035.
We wanted to share some of the data we have seen from analyzing signups at scale and insights from great companies like Hubspot.
It is by no means complete, so please share anything you believe is missing.
[1] https://github.com/google/libphonenumber/blob/master/FALSEHO... [2]https://beesbuzz.biz/code/439-Falsehoods-programmers-believe...