The world is increasingly digital, yet one thing remains constant: the need for a physical address. Whether you’re a financial institution, verifying a customer’s identity or a merchant gathering shipping details, your customers’ physical location is central to the transaction. Unfortunately, online address collection is prone to error. Studies have shown that 20% of addresses entered online contained some type of mistake.
The heart of the challenge lies with the HTML form itself. You likely verify that Street and City aren’t empty and that the Zip has 5 digits. But beyond these rudimentary constraints, how do you truly know that an address is “correct”? At Lob, we wondered if we could tackle this problem, using our print and mail expertise. Having sent over 1 billion pieces of mail and delivered to 1 out of 4 US households, uniquely positions us to understand how to improve the user experience and deliver higher quality data.
Keep it Simple
Our vision at Lob is to connect the online and offline worlds, and we offer a range of print and mail APIs that do just that. Two of these are particularly relevant to online address collection: US Address Autocompletion and US Address Verification. While some customers have implemented custom solutions that incorporate these APIs into their address collection workflows, we wondered if we couldn’t create a packaged solution to simplify their use in a standard HTML form.
From our vantage point, we’ve discovered that an HTML form is the perfect place to enhance the user experience. Considerable time has already been invested, styling and arranging the fields. And the form itself is probably part of a well-defined workflow. But what’s missing from these solutions is a semantic understanding of what an “address” actually is.
Consider the following Web form used for an e-commerce site. It collects a user’s name, address, email, and phone. It’s well designed and already includes consistent branding, styles and behaviors, but it accepts any user input, regardless of accuracy.
The problem begins with the underlying HTML. Although it’s well-designed, it uses standard HTML inputs to collect the address. There’s nothing special about the input elements, and that’s exactly the problem. They will cheerfully accept any string the user types.
Our strategy involves tagging standard HTML elements with custom attributes to identify their true purpose. We then connect these fields to our Autocompletion and Verification APIs, augmenting and validating the user’s input as they type. For example, adding data-lob-primary turns a standard HTML input, into an Address Autocompletion input. It’s a minor change with a big impact.
<script src="https://gist.github.com/lobot/bf1def39efef930f194f8ef876861088.js"></script> As users type in the primary address field, their input is sent to Lob’s Autocompletion API in the background. A few keystrokes and one click later, the address is ready for submission with fewer errors in a fraction of the time.
Adjustable Verification to Match Your Use Case
Even with autocompletion enabled, users are bound to enter data incorrectly or lacking necessary information like a suite or unit number. And depending upon your specific use case, you may want to allow these to pass through or not.
Lob Address Elements verifies an address by intercepting the original form submission and pre-validating the address fields with Lob. In this case, the address is missing the suite number, and the user has been prompted to fix before final form submission is allowed.
Each time the user submits the form, the address fields are pre-validated with Lob.com. In this case, the validation has succeeded and the form is automatically submitted to its original endpoint. From the user’s standpoint, nothing has changed, but from a data quality standpoint, it’s a game changer.
We created Lob Address Elements to make it easier to leverage our APIs in your address entry workflows. And a key principle is to leverage what you’re already doing well. There’s nothing to rewrite--just a few additional attributes to add to your existing markup, and you’ll be up and running with a few minutes of work.
1. Register for a Free Account
Create an account at Lob.com, and then access your Public API Keyfrom the Settings Panel. The key to use begins with the prefix, “live_pub”.
2. Add Lob Address Elements
Open your existing markup and add the Lob Address Elements script immediately above the closing body tag. Include your Live Public Key, using the attribute, data-lob-key.
Add attributes to your existing HTML markup to identify key elements to enhance. For example, the data-lob-primary attribute is used to identify the primary address field in your form. Add other attributes as necessary to complete the experience.
strict, normal, relaxed, passthrough
Include this attribute on the HTML <form> element to pre-verify the user's address submission with Lob. Choose relaxed as the attribute value, if you wish to allow users to submit an errant form once they have been warned. Their resubmission of an unchanged form will be used to indicate their preference to override and submit. Choose normal (the default) to halt any submissions that Lob deems undeliverable, while still allowing all other inconsistencies to be submitted once the user has confirmed their choice. Choose strict to halt any submission that does not pass verification, including minor errors like missing or unnecessary units.
This attribute identifies the HTML element where all verification errors will be displayed. You are responsible for styling this component. The Address Elements library will show and hide this element as necessary to communicate verification issues.
This attribute identifies the primary address field. This should be an HTML text input.
This attribute identifies the secondary address field.
This attribute identifies the city.
This attribute identifies the state.
This attribute identifies the zip code.
This optional attribute identifies where to display field-level error messages that affect the primary address field.
This optional attribute identifies where to display field-level error messages that affect the secondary address field.
This optional attribute identifies where to display field-level error messages that affect the city field.
This optional attribute identifies where to display field-level error messages that affect the state field.
This optional attribute identifies where to display field-level error messages that affect the zip code field.
Please let us know what you think. We’ve included some additional links to help get you started.
This blog provides general information and discussion about direct mail marketing and related subjects. The content provided in this blog ("Content”), should not be construed as and is not intended to constitute financial, legal or tax advice. You should seek the advice of professionals prior to acting upon any information contained in the Content. All Content is provided strictly “as is” and we make no warranty or representation of any kind regarding the Content.
Stay up-to-date with Lob’s latest
We have a lot cooking in the Lobster tank! Sign up for our newsletter to never miss a beat.