Looker Studio Dashboards on a Governed BigQuery Model

A Looker Studio page built on the native GA4 connector re-queries on every filter change and samples above roughly two million events a month, which means two people opening the same page on the same morning can read different revenue. Everything I build reads from date-partitioned tables in BigQuery, so the report holds no logic at all. It displays numbers that were agreed before the chart existed. The metric dictionary comes first: Before any chart, every metric on the page gets one definition, one owner by name, and one piece of SQL in version control that produces it. Where two departments hold two definitions of the same word, and conversion is almost always the word, the dictionary records both under separate names rather than quietly picking a winner. This step is where the difficult conversations happen, and moving it after the build is how dashboards get abandoned in month three. The model, then the page: Scheduled queries or dbt models materialise daily tables partitioned on date and clustered on whichever field the report filters most. Pages read those tables and nothing else. BigQuery on-demand bills per tebibyte scanned, so partition pruning is a cost decision as much as a speed one, and where an executive page is opened dozens of times a day a BI Engine reservation is cheaper than the scans it replaces. I show you that arithmetic before you agree to either. No blends. A Looker Studio blend is a left join executed in the browser, it drops rows without saying so, and it is the most common reason a dashboard total disagrees with the source it came from. Joins happen in SQL, where they can be tested and where the row counts are visible. Page architecture: One decision per page. An executive page answering whether we are on plan. A channel page answering where the money moved. A market page for the country leads, in their currency. Every page carries a freshness stamp showing the last successful load, because a stale dashboard that looks healthy is more dangerous than one that is visibly broken. A page with no named owner does not get built, and I will hold that line during scoping when the list of requested pages doubles. By sector: Travel and hospitality: revenue attaches to booking date and to stay date, both views exist, and cancellations are shown rather than netted away where nobody notices them. Logistics: quote to load, with 30 to 90 day lead times, so cohorts run by quote month. Conversion-month reporting makes a weak quarter look strong and a strong one look weak, and both errors get discovered at the worst moment. Pharma and medtech: no patient-level rows reach a report. Aggregation to HCP segment and geography, access through BigQuery authorised views with row-level policy, and a documented retention period that someone signs. Not included: Warehouse migration, CRM implementation, LookML for Looker proper, and rebuilds in Power BI or Tableau. No real-time pages. The decisions these reports support are made weekly, and a live tile invites people to react to noise and call it responsiveness. Who this is not for: Anyone who wants the dashboard the last agency built, only faster. If the definitions underneath were never agreed, rebuilding the surface reproduces the same argument at a higher frame rate. What you receive: The dictionary, the SQL models in your repository, the report owned by your Google account rather than mine, a runbook for the scheduled loads including what to do when one fails, and one session with the people who will actually use it in which we delete the tiles nobody is willing to defend.