Data Quality user documentation
home/Address validation/Pro API (version 7.98)/Overview/Introduction

Introduction

Pro API is a suite of functions that you integrate into your own applications. Once successfully integrated, Pro takes partial or full address information that you type in and returns a complete, validated address.

Benefits

  • Minimal information required: Real-time address validation from minimal address information. Capture a complete and accurate address by searching for and validating against one or more address datasets for a country. Search by premise number and postal code, or find a postal code using other elements of the address. Improve your customer journey and increase efficiency across the business through key stroke savings to record an address of up to 80%.
  • Improve marketing campaigns: Deliver more successful mailing campaigns and reduce wasted spend by using only accurate and deliverable addresses for customers and prospects.
  • Reach your customers: Communicate effectively with your customers and ensure important messages reach the intended recipients by increased addresses data quality.
  • Gain customer insights: Address validation guarantees contact records are accurate and consistent. Valuable consumer, business, location and public sector data can also be appended for further analysis and segmentation of your customer base.
  • Enhance customer experience: Streamline the customer journey from arrival to form completion while prioritising address data quality. Improve conversion and completion rates and subsequent delivery of goods with fast and accurate address data capture.
  • Reduce costs: Correcting data issues manually is costly and takes time. Automating data quality management eliminates the potential for human error, and in turn, reduces failed deliveries and chargeback costs.
  • Set up quickly: The solution is easy to set up and use. The software and data are installed on your environment, giving you complete control and greater flexibility.
  • Address Standardisation and Formatting: Addresses are formatted to a standard you specify. Getting data correct at the point of entry, in a standard format, removes the requirement for standardisation when sharing data across systems and web forms.

Features

  • Data enrichment – appends geolocation, health, government, business and consumer demographic data to addresses in real-time.
  • Trusted data – validates against authoritative postal sources (including Royal Mail, USPS and Australia Post), trusted third-party providers, and Experian proprietary information.
  • Flexible search types – provides multiple ways to find addresses with Singleline, Typedown, Verification, Intuitive and Keyfinder search options.
  • Advanced fuzzy matching – handles misspellings, abbreviations, missing information and formatting issues to find the right address. The solution also supports wildcard searching - use a substitute if any part of an address element is missing or illegible.

Functionality

Fuzzy matching is the process of intelligently searching for an address, approximately matching the address information provided by the user to addresses in the authoritative reference dataset (i.e. from Royal Mail, USPS, Australia Post), and returning all likely possibilities for the user to select from. This is useful when the user provides too little or too much information, inputs the address in the wrong format or includes a typo.

Pro API leverages advanced fuzzy matching logic to deliver the most approximate search results for the user to select from, based on a degree of confidence, rather than an exact match. The solution intelligently recognizes and works around the errors below, reformats the address if needed and includes missing elements to deliver a correct, complete, and formatted address.

  • Abbreviations – users enter abbreviations for certain address components. For example, Av for Avenue, Blvd for Boulevard, Rd for Road as well as Ch for Chemin (French) or Str for Straße (German).

  • Typos – users make errors in data entry, especially when on mobile devices or spelling addresses phonetically. For example, entering an 'n' instead of an 'm' or entering 'streeet' instead of 'street'.

  • Incorrect ordering or format – users don't always enter the address in the way it appears on an envelope. For example, enter the town or city first, followed by the street and building number.

  • Missing or additional spaces – users add or miss spaces between words or even within words without realizing.

  • Missing or additional information – users provide too little or too many address elements when searching for an address. For example, leave out the property/building number.

If the address input cannot be matched to any likely address, a "No matches" message will be shown to the user. Below is an example of fuzzy matching in practice, whereby the user has made an error in data entry and the sophisticated algorithms recognize this and return the relevant address.

Examples

Category Example

Formatting errors


Our service correctly classifies and rearranges components to find the intended address.		 Example - Formatting errors

Too little information


Our service correctly determines the building number and the postal code.		 Example - Too little information

Non-standard abbreviations


Our service provides recommendations for both "North Buck Creek" and "New Buck Creek".		 Example - Non-standard abbreviations

Users can use wildcards to replace one or more missing letters in their address information. There are two wildcards available. Users can use a combination of wildcards in a single search line.

  • Question mark wildcard (?)

    This wildcard replaces a single character in an address or postcode.

  • Asterisk wildcard (*)

    This wildcard replaces any number of characters at the end of an address element.

