Monday’s CPA read €41.20 when you sent the link. On Tuesday morning the same tile says €38.60, and the client has noticed. Nothing broke. The number was never wrong, it was just early, and dashboard data freshness is the part of live reporting that nobody briefs the client on before it bites.
A PDF never had this problem. It was wrong in a quieter way: frozen at the moment of export, aging silently, but at least consistent with itself. A live link gives up that false stability in exchange for being current, and the trade only works if the client understands what they are looking at. Otherwise the first shifted number reads as a mistake in your reporting rather than a property of the data.
So here is the set of questions clients actually ask, and the answers worth having ready before they do.
“Why did Monday’s number change on Tuesday?”
Because Monday was not finished when you first looked at it. Most campaign data arrives in a provisional state and settles over the following hours or days. Depending on the channel, the number you saw at 9:00 on Tuesday was based on a partial picture of Monday: delivery that had been logged but not yet validated, conversions that had fired but not yet been joined back to the click or impression that caused them, spend that had not yet had fees or currency conversion applied.
The direction of the movement tells you which kind of settling you are seeing. Impressions and spend usually go down or stay flat as invalid traffic gets filtered out. Conversions almost always go up, because they get credited backwards to the day of the click, not the day they happened. That is why CPA falls as the week ages while CTR barely moves at all.
The same report can also move in both directions at once. Spend revises down, conversions revise up, and the CPA tile drops noticeably more than either input changed. A client watching a single derived metric sees a bigger swing than the underlying data actually produced.
“Is one of these numbers the real one?”
The later one, usually, but not because the earlier one was false. Both were accurate statements about what was known at the time.
Three things cause the lag, and none of them have anything to do with how you built the report.
Platform finalisation. DSPs and ad platforms publish fast and correct later. Invalid traffic filtering, delivery reconciliation against the logs, deduplicated reach across placements: these run after the fact. Reach and frequency are the worst offenders, because deduplication across a week cannot happen until the week exists. A frequency figure for a campaign that started yesterday is close to meaningless.
Attribution windows. This is the big one, and most clients have never had it explained to them. A 7-day click window means a conversion on the 14th can still be credited to a click on the 8th, so the 8th keeps improving for a week after it ends. Attribution lag in reporting is not a delay in the pipeline, it is the model working as designed, and it means recent days are structurally understated. View-through windows stretch this further. If you report on a view-through model, the last three or four days of any dashboard are a draft.
The handoff. When the data left the platform, and what day boundary it used. A campaign bought in a UTC-reporting platform and reported to a client in Brussels has a shifting definition of “yesterday”. Then there is the gap between the export and the upload. If your Monday figures came from a pull taken at 08:00 Monday, “Monday” in that report is an empty day, and your client is looking at a live report data delay that is entirely about timing rather than accuracy.
What dashboard data freshness can actually promise
Live meant current, not instant. Part of the trust problem is that one word. Clients hear “live dashboard” and picture a stock ticker, a number that is true at the moment they look at it. What live reporting actually solves is a duller problem: reports stop being updatable the second they become an attachment.
Real-time dashboard accuracy is not something you can promise, because the platforms underneath you do not offer it. What you can promise is that the client is always looking at the most recent version of the truth rather than a version from the 3rd of last month, and that when the data settles, the page settles with it instead of requiring a correction email. That is a better deal than a frozen file, and it is worth saying in those terms. Most of the value of reporting through a live dashboard rather than a slide deck comes from exactly that: you never have to send a second file contradicting the first one.
The line that beats the question
Client dashboard trust is cheap to protect and expensive to rebuild. One sentence on the report, placed near the metrics it affects, does almost all the work:
Conversion figures for the last 7 days are provisional and typically revise upward as attribution completes. Spend and delivery finalise within 48 hours.
Put it in a text block on the dashboard, not in the email. The email gets read once. The dashboard gets opened on a Tuesday by someone who was not on the original thread, which is the exact moment the question gets asked.
Two refinements matter more than the wording. Name your window explicitly, because “recent data may change” tells a client nothing about whether to trust the figure in front of them, while seven days is a boundary they can act on. And if a metric settles slowly, consider showing the unsettled days visually separated, or excluding them from the headline tile. A client who sees a dip at the right edge of every line chart will eventually ask about it, and the honest answer is that the dip is an artifact. Choosing which metrics to lead with includes deciding which ones are stable enough to put in a KPI tile at all.
Teams that get ahead of this see fewer “quick question about the numbers” messages, which is the same mechanism behind most of why clients reply to reports in the first place. They are not querying your competence. They are filling a gap the report left open.
When the movement is actually a problem
Normal settling has a shape. It is small, it is directional, and it stops. Once you know what that shape looks like for your channels, the exceptions get easy to spot.
Investigate when:
- A number moves after the window should have closed. A conversion count for the 2nd changing on the 20th is not attribution. Something was reprocessed, or your data got loaded twice.
- The movement is large. Spend revising by 1 to 3% is filtering. Spend revising by 20% is a reconciliation problem, a wrong date range, or a currency or fee setting that changed between pulls.
- It moves in the wrong direction. Conversions dropping, or spend climbing after the fact, usually points to a duplicate or partial load rather than platform finalisation.
- A figure changes with no new data behind it. If nothing was uploaded and the number differs, the issue is in your process.
- The dashboard and the invoice disagree at month end. Platform-reported spend and billable spend differ for good reasons (fees, rounding, billable impressions). Reconcile before the client does, because this is the discrepancy that actually damages the relationship.
A habit worth building for that last one: on the day you close the month, snapshot the figures you intend to invoice against. Export the report to PDF or Excel and keep it. When someone asks in March what February said, you have an answer that does not depend on reconstructing a settled dataset.
That snapshot discipline is also why live and static are not really in competition. You want the page current for the client, and a fixed copy for yourself. Screebl covers both sides: the shared link reflects the data as it stands, you can unpublish or update it without reissuing anything, and the PDF, Excel or CSV export reproduces what the client saw at the moment you took it. If you are weighing up what to look for in client reporting software, holding both versions without contradicting yourself belongs on the list. The pricing page sets out which plans include client-branded reports and the client portal.
Questions clients ask about shifting dashboard numbers
How long until campaign data is final? Delivery metrics (impressions, clicks, spend) are usually stable within 24 to 48 hours. Conversions depend entirely on your attribution window: a 7-day click model means a given day keeps changing for seven days after it ends. View-through models extend that further. Reach and frequency only make sense over a completed period.
Should I report only on data that is more than a week old? For performance conclusions, mostly yes. For pacing and spend monitoring, no, because an outdated delivery figure is worse than a provisional one. The practical split is to keep current data visible for monitoring and labelled as provisional, while putting the analysis and any commentary on periods that have settled.
Does this mean a live dashboard is less reliable than a PDF? No. The PDF contained the same provisional numbers, it just never showed you that they had changed. A static report sent on the 1st with partial attribution stays wrong forever and nobody notices.
What do I say when a client has already screenshotted the old number? Acknowledge the difference, name the cause specifically, and give the window. “Conversions get credited back to the click date, so the 14th was still filling in when you looked. It should be stable by Thursday.” Vagueness is what makes this sound like a cover story.
Can attribution lag make a campaign look like it is failing? Yes, and it is a real risk in weekly reporting. Any report that ends on yesterday shows the worst-looking version of the most recent days. If a client reacts to that by asking for budget shifts, you are optimising against incomplete data, and it is worth saying so before the decision gets made.
