The single best strategy for improving your mailing addresses

Having accurate and current addresses for your constituents is one of the most important thing in your database. You’re using this information to engage with them, solicit them, inform them, communicate with them, and learn more about them in order to develop and evolve a two-way relationship. So why don’t we then have good addresses?

Based on my latest research from address cleansing services, the industry average for North American address cleanliness is between 63%-77%. International ones are usually much lower. Where do you stand against this average? If you’re within the average range, I’m arguing that this is not good enough. This is where our average used to be back in 2012, but now we’re constantly at 92% and above. So how can you get to %90 and higher?

The industry average for North American address cleanliness is between 63%-77%.

There are a few steps you need to take to achieve and maintain a sustainable data quality level for your mailing addresses. It involves analysis, planning, cleansing, optimizing processes, improving data capturing methods, creating audit controls, assigning ownership over this data set and more. Check out the article on “The trifecta of the best data quality management” for details. Putting these aside for now, let’s focus on the single best strategy for improving your mailing addresses. It simply entails developing and adopting the address standard.

This article will cover best practices for recording a North American address in your database through the front end of your CRM. This will not cover the way an address should be outputted on a paper medium such as a publication or envelope. If you’d like to read an article about this, please let me know.

Before going into the standard you should adopt, let’s go over what usually comprises an address:

Address line 1 and 2 (could be up to line 3 and 4 in some cases)
City/ Town/ Municipality/ Village
State/ Province
Zip code/ Postal code
Country

Reference data fields

I would like to first go over the fields which should use reference data. What is reference data?

It is a set of allowed values to be used by specific data fields.  Basically, on the front end you have a drop-down field to choose one or more values from, but most often only one.


Tip #1: Always use reference data when you have a data element which does not change much in definition and content. This takes away from data errors being created due to manual entry. Sure, you can still select the wrong country, but you will have a reduced error rate for this field if you don’t have to type in the value.


 

So where should you use reference data for an address? Definitely country and state/ province.

Reference data values are often defined by standards organizations and this is the case for countries. ISO-3166 is the country and state/ province codes standard (ISO 3166-1: country and ISO 3166-2: state/ province) used across industries and countries. If you’re not using it yet, what are you waiting for? Why should you adopt it?

1.It is a reliable source of information.

  • The only two ways to have an entry in their ISO-3166 list is to have it registered in:
  • United Nations Terminology Bulletin Country Names, or
  • Country and Region Codes for Statistical Use of the UN Statistics Division.

To be listed in the bulletin Country Names, a country must be at least one of the following:

  • A member state of the United Nations
  • A member of one of its specialized agencies
  • A party to the Statute of the International Court of Justice

2. It provides alpha-2, alpha-3, and numeric codes (ISO 3166-1: recommended for usability or programming efficiencies)

3. It provides the country names in both English and French

The downside is that you’ll need to purchase this data which costs around 300 Swiss Francs (~$315USD / ~$410CAD), though here is a free list for the countries, excluding their subdivisions.

Free list for all ISO 3166 country names and codes:

iso3166 country codes

 


 Tip #2: Some country names used by the UN, and therefore used in ISO 3166-1, are subject to dispute.  My recommendation is to stick with these, but be aware of the disputes. Ex:

  • China, Taiwan, Hong Kong are as recorded as such and not as People’s Republic of China
  • Cyprus not recorded as Republic of Cyprus
  • Kosovo is listed as an autonomous province of Serbia
  • and a few others

There are other countries listed differently from how you might want to record them. Ex:

  • Republic of Korea, you might want to output it for usability purposes as South Korea
  • Iran (Islamic Republic of), you might not want parenthesis in the name, so you might want to record it as Iran, Islamic Republic of OR Islamic Republic of Iran (because we know commas could create havoc if exported in Excel), OR just as Iran

Tip #3: If you don’t have a CRM or process which supports foreign characters, convert non-English characters before loading them into your reference table. Ex: Curaçao


 

