Memo - Address Validation PoC

This memo documents the background activities and considerations to introducing Address Auto-complete and Validation components into the existing Master Data estate to improve the quality of addresses used within the logistics business. It also provides the background into the various service providers, the evaluations undertaken as well as a recommendation on the preferred provider.

Capture of address for Customer, Vendor, Facility and Consumer

A valid address is required to ensure the correct address appears on shipping documents, and enabling correct delivery/collection of goods.

Customers, consumers, vendors and Maersk agents will benefit from a curated capture of addresses. An auto complete component will enable the capture of addresses based on country rules and on recognised country specific postal information. The validation component will validate the address as well as providing various address formats including labels, address lines 1 - 7, and the normalised individual attributes of the address. The addresses are formatted to the local country requirement.

Where applicable the address responses will be stored in one of the master data applications (ie CMD, VMD or Facilities)

Address validation capabilities required:

• The onboarding process must include address autocomplete and address validation components. This will enhance the experience for direct consumer, customer, vendor and facilities address capture, and support the service centre staff (who cannot be expected to recognise and validate addresses from around the world).
• The information captured needs to include an Address Accuracy score, which can be used by data quality teams to manage the data quality.
• The information returned from the address validation component should include Geo Coding.
• There needs to be a bulk validation capability to support batch validation of historical master data addresses.
• There is a requirement to manage local country formatting as well as local language translations as certain countries may enforce ruling on how address are provided

Address validation providers - Market scan

It is recognised that this is a common capability provided by many different service providers and does not justify being built in-house.

Objectives:

• Identify a set of suppliers that can provide Address Validation capabilities, the suppliers are split into 2 groups
  • ‘Map’ address validation vendors - Navigational Map providers who have extended their offerings to include address validation (Google Maps, Azure Maps, etc)
  • 'Aggregator’ Address validation vendors , who aggregate data collected from country postal providers (Melissa, Loqate, Address Doctor, etc)
• High level analysis of the capabilities of each supplier
• High level approach to testing the capabilities of the suppliers

The following providers were analysed.

Provider	Origin
Smarty	Aggregator
Melissa	Aggregator
Loqate	Aggregator
Postcoder	Aggregator
Address Doctor (Informatica)	Aggregator
Google Maps	Map
Azure Maps	Map
Here Maps	Map
Postgrid	Aggregator
Experian	Aggregator

Based on the market scan - which included high level investigation into global coverage, integration capability and company presence, the following providers were selected for the test

• Google
• Loqate
• Melissa

Full details of the market scan can be found here → Market scan - Address validation providers

Address validation providers - Proof of concept result.

Address Autocomplete.

It was not possible to setup an automated PoC for the Address autocomplete. Manual testing was performed on a small set of customer addresses against each of the service providers.

Each of the solution providers were able to provide good quality results and the differentiation between the providers was very small.

Address Validation.

Each of the solution providers were tested on the address validation component using a sample set of data from CMD. The sample was limited to 10 customers in each of the 235 countries that Maersk does business.

Coverage

Google validation is limited to 39 countries, of which 20 are included in the top 50 ‘Countries by Revenue’ for Maersk.

Loqate and Melissa provides validation across 250 countries. Both Loqate and Melissa were able to provide reasonable quality results across the 235 countries and the differentiation between them was very small.

Quality

The solution providers were able to correct addresses that were moderated incorrect, but for addresses where quality was bad, they were not able to provide correct addresses. See appendix B for example of misaligned customer addresses.

None of the providers were able to validate the Chinese addresses to a good score, this may be based on the data quality of the addresses selected for the PoC.

Loqate and Melissa provided good quality results in Europe and North America, average quality in the rest of the world.

All service providers provide an Address accuracy score. Melissa and Loqate have more detailed accuracy score.

Comparison to existing provider - Azure

Reviews of the customers created in the last 6 months (which would have used the Azure Address validation component) show that only 49% of the Azure supplied address were accepted by the Data Stewards.

This can be broken down further to state that in Europe and Pacific countries the Azure supplied address is correct in 88% of the time, whereas for Americas, Asia, Africa the Azure supplied Address is correct in 50% of the time.

Comparison between Melissa and Loqate

Melissa across top 40 countries by revenue

Loqate across top 40 countries by revenue

Results of Address validation for countries split into High Revenue and medium Revenue ( High revenue > 10Million, Medium revenue > 1Million and < 10Million)

Recommendations

The recommendation to improve the data quality of the addresses is that Maersk uses a combination of a map provider and an aggregator provider. All the evaluated providers have a commercial model based on a per usage model, therefore the solution should not be restricted to a single provider.

When comparing the map providers ( Google and Azure), Google has good quality in North America, Europe and Pacific, whereas Azure has good quality in Europe and Pacific.

Recommendation on map provider is Google

When comparing aggregators (Melissa and Loqate) the coverage and validation results are similar/

Recommendation on aggregator should be based on commercials.

Master Data team is to built a wrapper component which would wrap the service providers API, enabling service providers to be added (or replaced) as needed ( as example adding a Chinese address service provider to get improvements in Chinese addresses). The wrapper will use the country to direct traffic to different service providers.

Risk - Google

Google has some restrictive T&C’s on how the Address information can be used. Maersk legal team will need to review these in detail - some perceived examples;

• Restrictions on what mapping the addresses can be shown
• Google logo requirements when sharing the addresses.

Google terms and conditions → https://cloud.google.com/maps-platform/terms?%5Fgl=1%2Akbtoy9%2A%5Fga%2AMTY4OTY2MzcwMS4xNjgwMDM1NTUw%2A%5Fga%5FNRWSTWS78N%2AMTY4MDIxNTI3Mi4zLjEuMTY4MDIxNTU5My4wLjAuMA..#3.-license.

Risk - Address

It should be noted that even with the implementation of one or more of the service providers, the historical address data in CMD, VMD and Facilities will continue to take a large effort to improve. It is not possible to correct addresses which have conflicting values (ie street name mismatches to postal code). However once the service is implemented - and new addresses are autocompleted, the quality of these new addresses will be good.

There will be additional requirements to ensure that address can be stored in the existing structures in the master data solutions. Address validation providers support up to 7 address lines, whereas existing master data applications have a limit of 3 address lines. A set of coded rules is required to ensure the 7 address lines are concatenated into 3 address lines and any excepts will be routed to the data stewards. Alternatively the master data applications can be changed to hold more address lines, however this is not recommended due to the impact on downstream consumers.

The Master data applications currently separates out the ‘street number’ and ‘street’ this is obsolete and in many cases the data is incorrect. Th ‘street number’ is not required as an isolated field and should be deprecated. see examples in Appendix A

Risk - Geography

Analysis and management of consumers, facilities, customers and vendors is based on the ‘geographic reference data’ included in the address details, for example country or city.

As the address details will be provided by address validation provider, the mapping of the geographic reference data is impacted.

Both Maersk and the providers use ISO-3166 for countries and sub-divisions and include Longitude and Latitude.

However there is no international standard for city and district, therefore the information received from the address validation providers will require either additional entry of city and district codes at the time of address capture. Alternatively, when parsing responses from the address validation providers, the city (and district) details will require mapping between the 2 sets of data.

One consideration is that Melissa provide ISO-3166 codes for Sub-divisions, which will simplify the mappings between Maersk geography and Melissa geography.

Appendix A

Examples showing incorrect usage of Street Number

example 1 - the 312 is the Suite number and not the street number

example 2 - the street number is not shown as the street number is after street name

example 3 - the 4 is the unit number and not the street number

Appendix B

Showing variations on Address for same company

Dun and Bradstreet information