Improving reporting reliability with BigQuery at the V&A

The V&A is a family of museums focused on art, design and performance. Alongside their exhibitions and public programmes, their digital channels play an important role in helping people explore collections and plan visits.

The V&A had a set of important dashboards in Looker Studio, pulling data directly from GA4. These reports were widely used across the organisation, but they regularly timed out. People would open a dashboard and see no data, not because information was missing, but because the setup was hitting GA4 usage limits.

Early conversations focused on understanding those limits and what options were available to make the reporting more reliable.

Before rebuilding anything, we documented what was already there.

We went through the existing data in the dashboards and captured how each metric and dimension had been defined, including all the bespoke logic that had built up over time. This became a detailed reference document with two important purposes:

• the V&A could clearly see what was in the dashboards and how it worked
• we could rebuild the reporting on a new foundation without losing definitions people still relied on

Alongside that documentation, we had regular check-ins with the V&A team to sense-check how the reports were used in real life; how different teams relied on them; what was missing, and what mattered most to carry across.

The dashboards were pulling data directly from GA4, which was causing the timing-out issues. To address this, we supported the V&A to move GA4 data into BigQuery, which doesn’t have the same usage limits.

This changed how the data source within the dashboard was powered, giving the team more control over how data is accessed and used, and created a foundation that could support additional data sources in future, if needed.

BigQuery gives much more flexibility for reporting, but it also introduces a cost consideration. While storing data is relatively inexpensive, running lots of queries directly against raw data can add up over time.

To manage this, we set up a dbt (Data Build Tool) layer between BigQuery and Looker Studio. Rather than every report view querying the raw data directly, the key tables are prepared in advance and then reused by the dashboards. In practice, this means the heavy lifting happens once, rather than every time someone opens a report.

This approach keeps reporting costs under control while still allowing the V&A to benefit from having their data in BigQuery.

When building these tables, we focused on the KPIs that mattered most to the V&A, including ticket purchases, visits to key areas of the site, and how users search for and engage with content, along with the most appropriate dimensions for analysing them.

With the new BigQuery setup in place, we rebuilt two key dashboards so they ran against BigQuery rather than the GA4 connector.

Because the existing reports had built up a lot of bespoke metrics and definitions over time, rebuilding them required care. We focused on carrying that logic across accurately, so long-standing definitions people relied on were preserved, while the underlying structure became easier to maintain.

An important part of this work was being clear and transparent about where everything lived and who owned it.

From the outset, we set the BigQuery and dbt setup in the V&A’s own infrastructure, including their GitHub environment. This means the reporting isn’t dependent on Torchbox systems, and the V&A has full access to and control over how it works.

That approach avoids situations where organisations lose access to their reporting when an agency steps away, and makes it easier for in-house teams to maintain and develop the setup over time.

The outcomes of this work include delivery of:

• GA4 data set up in a BigQuery environment
• a dbt layer in place to support more cost-effective reporting
• two dashboards migrated and rebuilt on the new setup
• detailed documentation of how reports and metrics are defined

Together, this gives the V&A a reporting foundation that they can build on, rather than a set of dashboards that are hard to maintain or explain.

Alongside the delivery, we worked closely with the V&A team throughout the project. Communication was informal and open, making it easier for them to ask questions and understand how the setup works. The aim wasn’t just to deliver new reporting, but to leave the team better equipped to work with it themselves in the future.