A date range control in Looker Studio (called Data Studio in current Google documentation) does one precise job: it filters eligible charts according to each chart’s Date range dimension. It does not make every source report the same business event. In a B2B revenue dashboard, this distinction decides whether a monthly comparison is useful or fundamentally misleading. The first step is to define which date belongs to each metric—before adjusting the calendar widget.
For example, Google Ads cost may refer to ad interactions in October, GA4 sessions to activity in October, and CRM closed revenue to deals completed in October. Those numbers can belong on one operating dashboard, but they are not automatically an October acquisition cohort. A lead from an earlier month can close during the selected month. A late CRM update can arrive after the report is first viewed.
Start with the question the dashboard needs to answer
There are two legitimate but different questions. A period activity report asks what happened between selected dates: spend recorded, sessions observed, meetings held, and revenue closed in that window. A cohort report asks what ultimately happened to leads or accounts originating from a defined period, even when their later milestones occurred in another month. A single date control can support the first question; the second needs a persisted identifier and a clearly defined cohort anchor.
Choose the reporting question before comparing rates or drawing causal conclusions. The same-period ratio of closed revenue to advertising spend can be a management indicator, but it is not proof that the spend in that calendar window caused the revenue reported in that window.
Map each source to the date it actually filters
| Source and measure | Date meaning | Interpretation and caution |
|---|---|---|
| GA4 sessions or key events | Activity date used by the GA4-connected chart | Shows observed or modeled web activity according to GA4 definitions, not a sales-qualified opportunity. |
| Google Ads cost | Advertising reporting date associated with ad activity | A selected reporting window is not automatically the date a CRM opportunity was created or won. |
| CRM leads created | Lead creation timestamp | Useful for inquiry volume; later qualification and revenue may occur in another period. |
| CRM qualified or won milestones | The corresponding stage-change or closed date | Describes commercial movement in the window, not necessarily acquisition from it. |
A CRM dataset may contain several legitimate dates—for example lead_created_at, meeting_held_at, and closed_won_at. Do not let whichever happens to be the first date field silently determine the meaning of a chart. Select the Date range dimension explicitly for that chart, or use separately modeled views for different event dates. Google’s date range control documentation confirms that charts with multiple date fields respond through the date dimension configured for that chart.
Configure a date range control without changing the metric definition
- Add the control: edit the report, choose Add a control, then Date range control. Set an explicit default window rather than assuming every data source has the same default.
- Check the scope: a control normally affects eligible charts on its page. Group it with selected charts when those visuals should have a separate window, or set a chart-level date range override where needed.
- Inspect the chart date: for a table based on a warehouse or CRM source, select the intended Date range dimension and verify its data type. Google Analytics and Google Ads connectors automatically select their built-in date field.
- Record the business meaning: label a metric “Leads created” or “Revenue closed,” not simply “Leads” or “Revenue,” when dates have different meanings.
- Test an isolated chart: temporarily choose a narrow period containing a known record and confirm that the chart responds before reconnecting the broader dashboard.
Google’s documentation on applying controls to specific charts and grouping components describes how scope changes when controls and charts are grouped. Do not confuse a page-wide control with a global guarantee that every chart has the same date basis.
A worked example: one month, three valid numbers, one invalid inference
Illustrative scenario, not client data: a leadership dashboard selects October 1–31. Google Ads shows $12,000 in campaign cost, GA4 shows 9,000 sessions, and CRM shows $90,000 in contracts closed that month. None of those individual numbers is intrinsically wrong. But a claim that October ads generated $90,000 in revenue would require additional evidence linking the October media interactions to the actual opportunities, with an explicit attribution method and time lag.
Suppose a contract closed on October 20 after a lead was created in August. It contributes to October closed revenue and to an August-originated lead cohort. Both classifications are defensible because they answer different questions. For CAC, ROAS, pipeline contribution, and forecasting, pick a definition consistent with the decision being made. For cross-system conversion dates, see Scale Orbit’s GA4-to-CRM date reconciliation guide.
Create a reporting contract that travels with the dashboard
A practical dashboard specification needs only a handful of fields, but they should be visible to analysts and decision-makers. Record the metric name, source system, event or timestamp used, timezone, record grain, freshness expectation, attribution logic where relevant, and the person responsible for investigating a discrepancy. Keep this definition next to the dashboard or in its linked documentation.
| Metric | Date basis | Grain | Review question |
|---|---|---|---|
| Campaign spend | Platform reporting date | Campaign × date | How much was allocated to the selected window? |
| Qualified meetings held | CRM meeting completion date | Meeting ID | How many meetings actually happened? |
| New opportunities | CRM stage-entry timestamp | Opportunity ID | How many opportunities entered the stage? |
| Closed revenue | CRM won/close date with approved amount definition | Opportunity or booking ID | What did sales close in this window? |
A reporting contract prevents a common problem: stakeholders assume all figures update at the same speed, count the same entities, and obey the same attribution rules simply because they share one selector. The related article on marketing data lineage explains how to trace a KPI back to its source records.
Handle different timezones and incomplete recent data
Two systems can both expose a Date field and still disagree around midnight because their source timezones differ. Decide whether the report follows the advertising account timezone, the GA4 property timezone, or an agreed company reporting timezone. Document the conversion of timestamps from CRM or warehouse sources before comparing daily totals. For mixed timezone setups, use a verified sample record near a date boundary and check which day each chart counts it in.
Freshness adds another dimension. Google’s data freshness documentation explains that reports can serve cached query results until a connector’s freshness threshold is exceeded. Separately, underlying systems may update or revise their own data after the initial event. The date control does not remove this lag. A label such as “Data through yesterday; CRM refresh checked at 08:00 ET” can be more decision-useful than suggesting the entire report is live.
For weekly management reporting, choose an as-of timestamp and a close policy. For example, present a provisional recent week separately from a finalized prior week when conversions or CRM classifications are still changing. Scale Orbit’s marketing data freshness guide covers this operating expectation in more detail.
A 10-minute QA pass before the report goes to executives
- Window: select a short known period, then a second period; confirm which charts change and which intentionally remain fixed.
- Fields: inspect the date field and record grain behind every CRM, warehouse, or spreadsheet chart.
- Boundaries: compare one record near midnight and one record on the first or last reporting day.
- Totals: reconcile one metric against its authoritative source, using identical timezone, filters, status definitions, and data-finality policy.
- Controls: test grouped charts, default chart overrides, and pages that reuse the same report-level selector.
- Freshness: check the source update and cache settings; avoid treating a recent zero as confirmed zero activity.
- Labels: state which values are period activity, which are acquisition-cohort outcomes, and which are estimates.
Troubleshoot common symptoms without redesigning the whole report
| Symptom | Likely place to investigate | Safest first test |
|---|---|---|
| A chart does not respond to the date control | Missing or wrong Date range dimension, chart override, or control group | Select the chart and inspect Setup plus grouping. |
| CRM revenue shifts when the selected month changes | The selected date is closed date, not lead acquisition date | Check a known opportunity created earlier and closed in the chosen month. |
| Two charts disagree at a period boundary | Timezones, data processing, record definitions | Compare one timestamped source record across both systems. |
| Old totals change after refreshing | Late CRM updates, source revision, cache/freshness | Check source update time and whether the reporting period was finalized. |
When to use a warehouse instead of another date filter
If leadership asks how September-originated leads converted into pipeline and revenue over the following months, build a cohort dataset keyed to lead, account, or opportunity IDs, with an agreed originating date and stage-event timestamps. You may then visualize elapsed time and outcome in Looker Studio or another BI tool. A date control alone cannot manufacture those joins, and blending tables with different grains can duplicate totals. See the existing Looker Studio blending guide before combining campaign, contact, and opportunity tables.
Frequently asked questions
Why does a Google Ads chart change but my CRM scorecard does not?
The CRM chart may lack a usable date dimension, may have a chart-level override, or may not fall under the control’s current scope. First inspect the configured date field and group, not the campaign tags.
Does a shared date range make Google Ads ROAS match CRM revenue?
No. The selected period may be consistent while the metrics still differ in attribution window, date basis, modeling, event identity, and qualification definition. Reconcile those before interpreting the ratio.
Should I use lead created date or closed-won date?
Use lead created date to measure acquisition cohorts, and closed-won date to measure closing activity within a period. If you need both, create separately labeled views and an explicit join for longitudinal attribution.
Bottom line: a useful Looker Studio date range control is part of a measurement contract, not a substitute for one. Define the date and entity behind each metric, test source boundaries, and give executives the distinction between what happened during a month and what happened to the cohort that started in it.
Source check: November 1, 2026. Platform behavior verified against Google’s Date range control, chart configuration, control scope, and data freshness documentation. Worked figures are hypothetical.
How did this article land?
Choose one reaction. You can change it anytime.