Platform 9 ¾ may be a fictional location in Harry Potter where students would catch the Hogwarts Express, but fractional addresses do exist across the world, and even here in the US they are common. In this article, we will look at the implications of these addresses for address validation.
Fractional addresses usually come into play in larger cities, and in situations where a new location is created between two existing locations. Instead of renumbering the area to fit in the new address, they simply assign a fraction to it. This sounds like a simple solution to a problem – until these people start trying to get accurate deliveries.
These problems often involve the way the user interface (UI) and the address forms were developed, often because of home-grown solutions combined with a developer lacking mailing address knowledge in a way that unwittingly pushes away business. Don’t just blame the developer, however – it is easy to think, “Address Validation should be easy. I mean, how many kinds of addresses are out there, and how many different ways could an end user possibly enter an address into a form?”.
The answer to that question is that there is plenty of variation in addresses, and an exponential amount more in the various ways that people enter addresses into forms. Without this knowledge, some organizations create forms that do not allow “/” characters to be entered, so that “1/2” cannot be entered as a fractional address even though it is a legitimate and accurate part of the address.
Customers and end users alike in this situation try to circumvent the systems and try things like using “.5” instead of “1/2” or dropping the fraction altogether. When addresses are altered and entered in this way, underlying systems that are trying to do address validation can and will fail the address or recognize the address as a completely different address, leading to failed deliveries. In other cases, systems will strip special characters from the address without warning to the end user and decide the “1/2” to be “12”, and then assign that value as a unit instead of a fractional address.
After all that work to get past the address entry portion of a form, you are still not guaranteed that your package will be delivered properly. As a result, people in this situation often simply end up using a friend or family member’s address for important deliveries. They may even use their neighbor’s address when ordering dinner online.
So, what is to be done? Part of that solution falls on the research businesses do to learn about addresses, and how they can create useful UIs that allow for the proper input and handling of an address. Websites that don’t allow the “/” character or other characters like a “-” have made a short-sighted decision in the wake of thinking they are doing the right thing in their applications in trying to reject bad data, because as the saying goes, “garbage in is garbage out”. They have the right idea but the wrong implementation.
Sometimes these situations develop because the organization is only making a few rudimentary checks on an address and isn’t doing any real address validation, and sometimes it is merely a lack of understanding. In the end, organizations unwittingly end up turning away business when the end user can’t enter their address or when delivery goes wrong.
However, there is a standard when it comes to fractional mailing addresses, and the USPS does recognize them as part of the characters in the address range field. A little research goes a long way, but the best thing that can be done is often talking with experts before implementing a UI that accepts addresses. There are a lot of caveats to mailing addresses and address validation.
Service Objects handles special characters like the “/” just fine. For example, Cox Communications of Franklin has an address of
1008 1/2 MAIN ST
FRANKLIN, LA 70538-4317
This is the result from our Address Validation US 3 API:
{
"Addresses": [
{
"Address1": "1008 1/2 Main St",
"Address2": "",
"City": "Franklin",
"State": "LA",
"Zip": "70538-4317",
"IsResidential": "false",
"DPV": "1",
"DPVDesc": "Yes, the input record is a valid mailing address",
"DPVNotes": "26,28,38",
"DPVNotesDesc": "The input address matched the ZIP+4 record,The input address matched the DPV record,Street address",
"Corrections": "",
"CorrectionsDesc": "",
"BarcodeDigits": "705384317084",
"CarrierRoute": "C001",
"CongressCode": "3",
"CountyCode": "101",
"CountyName": "Saint Mary",
"FragmentHouse": "1008 1/2",
"FragmentPreDir": "",
"FragmentStreet": "Main",
"FragmentSuffix": "St",
"FragmentPostDir": "",
"FragmentUnit": "",
"Fragment": "",
"FragmentPMBPrefix": "",
"FragmentPMBNumber": ""
}
],
"IsCASS": true
}
Our system has no issues with the special characters and returns a DPV score of 1, meaning that the address is a valid mailing address. On the other hand, what happens when the “1/2” is entered as .5 instead? In this case, the system switches the .5 to a unit number and validates that. Since 5 as a unit number does not exist, the system returns a DPV score of 3, meaning that the street address is good but there is something wrong with the unit number.
Now, if we remove the fractional part altogether and try validating that, we get a valid mailing address returned through the validation process, but it is only valid because 1008 on Main St does exist as well. So, while the address technically passed validation, a delivery to this address will never make it to the right building. Our recommendation for curating input fields related to addresses is to limit error handling to only the necessary logic for the business, and pass the whole address entered by the end user to our address validation API to take care of evaluating the data.
Lean on our Address Validation Expertise
When clients work with Service Objects on address validation, we will help educate them about address validation so that they can create good end user experiences and leave the heavy lifting of address validation to us. We have over 20 years of experience in the address validation segment, and we are always happy to share this expertise with you.
In conclusion, while fractional addresses can complicate data entry and validation, a thorough understanding, and the right tools can streamline the process. Service Objects provides the expertise and technology to manage these complexities, ensuring that every address—no matter how fractional—is handled accurately and efficiently.
