Address verification systems validate a user provided address against a database of known addresses, usually provided by Postal services. An example can be seen at http://www.qas.com/address-search/interactive-demo.htm

Has anyone had any experience with implementing an address verification system in online (application) forms? Any noticeable negative impacts on completion rates?

Any insights or experience you can share would be really appreciated.

  • I've seen some awful side-effects that made for a harsh UX. In one case if their was no exact match the address verification system would do a search for possible matches. Very useful, but unfortunately it would do a match against too many components of the address and so "1 Smith St" would get suggestions of "100 Smith St", "1/32 Smith St" (and the other 42 units at that building), "1 Smithers St", and more and more. It was painful to watch users react to that. – Erics Oct 17 '11 at 8:45
  • 1
    I think it's a great way to say "Are you sure this is correct? We found X possible problem with your address" but no way in heck would I trust it to actually reject user input. – Ben Brocka Oct 31 '11 at 13:07

It probably depends on your target audience and country. I've seen problems with these systems here in New Zealand because people often don't know their real postcode or official postal suburb. They enter what they think is their address, but the system says it's not valid and they end up frustrated.

  • I would blame that on the people in New Zealand in your case, just like I blame it on the people here in the US for not knowing their real, correct address (see my comment on snipe's post). If you don't know your correct address, then there is something seriously wrong there. – Charles Boyung Feb 22 '10 at 7:24
  • 1
    Seriously wrong? :) My correct address is "1 Foo Street, Point Chevalier, Auckland 1022". But "1 Foo St, Pt Chev, Auckland" is also correct -- if you write that on a postcard it will arrive at my house. NZ Post prefers the first format but does not require. If NZ Post doesn't require it, why should a web app? – Bennett McElwee Feb 22 '10 at 22:18
  • 1
    For a long time I lived on a street which had an official sign of "St Neots Ave". The name also lends itself to colloquial expression ("I live on St Neots", he said to a local). Turns out the official name was actually "St Neot Ave". – Erics Oct 17 '11 at 8:40

I agree with Bennett that it depends on the country.

Just one idea: the great user experience may be achieved if you use only one field for the address and automatically parse user's input (which may be very different of course). Though it's definitely not a great experience for a developer ;), it's not so hard to implement as it may seem.

  • 1
    For more on this excellent idea, see uxexchange.com/questions/1346/… – Bennett McElwee Feb 22 '10 at 22:22
  • 1
    Great suggestion - that's exactly what I was getting at with respect to the "Trail" vs "TRL" frustration below. If we know that verification systems use "TRL" for "Trail" (but human beings generally don't), converting that on the back-end before it's posted to the verification server is one excellent way to make that experience smoother. – snipe Feb 23 '10 at 15:37

