Data Cleansing & Enrichment

Three separate jobs, in one pass over the file:

• Cleansing — corrects and standardises what you already hold. Addresses are corrected to GNAF, and invalid phone numbers and email addresses are flagged.
• Enrichment — fills the gaps from opted-in records, appending phones, emails and demographic fields, each carrying its own source and recency.
• Deceased suppression — washes the file against the official death register via the Australian Death Check.

They run together because they answer different questions about the same record. Cleansing fixes what is wrong, enrichment adds what is missing, and suppression removes who should not be there at all.

Both, and most clients do both. The usual pattern is an initial full-file cleanse to fix the accumulated backlog, followed by monthly or quarterly runs to keep pace with change.

Field mapping is configured once and reused on every subsequent run, so the recurring job needs no setup.

Scheduling matters because data decays whether or not you touch it. People move, change numbers and die at a steady rate, so a file that is cleansed once and then left alone is simply back where it started within a couple of years.

Duplicate detection matches on multiple keys (name, date of birth, address history and contact points), not on any single field, and a merge only happens above a confidence threshold.

Borderline pairs are never auto-merged. They are returned for review, so a human decides on the cases the rules cannot settle confidently.

That bias is deliberate. An unmerged duplicate is a minor inefficiency you can fix later; an incorrect merge fuses two customers' records together and is considerably harder to unpick once downstream systems have consumed it.

What changed, record by record. Results return in your original file layout with the report columns added alongside, so nothing has to be re-mapped on the way back in.

For each record you can see which fields were corrected and what they were corrected from, which fields were appended and where they came from, and whether the record was flagged as deceased.

That level of detail is what makes the run auditable. You can see the effect on any individual customer instead of accepting a summary count of records changed, and you can apply your own rules about which classes of change get loaded automatically and which get reviewed.

From opted-in Australian consumer records: around 20 million current profiles, drawn from a reference universe of more than 2 billion records.

Opt-in status is preserved on the appended field, not stripped away. If a phone number arrives with marketing consent attached, that status travels with it into your file, so a record enriched for service purposes is not silently converted into a marketing contact.

Each appended field also carries its source and the date it was last verified, so you can apply different confidence rules to a field confirmed last month and one confirmed three years ago.

The file is washed against the Australian Death Check, which draws on state and territory registry data (the same record a death certificate comes from), not an inferred list assembled from returned mail or obituaries.

You choose what happens to a match. Exact matches on multiple fields can be suppressed automatically; weaker matches can be routed for review, so a living customer who shares a name with a deceased person is not cut off in error.

The suppression flag feeds billing, marketing and mail alike. Marketing addressed to someone who has died lands on their family, and that is the complaint most likely to end up as a news story instead of a support ticket.

Files are processed in Australia under ISO 27001 controls, used only for the run they were supplied for, and deleted according to the retention schedule agreed in your contract.

There is also an obligation running the other way, which is often the reason for the work in the first place. The Privacy Act requires you to take reasonable steps to keep personal information accurate, current and complete. A scheduled cleansing run is one of the more straightforward ways to show those steps were taken.

CSV and the common delimited formats, uploaded through Insiight or delivered by SFTP.

Results come back in your original layout with the per-record report columns appended, so the file can go straight back into the system it came from without a transformation step.

If you would rather not move files at all, the same jobs run as endpoints (Address Validate Bulk, Enhance Record Plus and ADC Bulk) directly from your own pipeline.