Date controls that make clients think the data is wrong

The client has your dashboard on one screen and Google Ads on the other. Yours says 412 conversions, the platform says 431. They ask which one is wrong.

Nine times out of ten neither is. They are counting different days. The tenth time is a genuine tracking or attribution problem, and it is worth ruling out the nine before you go looking for the one.

Work through this list in order. It takes about five minutes and it resolves most of these calls before they become a credibility problem.

Auto date range means whatever the connector says it means, and the connectors disagree. Google documents it: Sheets and BigQuery provide the entire range of dates in the dataset, while the Ads, Analytics and YouTube connectors provide the last 28 days by default.

So a report blending a BigQuery table with a Google Ads source, both left on Auto, is comparing all of history against the last 28 days on the same page. Every ratio between them is nonsense and every chart looks plausible.

Fix: never leave Auto on a client report. Set an explicit default date range at report level, so every chart inherits the same window and a new chart cannot arrive with a different one.

Rolling ranges are relative to today, and the presets exclude today unless told otherwise. An Include today checkbox adds data collected so far for the current day, and it is unchecked by default.

Do the arithmetic on why this looks like an error. A client checks at 3pm on the 15th. The platform, defaulting to a range that includes today, shows 14.6 days of data. Your report, on Last 14 days excluding today, shows 14 days ending yesterday. On an account running 30 conversions a day, that is an 18 conversion gap that appears and disappears depending on what time of day somebody looks.

Including today has its own cost, because a partial day drags every trend line down at the right-hand edge and makes the most recent point look like a collapse. Google's own note on Analytics sampling makes the same point from another angle: including today's date may have sampling implications, and removing today from the range is the first thing to try when Looker Studio and Analytics disagree.

Fix: pick one convention, apply it to every chart, and put the convention in the report footer in plain words. Excluding today is usually the better default for a client report, precisely because it removes the partial-day artefact.

Looker Studio defaults its weekly rolling window to Sunday. Presets exist for the other convention, and you have to choose them: This week (starts Monday) and Last week (starts Monday).

Most Canadian and European businesses run their week Monday to Sunday. A weekly chart on the Sunday default therefore attributes Sunday's numbers to the wrong week, every week, by exactly one day of volume.

It is invisible on a monthly total and glaring on a week-over-week comparison, which is the chart operations people actually look at.

Fix: ask which day the client's week starts on, once, and set every weekly range and every week-grain chart to match.

A date range control filters on the field designated as that chart's date range dimension, and if the data source has several date fields the choice is yours to get wrong.

Google's own example is the one that comes up in practice: a source with order_date and ship_date, where changing which is the date range dimension changes every number on the page. And a single date range control can filter multiple charts using different date fields, because each chart responds using its own date range dimension.

So one control, one selected range, and two charts counting different things. The client sees two numbers that should agree and do not.

There is a related constraint. For some source types, including Google Ads and Google Analytics, the date range dimension is set automatically and cannot be changed. So a conversion counted on the click date in one system and the conversion date in another cannot be reconciled by changing a Looker Studio setting at all. That is an attribution question, and it belongs in conversion lag and attribution windows rather than in a dashboard fix.

Fix: label the date basis on the chart or the page. Revenue by order date and revenue by ship date are different reports and should say which they are.

A date range control governs all the charts on its page. Not the report, the page. Charts on other pages keep their own defaults unless the control is made a report-level component.

There are two ways to narrow it further, both legitimate and both a trap when undocumented. Setting a date range property on an individual chart overrides the control for that chart. Grouping a control with a chart limits the control to that chart, and leaves every ungrouped chart unaffected.

So a client changes the date to last quarter, three charts update, and one does not because somebody set an override on it six months ago. That single stubborn chart destroys more trust than a wrong number, because it makes the whole page look unreliable.

Fix: audit for overrides before handing a report over. Anything with a chart-level date range needs a visible label saying what period it shows and why.

Comparison ranges look like something a viewer controls and are not. Google's note is explicit: while viewers and editors can use a date range control to set the current period, only report editors can set the comparison date range.

So a client who changes the current range to last quarter is now comparing last quarter against whatever comparison you configured, which may be the previous period, the previous year, or a fixed range from when you built it. The delta arrows update, they are computed against something the client did not choose, and there is nothing on screen saying so.

The same ambiguity runs through comparison calculations. A percent-of-max figure can be computed relative to the base period or relative to the corresponding comparison period, and Google's worked example shows the two producing 80.69 percent and 100 percent from the same data point. Nothing on the chart says which one you picked.

Cached data compounds it. A dashboard shows results held in memory until the freshness threshold expires, and on Google marketing connectors that threshold is fixed at 12 hours and cannot be changed. A client refreshing the page at 4pm may be seeing a query answered at 7am.

Fix: state the comparison basis in the chart title, and put a last-updated line and the freshness interval in the report footer. Both are one-time edits that stop a recurring conversation, and they are the reporting equivalent of the freshness commitments in data freshness SLAs for reporting.

Every one of these is a labelling problem before it is a data problem. The report was right and the reader had no way to know what they were looking at.

That is worth saying to yourself before rebuilding anything, because the instinct is to go hunting in the pipeline. Rule out the seven rows above first, and if the numbers still disagree after that, you have a genuine measurement gap of the kind covered in why Google Ads and GA4 numbers do not match. Resolving that properly is a conversion attribution audit, not a dashboard change.

Put a footer on every client report carrying three things: the date basis, the freshness interval, and the last time the data was pulled. Three lines, written once, and they answer most of what generates a support email.

Then set the report-level date range explicitly and stop relying on Auto anywhere. A default that varies by connector is a defect waiting for a blend to expose it.

Neither habit makes the report better. Both make it trusted, which is the thing that determines whether anyone opens it next month, and that is the same standard applied to the cadence in the client reporting cycle that eats your first week and to the pre-publication checks in testing data before a dashboard sees it.