Find duplicate spend in a blended report

A one-to-many join can repeat an amount when several right-side rows match one left-side key. Compare the grain, row counts, distinct keys, and control totals before and after the join. Repetition is a signal to investigate, not a diagnosis by itself.

Reproduce the multiplication

Synthetic example RP-JOIN-01. The left table has one row per campaign: A spends $600 and B spends $400. The right table has two creative rows for A and one for B. Joining on campaign produces three rows.

The source spend is $600 + $400 = $1,000. The joined sum is $600 + $600 + $400 = $1,600. The difference is +$600 (+60%). Two distinct campaign keys survive, so a distinct-key count alone would miss the multiplication.

Choose a correction that preserves meaning

If the report needs campaign totals, aggregate the right table to one row per campaign before joining. Then test uniqueness of the entire join key, including date or account when required. In this fixture that produces two rows and $1,000. If creative-level spend is required, obtain spend at that grain or agree an explicit allocation rule. Do not divide by the number of rows just to force agreement.

Do not use SUM(DISTINCT spend) as a universal fix: two unrelated campaigns can legitimately spend the same amount. Likewise, a different chart aggregation may hide the repeated amount without repairing the underlying data model.

Check the actual blend

1. Write the grain of each input and the exact join keys.
2. Count duplicate full keys on the matching side; inspect unmatched keys too.
3. Compare totals at each join stage, then reapply filters and chart aggregation.
4. Re-test a single campaign and the complete agreed population after the correction.

Google documents that multiple join matches can increase blended row counts. Actual behavior also depends on aggregation, fields, filters, and blend order. This simplified fixture demonstrates relational multiplication; it is not a claim that every Looker Studio discrepancy has this cause.