A period-over-period change can answer two very different questions:
- What is newly reported in this release?
- What do we now believe about an earlier period?
They are both useful. They are not the same measure.
Confusing them is an easy way to inflate activity counts, trigger a false alert, or describe a revised historical baseline as fresh growth. Before calling a difference a trend, ask whether it represents new history or rewritten history.
The practical safeguard is to give every record two dates.
Keep the period being described separate from the date the data became available
The reference period says when the underlying activity occurred or which period the record describes. It might be a sales month, quarter ended, incident date, reporting week, or fiscal year.
The as-of date says when that version of the value was published, received, or extracted. A source publication date, file timestamp, or internal snapshot date can serve this purpose.
Consider a monthly sales file saved on October 5. It contains provisional August sales of $8.2 million. The November 5 file changes August to $8.5 million, adds two stores that filed August results late, and introduces October sales.
Those are three distinct changes:
- October sales are a newly available reference period.
- The August total changing from $8.2 million to $8.5 million is a revision.
- The two additional August store records are late arrivals: new to the dataset, but about an old period.
Calling all three “October growth” would misstate what happened. The later file contains new information, but not all of that information describes new October activity.
Preserve snapshots, not just the latest file
A live dataset usually shows what its publisher believes now. That is often the right version for current reporting. It is not necessarily the version available when an earlier decision was made.
Save each input extract with its as-of date. Then compare the saved October extract with the saved November extract. If instead an old report is compared with today’s live data, revised history may quietly replace the history that was known at the time.
This distinction is routine in official statistics. The U.S. Bureau of Labor Statistics publishes preliminary employment estimates and revises them as more complete reports arrive. Its employment estimates also receive later annual benchmark revisions. The Bureau of Economic Analysis similarly describes early GDP estimates as based on incomplete source data and updates them in later releases.
Revisions are not necessarily mistakes. They are often part of producing timely data while allowing later information to improve the estimate.
For reviews of a past forecast or decision, use the vintage available at that time. For a current assessment, use the latest consistent vintage. Mixing the two makes it hard to tell whether a forecast failed or the historical record was later updated.
Compare records with a stable key
Before looking at values, define what makes two rows comparable. A typical key might be:
entity ID + metric + reference period + geography + unit
The exact fields depend on the data. A fiscal quarter may need a fiscal-year label. A rate may need its denominator or population definition. A product metric may need an edition, package size, or currency.
A matching entity ID alone is rarely enough. If the unit shifts from dollars to thousands of dollars, or a geography is redrawn, an apparent value change may be a definition change. It should not enter a normal trend calculation without an explicit mapping or a separate label.
Classify differences before aggregating them
A bare old-versus-new delta hides the reason for change. At the row level, sort differences into a few clear buckets:
| Change type | Meaning |
|---|---|
| New reference period | A newly available month, quarter, or other period |
| Late-arriving record | Newly reported data describing an older period |
| Revised value | Same comparison key and reference period, but a later value |
| Withdrawn or deleted record | A row disappeared and needs investigation |
| Definition or classification change | The measure, category, coverage, or mapping changed |
| Unresolved | The available evidence does not support a confident classification |
The unresolved bucket matters. A deleted row could represent a withdrawal, deduplication, publication error, changed source filter, or an access problem. It does not automatically mean zero activity, a closure, or a cancellation.
A simple comparison table helps keep the work reviewable: comparison key, reference period, old value, new value, old as-of date, new as-of date, change type, stated reason, and review status.
Report current activity and revised history separately
The final report should preserve the distinction made in the comparison. For example:
> This release adds 126 records for the newly available period. It also revises 41 records from May through August, withdraws three records, and changes two category mappings. Period-over-period growth should be calculated against a consistently revised historical baseline.
That wording tells readers what is new, what changed about the past, and what still needs review.
Set a revision window where the source has a known pattern. If the prior two months commonly change, compare and label them every cycle. If a source periodically revises several years, treat it as a benchmark or restatement event and rerun affected trend analysis. Eurostat’s revision policy, for example, distinguishes routine updates from major revisions involving sources, methods, definitions, or classifications.
The working rule is plain: a changed row is evidence of a data update. It becomes evidence of a new event only when its reference period and change type support that interpretation.
Morrow Creek Data Services handles paid research, cleanup, verification, and structured delivery projects.
Start a data project