Looker Studio on BigQuery for Weekly Budget Decisions

A Looker Studio report wired straight to the Google Ads and Meta connectors reads correctly for about a month. Then filters take twenty seconds, a blend hits the five-table ceiling, and two pages built on the same connector disagree because each re-queried the API at a different moment. The fix is not a faster report. It is a modelled table in BigQuery underneath, with Looker Studio doing the one thing it is good at: painting an agreed number for someone who has to decide something on Monday. The architecture: One date-partitioned, clustered fact table per grain — daily campaign performance, and where the business needs it, order-level conversions joined to their source. dbt models in between, so a definition such as net media cost exists exactly once. Looker Studio then reads those tables and nothing else: no live connectors, no blends performing joins at render time, no calculated fields carrying business logic where nobody will find it. A BI Engine reservation sized to the fact table holds page loads inside a couple of seconds. BigQuery on-demand scanning runs around six dollars per tebibyte, which makes partition pruning a cost decision as much as a speed one, and I show you the projected monthly figure before the build starts. Every page answers one question: The build opens with a list of the decisions this report exists to serve, each with a named owner and a cadence: who moves budget between Yahoo! JAPAN Ads and Google Search, on which day, using which number. Pages that map to nothing on that list do not get built. Clients push back on this more than on anything else in the engagement, and it is the single thing that determines whether the report is still open six months later. A page of channel trend lines nobody has ever acted on is a maintenance liability with a chart on it. Japanese-market specifics: Yahoo! JAPAN Ads and LINE Ads land in the same schema as Google and Meta, with their own conversion windows carried as columns rather than quietly averaged into a blended figure. Labels run bilingual where a Tokyo team and a foreign parent both read the report. Report timezone is fixed to JST and stated on the page. Any figure still inside a platform's restatement window is marked provisional rather than presented as settled, because the alternative is a Monday meeting reacting to a number that will change by Thursday. Not included: Warehouse and pipeline construction. If the data is not already landing in BigQuery, that is separate work and I say so before quoting rather than after. Attribution modelling. Rebuilding the same content in Tableau or Power BI. Report maintenance past the revision window unless you take the retainer. Who this is wrong for: Teams who want one screen showing everything. That request reliably produces a report with forty controls that gets opened once. It is also wrong where nobody can own the semantic layer afterwards: Looker Studio is easy enough to edit that an unowned report contradicts itself within two quarters, and I would rather hand over to a person than to a department. Handover: The dbt project, the BigQuery dataset with partitioning and clustering configured, the report itself, and a short document stating each metric in one sentence. The work happens in your Google Cloud project, not mine, and nothing depends on my account once the engagement closes.