Skip to content
Naurt Docs

Input Filter

Reference

When searching for an address, you need to provide enough information to be able to confidently identify the intended address. Take for instance the address “10 Main Road”. This is technically a valid address, and the person searching for it may have a specific address in mind. However, there are many Main Roads in the UK, and globally probably hundreds or thousands.

Databases are not humans searching records. If we ask a database to find “10 Main Road”, it will diligently go out and find a match for us. However, we as humans know whatever it finds can not be a good match since there’s just not enough information to identify a specific address with confidence.

Naurt solves this problem with a process called input filtering. Input filtering rejects some requests very early on, before any attempt to search the database is made.

Input filtering is controlled with the input_filter parameter of the options.

For example, the options could look like

{
  "input_filter": "strict"
}

The input filter parameter has three levels:

  • none
  • loose
  • strict

If you do not include this parameter, it will default to loose.

none means that this feature is turned off entirely. All requests will be searched, and the database will most likely find something. That may be a very poor match. For instance if you were to search a single postcode, it will pick one address within the postcode at random to be the best_match.

loose as mentioned is the default. It will filter some poor inputs, but still errs on the side of allowing requests. Some examples of requests which would be blocked by this filter:

  • “Flat 6”
  • “2”
  • “Main Road”
  • “BN3 4BH”

strict filters out much more poor inputs. Some examples of additional requests which would also be filtered out at this level:

  • “5 Main Road”
  • “BN3 4BH, BN3 4BH”

Which Input Filter Should I Use?

Section titled “Which Input Filter Should I Use?”

Input filtering is a topic of balancing. While stricter and stricter filters will help prevent bad searches, they will also start to reject some good searches. Depending on how much control over address input you have, different levels are possible.

The best way to handle input filtering is to sidestep the issue: do not allow customers to type in an address. Provide postcode lookup and autocomplete services, and force addresses to comply to forms with fields (which have sections like “postcode” and “street” and so on).

However, this level of input control is not always possible. If you consistently receive poor addresses from a third party, consider switching to strict. There is some chance that good inputs will be filtered out. To handle all rejected cases, we suggest human intervention at this point. Provide them with the ability to make the request to Naurt again with the input filter off, to see if anything can be obtained, or the ability to reject the request entirely and seek clarification from the customer. In Naurt’s opinion, it’s better to handle as many potentially poor addresses as possible before the packages actually leave the facility as correcting a missed or failed delivery once dispatched is much harder.