From dashboard KPI to source tables: tracing lineage in Google Cloud

Let's discuss your project →

When a dashboard value looks wrong, the instinct is often to debate the final number. A better starting point is to trace the KPI back to the source tables and views that shaped it. In Google Cloud, data lineage is the feature that helps reconstruct that path across BigQuery and Knowledge Catalog. Google also notes that lineage visibility depends on the object, the operation, and the product configuration, so it should be treated as a verification aid, not as automatic proof that a metric is correct. See the official overview in About data lineage and the BigQuery documentation in Work with Data Catalog.

This guide is intentionally narrow. It does not cover policy tags, masking, dashboard freshness, or KPI quality frameworks. The practical question is simpler: how do you go from a KPI on a dashboard to the source tables, and what should you check when the lineage graph is incomplete or only partly available?

What to collect before opening lineage

Before you inspect the graph, gather three items:

  1. The KPI name exactly as shown on the dashboard.
  2. The BigQuery table or view that feeds it.
  3. The owner of the dataset or transformation, so you know who can confirm meaning and maintenance.

That last item matters because lineage shows structure, not business intent. If a node exists but the semantics changed, only the responsible team can confirm whether the result is still valid.

Step-by-step workflow

1) Define the exact KPI you are investigating

Write down the metric name, time window, filters, and dashboard tile. If the dashboard hides the technical source, lineage does not replace that missing context; it becomes useful only after you know which object to inspect.

2) Open the BigQuery object and inspect its lineage

Google Cloud documents lineage access from BigQuery and Knowledge Catalog, with the lineage view attached to tables and related objects. Start from the final table or view, then read the graph from right to left: downstream result, intermediate transformation, upstream source. The BigQuery guidance and the lineage overview both describe this relationship between the catalog and the queryable objects. Work with Data Catalog · About data lineage

3) Record each hop in plain language

For every step, capture:

  • source object;
  • derived object;
  • transformation type;
  • responsible team.

This is not about building a perfect architecture diagram. It is about making the data path understandable enough to decide the next action.

4) Check whether the lineage is complete enough for the decision you need to make

Google Cloud distinguishes between available lineage and gaps caused by product limits, configuration, or preview scope. In practice, that means a missing edge is not automatically a data incident. It may simply mean the path was not captured in the current setup. The documentation for lineage and table-level views makes that limitation explicit. About data lineage · Work with Data Catalog

Simulated example: a column rename and its downstream impact

Simulated example. This is a teaching case, not a real Dedaloop project.

Assume a dashboard KPI named conversion_rate is fed by a BigQuery table called mart_marketing_daily.

Upstream, that table joins event data from stg_events with a campaign reference table using campaign_id. Later, the source column is renamed to ad_campaign_id, and the transformation query is updated on the same day.

Input for the review

  • KPI: conversion_rate
  • Final object: mart_marketing_daily
  • Upstream object: stg_events
  • Changed field: campaign_id → ad_campaign_id
  • Change type: column rename plus query update

Example output you want from the lineage review

  • The KPI still points to the same final table.
  • The intermediate node changes as expected after the query update.
  • The renamed column appears in the new path.
  • The owner of the transformation confirms that the semantic meaning did not change.

What the lineage can and cannot tell you

  • If the full path appears, you can verify whether the dashboard still reads the expected field.
  • If the path breaks, you have a coverage or configuration question, not yet a business conclusion.
  • If column-level lineage is not available for that object, you may need to fall back to manual query review.

Google Cloud documents both table-level and, in some cases, column-level lineage, but also notes that availability is not universal. About data lineage

Owners and verification responsibilities

A useful rule is to split responsibility by layer:

  • Analytics or data platform team: checks the technical path between tables and views.
  • Pipeline owner: confirms the transformation logic and whether the rename was intentional.
  • Dashboard consumer: verifies that the final number still answers the business question.

Acceptance checks

Treat the review as complete only when these checks pass:

  • the KPI is linked to a known BigQuery object;
  • the visible lineage is sufficient to explain the current path;
  • every visible hop has a named owner;
  • any missing edge is explicitly documented as a product or configuration limit;
  • the next manual step is clear if the graph does not answer the question.

A practical limitation to keep in mind

Lineage improves traceability, but it does not certify semantic correctness on its own. A graph can tell you where data came from and what object transformed it. It cannot decide whether the KPI still means what the business thinks it means. For that, you still need the query logic, the schema, and a human confirmation from the responsible team. Google Cloud’s documentation supports that distinction by describing lineage as a mapping of data flow rather than a substitute for governance review. About data lineage

If you need a simple operational rule, use this one: follow the KPI backward until the lineage stops, then decide whether the remaining gap is acceptable for the decision at hand. If it is not, stop and verify manually before changing the dashboard or the pipeline.

Sources