Leveraging the Cloud to verify addresses is easy to do and can pay significant dividends. Incorrect shipping addresses, address typos in Web forms, "return to sender" stamps, prospects who never receive marketing materials, and customers who don't get communicated to can all be a thing of the past simply by integrating a single line of validation code wherever address data is collected, either electronically or by humans. Address verification represents one of the best examples of how to leverage a cloud service to provide value internally to an organization with very little effort.
The United States Post Office (as do other postal entities around the world) publishes updates to their master physical address databases monthly. These updates capture all of the new houses that are being built, new businesses that emerge, the launching of new zip codes, and all of the other address additions, updates, and deletions that occur throughout the U.S. on an ongoing basis. Utilizing this master reference data as a validation source can ensure the accuracy of all collected addresses, comparing those collected to a master list in real-time (a millisecond across-the-Web check). This is something you definitely want to do as the address is collected, as waiting to fix bad addresses downstream can far more costly.
Obtaining, managing, and updating this verification reference data in the raw for an organization that wants to put it to use for maximum address accuracy can be a quite difficult exercise to undertake on their own however, and most often can only be done at considerable cost, requiring hardware, software, personnel, and time. And shortcut approaches that try to leverage this data without the frequent updates can be an absolute disaster.
This is where StrikeIron and the Cloud come in. We acquire and update the reference data from various third parties as frequently as they allow, maintain the data in our data centers within our multi-tenant, high performance delivery platform, have built and perfected intelligent algorithms to handle address matching ambiguity (a straight, raw lookup won't work), and provide interfaces to these verification algorithms available in multiple protocols (SOAP, REST, HTTP Secure) so they can easily be integrated into any business process, application, Web site, or even mobile device. We pull all of this together, productize it, and deliver it as simple, easy-to-use plug-and-play Web services API. A single line of code from any platform is all it takes to tap into these algorithms that are living out on the Web. And like all good Cloud services, all of the details are abstracted away.
Best of all, our solutions are usage-based in cost, so you don't have to bet the farm just to get started, and you can always start small. And, free trials are available, so we can gain your trust before you subscribe. Give it a try today!
One of the features of StrikeIron's IronCloud platform is that it can accept invocations of Web services via multiple protocols including both SOAP and REST. This maximizes the audience of potential users and provides for a good deal of flexibility with multiple IDEs, coding styles, and platform implementations.
In addition to the support for SOAP calls within the platform (including SOAP Headers, SOAP parameter-based authentication, and SOAP w/ HTTP Secure) there is also support for accepting REST calls. This is achieved within the “Transformation” sub-system of our IronCloud platform, meaning we translate the REST call to its equivalent SOAP call before hitting the actual Web service living within our data centers, and then translate the response back to the REST format before it is sent back to the calling entity, and of course all within milliseconds.
This is powerful because it allows any of our services to be integrated into Web scripting languages and other places where a REST call might be more appropriate or convenient, and opens up the functionality to Web developers who can quickly put this concept to use. These REST calls for example can easily be used within PHP, Python, Ruby, ColdFusion, JavaScript, Perl and even embedded into Java, .NET, and other IDE platforms, including anything that can utilize Representational State Transfer (REST). In other words, REST provides a nice interface for easy leveraging of functionality out in the Cloud.
Here is an example using REST with our North American Address Verification service, a Web API that validates the existence of any address in the United States or Canada, and then standardizes the address according to postal standards (as well as appending additional data such as county and latitude/longitude coordinates). The example below can be entered into any Web browser address line as-is (with the appropriate authentication - click the Free Trials button to the right or contact StrikeIron to get access) in order to get a response. You can then change parameter values for different addresses to get the different corresponding responses. You can also try other methods within any of our Web services following the same form (you have to change the parameters to match the method of course).
Form:
http://ws.strikeiron.com/NAAddressVerification6/NorthAmericanAddressVerificationService/NorthAmericanAddressVerification?LicenseInfo.RegisteredUser.UserID=[UserID]&LicenseInfo.RegisteredUser.Password=[Password]&NorthAmericanAddressVerification.AddressLine1=[AddressLine1]&NorthAmericanAddressVerification.AddressLine2=[AddressLine2]&NorthAmericanAddressVerification.CityStateOrProvinceZIPOrPostalCode=[CityStateZip]&NorthAmericanAddressVerification.Country=[Country]&NorthAmericanAddressVerification.Casing=[Casing]
Example:
http://ws.strikeiron.com/NAAddressVerification6/NorthAmericanAddressVerificationService/NorthAmericanAddressVerification?LicenseInfo.RegisteredUser.UserID=***********&LicenseInfo.RegisteredUser.Password=******&NorthAmericanAddressVerification.AddressLine1=15501 Weston Parkway&NorthAmericanAddressVerification.AddressLine2=&NorthAmericanAddressVerification.CityStateOrProvinceZIPOrPostalCode=Cary NC&NorthAmericanAddressVerification.Country=US&NorthAmericanAddressVerification.Casing=UPPER
Because a REST call contains parameters including UserID and Password, we of course recommend to our users that these parameters be stored in a non-viewable config file and not the actual Web page source, or some other means of hiding credentials (within non-viewable code or within a database for example).
Have a REST-related question? Contact us at support@strikeiron.com Like a free trial? Contact us at info@strikeiron.com
As Point of Sale (POS) systems move to the Cloud and ecommerce transactions continue to grow at double digit rates, utilizing external APIs to optimize and essentially outsource functionality that isn't a core part of your business makes a lot of sense.
Leveraging Cloud-based business functionality not only provides short-term and long-term cost-savings, but also helps getting systems and new capabilities into production sooner rather than later. Using external resources also frees up internal resources to focus on those requirements and activities that are core to the business.
For example, when a product is sold over the Web, the automated ecommerce transaction can kick off a series of calls to external APIs that swiftly and accurately:
- obtain the required tax rate of the buyer based on geographic location
- verify the shipping address against constantly-updated postal data to ensure proper order fulfillment
- validate a customer provided a correct phone number and valid email address for communication purposes
- obtain other demographics for customer profiling purposes
In addition, prices can be shown in local currencies using live currency rates for greater accuracy, and shipment notifications can be sent via an SMS text message for enhanced customer service.
In each case, the functionality can be achieved either with an in-house system and all of the software, hardware, and ongoing data management ($$$$) that goes along with it, or an external API can be called, typically with a single line of code, as part of the automated business process triggered by the transaction. Hopefully, it is fairly obvious which would be easier, less costly, and more quickly achieved in most cases.
All of these capabilities, accessible in the form of SOAP and REST APIs, are available from StrikeIron for easy integration to many different ecommerce systems and development environments. This is why ecommerce and POS systems represent many of our top use-cases, as the real-time and "Cloud ready" nature of our offerings represent a better ecommerce experience for many of our customers and their customers.
There are three primary points of communication with customers and potential customers. They are the physical address (mail), the email address, and the telephone number. And often more than one in each case.
All businesses aren't the same, but in general, how important is it to communicate regularly with customers and contacts? What value can you place on the accuracy of data about your customers? Does it mirror the value of the customers themselves?
Most would agree that these data points about contact data are important enough to ensure resources are available to ensure this contact information is current, accurate, and complete. After all, these are the gateways to those who drive the bottom line. Can you afford for this information to be wrong or incomplete?
So what are some of the threats to "Big Three" accuracy?
One threat is that email addresses are changed regularly, often resulting in the disabling of existing email addresses. This can happen when someone changes jobs or leaves a company, and in an era where once the spam kings get a hold of an email address, 95% or more of email can be spam, sometimes email addresses are changed just to be relieved from this electronic deluge of junk email.
Also, at least 40 million Americans change their mailing address at least once each year, and this usually results in one or more phone numbers being changed. And of course with the skyrocketing popularity of smartphones, keeping up with a contact's various telephone points of contact can be a bear.
Each of these are just some examples of contact data can degrade over time.
Taking these "facts of life" and combining them with the large number of typos that can occur during the data collection process of these data elements, especially over the Web, and you have a recipe for a significant data accuracy problem.
Getting the "Big Three" right isn't always easy, but in most cases, investing effort and resources on this issue along with the application of various solutions designed to solve these kinds of problems can pay significantly dividends, both short-term and long-term. Focusing on these three primary points of contact, and greatly improving the validity and accuracy of that information, can go along way in getting the results you are looking for when communicating with customers and potential customers.
And of course, perhaps our Contact Record Verification Suite can help. We'd be happy to talk with you about it and help address your particular situation. After all, that's what we do every day.
The Addresses of prospects and customers are very important. Not only is a correct address required to properly ship a purchased item and to reduce customer service issues, it is also a very important piece of data in terms of ongoing communication with a customer or prospect. For example, the Direct Marketing Association (DMA) estimates over $170 billion is spent on direct marketing annually, communicating brand, new product information, and other account servicing information with a goal of lasting customer relationships.
These marketing and customer communication campaigns of course can have their effectiveness substantially decreased if the individual addresses that serve as the foundation of these campaigns are incomplete or incorrect. To quantify this, the United States Postal Service estimates there will be 6.8 billion mail pieces designated UAA (Undeliverable As Addressed) at a cost of about $2 billion in postage each year. In addition, the USPS also reports that there is something wrong with the address in 25% of all mailed pieces. The potential loss can be pretty significant on the bottom line if address quality is poor within customer and prospect databases.
And the heavy costs aren't limited to wasted postage alone. There is also the cost of wasted print and marketing materials, missed opportunities, and other poor customer service costs as a result of bad address data, all of which can very well be higher than just the cost of postage.
And as companies look for ways to be "greener" and environmentally-conscious, eliminating mass paper waste due to poor address data can score significant points in any of these initiatives, and of course is better for us all at the end of the day.
One way to achieve a substantially higher level of address quality is with StrikeIron's North American Address Verification product that focuses on US & Canada, and also our Global Address Verification offering for the rest of the world which handles addresses in over 200 countries (see the full country list here). Both of these solutions provide an easy-to-integrate Web service API that enables an address to be verified on-the-spot when collected from a Web form, within a business process, or manually entered from a data entry professional.
Here is an example:
Once the call out to our data services is integrated into an application or Web site (usually with a single line of code), that's it forever. We handle all of the ongoing monthly data updates to the master address data files so our customers don't have to worry about the growing and ever-changing address reference files the post office puts out each month.
It's always nice to save a few trees, especially when it's so easy and when there can be a large, positive impact to the bottom line to go along with it.
Once the call out to our data services is integrated into an application or Web site (usually with a single line of code), that's it forever. We handle all of the ongoing monthly data updates to the master address data files so our customers don't have to worry about the growing and ever-changing address reference files the post office puts out each month.
It's always nice to save a few trees, especially when it's so easy and when there can be a large, positive impact to the bottom line to go along with it.
When customers are using our address verification capabilities via a Web service API within their applications and Web sites, they often ask what the difference is between an "address validation" and a "delivery point validation."
The ability to determine both exists within our product offering, but there is often confusion concerning the difference between the two and where and why the distinctions are useful. So let me try to explain.
In the case of "address validation" and whether or not an address is "valid", this refers to the CASS-certification-related style of determining the validity of an address according to the United States Postal Service master database (typically employed to gain postal discounts). However, this particular database only contains ranges of valid addresses for a given zip+4 location rather than a listing of actual physical addresses.
In other words, if you are trying to validate an address of "500 Broad Street, Anywhere, USA 12345", the database will contain entries of the ranges street numbers of that street in that particular city, and if the address to be validated falls within that range of valid street numbers, an address will be considered valid. This is without consideration as to whether or not that specific address physically exists and mail can be delivered to it. There could be a "490" Broad Street, a "496", and then a "504", but no "500". However, because it falls within a valid range, it will be returned as "valid."
This is where "delivery point validation" comes in (also known as DPV). During the address validation process, if the DPV flag is set to Y (because it exists in the DPV database), then this means that this particular address does indeed physically exist, is a "delivery point" and mail can be delivered to it. This is a more granular indicator in cases where that is necessary.
Here is an example of the two approaches. In the first, "500 Broad Street" would be determined a valid address:
-resized-600.bmp)
In the second, the DPV indicator for this particular address would be returned as "N" since the address does not exist within the delivery point database:
-resized-600.bmp)
So while a CASS-certified style of address verification is useful and effective in a broad set of business cases, what this demonstrates is that in terms of saving postage on undeliverable addresses and address quality in general, the DPV indicator, with its database containing over 145 million verified delivery points in the USA and its territories, is a more effective means of determining the physical existence of a given address and whether or not mail can actually be delivered.
Using both together, which StrikeIron does within both its North American Address Verification and Contact Record Verification Suite offerings, is a great approach to better address quality within any system.
At StrikeIron, we have hundreds and hundreds of customers that use our address verification capabilities to ensure impeccable address quality in various business systems. These uses include CRM, call centers, marketing systems, for use in various GIS systems, and also to drastically reduce customer service problems associated with incorrectly shipped products in e-commerce scenarios.
Each of these individual customers is verifying addresses "in the Cloud" using our subscription-based
address verification offerings (delivered as easy-to-integrate SOAP and REST APIs), often several times a second each, twenty-four hours per day, seven days per week.
The primary reasons customers work with StrikeIron are because of our high performance delivery, the investments in reliable infrastructure we have made, and the zero data maintenance required to work with our products (we do all of the reference data updates in our own data center so our customers don't have to worry about the time consuming and costly process).
However, from time to time we get questions as to why a certain street address abbreviation gets applied, why a suite number gets standardized the way it does, and several other similar questions. Invariably, in the case of USA address verification for example (we also have Canadian and global address verification capabilities), we point people to the postal addressing standards documentation provided by the United States Postal Service (USPS). These guidelines define the correct abbreviations and address processing logic that is utilized within our systems. These rules also ensure the greatest level of address quality across multiple systems and use cases.
If you'd like to know exactly what these standards are, the USPS guidelines can be found here: http://pe.usps.com/cpim/ftp/pubs/pub28/pub28.pdf
So in addition to all of other great performance, reliability, and reduction of complexity reasons to integrate StrikeIron address verification into Websites, business processes, and other applications, another great reason is the assurance that we are utilizing the highest possible standard of address quality processing when we deliver verified, standardized, and enhanced addresses by the millisecond, anywhere in the World.
