Why don’t more survey software packages offer zip code validation or real e-mail address validation? I don’t just mean syntax validation — anyone can offer that (although it is interesting that not everyone does). I mean real zip code validation where the postal code is looked up in a database or an e-mail address is tested as soon as it is entered to verify that it is real. It seems that both of these features would be easy to implement and would be of much use to the client.
Update: It turns out that SurveyGizmo already offers email validation lookup. This means that when you do a survey on their system and validate it using their software, it will check to make sure that the server exists! See their blog posting for details.
Zip Code Validation
There are about 42,000 zip codes in the United States. In Canada there are over 800,000 unique postal codes, although for most purposes (at least, for most survey purposes I’ve ever heard of) the first three characters (the “FSA”) is more than enough and there are only about 1,500 of those. It wouldn’t be hard for a survey software to offer a feature that validates postal codes as they were entered. Which is to say that with a database of less than 45,000 records it would be fairly easy for to automatically validate zip codes as they were entered.
Any why just validate? I can only imagine that a lot of clients would appreciate the option of knowing the city, state, census region, and even latitude and longitude of the people who take their survey based on the zip codes that they enter. All this information is inexpensively available at places like zipcodedownload.com and can be easily integrated into online applications.
E-Mail Address Validation
Real-time e-mail address validation is even easier because it doesn’t require a database. While a lot of survey systems (but again, not all) offer syntax validation, what is much more useful is real-time e-mail address validation where the system uses a component to contact the the respondent’s e-mail server to verify (a) that there is a server there (dns lookup); (b) that it is a mail server (mx record lookup); (c) that it can accept e-mail (smtp server validation); and (d) that the user has an e-mail address on that system.
All of these things are very easy and very fast to do (the deeper you get into it, the longer it can take — for example, verifying that an account exists on a server can take 30 seconds if the system even gives a reply — which is why I usually only go to the level of testing whether there is an active smtp server). Plus it almost guarantees that the e-mail address that ends up in the data base is a valid, working e-mail address.
For example, whenever someone starts one of my surveys I have them first enter their e-mail address — this is so that I can later award them a prize in whatever sweepstakes I have going on at the time. Since it would be troublesome for everyone if the e-mail address they give us doesn’t work, before I start the survey I first validate their e-mail address using a component called aspNetMX. If the e-mail address is valid (or at least links to a valid e-mail server) then I start the survey. If not, I have them re-enter their address until they get it right. You’d be amazed how many people will mistype an e-mail address over and over again (I keep a log of the errors so I can make sure it is working properly, and the errors usually are really respondent errors).
Once again, it would be a great feature to the client (and something you could promote as a feature of your software) if you offered real validation whenever possible which helps the client have better, cleaner data.