I personally do not encourage these types of verification systems. Many people in the US live in rural areas where they only have a Rural Route, which can make the experience incredibly frustrating. I myself live on a trail, and those verification systems always throw an error, asking me to correct the street address to "TRL" - which is the same damned thing, so that annoys me quite a lot. I've learned to just write it as TRL, instead of "Trail", but only because those verification systems have caused me so much grief.

  • 1
    You are upset that a verification system asks you to use the proper verified address? I don't understand the complaint. I don't have strong feelings one way or another about address verification systems on websites, but this to me seems to be just a complaint because in the US we are coddled by the postal service. In many other countries, if you don't put the address 100% the way that their post office requires it, it won't get delivered at all. Just because the USPS corrects it for you it doesn't mean that you shouldn't be forced to correct it when you mess it up. – Charles Boyung Feb 22 '10 at 7:18
  • 3
    Maybe we're spoilt here in Australia as well, but I would have expected my local posty to be able to deliver my mail whether the address was 'TRL', 'trail' or even 'trale' - not everyone who writes a letter/sends a parcel has the luxury of being fully literate. From all the feedback I'm receiving, I beleive that address verification systems can certainly add a lot of value to both business and customer, but care certainly needs to be taken not to evoke a feeling of frustration in the user - either by making it to hard to provide a valid address or by not being able to deliver. Thanks. Marcus – Marcus Coghlan Feb 22 '10 at 9:58
  • 1
    Yes, it's pretty clear that forcing people to write "TRL" instead of "Trail" leads to a poor user experience. – Bennett McElwee Feb 22 '10 at 22:10
  • 2
    "You are upset that a verification system asks you to use the proper verified address?" When I write my address out for any other purpose, I use "Trail" - because that's what it's called. That's what it says on the sign at the end of my house, that's how it's said out loud, and that's how all of my mail except pieces that go through this screen process are delivered. I encounter verification systems so infrequently (and I'm never warned in the form that it will be verified) that my first response is to write it the way it sounds, and the way it appears on my street sign. So, yes, Actually. – snipe Feb 23 '10 at 15:33
  • 1
    Similarly sometimes the system insists you write "Ave" instead of "Avenue". That's just pedantic nonsense. It would be like a date entry field insisting on leading zeros. – Erics Oct 17 '11 at 8:50

I'm from Ireland and we have a very lax address format. Notably, we don't have an postcodes. Many webforms require you to enter a postcode. So it's common to just put "n/a"/"XXXX"/90210/etc. as a postcode just to get past that bit of the form.

One massive problem with address validation IMO is if the website tells you your address is invalid. I strongly suggest rewording that to "We couldn't understand your address format". I know where I live, my address I entered is valid.

  • +1 for user friendly error messages, and +1 for blaming the system and not the user – Erics Oct 17 '11 at 8:52

The International Postal Union lists address formats for 180 countries. If you can determine the correct format you should go and add adress verification...

However, if you cater for international users it is easier to use a single text box/field where the user can enter the address in his or her format (see Kostya's reply). Somebody can later pick up the entered address and add it to the system manually. I know, it's bad hard manual work, but it works ;)

  • Thanks Brian. Personally, I agree that the business should absorb the load and not burden the user any more than absolutely necessary. However, a reduction in manual processing is one of the main (popular with business stakeholders) drivers for implementing an address verification system. Its a valid goal. The costs of correcting addresses manually are substantial. Ideally, we'll find a solution which will not negatively impact the usability, or UX, of the form and, at the same time, achieve the goals of the business. After all, isn't that what we do :D Thanks for taking the time to respond. – Marcus Coghlan Feb 18 '10 at 22:32
  • Marcus makes a good point here - if you mess up entering your address and your product doesn't get shipped or takes potentially weeks to get it sent to the correct address, aren't you going to be wishing that the website had done address verification? And the other point about manual work as well - when you are dealing with a few orders, okay fine, have someone manually verify the address. But if you have a goal of actually making money with your system, you're going to need a lot more than just a few customers, and manual address verification becomes an impossibility. – Charles Boyung Feb 22 '10 at 7:22
  • ... if you can determine the address format you should go ahead and support it. It often it comes out of the box with some CMS or other software packages. However, if you want to add support for 10+ or even 50+ international formats ... it usually is going to cost you. It really depends on the actual business case, expected number of visitors, conversion rates etc. if it is feasible or not to spend money on this feature. E.g. for lead-generation vs. e-commerce vs. branding / b2c vs. b2b / startup vs mature company / ... – Brian Feb 22 '10 at 8:22

We have a number of quotation apps, some with address verification functionality and some without (and I'm in the process of scoping out the changes to add it to all apps).

The dropout rates for the apps that do not feature address verification are higher than those that require the user to manually input their full address details. I don't have any data or stats to provide, although I'll try and generate some to illustrate the point.

The only instances I can think of where address verification is cause for increased dropout rates is where it is poorly implemented in the form design, where it may confuse the user - for example, sites where the validation either spawns another window (i.e. not in-page), or the validation pre-fills the form but leaves the cursor at the top...(these examples off the top of my head).

Apart from a poor implementation, all I have seen are positive outcomes from address validation because it saves the user time and effort (and in big web forms this is a massive benefit because completing web forms in general sucks!!).

  • Thanks Nick. Think I've figured out your stance, but can I clarify your comment, "The dropout rates for the apps without address verification is much higher than without."? Did you mean, "The dropout rates for the apps without address verification is much higher than with." or the other way around? Thanks. – Marcus Coghlan Feb 18 '10 at 1:00
  • Sorry Marcus...the dropout rate for apps that do not feature address verification are higher than those that require the user to manually input their full address details. I would have been a terrible accountant or lawyer ;) – Nick Fine Feb 18 '10 at 9:04

Interestesting validation, haven't yet seen anything like it. What we have done is we tried forms in which the postal code is informed first, and if verified, fills in the rest of the address, which seems to be quite helpful.

  • 1
    Thanks Renata. We are actually considering this approach as part of the design, but I'm not decided if the benefits outweigh the potential costs to the UX. As usual, Luke Wroblewski has some interesting comments on this pattern. See lukew.com/ff/entry.asp?605 or lukew.com/ff/entry.asp?968 under 'Automatic city & state input'. Good to hear that its working for you. Cheers. – Marcus Coghlan Feb 18 '10 at 1:24

Here is the story: A while ago, Guido migrated from the US to Europe. His wallet got stolen. He reported the theft but the customer agent couldn't process the request since the report form required 5-digit postal codes (and Guido lived in Switzerland which has only 4-digit codes).

When the agent entered a 5 digit code fake, the system refused because the code was either incorrect (starting with 0) or it didn't exist in the US or because the code didn't match the city.

So my stance is: The system should accept anything. During validation, the system should try to match the address with its database. Now we have three situations:

  • Match. Great.
  • Similar but not perfect match. Offer "Did you mean?" to avoid typos in your database. Accept "No" and maybe flag the entry as "dubious" (so someone at your place can have a look - don't bother the customer about it).
  • No match. Accept it but flag is as "needs human intervention"

If you can, add Google maps or similar so customers can easily verify the correctness of the address.


I've seen address verification services have positive, and maybe a few negative impacts, on user experience.

It's a positive when it makes autocompletion easy and helps to standardize the address formatting. Users feel secure when they find that they can select the validated, standardized address that matches their input. It's nice to not have to worry about perfect punctuation (when should I put commas or periods?) or capitalization. It's also nice to save a lot of typing when you find the correct suggestion early. Furthermore, depending on system requirements (shipping?), ensuring a valid address can be more important than most other considerations.

On the negative side, it can be annoying to users if the address they want isn't valid or doesn't have results from the service. It's annoying because it can be confusing: having a list of suggestions that don't match what you want can cause the user to be confused about whether they can submit an address that hasn't been validated. (Generally, if you use validated suggestions, it is a good idea to allow the user to still enter whatever they want, regardless of the suggestions; but how do you inform them that they can? It's a problem, but I think it's ok to allow users to just keep typing input if the suggestion doesn't match and not say anything. They may feel insecure that their address isn't pulling up matches, but at least they can submit what they want to submit.)

Sometimes, websites allow the user to input an address, and when they click submit, they validate the input. They then tell the user that the address didn't validate (couldn't verify a match), or they allow the user to choose a matching address. This works for some needs, but personally, I don't think that's as good of a user experience. Generally, this kind of set up doesn't allow users to submit their input when they don't want to use the suggestions.

Full disclosure: I work for SmartyStreets, an address verification service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy