Posts Tagged ‘Address Validation International’

DOTS Address Validation International (AVI) enables businesses to develop consistent addressing formats for your international addresses.

AVI Address Output: We Speak Your Language

You say tomato, I say tomahto.
You say Rome, I say Roma.
You say Munich, I say München.
Let’s Not call the whole thing off.

Have you ever wondered why the country code and abbreviation for Germany is DE, or similarly why it is ES for Spain? Unlike FR and CA, which are France and Canada respectively, DE and ES seem out of place for Germany and Spain. A simple explanation is that DE is short for Deutschland and ES is short for España – which are the names used locally for these countries.

Local names such as Deutschland and España are known as endonyms, and Germany and Spain are English language exonyms. You may be wondering, what are endonyms and exonyms? To put it simply, endonyms are the names of places used by the locals and exonyms are the names used by foreigners. So an endonym is what a country calls itself, and an exonym is the name used by other countries.

(As another example, United States is an endonym for, well, the United States. Meanwhile, exonyms for the United States will depend on the country involved: the French call us the États Unis and the Russians call us Соединенные Штаты.)

The DOTS Address Validation International (AVI) service currently offers three output language options to let the end user choose their preferred language setting and behavior: ENGLISH, BOTH (English and local addresses), and LOCAL_ROMAN. Let’s examine each of these in detail:

ENGLISH – Instructs the service to return the address in English, without any localized text or accents.

BOTH – Instructs the service to return a standardized address in both English and in its localized text (e.g., Cyrillic, Chinese, etc.) and format when applicable.

Here’s an example of a Chinese address in both English and in its local Chinese text.

Address input in English

No. 1514 Changyang Lu
Yangpu Qu, Shanghai Shi

Address output in Simplified Chinese

上海市杨浦区长阳路1514号

 

Here’s an example of a Russian address in both English and Cyrillic.

Address input in English

Kommunarov Ul, 290, 9
Krasnodar
Krasnodarskiii Kraii
350020

Address output in Cyrillic

Коммунаров ул, д. 290, OFFICE 9
КРАСНОДАР
КРАСНОДАРСКИЙ КРАЙ
350020

 

One last example, this time in Greece.

Address input in English

Alkamenous 76
104 40 Athens

Address output in Greek

104 40 Αθηνα
Αλκαμενους 76

 

LOCAL_ROMAN – Instructs the service to return the address in its local spelling using Roman text.

For example, the city of Rome will be returned as Roma, Naples as Napoli, Dublin as Baile Átha Cliath, Naestved as Næstved, and Cologne as Köln. Let’s take a look at some address examples.

Here’s an example of an address in Italy.

Address input in English

Via Villafranca 20
00185 Rome RM

Address output in Italian

Via Villafranca 20
00185 Roma RM

 

Example of an address in Denmark

Address input in English

Kobmagergade 20
4700 Naestved

Address output in Danish

Købmagergade 20
4700 Næstved

 

Example of an address in Germany.

Address input in English

Weisshausstr. 20-30
50939 Cologne

Address output in German

Weißhausstr. 20-30
50939 Köln

 

The service also has the ability with some countries to accept an address in its localized spelling and text and return the address in English. Try entering any of the address examples above into the AVI service using the local language, spelling, and format with the output language set English to see the address validated and standardized into English. When submitting an address in a non-English language, be careful to ensure that the text is properly encoded.

The AVI service cannot correct corrupted characters, so it is important to ensure that anything that will hold the address in memory and stores the data can support the character set. Otherwise, you will end up with data corruption, which is not always easy to detect or fix.

For example, in some cases, a character may simply come back as a question mark ‘?’ or a square ‘■’. Take the following address.

Weißhausstr. 20-30
50939 Köln

The fourth character of the first line and the eighth character of the second line will come back corrupted, as follows:

Weihausstr. 20-30
50939 K?ln

 

In other cases, the corruption can be quite severe, and you may end up with something like ‘تخت اره ÙŠÚ©’. Not only is it important to ensure that you do not send any corrupted data to the AVI service, but you also want to make sure that you properly handle and store the service response. Otherwise you may end up corrupting an address after it has been validated. (How this happens would make a good topic for another blog, but for now, just make sure to use the Unicode Transformation Format (UTF) on everything that handles the data.)

Each of these options gives you the flexibility to have a consistent addressing format for your international addresses, depending on your location, your customers, and your mailing conventions. All of them provide an automated, consistent approach to address validation. Whether it is addressing mail to customers in the format of their home countries, translating addresses, or ensuring readability for the sender, DOTS Address Validation International truly speaks your language.

