Improving Address Data Quality at Input is Key to Increasing Match Rates
Data quality is perhaps the greatest challenge of modern business. Making decisions based on incorrect or incomplete data can be disastrous for a business. I have long appreciated the quote by Aristotle “Quality is not an act, it is a habit” and while I am certain Aristotle was not concerned with the ability to match addresses against reference data as we are at Fenris today, it is relevant, nonetheless.
In pursuit of data quality and assisting our customers with their endeavors to have better data quality and higher match rates we recently added an Address Description return field to API’s. The purpose of this article is to explain the various messages returned in this added field and to help customers and prospects who are testing our API’s to use these clues to prompt end users and hopefully increase their match rate.
The possible returns for the Address Description field are:
- Address verified
- City, state, and ZIP verified, but street address not found
- More than one possible address found
- Street address verified but unit is missing/wrong
- Address verification failed
- Address verification not attempted
- Artificial address matched
I will review some of the more common issues we see with input addresses below and suggest some reasons for and ways to use the description to help correct those errors.
- Street Address verified but unit is missing / wrong
One of the biggest issues we see in input addresses is missing secondary address information such as a suite or apartment number. For example, we may receive an input address of:
20 W 22nd Street
New York, NY 10010
In this case we identify that the address is a high rise apartment and that a unit number will be necessary. Sometimes in this case we can append it but you will still want to return the corrected address to the end user for verification in order to ensure a match as well as to retain the corrected address in your systems.
- City, State and Zip verified but street address not found
A second very common issue with input data quality is the Address Line 1 / Street Address line doesn’t match reference data. This is often a data entry error in which the user transposed numbers / letters but can also be from user input from those reluctant to give their full or complete information. This common occurrence can easily be corrected if the end user is prompted to review their input and receives messaging that accurate and complete information is required for input.
An example of this input would be when we see an address line one that is generic like 123 Main Street but with a legitimate City, State, Zip because the user is not sure if they want to provide an actual home address due to privacy concerns. But it can also be an unintentional error like entering 560 when you meant to type 506 for a house number.
This validation of input addresses is also effective for PO Boxes because our reference data includes the correct range of boxes available for each post office and zip combination.
- More than one possible address found
The final common address data quality example I would like to point out that is correctable by the end user is multi-match. This occurs when the address input is missing a directional like north or south and the house number exists in both directions or perhaps both a Street or Terrace exist with the same street name. For example, input address:
6488 Main Street
Arvada, CO 80007
It is possible that in Arvada, Colorado there are both South Main Street and North Main Street with the house number 6488. The person doing the data entry perhaps in a hurry or without realizing the two different streets are possible returns attempted to be brief and prevented the match. By prompting the end user, you have a second chance to correct and resubmit.
By implementing intelligent messages back to your end users to allow for correction of addressing errors we have data to suggest it can improve match rates by 5-15% for many of our customers. If you need any further assistance in how to best use this data, please don’t hesitate to contact Heather Rubesch in Customer Success for assistance in reviewing your specific data quality issues.
