Blended data in Looker Studio joins up to five data sources into one table so a single chart can combine, for example, Google Ads spend with GA4 conversions. Blends work by matching join keys such as date and campaign, and nearly every problem people hit with them comes from mismatched keys or the wrong join type.
Key Takeaways
- A blend is a join, not a merge: choose the join type deliberately or you will silently drop or duplicate rows.
- Join keys must match in both name-independent meaning and exact value formatting, which usually means normalizing campaign names at the source.
- Blends aggregate before joining, so a metric that looks inflated is almost always a fan-out from a one-to-many key.
- Calculated fields that mix metrics from two sources belong in the blend, not in the individual chart.
- Beyond three or four sources, moving the join into a warehouse is faster to build and far cheaper to maintain.
What Is Blended Data in Looker Studio?
A blend is a virtual table defined inside a report. You pick up to five sources, choose the join configuration between them, select which dimensions and metrics to carry through, and the result behaves like any other data source for charts built on it. Nothing is copied or stored: the blend is recomputed whenever the report queries it, which is why blend design has a direct effect on report load time.
The important mental shift is that a blend is a database join with a friendly interface. Each source is queried and aggregated first, at the grain of the dimensions you included, and then the results are joined on your keys. That order explains most surprising numbers. If you include a dimension in one source that has no counterpart in the other, you change the grain of the join and therefore the totals.
When Should You Use a Blend Instead of Another Approach?
Blends are the right tool for a specific job: presenting metrics from two or three sources side by side, at a shared grain, in one visualization. A cross-channel spend and conversion table by date and campaign is the canonical case.
| Need | Better approach | Why |
|---|---|---|
| Spend from two ad platforms in one time series | Blend with a full outer join on date | Shared grain, no key ambiguity |
| Ad platform cost against GA4 conversions | Blend on date plus a normalized campaign key | Requires consistent campaign naming to be trustworthy |
| Five or more sources with heavy transformation | Warehouse table or a connector product | Blends recompute per query and get slow and brittle |
| Historical snapshots or reprocessed attribution | Warehouse with scheduled loads | Blends cannot store state or backfill |
| Two views of the same source | Chart-level filters or a calculated field | A blend adds cost with no benefit |
The failure mode worth naming is the blend that grows. A two-source blend on date is robust. The same blend after someone adds three more sources, four calculated fields, and a filter on each side becomes the slowest and least debuggable object in the report, and it is usually the moment to move the join into BigQuery instead.
Which Join Type Should You Choose?
Looker Studio offers left outer, right outer, inner, full outer, and cross joins. The choice determines which rows survive, and picking the default without thinking is the single most common cause of missing data in a blended chart.
- Left outer join keeps every row from the left source and only matching rows from the right. Use it when one source is authoritative, for example every campaign that had spend, even those with zero conversions.
- Inner join keeps only rows present in both. Use it when a row is meaningless without both halves, and expect totals to be lower than either source alone.
- Full outer join keeps everything from both sides and fills gaps with nulls. This is the safest choice when you are combining channels and do not want to hide a channel that had activity in only one system.
- Right outer join is the mirror of left outer and is rarely needed, since reordering the sources is clearer to whoever reads the report next.
- Cross join pairs every row with every row and has almost no legitimate reporting use. If your totals are wildly inflated, check whether you have effectively created one.
Where the correct join is not obvious, build the blend twice and compare. A table showing row counts under an inner join and a full outer join takes two minutes to make and tells you exactly how much of your data lives on only one side.
Why Do My Blended Metrics Look Wrong?
Almost every blend bug reduces to one of four causes, and they are quick to check in order.
Fan-out from a one-to-many key. If one row on the left matches several on the right, the left metric repeats for each match and any total that sums it becomes inflated. Reduce the grain on the many side, or aggregate it before joining, so the relationship is one to one.
Key values that do not actually match. Dates that differ by time zone, campaign names with trailing spaces or inconsistent casing, and identifiers stored as text in one source and numbers in another all join to nothing. This is why disciplined UTM naming conventions matter more for reporting than any dashboard feature: consistent keys at collection time remove the whole class of problem.
Currency, time zone, and attribution window differences. Ad platforms and analytics tools rarely agree on any of the three. Spend recorded in account currency next to conversions counted in a different time zone will never reconcile, and no join type fixes it. Decide which system is authoritative for each metric and label the chart accordingly.
Metrics recomputed after the join. A ratio such as cost per conversion must be calculated from the joined totals, not averaged from a pre-existing per-row metric. Averaging an average is one of the most common ways a dashboard produces a number nobody can reproduce.
How Do You Build Calculated Fields Across Sources?
Calculated fields that combine metrics from two different sources must be created inside the blend, because that is the only scope where both fields exist as columns of the same table. Cost per acquisition, blended return on ad spend, and cross-source conversion rate all belong here.
Two practices keep them reliable. Wrap denominators to handle zero and null, since a channel with no conversions on a given day will otherwise render as infinity or blank and pull the eye to a non-issue. And name the field with its source explicitly, for example spend from Google Ads rather than cost, because once three sources contribute similarly named metrics the ambiguity becomes permanent.
Keep transformation as close to the source as you can. Normalising a campaign name is better done in the source or in a warehouse view than in a blend calculated field, since the blend version has to be repeated in every report that needs it. That principle is what eventually moves most maturing teams from blends to modelled tables in their Looker Studio reporting stack.
How Do You Keep Blended Reports Fast?
Blends recompute on every query, so their cost is paid by every viewer of the report. Four levers make the difference. Include only the dimensions and metrics you actually chart, because every extra field widens the join. Apply filters inside the blend rather than on the chart, so less data is joined in the first place. Keep the date range default modest and let users widen it deliberately. And enable data source caching where the connector supports it.
If a blended report still takes many seconds to load after those steps, the blend has outgrown the tool. Materialising the joined table on a schedule, in a warehouse or an extract, converts a slow live join into a fast read and is usually the right investment once the report has real recurring readers. That is the same threshold at which most teams formalise the rest of their marketing reporting layer.
Frequently Asked Questions
How Many Data Sources Can a Looker Studio Blend Contain?
A single blend supports up to five sources, joined pairwise in the order you arrange them. In practice performance and debuggability degrade well before that ceiling, and most reliable blends use two or three. If you find yourself needing four or five, that is a strong signal to move the join upstream into a warehouse table and connect Looker Studio to the result instead.
Why Is My Blended Data Showing Null or Blank Values?
Nulls in a blend mean the join found no match on that row, which is expected behavior for an outer join rather than an error. Check the join keys first: mismatched date time zones and inconsistent campaign naming are the usual culprits. If you would rather show zero than blank, wrap the metric in a calculated field that substitutes zero when the value is null.
Can You Blend Data from Different Date Ranges?
Not meaningfully within one blend, because the join happens on the values in the key fields and a date range is not a key you can offset there. To compare periods, either add a comparison date range at the chart level, which Looker Studio handles natively, or prepare period-over-period columns upstream in a warehouse view and blend the prepared table.
Does Blending Data Slow Down a Looker Studio Report?
Yes, because the blend is recomputed on each query rather than stored. The cost scales with the number of sources, the number of fields carried through, and the date range requested. Trimming unused fields, filtering inside the blend, and keeping the default date range short recover most of the performance; beyond that, materialize the join upstream.
Should I Blend Google Ads and GA4 Data?
You can, on date plus a normalized campaign key, and it is a common request. Be explicit about the caveats when you do: the two systems use different attribution models, conversion windows, and often different time zones, so the numbers will not tie exactly. Label which system each metric comes from and use the blend for directional comparison rather than as a reconciliation of record.