How blends work
A blend combines up to five data sources into one virtual source. You pick join keys (fields present in both), the join type, and which dimensions and metrics to bring through from each side.
Modern Looker Studio supports the full set: left outer, right outer, inner, full outer and cross join. Earlier versions only offered left outer, which is why older documentation and interview answers say blending is always a left join.
The granularity trap
Blending aggregates each source to the level of the join keys before combining. If one side has multiple rows per key, its metrics are summed first — which is usually correct.
The trap is the reverse: a metric from the left source repeats across matched right rows and can be double-counted when you then aggregate again. Symptoms are totals that are too large by a consistent factor.
Check a blend by comparing a simple total from the blend against the same total from the unblended source. Do this before building anything on top.
Limits worth knowing
Blends are computed at query time and can be slow, particularly across different connectors. Some connectors do not support all join types. Calculated fields referencing multiple sources within a blend have restrictions.
And blending cannot fix a modelling problem. If two sources need a genuine relational join at row level, do it upstream — in BigQuery, or by consolidating into one table.
When to blend anyway
Blending earns its place when the sources genuinely cannot be joined upstream: Google Ads spend against Analytics sessions, for example, where both are managed APIs.
In those cases blend on a shared date and campaign key, keep the blend narrow — only the fields you actually need — and validate the totals before trusting them.