Skip to content
allanninal.dev/build
Collaborate

Part 5 of 7 · Address verifier series ~5 min read

How stored addresses get swept

Validation at checkout only ever improves addresses collected from today onwards, and a business that has been trading for years has a database full of addresses collected before anybody thought about it. That is where the failed deliveries are.

Key takeaways

  • Sweep the existing database slowly in the background; that is where the failures are.
  • Never contact a customer about a stored address out of the blue.
  • Ask at the next natural moment: their next order, at the address step.
  • Sweep by likelihood of use, not alphabetically. Recent customers first.
  • The number that matters is failed deliveries, not addresses verified.

Where the failures are

How stored addresses are swept in the backgroundA vertical chain of five steps entered by a box labelled The stored database, holding years of addresses. Step one orders by likely use, putting recent customers first. Step two checks at a slow rate of a few hundred a day, with most hitting the cache. Step three asks whether the address verified; most do, and those exit to Record and move on. Step four asks whether to contact the customer out of the blue; the answer is never, and it exits to wait for a natural moment. Step five flags the address to be asked about at their next order. A note says the slow rate is deliberate, because this is a backfill rather than an incident.AWS ACCOUNTThe stored databaseyears of addressesOrder by likely userecent customers firstCheck at a slow ratea few hundred a dayCachemost are hitsVerified?Record and move onmost of themyesContact them?out of the blueNowait for a natural momentneverFlag for next timeasked at their next orderA slow rate is deliberate: this is a backfill, not an incident.
Fig 1. How the existing database is swept. The deliberate slowness and the refusal to contact anybody are what make this safe to run against a customer database.
  • Database
  • App integration
  • Machine learning
  • Security & identity
  • Management
  • Analytics

Never contact out of the blue

The tempting action on discovering four hundred unverified stored addresses is to email those customers and ask them to confirm. It is a bad idea for reasons that are obvious in hindsight: most of the addresses are fine, the email reads as either a phishing attempt or a sign of disorganisation, and the response rate on a request with no benefit to the recipient is very low.

Asking at the next order costs nothing, arrives at a moment when the customer is already thinking about where the parcel goes, and converts at a completely different rate. The cost is patience: a customer who does not order again is never asked, which is fine, because they were never going to receive a delivery either.

Order by likely use

Sweeping alphabetically or by identifier spends the same effort on a customer who ordered last week and one who ordered once in 2019. Ordering by recency of activity means the addresses most likely to be used next are checked first, which front-loads essentially all of the value.

It also matters for the ask: a flag on a recent customer’s address will be acted on within weeks, and one on a dormant customer may never be. Doing the recent ones first means the flags that get resolved are created first.

The numbers

Six months of address sweeping summarised in five numbersA horizontal row of five boxes. Addresses: eleven thousand four hundred stored. Swept: nine thousand one hundred so far. Unverified: six hundred and forty. Asked at reorder: eighty-one, of which sixty-two were fixed. Failed deliveries: down from fourteen to four a month. A note says the last number is the only one that matters and the others explain it.SIX MONTHS OF SWEEPINGAddresses11,400 storedSwept9,100 so farUnverified640Asked at reorder81, of which 62 fixedFailed deliveries14 -> 4 a monthThe last number is the only one that matters. The others explain it.
Fig 2. Six months of sweeping in five numbers. Only the last one is an outcome; the rest are activity, and reporting activity as achievement is the standard failure of a data quality project.
  • Database
  • Management
  • Analytics
  • People

Reporting the failed delivery count rather than the verification count is the discipline that keeps this honest. Nine thousand addresses verified is activity; ten fewer failed deliveries a month is an outcome, and it is what justifies the reference lookups on the bill.

When to stop

A sweep is finite. Once the database has been through once, the ongoing work is small: new addresses are checked at entry, changed addresses are re-checked, and everything else is already known. Running the full sweep repeatedly costs lookups for almost no additional finding.

The sensible ongoing cadence is to re-check an address when it is about to be used for a delivery and its last check is more than a year old, which is a small number per day and catches the genuine changes — renumbering, postcode boundary moves — without re-sweeping eleven thousand records every quarter.

Next: what all of this costs to run.

All posts