Stale event data detection and the age at which a record misleads

The sales team asked for a call list of past attendees for a March show, got 62,000 names, and worked through the first thousand with a hit rate that made everybody uncomfortable. Wrong numbers, people who had left, two who had retired. The operations lead said the data was old. Nobody in the room could say what old meant, which meant nobody could say which of the 62,000 to keep.

Stale event data detection is the work of answering that question with a number rather than a shrug, and the first move is to stop looking for one answer.

Age and staleness are different properties

Age is arithmetic. Take the timestamp, subtract it from today, and you have a number that nobody can argue with.

Staleness is a judgement about whether that age still supports a particular use, and the same record can be fresh and stale on the same morning. A 2019 attendance row is a perfect input to a five year attendance trend and a poor input to a phone list. The company name on a 2021 registration is probably still right for a portfolio spend analysis and probably wrong for a booth sales conversation. One record, one age, several verdicts.

This is why a single "data is stale" flag on a table never survives contact with the business. It forces one verdict onto a record that needs several, and the first person whose use case it contradicts stops trusting the flag.

Which definition of timeliness are you using?

The vocabulary here is genuinely contested, and it is worth knowing that before somebody senior asks why two reports disagree.

The DAMA NL Foundation published a research paper on dimensions of data quality in 2020, written by Black and Van Nederpelt, which collected published definitions and evaluated them against a set of criteria. Out of 127 definitions drawn from nine authoritative sources, the authors settled on 60 preferred definitions of quality dimensions and associated concepts. Timeliness alone carries nine competing definitions in their catalogue, attributed to sources including DAMA UK, Eurostat and Wang, and they do not agree with each other.

Two are worth having in your head because they pull in different directions. DAMA UK's 2013 formulation, as recorded in that paper, is the degree to which data represent reality from the required point in time. Wang's 1996 formulation is the extent to which the age of the data is appropriate for the task at hand.

The first is about a moment. The second is about a job. For detecting stale records in an event warehouse the second is the operational one, because it forces the question "appropriate for what", and the answer differs by use. The wider argument about quality being defined by use is K2's territory and this post stays out of it.

Set the maximum age against the use

Write a small table with two columns: the downstream use, and the maximum record age at which that use is still supported. Four rows cover most of an event business.

Contactable audience. Eighteen months since the record was last confirmed by the person. Past that, treat the contact details as unverified.

Attendance and registration history. No limit. A 2016 registration is a fact about 2016 and does not decay.

Job title and seniority. Twenty-four months. Titles change on promotion and on reorganisation, and a seniority mix report built on five year old titles overstates the senior share, because people move up more often than down.

Company for account matching. Thirty-six months, with a caveat. The company on an old record is usually still a real company, so it stays useful for matching, while its relationship to the person may have ended.

Keep the table itself in the warehouse rather than in a document, so a report can join to it and compute the staleness rate without anybody retyping the thresholds. When somebody changes eighteen months to twenty-four, every report that reads the table moves at once and the change has one place to be argued about.

Those numbers are a starting position, and yours should come from measurement. Take a campaign you have already run, split the sends by the age of the record, and plot the bounce rate. The age at which the bounce rate turns upward is your limit, measured on your own audience rather than borrowed from a vendor's benchmark.

What does this look like on the call list?

Now the 62,000 becomes tractable, and it takes one query rather than a project.

Apply the eighteen month rule for contactability. Suppose 24,100 of the 62,000 records have been confirmed by the person within eighteen months, through a registration, a survey response, a badge scan or a profile update. That is 38.9 per cent of the file, and it is the call list. The other 37,900 are not deleted and not called.

Split those 37,900 once more, because they are not homogeneous. Suppose 9,400 of them have an attendance row in one of the last two editions but no recent confirmation of their contact details. Those people are demonstrably still in the market and their phone number is the doubtful part, so they belong in an email re-permission flow instead of a call queue. The remaining 28,500 have neither recent contact nor recent attendance, and the honest description of that group is dormant.

Three numbers, three treatments, and every one of them is defensible in a meeting. Compare that with the original request, which produced one number and no treatment at all.

Report the same split as a standing metric: the share of the person table inside each use's age limit, refreshed monthly. That is your staleness rate, and unlike a generic quality score it maps onto a decision somebody is about to make.

Watch what the rate does across the year, because on an events business it has a shape. Every edition of every show refreshes a chunk of the audience at once, so the contactable share steps up in the fortnight around each show and then decays steadily until the next one. A portfolio with shows in March, June and October has three steps a year and three slow declines between them, and the low point sits just before the biggest show, which is exactly when the audience acquisition team wants the list. Knowing that in advance turns a complaint into a plan.

The decay rate itself is worth measuring once. If the contactable share falls from 42 per cent to 38.9 per cent over four months with no show in between, that is 3.1 percentage points in a third of a year, or roughly nine points a year of natural drift, and it sizes how much re-permission work the audience needs simply to stay level.

The obligation that sits underneath this

There is a legal floor under the commercial argument, and it points the same way.

Article 5(1)(d) of the UK General Data Protection Regulation requires that personal data be "accurate and, where necessary, kept up to date", and that "every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay". The phrase that matters for this post is "having regard to the purposes", which is the same use dependent logic arrived at from the other direction.

A staleness report is one of the more straightforward pieces of evidence that reasonable steps are being taken, because it shows the organisation knows which records are old and what it does with them. How long records may be kept, and the deletion rules that follow, belong to cluster U and are not settled here.

Where this stops

The whole method depends on a timestamp meaning what you think it means, and very often it does not.

In most warehouses the updated timestamp records when the pipeline last wrote the row. A full reload sets it to today for every record, and the following morning your staleness rate is 100 per cent fresh and completely false. The fix is to keep the source system's own modified timestamp as a separate column, and better still to keep a confirmation timestamp that only advances when the person themselves did something: registered, scanned a badge, opened a profile, answered a survey. That column is the one the eighteen month rule should read. Building it is a modelling decision inside the unified data record rather than a monitoring one, and the two are frequently confused, because they both look like freshness from the outside, which is K15's subject and a different question entirely.

The second limit is that absence of change is ambiguous. A record untouched for three years might belong to somebody who has stayed in the same job at the same company and has simply been busy in March, in which case the record is perfectly accurate and merely quiet. Nothing in the warehouse separates that person from somebody whose details went wrong two years ago. Only contact resolves it, which is why the practical use of a staleness report is to size a re-permission campaign rather than to justify a deletion, and why a feed that only lands once a year in K16 gives you so few chances to refresh anything.

This week, add one column to your person table holding the most recent date on which the person themselves did something, computed across registration, scan, survey and profile update. Then count how many records have a value inside eighteen months. That count, against your total, is the honest size of your contactable audience, and on most portfolios it is less than half of what the sales team has been given.