Free text data fields

So what’s next? Zip/ Postal code, City, and Address Lines.

Consistency in the zip/Postal code field is particularly important. Not only it is more aesthetically pleasing, but it will help you identify potential address errors quicker and reduce those mail-house formatting and cleansing costs. The format is country dependent and for the purposes of this article we’ll cover US and Canada.

Canadian postal code
  • Canadian postal codes are always LDL DLD (Letter, Digit, Letter, Space, Digit, Letter, Digit).
  • Letters are always capitalized
  • The space between the first grouping (forward sortation area) and the second (local delivery unit) should not be optional

 

US zip code
  • zip codeUS zip codes are always DDDDD-DDDD (5 digits, Dash, 4 digits)
  • The Zip+4 digits are not required, but I heavily encourage them. Not only it will provide you with a more accurate address, it will also:
  1.  flag potential data quality issues if the Zip+4 cannot be obtained
  2. be delivered quicker
  3. avoid having the zip-code changed if you ever export your data in Excel. Most often than not, Excel will convert the zip code into a number, if the Zip+4 is not present, and if you have a zip code start with “0”, that will be removed. Ex: 06390 will be outputted in Excel as 6390

Tip #4: There are some easy data quality checks you can do for zip/ postal codes, not only based on the format, but also the letter or digit it starts with. These are well defined so you can always verify against these set values as well as against the state/ province to ensure there are no conflicts.


 

For the City/ Town/ Municipality field, there’s not much to mention. I recommend always using the proper case format.

The address lines are again dependent on the country, but for US and Canada there are usually two address lines.

Canadian address lines

Civic address:

Format:  {unit number location &”-“} {civic number}{civic number suffix} {street name} {street type abbreviation} {street direction capitalized abbreviation} | Example 1: 10-123 Main St SE | Example 2: 123A Main St W | Example 3: 10-123 1/2 Main St

Address Line 1: Additional delivery information, if exists. Otherwise, the civic address

Address Line 2: The civic address, if not already entered in line 1

Postal box address:

Format: PO BOX {box number} STN {station information} | Example: PO BOX 4001 STN A

Address Line 1: Additional delivery information, if exists. Otherwise, the civic address

Address Line 2: The postal box number and station information or the civic address, if not already entered in line 1

Address Line 3: The postal box number and station information, if not already entered in line 2

Rural route address:

Format: RR {rural route identifier} STN {station information} | Example: RR 6 STN Main

Address Line 1: Additional delivery information, if exists. Otherwise, the civic address

Address Line 2: Rural route identifier and station information or the civic address, if not already entered in line 1

Address Line 3: Rural route identifier and station information, if not already entered in line 2

General delivery address:

Format: GD STN {station information} | Example: GD STN Main

Address Line 1: General delivery identifier and station information


Tip #5: For the latest address guidelines refer to CanadaPost and USPS.


US address lines

Civic address:

Format:  {primary address number} {pre-directional} {street name} {suffix} {post-directional} {secondary address identifier} | Example 1: 123 Main St SE | Example 2: 123 W Main St Apt 111

Address Line 1: Additional delivery information, if exists. Otherwise, the civic address

Address Line 2: The civic address, if not already entered in line 1

Postal box address:

Format: PO BOX {box number}  | Example: PO BOX 4001

Address Line 1: Additional delivery information, if exists. Otherwise, the civic address

Address Line 2: The postal box number and station information or the civic address, if not already entered in line 1

Address Line 3: The postal box number and station information, if not already entered in line 2

General delivery address:

Format/Example: GENERAL DELIVERY

Address Line 1: General delivery, uppercase preferred

Final recommendation

The full address is country dependent. For certain countries the postal code might not exist or not be required or in some remote areas there might not even be a street address, but just a house name. Consider these exceptions when constructing your data quality rules. My advice is to look at the countries where the 80%-90% of your constituents are located and ensure you create address standards for those countries. Do you agree?

%d bloggers like this: