Looker Studio Blended Data: Join Keys, Data Grain, and Duplicate Rows

A blend combines fields from separate sources so a chart can use them together. Before choosing a join field, define what one row should represent in the result: one day, campaign, landing page, account, or another entity. This is the data grain. Every source needs to be compatible with that level or aggregated to it first.

Start with the question and the grain

Suppose spend is recorded once per campaign per day while CRM opportunities are recorded once per opportunity. Joining directly on campaign can repeat the daily spend for every matching opportunity. The chart may look plausible while totals are overstated.

• Write the intended row grain in one sentence.
• Check how many rows each source has per proposed join key.
• Aggregate the more detailed source before blending when the question needs a higher-level result.

Choose stable join keys

A good key is present in both sources, uses the same meaning, and has consistent formatting. Campaign IDs are usually safer than campaign names because names may be edited, reused, or written differently across systems. If you must join on text, normalize case, whitespace, punctuation, and known aliases upstream.

Null values do not create a meaningful match. If two sources both contain blank keys, a blend should not be treated as if those blank rows identify the same entity. Inspect unmatched rows instead of filling blanks with a generic value that could connect unrelated records.

• Prefer immutable IDs over display labels.
• Use the same date zone, granularity, and identifier format on both sides.
• Measure unmatched and duplicate keys before trusting a chart.

Know what the join type changes

The selected join type determines which rows survive when a key exists on one side only. An inner join keeps matched keys; left or right joins preserve one chosen source; a full outer join can retain keys from both sides where supported. The exact controls available depend on the blend setup.

A missing row is not necessarily zero. If no revenue record matches a paid campaign, the blended chart may show a null, omit the row, or display a zero depending on the chart and field configuration. Choose the treatment intentionally and make it visible in reporting.

• Confirm which source is the primary side of the blend.
• Compare blended totals with the original source totals at the same grain.
• Label null handling so readers can distinguish “no match” from a true zero.

A short validation routine

Build a small table with the join key, row counts, and key measures from each source before styling a dashboard. Test a few known records end to end, then compare totals before and after blending. If a measure changes unexpectedly, inspect the grain and key cardinality first; changing aggregation settings may hide the symptom without fixing the relationship.

When the logic becomes difficult to explain, prepare a curated table upstream in a warehouse or spreadsheet. A clear model is easier to reuse, test, and maintain than a large blend whose join behavior only one dashboard owner understands.