Address Suggestion with Validation: A Match Made in Heaven

In an ideal world, data entry would always be perfect. Sadly, it isn’t – human errors happen to end users and call center employees alike. And while we make a good living cleaning existing bad data here at Service Objects, we would still much rather see your downstream systems be as clean as possible.

To help with that, many organizations are getting an assist with Google, in the form of the Autocomplete with their Places API.  If you setup your form properly and use their API you can have address suggestions appear in a dropdown for your end users to take advantage of to help enter correct data into your system. That’s great, isn’t it?

It does sound great on the surface, but when you dig a little deeper there are two problems:

  • First, Google Places API often does not often suggest locations to the apartment or suite level of detail. The point is that a considerable segment of the population lives in apartments or does business on separate floors, suites or buildings.
  • Second, the locations the Google Places API suggests are often not mail deliverable. For instance, a business may have a physical location at one address and receive mail at a completely different address.  Or sometimes Google will just make approximations as to where an address should be.

For example, check this address out on Google Maps: 08 Kings Rd, Brighton BN1 1NS, UK.  It looks like a legitimate address, but as the street view shows, it does not seem to correspond to anything.

These issues can leave gaping holes in your data validation process.  So, what can you do? Contact us at Service Objects, because we have the perfect solution: our Address Suggestion form tool. When combined with the Google Places API you will have a powerful tool that will both save time and keep the data in your system clean and valid.

This form tool is a composite of the Google Places API and our Address Validation International service.  The process consists of the data entry portion, the Google Paces API lookup, then the Address Validation International service call, finally displaying selectable results to the end user.

Let’s start by discussing the Google API Key, and then the form, and finally the methods required to make that Google Places API call.

Google Places API requires a key to access it.  You can learn more about this API here.  Depending on your purposes you may be able to get away with using only Google’s free API key but if you are going to be dealing with large volumes of data then the premium API key will be needed.  That doesn’t mean you can’t get started with the free version: we in fact use it to put our demos together, and it works quite well.

When setting up your key with Google, remember to also turn on the Google Maps Javascript API, or else calls to the Places API will fail.  Also, pay particular attention to the part about restricting access with the API key.  When you have a premium key this will be very important because it will allow you to set the level at which you want the key to be locked down, so that others can’t simply look at your Javascript code and use your key elsewhere.

The form we need to create will look like a standard address data entry form, but with some important details to note.  First let’s look at the country select box: we recommended that this be the first selection that the user makes. Choosing a country first benefits both you and the user, because it will limit suggested places to this country, and will also reduce the number of transactions against your Google Places API key.  Here is a link to how Google calculates its transaction totals.

Another important note is that we need to have the Apt/Suite data entry field.  As mentioned earlier, the Google Places API often does not return this level of resolution on an address, so we add this field for the information be provided by the end user.

The rest of the fields are really up to you in how you display them.  In our case, we display the parsed-out components of the results from selected address back into the rest of the address fields.  We keep all the address input fields editable so that the end user can make any final adjustments they want.

The methods associated with this process can be summarized by a set of initializations that happen in two places: first, when a country is selected, and second, when the focus is on the Address field by a user clicking into it.  For our purposes we default the country selection to the United States, however when the country is changed the Autocomplete gets reinitialized to the selected country. And when a user clicks into the Address field, the initialization creates a so-called bias, e.g. Autocomplete returns results based on the location of your browser.  For this functionality to work, the end user’s browser will ask to let Google know its location.  If the user does not permit Google to know this the suggestion is turned off and does not work.

This bias has a couple of interesting features.  For instance, you can change the code to not utilize the user’s browser location but instead supply a custom latitude and longitude.  In our example, the address suggestion does not end up using the user’s current position when the selected country is not in the same country as the user.  But when the user is in the same country as the selected country then the results returned by the Google Places API are prioritized to your location.  This means that if you are in Santa Barbara, CA and select the United States as the country, when you start typing a United States address you will first see matching addresses in Santa Barbara, and then work outward from there.

You can customize the form bias to any particular location that you have a latitude and longitude for.  The ability to change this bias is very useful in that setting the proper bias will reduce the number of lookups against the Google Places API before finding an address match, and will also save manual typing time.

Now let’s discuss the Address Validation International service API call, which consists of a key, the call to the service and setting up best practices for failover.

Let’s start with the key.  You will need to either have a live or free trial license key from us, the latter of which can be gotten here.  For this example, a trial key will work fine for exploring and tinkering with this integration.  One of the great things about using our service is that when you want to turn this into a live production-ready solution, all you have to do is switch out the key from the trial to the production key and switch the endpoint to the production URL, both of which can be done in minutes.

The call to the Address Validation International service will be made to either the trial or production endpoints, which will depend on the key that you are using.  The details of the service and how to integrate with it can be found in our developer guides.  In the Javascript code you will round up all the data in the fields that were populated by the address suggestion selection and send them off to the service for validation.  The code that manages the call to the Address Validation International service needs to be executed on some back-end server client.

It is strongly discouraged to make the call to the service directly from Javascript, because it will expose your license and allow someone to take it and use your transactions maliciously.  You can read more about those dangers here.  Also, here is a blog about how to make a call to another one of our services using a proxy.  The basic idea is that your Javascript call will call the proxy method that contains your license key, essentially hiding it from the public.  This proxy method will make the final call to the Address Validation International service, get the results from it and pass those results back to the original call in the Javascript.  In this situation, the best place to implement failover is in the proxy method.

So what is failover? Failover, from the perspective of an end user developer, is just a secondary data center to call in the unlikely event that one of our primary data centers go down or does not respond in a timely manner.  Our developer guides can again help with this topic.  There you will also find code snippets that demonstrate our best practice failover.

Once this call is set up, all that is left is evaluating the results and displaying the appropriate message back to the end user. While you can go through our developer guides to figure this out, the first important field to examine in the response from the Address Validation International service is the Status field – here is a table of what is expected to be returned:

Address Status

Name Description
Invalid For addresses where postal and/or street level data is available, and the street was not found, bad building number, etc.
InvalidFormat For addresses where Postal data is unavailable and only the address format is known.
InvalidAmbiguous For possibly valid addresses that may be correctable, but ultimately failed validation.
Valid For addresses with postal level data that passed validation.
ValidInferred For addresses where potentially far reaching corrections/changes were made to infer the return address.
ValidApproximate For addresses where premise data is unavailable and interpolation was performed, such as Canadian addresses
ValidFormat For addresses where Postal data is unavailable and only the address format is known.

 

Another important field will be the ResolutionLevel, which can be one of the three following values: Premise, Street and City.  The values returned in these two fields will help you make a decision in the code with respect to what exactly you want to display back to the end user.  What we do in our demo is display the Status and ResolutionLevel to the end user along with the resulting address.  Then we give the user a side-by-side view of both the resulting address just mentioned and the original address the user entered.  This way the end user can make a decision based on everything we found. In the case shown here, for example, we updated Scotland to Dunbartonshire and validated to the premise resolution level.

There are many customizations that can be made to this demo, such as the example we mentioned earlier about setting up the bias.  Additionally, instead of using the Address Validation International service you could also create an implementation of this demo using our Address Validation US or our Address Validation Canada products.

Want to try this out for yourself? Just contact one of our Account Executives to get the code for this demo – we’ll be glad to help.

Our 2018 New Year’s Resolutions

A brand new year is upon us – and once again, many of us are making resolutions for 2018. Perhaps eating better, working harder, or even blowing a thick layer of dust off that exercise machine in our basement. The new year is always a great time to make a fresh start.

Here at Service Objects, we have our own resolutions for 2018 as well. Of course, ours are designed to help your 2018 marketing efforts be even more successful than last year. Here are some of the biggest ones on our list:

Automate your regulatory compliance. More than anything, 2018 will cap a growing era of global consumer rights and stiffer regulation. Between the pending May implementation of the European Union’s General Data Protection Regulation (GDPR) and the recent expansion of the US Telephone Consumer Protection Act (TCPA), your use of consumer contact data for marketing is more tightly controlled than ever. And ignorance of the law isn’t bliss: fines for TCPA violations run as high as $15,000 per violation, and GDPR violations can command fines as high as 4% of your gross turnover.

We can help you get started on your path to achieve compliance with both of these new regulations. For GDPR, which requires maintaining explicit customer permission for use of their personal data, products such as Address Validation International, Lead Validation International and Email Validation can flag European addresses for GDPR processing and clean your contact database at time of use. And for TCPA, which prohibits unsolicited calls to consumer cellular numbers, our GeoPhone Plus product can help ensure that customer contact numbers haven’t been ported to new mobile customers.

Help you move into global markets. The world is getting smaller every year, which means that your potential market is getting larger. We can help you validate and verify international leads with tools such as Address Validation International and Lead Validation International, to help you target your overseas marketing more effectively.

Reduce the amount of fraud in eCommerce transactions during sales peaks. Did you know that 2017 saw the largest online sales volumes ever for Black Friday and Cyber Monday? According to data from Adobe Analytics, consumers spent a record $11.6 billion dollars across these two peak sales days – and according to Forbes Magazine, fraudulent transactions spike during these peak periods as well. We have a wide range of solutions for eliminating online fraud, ranging from lead validation to best practices such as validating IP addresses, to ensure that order from Kansas isn’t originating in Kyrgyzstan.

Give your customers a better experience. Your business rises and falls with the service experiences you deliver your customers. Our flagship delivery accuracy solutions, powered by continually-updated USPS, Canada Post and international address databases, makes sure your products get to the right people at the right address every time. And even when customers slip up and give you an undeliverable address, our Address Detective product can help make things all better.

Lower your costs. Would you like to get better lead response rates in 2018? Keep your contact database clean and up-to-date as prospects move or change jobs? Or improve your marketing ROI by filtering out bogus or fraudulent leads? We can do all of that for you, and more. We have a whole smorgasbord of solutions that help you have genuine, accurate and up-to-date data, improve marketing campaign performance, ensure better leads, and do more with less.

One more thing that makes our New Year’s resolutions better than most people’s – we always keep ours! That’s why we have over 2400 clients and counting today. And we look forward to serving you in 2018.

GDPR Compliance: Is Your Business Ready?

If you conduct business in Europe, May 2018 will be an important date. This is when the planned introduction of the European Union’s General Data Protection Regulation (GDPR) is scheduled to take effect.

GDPR represents a sweeping set of privacy regulations that impact your use of personal data from European citizens. If you conduct business with people from Europe – whether they are your customers, employees, or job prospects – GDPR affects you as well. It will require you to have policies in place to protect people’s personal data, as well as require notification when this data has been breached. And penalties for violations will be extremely stiff, up to the greater of 20 million Euros or 4% of your gross turnover.

GDPR starts with the definition of “personal data.” This is an extremely broad net: a recent article from Software Development magazine notes that the European Commission’s guidelines include both obvious data such name, address or email, and associated data ranging from bank accounts to photos and social media posts. Even the IP address a European is using on their computer is considered part of this personal data.

Much like the HIPAA requirements on electronic health care data in the United States, GDPR will require organizations to safeguard the personal data they collect and store in the course of doing business. At one level, this will involve technology such as encrypted data storage, password protection, and other approaches, along with policies and procedures for protecting this data. At another level, it obligates you to inform European consumers about your privacy policies, gain explicit consent to collect and use their personal data and provide them with the ability to control or opt-out of data collection. And in the event personal data is compromised, you need a plan for reaching people affected by the breach.

Each of these levels have important areas where data quality and GDPR compliance efforts intersect. Some of the questions businesses will have to ask themselves include:

  • Do we have accurate contact information for people we do business with in Europe?
  • Is there a notification procedure in place for our privacy and data policies, including opting out of data collection or making changes to personal data?
  • If a breach notification were necessary, do we have the means to quickly reach all affected parties?
  • How do we handle changes to contact information? What if a person in your database moves, changes jobs, or gets a new email address?

This means that your GDPR and data quality strategies will need to be closely linked. Tools such as international address verification, lead validation and name validation can help make sure data is complete and correct as it enters your system, and stays correct when it is needed later. As a recent article in Information Management points out, the key to GDPR compliance lies in proactively analyzing your data and performing a thorough risk assessment long before an actual privacy issue arises.

The European Union has long been on the vanguard of consumer protection legislation, and the new GDPR regulations are the latest in an effort to level the playing field between big data and the individual rights of its citizens. They have a global reach, whether you do business in Europe or serve Europeans from elsewhere. At a broader level, GDPR is part of a new reality that businesses will soon need to work with, one that is part of a larger trend toward increasing privacy regulations.

May 2018 is coming soon – is your business ready?

The Importance of Data Quality for International Ecommerce

In today’s era of online ecommerce, international sales represent a huge potential market for US vendors. According to research firm eMarketer, international sales represent three-quarters of a nearly US $2 trillion retail ecommerce market, nearly half of which comes from China alone. And much of this vast market is only a click away.

On the other hand, cross-border sales remain one of the greatest risks for fraud, with a rate that was more than twice that of domestic fraud through 2012, and despite recent improvements in data quality technology this rate is still 28% higher as of 2015. And one digital commerce site notes that while retailers are making progress at managing fraudulent transaction rates, they are doing so at the expense of turning away good customers – people who, in turn, may never patronize these sites again.

So how do you exploit a rich and growing potential market while mitigating your risk for fraud? The answer might surprise you. While nearly everyone preaches the importance of a fraud protection strategy for ecommerce, and suggestions abound in areas that range from credit card verification to IP geolocation, the head of ecommerce at industry giant LexisNexis points to one area above all: address verification.

In a recent interview with Multichannel Merchant, LexisNexis ecommerce chief Aaron Press points out that the biggest problem with international addresses is a lack of addressing standards between countries. “Postal codes have different formats, where you put the number, how the street is formatted. Normalizing all of that down to a set of parameters that can be published on an API is a huge challenge.”

This means that you need robust capabilities in any third-party solution that you choose to help verify international addresses. Some of the key things to look for include:

  • How many countries does the vendor support address formats for, and does this list include all of the countries where you do business?
  • Can the application handle multiple or nested municipality formats? For example, a customer may list the same location in Brazil correctly as Rio, Rio de Janeiro, Município do Rio de Janeiro – or even the sub-municipality of Guanabara Bay.
  • Will the application handle different spellings or translations for common areas? In the address above, for example, the country may be spelled as Brazil or Brasil. Likewise, the United Kingdom may also be referred to as England, British Isles, Karalyste, Birtaniya, United Kingdom of Great Britain and Northern Ireland, or even 英国 (Chinese for the United Kingdom, literally “England Kingdom”).
  • Can these capabilities can be implemented as an API within your ordering application? Or can it process addresses externally through batch processing?

In general, cross-border fraud prevention requires a multi-pronged effort involving all of the potential stress points in an international transaction, including international address verification, email validation, credit card BIN validation, IP address verification – even name validation, so you can flag orders addressed to Vladimir Putin or Homer Simpson. These are clearly capabilities that you outsource to a vendor, unless you happen to be sitting on hundreds of millions of global addresses and their country-specific formats. The good news is that in an era of inexpensive cloud-based applications, strong fraud protection is easily implemented nowadays as part of your normal order processing strategy.

Thinking Alternatively About Place Names

Here at Service Objects we come across a lot of names, particularly the names of places. We also work with a lot of personal names, but for now I would like to focus on just place names. Whether the name is for a city, town, village, hamlet, district, region, state, prefecture, mining area, national park, theme park or what have you; chances are that the place may have one or more even alternate spellings and alternate names associated with it.

For a human fluent in English, “North Carolina” and “N. Carolina” will be considered equal, but for a computer they are not. With the use of fuzzy-matching and/or standardization we can work around seemingly trivial issues like this. Now let us suppose that you are working with a set of Japanese data and come across the same name but written in Katakana “ノースカロライナ” or Ukrainian data written in Cyrillic “Північна Кароліна” or even Thai “รัฐนอร์ทแคโรไลนา”. Well, fuzzy-matching and standardization are still our friends; we just have more fuzzy-matching and standardization rules to consider. However, we first need to ensure that we even have the data available to associate a name in a different language.

We’ve been creating a list of place names to help us tackle problems like the ones mentioned above. We currently have a list of over five million unique place names generated from a pool of approximately 11 million names. We are aggregating name data to come up with a more comprehensive list that consists of known alternates, variations in spellings, different languages and the transliterated versions for the different languages.

Here’s a quick look at what we have accomplished, so far:

  • Current list of approximately eight million place names and growing
  • Transliteration and phonetic mappings for various languages
  • Case, accent and kana sensitivity handling
  • Queryable using fuzzy-matching algorithms

We have taken some of what we have learned from our DOTS Address Validation – International service and built upon it in order to improve data beyond the realm of just address validation. When working with Phone, Email, IP, Demographic and Geo-coordinate related data we too often find that location names do not match up. Naturally this is to be expected, since different data vendors will have different standardizations and practices when it comes to naming conventions. Utilizing a comprehensive place name library will allow us to quickly perform various actions, such as cross checking multiple data sources against each other with increased flexibility and match rates.

It may not be immediately apparent how useful a place name library like this is and what kind of avenues it can open up, but expect to see new and exciting developments from us in the coming months!

C# Integration Tutorial

C# may very well be our most requested sample code.  There is good reason for that too; C# and the .NET framework are many developer’s first choice for creating a web page or any other type of application because of the versatility of the language and framework as well as the robust features that Visual Studio offers.  One of those features is the ability to consume a WSDL (Web Services Description Language) and create all the necessary classes and methods to successfully call a web service.  This makes using SOAP squeaky clean! Ok, that was the first and last SOAP pun, I promise.  Here’s what you will need for this tutorial.

Requirements

  • Visual Studio (2015 is used in this tutorial but the process should be relatively similar with any other version)
  • DOTS Web Service License Key (We are using DOTS Address Validation International for this example)
  • Some familiarity with C# and the .NET Framework. This tutorial will be pretty basic so it should be accessible even if you are a beginner.

Setting Up the Visual Studio Project

For starters, launch Visual Studio and create a new ASP.NET Web Application and choose an appropriate project name. Your screen should look similar to the following:

Click ok and then select “Empty” to create an empty web form. We will add the necessary aspx page momentarily.

But, our first step for our new project will be to add the service reference to the DOTS Address Validation International web service. To do this, right-click on “References” in the Solution Explorer and select “Add Service Reference” a pop up should appear to add the Service Reference.  Here we will add the URL to WSDL that contains the information on how the project should interact with the DOTS Address Validation International web service and we will name the Service Reference.

For reference here is the WSDL URL and here is what the pop up page should look like

WSDL: http://trial.serviceobjects.com/avi/soap.svc?wsdl

Now that we have successfully added the service reference, we can add an aspx page that will have our input form and display our results. Right click the project name and select “Add” and then select “Web Form” to add a blank web form to the project.  For our example we’ll name the form “AVIForm”.

Creating the Input Form and Code Behind

Now that our form is present, we’ll add some simple HTML and ASP elements to take in our inputs and display them to the screen after we get a response from the service. Make your ASPX page look like the following.

The above code will allow us to take the inputs send them to the code behind and the display the results in the outputGrid and InformationComponentsGrid.  We have to separate grids; one to account for the standard outputs from the service, and the other to account for the InformationComponents field to account for some variable information and data to be returned by the service.  This field can change based on the country or data available for a specific international address. Now that our input form is all set up, we’ll add the proper code behind that will display the results to the user.

We won’t look at every part of the code here, to download a .txt version of the code, click here.

One thing we like to stress to clients who are integrating our services is proper Failover Configuration.  In the unlikely event that our primary datacenters are offline or producing strange errors, we want to ensure that our clients are pointing their code to our backup datacenters so that their applications and business processes go uninterrupted.  Here is a full picture of the proper way to integrate failover into an application.

We’ve found that to ensure uninterrupted service the best practice is to have the calls to the web service nested in a try-catch block of code.  In our current setup, the backup call will hit the same data center as the primary call; but if a License Key is purchased the primary call should point to ws.serviceobjects.com and the backup call should point wsbackup.serviceobjects.com.   The screen shot below, highlights some of the primary failover logic that will allow the code to run uninterrupted.

This code occurs right after the primary call to the web service if it detects that the response from the service is null or if an Error TypeCode of “3” is returned, then the code will throw a new exception and the catch statement will call the backup web service call.

If a successful response is received from the service, the code will call a method named “ProcessValidResponse” which takes in the response from the web service and display the results into a DataGrid and then send that data grid to the ASPX page for the user to see. This method is pretty straight forward for the most part, as it simply assigns the outputs and their respective values into separate columns for the user to see.

The only part that may be mildy tricky would be the InformationComponents field that is returned from the service.  This field is an array of InformationComponent which contains two strings; one for the “Name” of the variable returned and one that indicates the “Value” of the variable returned.  For example is you pass a US address into the AVI service, one InformationComponent that can be returned will have a Name of “DPV” and a Value of “1” indicating that it is considered delivered by the USPS.  Below is an example of the XML output.

 

This array of fields allows us to add new outputs to the service over time without potentially breaking any existing client’s code.  To account for this array of information we have a brief For loop below that will loop through all the elements of InformationComponents and add their names and values to the InfoCompTable so that they can be seen by the user.

Making a Successful Call to the Service

If we go ahead and run our project, our webpage will look like the following.

Not very exciting, but it will get the job done. As an example address, we’ll use the following in France:

3 Place de la Victoire, 33000 Bordeaux, France

If this address is sent to the service you should see the following response.

As you can see, this address is considered Valid by the service and the service has a premise level resolution for this address.  The Address1-Address8 fields will also display how the address should look for mailing purposes. For this particular example we only need Address1 and Address2 but for other countries all 8 address lines may be used.  The InformationComponents field was also parsed out and the two Name and Value pairs were shown below the standard outputs from the service.

That wraps up our tutorial for DOTS AVI integration in C#.  Congratulations! You are now on your way to being a DOTS Address Validation International expert! Feel free to go and test more International addresses, and as always if you have any questions feel free to reach out to us at support@serviceobjects.com!

How to Validate International Addresses

