A blended chart can show a convincing percentage while repeating the target behind it. The join may run without an error. The problem is that its rows no longer represent the same thing as the rows in either source.
This guide uses Data Studio, formerly Looker Studio. Its worked example is hypothetical: weekly targets meet daily sales split by device. The arithmetic follows the stated rows; it is not a reported test on a live dashboard.
Define the row you want before choosing the key
Write what one row represents in each input and in the intended chart. In this example, sales have one row per date, campaign and device. Targets have one row per week and campaign. The required result is one row per week and campaign, showing actual revenue against its target.
Use both week and campaign as the join key. Campaign alone can connect several weeks. Agree the week definition, campaign identifiers and currency across sources. Equal-looking labels do not establish equal meaning. A correct join cannot reconcile two different definitions of revenue.
Inspect the blend tables before the chart
Google’s guide to how blends work describes a grouping and aggregation step in each table before the join. The dimensions included in that table determine its rows. Hiding a dimension from the final chart does not remove it from the blend configuration.
For the weekly comparison, configure the sales table with Week and Campaign plus summed Revenue. Configure the target table with the same dimensions and its Target revenue metric. Check that each key has one row on each side. Adding Date or Device to the sales table creates a finer level that the weekly target does not share.
A unique row identifier is useful when individual records must survive pre-aggregation. It is not a universal repair. Adding one here would preserve detail that the target cannot match. Choose fields to express the required comparison, rather than adding identifiers until the row count looks familiar.
