Looker Studio data blending
Data blending in Looker Studio combines fields from up to several sources into one logical table by joining on configured keys. It supports join types (left outer, inner, full outer, cross). The common failure is join-key cardinality: a one-to-many key fan-out multiplies metric rows, so blended totals can silently overcount.
What this means
Blending joins multiple data sources into one table you can chart. You pick a join configuration — the keys that link rows across sources — and a join type. The result behaves like a single source for the chart that uses it.
Join type and key cardinality
Looker Studio supports left outer, inner, full outer, and cross joins. The pitfall is cardinality: if the join key is one-to-many (one date maps to many campaign rows), the 'one' side's metrics repeat per matching row and aggregate too high. Inner joins silently drop keys present in only one source. Match key granularity across sources, and verify totals against each source alone before trusting the blend.
- Join types: left outer, inner, full outer, cross
- One-to-many keys fan out and overcount metrics
- Inner joins drop unmatched keys
How it appears in analytics and logs
A blended table is the result of a join. If metrics look inflated, suspect a one-to-many join key duplicating rows; if rows vanish, suspect an inner join dropping unmatched keys or mismatched key formatting.
Diagnostic use case
Combine, for example, GA4 sessions with ad-platform cost on a shared date or campaign key to build cost-per-result views in a single Looker Studio chart.
What WebmasterID can help detect
WebmasterID exposes first-party metrics you can bring into a blended report alongside other sources, without relying on cross-site tracking.
Common mistakes
- Blending on a one-to-many key and overcounting metrics.
- Using an inner join and silently losing unmatched rows.
- Joining sources with mismatched key granularity or formatting.
Privacy and accuracy notes
Blending operates on aggregated source data. It does not create cross-site identity; avoid joining on personal identifiers and keep keys non-identifying.
Related pages
- Looker Studio connectors
A connector is the bridge between Looker Studio and a data source — Google connectors (GA4, BigQuery, Sheets, Ads) and community/partner connectors for everything else. The connector defines available fields, default aggregations, and data freshness/caching behavior, all of which shape what a report can show and how current it is.
- Looker Studio calculated fields
Calculated fields let you derive new fields with formulas — arithmetic, CASE logic, text and date functions — at the data-source or chart level. The decisive subtlety is aggregation: a formula's result depends on whether it is computed per-row then aggregated, or on already-aggregated values, which differs between field-level and chart-level calculations.
- BigQuery vs UI discrepancies
When GA4's BigQuery export and the reporting interface show different totals, it is usually not a bug. The UI applies sampling, data thresholds, (other) aggregation, and behavioral/conversion modeling on top of the raw event stream; BigQuery exports the unmodeled, unsampled events. Knowing which transformations the UI adds explains most gaps.
- Multi-site analytics
Combine first-party data across properties.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.