If too many wildcards are used in a search, there is a risk of a considerably extended searching time, and possibly no returned matches. To prevent this from having an adverse effect on the server, a timeout is provided and also a limit on the number of returned searches.

Question Mark Wildcard
When users search with a question mark wildcard, Pro API produces a list of all matching streets and postcodes. For example:

Action Pro API retrieves…
Select the USA dataset and enter ?146? A list of all US cities with ZIP Codes beginning 114, 214, 314 etc. Similarly, all ZIP Codes ending with 461, 462 and so on.
Select the AUS dataset and enter 13 Clarke St, 3?67 Two addresses at "13 Clarke Street, Abbotsford, VIC 3067" (Two bordering locality matches in Richmond are also returned.)

Users can use the question mark wildcard on any type of address element, including postcodes, street names, towns and localities.

Asterisk Wildcard
This wildcard replaces any number of characters at the end of an address element. For example:

Action Pro API retrieves…
Select the USA dataset and enter Rose *, New Orleans Any address starting with "Rose" in New Orleans, including Rosecrest Ln, Rosedale Dr, etc.
Select the USA dataset and enter Highland Ave, Trent/* Streets called "Highland Ave" in places beginning with "Trent". This could include Trenton, Trentwoods, etc.

Both Wildcards Combined
Users can combine * and ? wildcards in one search.

Action Pro API retrieves…
Select the UK dataset and enter 33 back*, cb?4?a The full address: "33 Back Hill, Ely, Cambridgeshire, CB7 4DA".
Select the UK dataset and enter oak house, threemile, tr?6G/ The full address: "Oak House, Threemilestone, Truro, Cornwall, TR3 6GU".

Special Picklist Items

There are certain types of picklist item that must be treated as special cases in Typedown and Single Line searches. These are:

Unresolvable Ranges

An unresolvable range is a picklist item that represents a range of premises, but where there is not enough information within the data to resolve the entry into a list of premises.

These are very common when searching against the USA data, although they also exist within other data and must be handled appropriately.

For example, search using Single Line against the USA data using the optimal prompt set with the address:

Street Address: Arch St
Zip Code: 02110-14ND

This returns a page containing a text box that prompts the user to enter a premises within the following range:

2...78 Arch St, Bostom MA [even]

This is an unresolvable range meaning that there is no available data to determine which possible even values between 2 and 78 are valid, and which are invalid. The user therefore has to specify the premises number that will resolve this picklist item, so that a single address can be generated from the range.

Phantom Primary Points

A Phantom Primary Point (PPP) is specific to AUS data. A phantom primary point is a premises which is non-deliverable unless the user enters further secondary information. This secondary information may or may not be in the actual data. The user must enter this sub-premises information in order to complete a final address match.

For example, search using Single Line against the AUS data using the optimal prompt set with the address:

Building number or PO Box: 44
Street: Miller St
Postcode: 2060

This returns a picklist where the first entry is:

44 Miller Street, NORTH SYDNEY NSW

This is marked as a PPP, which means that if this picklist item is selected, the integration must prompt the user for additional sub-premises information.

Incomplete Addresses

An incomplete address is an address that is not deliverable due to missing premises information within the data. This therefore requires the user to provide additional premises information within the data. This therefore requires the user to provide additional premises information so that the address is deliverable. Incomplete addresses are found in various datasets, such as the DEU data.

For example, search using Single Line against the DEU data using the optimal prompt set with the address:

Street: Feldburg
Building number or name:
Postcode: 50181

This returns a picklist with the following single entry:

Feldburg, BEDBURG 50181

This is marked as an incomplete address, which means that if this picklist item is selected, the integration must prompt the user for additional sub-premises information.

Dealing with Special Picklist Items

The following steps should be taken when a picklist item is flagged as an unresolvable range, Phantom Primary Point or incomplete address:

  1. The entry should be stepped into, in the same manner as with hierarchical picklists.
  2. The premises information submitted by the user should then be used to refine the resulting picklist.
  3. The picklist should contain a picklist item at the first position that does not have the original flag, but instead a FullAddress flag/property.

This flag can be used to format the address.

Pro API

Overview