Google Address Validation | What Google isn't telling you.
While Google does a great many things, it may surprise you to learn that Google does NOT parse and/or standardize addresses. In fact, Google Maps doesn't even validate the addresses they show you. Google's mapping API suite is impressive, but isn't perfect, and there are a lot of things it doesn't do. Below is the "everything you wanted know about address parsing and standardizing but were afraid to ask" explanation and possible solutions for you.
Table of Contents
What Google Does Not Do with Addresses
There are a lot of things that Google does. There are also a lot of services they don't provide. It's a trade-off that every business makes when they decide the scope of their offerings. For example, here at SmartyStreets we provide address validation and associated geocodes at wicked high speeds. We don't make shoes. We leave that part to Nike and Reebok. By comparison, Google offers mapping services, and a really sweet search engine (sorry Bing) among other things. But they don't parse, standardize, or validate addresses.
Applicable to this particular inquiry, Google can give you an estimation of where an address would be on a map. They won't tell you what the address is, or format it correctly (or tell you if it's real). So even though Google's a big name in knowing where things might be on a map, they can't tell you much about the address you give them.
So let's talk about that, and clear the air on a couple topics—particularly, what parsing and standardizing are, why you might need them, and how they relate to a process called "address validation."
Parsing is a general term that simply means having a computer analyze input and then try to determine what each piece of it means. Specific to our application, parsing an address means breaking it into its relevant parts: "123 Main" is the street address, "Manhattan, California" is the city/state, and so on.
It's sometimes tricky, as things like "St." can stand for either "Street" or "Saint." With hiccups like that, parsing (depending on the style of parsing used) can trip, mislabeling parts of the address and returning an inaccurate result.
Additionally, unless it's used as part of an address validation service, parsing doesn't check for the accuracy of an address to tell you if it's real. And unless it's paired with standardization, it doesn't fill in gaps of missing address data, or reformat it to meet mailing standards. All it does is try to break down data into its constituent parts and label them. It only really reaches full effectiveness when combined with the other two services of standardization and validation.
Still, it's nice when you don't have to go through and label all the cities and states yourself. There's only so many times you can reenter Albuquerque, New Mexico, before you start to lose it.
Standardizing is when you take an address, fill in gaps in the data, reformat it, and otherwise bring it up to a mailing authority's standards. (In the US, that authority is the USPS. Other countries have their own versions of the USPS.) It makes life easier for the postal workers, as they process no small number of addresses throughout a given day. It also makes keeping records easier, since there's a standard format to keep everything neat. Standardizing helps keep your data from being sloppy and difficult to read, and makes it look professional.
(By the way, the USPS uses the CASS standard when standardizing addresses.)
Standardizing is required before an address can be validated. It's also helpful if you want to fill in the missing information in your database, as well as helping deal with duplicates that you want to delete from the records (that's called deduplication, in case you wanted to learn a new word today).
Clarification time: parsing and standardizing are two different things, and one does not automatically include the other. An address can be parsed, but not standardized (as mentioned above). Likewise, it can be standardized, but not parsed. Parsing is the componentizing, and standardizing is the reformatting. Make sure you don't get the two confused.
Likewise, standardizing by itself does not validate an address. All standardizing does is clean the address up and make it look pretty.
Address validation (sometimes called address verification) is when a given address is compared against an authoritative database (like the USPS) to see if it can be shipped to. If it's registered with the database, the address will be marked "valid," which means it's real and your mail will make it there. If it's not on the list, the address is "invalid." An address might be invalid for a number of reasons, even if it physically exists.
To be clear, an address that validates is real, as the database only contains addresses that exist. Invalid addresses may or may not be real—reasons for being invalid vary, as stated above—but they for certain are not currently being serviced by the mail carrier.
So, in order of operations, an address is usually parsed, then it is standardized, and finally it is validated. If the address wasn't standardized before validation, its format might not match the way addresses are stored in the authoritative database. And if it doesn't match, it comes back as invalid because the system can't find its match.
Integral as they may be to the process of validation, neither parsing nor standardizing actually fill the function of interfacing with the authoritative database. Only validation does that. Along those same lines, parsing is not always included in the validation process, and not all parsing/standardizing service providers validate the addresses. That said, the three work best when used together.
So, what does this all have to do with Google Maps?
What Google Does Do With Addresses
Google does maps. Those maps include latitude and longitude (to pinpoint locations on said maps), time zones and other boundaries (to keep things organized), and roads and directions (you know, for getting places). The rest of what they do is meant to improve the functionality of the items above.
That's it. The whole kit and caboodle. There's no validation performed on the address you enter. Here's an example of what can happen because Google Maps is excluding the parsing-standardizing-validating process.
Knole Lane in Dennis, Massachusetts, is a cozy little place with lots of trees. So let's say you plug an address
15 Knole Lane, Dennis, Massachusetts into Google maps, it will show you this location:
So Google gave you a map. That's what they do. What they didn't do is give you an accurate or reliable map. Give that location a closer look; Google drops the pin next to a house that's very clearly on Croft Path, not on Knole Lane; and on the Knole side of the property, it's all just a bunch of those trees we mentioned. So, the address doesn't really exist. But Google Maps still gave you directions to it.
Think about that for moment; unless the house you're looking for is a treehouse, we're pretty sure that Google didn't give you something helpful.
Now, you may still be thinking, "Maybe they're off a little bit, but they probably still gave us something close to the address, right?" If you are, you are unfortunately mistaken. A quick trip to our demo page and a brisk tap of the keys on your computer will let you know that 15 Knole Lane is not a valid address.
As a matter of fact, there are only two deliverable addresses on that street: 30 Knole Lane and 33 Knole Lane. We don't want to state the obvious, but 15 Knole Lane is neither 30 Knole Lane nor 33 Knole Lane. Hence the address is not valid. (Yes, we have dizzying intellects here at SmartyStreets).
The point is, Google doesn't do everything, and if you're looking for genuine address processing or validation, Google isn't going to cut it.
So you're looking for parsing/standardization . . .
If parsing, standardizing, and knowing if an address is real are superpowers you would like to have, you can try them now for free to see how they work. Or if you have more questions, give us a call, and we'll help map out a solution for you.