Dealing with international addresses is no simple task. An address can often be misspelled, incorrectly formatted or simply written in a foreign language that you do not understand. The simple fact that many international addresses are foreign to us means that we are unable to recognize when something is wrong.

Take the simple word “street” for example. It is one of many commonly used words in an address. The French word for street is “rue”, in German it’s “Straße”, in Portuguese it’s “rua”, and it’s the character “路” pronounced “lu” in Chinese and so on. That’s not to mention common abbreviations either. In many cases a person will have a hard time identifying the name of a city or a street in an address and they would be unable to distinguish one from the other.

Let’s take a look at a few international examples:

China (中国)

Address:

Shanghai DPF Textile Co., Ltd.
200331
上海市普陀区武威路259号
98 -A3

Unless you are able to read Chinese you would be hard pressed to make sense of the above example. The first line is in English but it appears to simply be the name of a business. Business names are not required to validate addresses with the AVI service and it is unlikely that it would prove helpful in the validation process. To the contrary, extraneous information like this is often regarded by most systems as garbage data; however, let’s go ahead and pass the address as is to the AVI service and see how it handles it.

URL Query:url1

Here is what the query looks like when using the web service test page:

getaddressinfo

Here is the output in JSON, although the service also supports XML:json1Examining the output, we see that the AVI service fixed the order in which we entered our input values. This was done not only in the transliterated Romanized spelling of the address but also in the localized Chinese format.

Here are both versions of the address parsed from the JSON response output:

Roman Character Format

Shanghai DPF Textile Co , Ltd
98 – A3
No. 259 Wuwei Lu
Putuo Qu, Shanghai Shi
200331

Local (Chinese) Character Format

200331
上海市普陀区武威路259号
Shanghai DPF Textile Co , Ltd
98 – A3

The AVI service identified the street name, city name, postal code as well as other useful information.

 

Greece (Ελλάδα)

Address:

114 71 Αθηνα
Ασκληπιου 104
Το ΝΟΣΤΙΜΟ

Unless you can read Greek the above address would be difficult to decipher. Let’s see what the AVI service returns.

URL Query:
url2

Here is what the query looks like when using the web service test page:

getaddressinfo2

JSON Output:json2

Parsing out both of the address formats from the JSON response we get the following:

Roman Character Format:

To NOSTIMO
Asklepiou 104
114 71 Athens

Local (Greek) Character Format:

114 71 Αθηνα
Ασκληπιου 104
Το ΝΟΣΤΙΜΟ

As it turns out, “To NOSTIMO” or “Το ΝΟΣΤΙΜΟ” (in Greek), is the name of a café that resides at the address. Even though the name of the café is not technically a part of the address nor is it necessary for validation, we see that its inclusion did not impede the AVI service from performing its job.

 

Germany

Let’s see how well the AVI service handles an address when several lines of extraneous data are included.

Address: 

Accemic GmbH & Co. KG
C/O World Express (GmbH)
Gunther Meyer, Phone: +49 (0) 8033 6039790
Franzhuber Str 39
Kiefersfelden

In this example, the address is in English, but there is a mess of extraneous information included. What will the AVI service make of this example?

URL Query:url3
Here is what the query looks like when using the web service test page:
getaddressinfo3

JSON Output:json3Parsing out the address from the JSON response we get the following:

Roman Character Format:

Accemic GmbH & Co KG
C/O World Express (GmbH)
Gunther Meyer, Phone: +49 (0) 8033 6039790
Franz-Huber-Str. 39
83088 Kiefersfelden

In the above example, we see that the AVI service was able to ignore the three lines of extraneous information and identify the pertinent address information. From there the service standardized the street name, corrected the locality name and appended the missing postal code.

Lost Deliveries Equals Lost Revenue

Getting Your Mail Delivered

In 2014, the United States Postal Service reported that 4.3% of all mail was ‘Undeliverable as Addressed’ (UAA). At first glance, this doesn’t seem too bad, BUT this seemingly small percentage can become a very expensive issue, having a negative impact on your business. Looking at the big picture, this translates to over 6.6 billion pieces of UAA mail, costing the USPS $1.5 billion a year. What’s more, UAA mail cost the entire mailing industry over $20 billion in 2015.

Think about the number of packages, mailers, documents, and invoices that you send out on a daily basis. How many Undeliverable As Addressed mailings do you experience daily, monthly, yearly? As reported by the USPS, it is likely around 4.3% of mailings. And that number doesn’t account for 3rd party courier services like UPS, FedEx, DHL, etc.

To help illustrate the hard and soft costs associated with of UAA mail, let’s take a look at a couple examples.

