Practical framework / 5 MIN READ
Let late records update the right period without hiding revisions
Separate when an event happened, when it arrived and when a report was issued.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A report can change because new records arrive after its first publication. A reliable process assigns those records to the correct period, prevents duplicates and explains material revisions without confusing them with newly generated business.
What you will leave with: Create a late-data policy covering provisional periods, safe reprocessing and revision communication.
Use this when
- Yesterday’s event total keeps increasing after the morning report.
- A recovered connector delivers old records in today’s file.
This lesson concerns ingestion and report revision, not the time customers take to convert after advertising.
Map the different clocks
List the event time, source update time, ingestion time and report publication time. A delayed upload may contain an old event, while a corrected value may legitimately change an old record. Those situations require different handling even if both arrive in today’s extract.
Keep the original timestamps where authorized and preserve source identifiers needed to distinguish retries from new activity. Define which clock places a record into a business period. Do not default to file arrival date unless that is deliberately the question the report answers.
Check the source’s update behavior
Google Analytics documents daily export tables that can receive late events after the event date, as well as temporary intraday tables. This is a concrete reason not to assume a table is final when it first appears. Current timing and exceptions are source-specific.
For each provider, verify its documented revision window and your actual observed delivery. Distinguish a platform limit from an internal promise. If the source discards or changes records after a boundary, re-running your own pipeline cannot necessarily restore them. Avoid claiming completeness beyond the evidence.
Reprocess without multiplying records
Design a bounded lookback that reloads or merges the periods the source may revise. Use a stable supported identity and clear update rules. Appending every recovered file to the existing table can duplicate data when a provider resends the same records.
Test recovery with a controlled fixture: an unchanged record, a late new record and a correction to an earlier record. The unchanged record should remain single, the late record should reach its event period, and the correction should update the intended value with appropriate traceability. Have the data owner approve the implementation.
Make provisional and revised results visible
Choose a close policy based on the decision. An operational pulse can use provisional values with a freshness note; an incentive calculation or finance close may require a stricter reconciliation. Record the report version and the data cutoff used.
When a revision changes a conclusion, send a concise explanation through the authorized reporting process: what changed, which periods are affected and which decisions need review. Small routine revisions can stay in a change log. A closed period is a governance state, not proof that no future correction can ever be necessary.
Make the reasoning concrete.
A hypothetical daily report initially counts 80 valid events for Monday. On Wednesday, 12 additional Monday events arrive and five already-loaded records are resent unchanged. Correct reprocessing produces 92 Monday events, not 97 Wednesday events.
Append by arrival day
Opening: Add all 17 rows to Wednesday.
Hypothesis: The import completes quickly.
Risk: It duplicates five records and misstates the activity date.
Merge by supported identity
Opening: Retain five existing records and add 12 to Monday.
Hypothesis: Monday becomes 92 with a documented revision.
Risk: The identity and correction rules still require validation.
Revise Monday’s provisional total and preserve the original report version if it informed a decision. Do not call the increase new Wednesday activity.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Clocks
Which timestamp determines the business period?
Window
How long can this source revise data?
Identity
How are retries and corrections recognized?
Close
When does provisional reporting become reconciled reporting?
Notice
Which revisions require a visible correction?
Watch for the wrong conclusion.
- Assigning every recovered record to its arrival date.
- Appending resent records without identity checks.
- Treating first export as final.
- Hiding a revision that changes a decision.
Your next action
Write a late-data recovery fixture and a revision policy for one high-value reporting source.
Sources & scope
Frameworks, worksheets and hypothetical examples are original editorial synthesis. Linked primary sources support only the stated concepts. Source checking is not an independent audit of effectiveness. No named human author or reviewer is claimed.
- Google Analytics: BigQuery Export schema →Primary technical documentation · Supports: Documents daily and intraday exports and updates for late-arriving events. The recovery and close-policy recommendations are original; current source-specific timing must be checked.