Mail-Order Catalogs

You might think with the advent of the internet, mail-order catalogs would have become obsolete by now. On the contrary, catalogs are a healthy part of omnichannel marketing and with over 11.9 billion mail-order catalogs mailed in 2014, they do not appear to be going anywhere.

In fact, direct mail outperforms digital channels by a long shot, with 3.7% response rate on a house list and a 1.0% response rate on a prospect list. By comparison, all digital channels combined, only achieve a 0.62% response rate. The real power shows up when marketers combine direct mail WITH digital marketing. As Kurt Salmon discovered, over 58% of online shoppers say that they browse catalogs for ideas, and 31% have a retailer’s catalog with them when they make an online purchase.

“For example, during one calendar-year period, we observed that Internet-only customers of one specialty retailer placed orders of $80 on average, whereas catalog customers’ average orders totaled approximately $90.”

Extensive market research helps us see just how important mail-order catalogs are to many businesses. Unfortunately, of the 11.9 billion catalogs mailed in 2014, 476 million catalogs went undelivered. For companies that rely on catalog marketing, deliverability does have an immediate effect on their bottom line.

To provide more context, consider the following scenario.

A large retail clothing company is sending out millions of seasonal catalogs to their house and prospect lists. The costs to design, create, print, and mail these catalogs is substantial but they know that customer order values increase by 15% when they have a catalog in hand.

Unfortunately, recent sales reports indicate that the company’s response rates have dipped about 1%. After some inquiry, they discovered that 4.3% of their catalogs came back as UAA, and therefore did not reach their targets. They have suffered the direct costs of printing and postage and the indirect costs of a lost sales opportunities.

To correct this problem, they implemented some simple address validation tools and were able to reduce their UAA rate, thus saving on these costs and immediately getting back on track.

Return to sender stamp on envelopeUndelivered Invoices & Packages results in Decreased Cash Flow & Unhappy Customers

Your relationship with your customers is everything. And a key part of customer service is “knowing” not only who your customers are, but also where they reside so that their deliveries are consistently getting to them. And, when you have loyal, happy customers, you maintain a steady cash flow.

Along those same lines, customer invoices must be delivered on time, every time, in order to avoid unnecessary operational costs.

Companies whose invoices are not received in a timely fashion will experience a direct impact on their:

  • Accounts Receivables Department: requiring additional time to call on customers or clients when invoices are not received
  • Finance Department: affecting accounts receivable, aka, interrupting company cash flow
  • Mailroom Operations (if applicable): spending time researching and in most cases resending statements/invoices and adding additional postage costs

But, by taking steps to validate their mailing addresses, they increase their chances of maintaining their customer relations. Ask yourself this question: How many times will a customer “tolerate” inadequate service, such as undelivered packages or invoices, before they decide to cancel their business altogether?

So how can you correct and streamline your customer lists for address accuracy while also keeping them current?up-to-dateness? It starts with plugging in Service Objects’ DOTS – Address Validation solution to verify, validate, and correct undeliverable mail.

Solutions, Solutions

To significantly increase the deliverability of your mailing lists, Service Objects offers a number of solutions that will help validate and correct your mailing addresses. All of our services can be accessed through our real-time APIs and/or using our batch process.

Here’s a quick rundown:

  • DOTS Address Validation – US, can instantly verify, correct and append address information against our CASS-Certified USPS address verification database. Some companies choose to append latitude/longitude and demographic information, in which case, we recommend DOTS Address Validation Plus. Using either of these services, the majority of your addresses will be verified and corrected, and ready for mailing.
  • DOTS Address Detective uses real-time “fuzzy” logic to complete missing data points in the address and then verified against our CASS-Certified database. Great for incomplete and hard to validate addresses.
  • DOTS NCOA Live service, keeps verified and corrected addresses up-to-date. This is built on the USPS National Change-of-Address database (NCOALink).

Think Globally

  • DOTS Address Validation – Canada, covers 15.7 million addresses in all 10 provinces and 3 territories and validates both French and English addresses.
  • DOTS Address Validation – International, verifies, corrects, and appends addresses outside the United States and Canada. Covers over 250 countries, dependent areas and territories. Addresses are corrected to the unique requirements of country’s postal address formats and cultural idiosyncrasies.

Whether it’s a direct marketing mailer campaign, confidential documents, packages, or customer invoices, you need to count on successful deliveries every time.

So get it right the first time by using the most genuine, accurate, and up to date customer address information available. As it relates to your bottom line, there is no room for error. Plain and simple, Service Objects Address Validation solutions can help you reach your mailing goals!