Looker Studio Interview Questions: Data Blends, Aggregation, and Misleading Totals

Looker Studio interview questions about data blends test whether you can explain a plausible dashboard total that is wrong. A join may repeat a cost, pre-aggregation may remove detail, or a chart may average rates that should have been calculated from summed counts.

Quick answer: name the grain of each source, the fields included in each blend table, the join keys and type, and the chart's final aggregation. Reconcile those stages separately. A correctly configured connector and a successfully rendered chart do not establish metric correctness.

Naming and evidence boundary: the current Google documentation redirects the Looker Studio blend pages to Data Studio documentation. This article retains the requested Looker Studio title and concerns report-level blends, not Looker LookML Explores. Product mechanics are official; all campaign values and diagnostic exercises below are original examples, not candidate reports.

Practice Clean and Aggregate Transactions for Finance Dashboard to build the reconciliation habit. Explain the authoritative amount and row grain before deciding whether a dashboard's displayed total is valid.

Looker Studio interview questions need three grain statements

Write down three stages: the underlying source rows, the rows produced by each blend table, and the rows or groups shown by the chart. A transaction source, a campaign-day blend table, and a campaign scorecard are different grains even when they use similarly named fields.

Official behavior: Google's blend documentation says each table is grouped and aggregated by its included dimensions before the tables are joined. Omitting a unique row identifier can collapse identical dimension combinations. A blend therefore need not reproduce a raw SQL join over the underlying records.

For an original example, three orders for campaign A have revenues 40,40,120. A blend table containing only Campaign as a dimension and SUM(Revenue) produces one A row with revenue 200. Including OrderID retains three rows instead. Both can be legitimate; they permit different joins and final aggregations.

Do not add every available identifier merely to prevent collapsing. Retaining order-level detail when the other table is campaign-level can create the very fanout you were trying to avoid. Select the dimensions needed for the metric's intended grain and prove the join's cardinality at that grain.

Also separate Looker Studio from Looker. A LookML primary-key declaration or symmetric-aggregate discussion is not a substitute for explaining a report blend. Name the product and actual calculation boundary rather than treating all tools bearing “Looker” as one query engine.

Reproduce a spend total that doubles after blending

The original source tables have one campaign-level spend row and two campaign-device revenue rows:

Source	Campaign	Device	Amount
Spend	A	Not present	100
Revenue	A	Mobile	80
Revenue	A	Desktop	120

If the spend table groups by Campaign and the revenue table groups by Campaign and Device, joining on Campaign produces two rows. Each joined row carries spend 100, with revenues 80 and 120 respectively.

Summing the repeated spend yields 200. The authoritative campaign spend remains 100. Summing revenue yields 200, which is correct for the two-device revenue in this fixture. One metric can reconcile while the other is wrong, so testing only a revenue total is insufficient.

The defect is not necessarily a duplicate source record. The join created multiple appearances of the same campaign-level amount. Removing duplicate whole rows will not help when the device and revenue fields differ.

The dashboard must choose a valid meaning for device-level spend. If source data supplies no allocation, displaying 100 on every device may represent a campaign benchmark, but it should not imply each device actually incurred that cost. Allocate spend only with an explicit business rule or an authoritative device-level cost source.

For a campaign-only scorecard, one possible repair is to aggregate both sides to Campaign before joining. For a device comparison, obtain compatible device-grain spend or clearly label a repeated campaign denominator. The repair follows the intended metric, not whichever aggregation makes the screenshot look right.

Why MAX can help one row and fail the overall total

On campaign A's joined device rows, MAX(Spend) returns 100. That can recover the campaign-level value for this particular grouping. But MAX is not a general deduplication solution.

Add campaign B with spend 70. Taking a global MAX gives 100, while total spend should be 170. The correct overall total needs one authorized spend value per campaign, then a sum across campaigns. A formula that works within one campaign does not automatically preserve the cross-campaign contract.

SUM(DISTINCT Spend) is also unsafe as a conceptual repair. Two different campaigns might each spend 100. Deduplicating equal numeric amounts would collapse two legitimate costs into one. Identity should come from campaign and date or another declared key, not from the measure's numerical value.

This original counterexample is useful in an interview because it tests the proposed repair. Ask for a second campaign with the same amount, a campaign with a different amount, and a missing campaign. A reconciliation method should handle all three without special pleading.

Sometimes the cleanest answer is to move the combination into a warehouse view at a documented grain. That creates a reusable place to test cardinality and allocation. A report-level blend can remain appropriate for a small comparison, but complexity and shared metric ownership should guide the choice.

Locate filters and date ranges before interpreting row loss

Google's blending tips explain that blend-table date ranges, filters, and calculated fields affect each table before joining. Report and chart filters need to be inspected separately. “I filtered campaign B” is not enough to determine the resulting relation.

Consider an original full-join exercise. Spend has campaign A=100 and B=70. Revenue has A=200 and C=50. Without a filter, the joined campaign set is A,B,C, with missing values on one side for B and C.

Filter the revenue table to A before the full join. The resulting campaign set is A,B: C no longer enters from the right side. By contrast, joining all three campaigns first and then filtering the final combined campaign key to A leaves only A. These are different operations.

For a left join, a final condition on a right-side field can also remove unmatched left rows. Inspect whether a null extended right value is excluded by the filter. Do not infer from the label “left join” that every later chart will retain every left-side campaign.

Date keys introduce similar traps. A daily spend table and monthly revenue table cannot be safely joined on Campaign alone merely because both have date fields. State the timezone, reporting period, and date granularity. A left-side date range may select different periods than a right-side range.

Record which date field each connector uses and whether late updates can change previously reported periods. A date control that seems to apply uniformly may still leave asymmetric source queries. Compare the actual table-level conditions before blaming a chart's arithmetic.

Calculate ratios from the intended numerator and denominator

A conversion-rate example exposes another misleading total. Suppose one row has 9 conversions from 10 visitors, and another has 10 from 100. Their rates are ninety percent and ten percent. Averaging the rates gives fifty percent. Combining the counts gives 19/110, about 17.27 percent.

Neither aggregation is intrinsically forbidden; they estimate different quantities. An equally weighted average of two segment rates is not the same as the overall visitor conversion rate. Most dashboard disputes become easier once the metric owner states which quantity is desired.

For the campaign fixture, revenue divided by repeated spend can produce a blended ratio of 200/200=1 instead of the campaign's 200/100=2. Fixing the division expression alone cannot repair a duplicated denominator. Reconcile numerator and denominator separately at their legitimate grains.

Use Google's calculated-field guidance to verify where a calculation is defined and which aggregation rules apply. Connector-provided aggregated metrics have different constraints from raw numeric fields. Do not promise arbitrary reaggregation of every connector field.

Handle zero and missing denominators deliberately. Missing spend can mean no matching record, not zero cost. Displaying a zero or an infinite return can turn an incomplete join into a confident business claim. Preserve an explicit missing-data indicator when reconciliation is incomplete.

Explain table order and what adding a dimension changes

The official blending tips describe joins evaluated from left to right. With three or more tables, inspect the intermediate result before the next join. A key absent after an earlier inner join cannot be restored by a later join unless the later operation explicitly introduces it.

Adding Device, Date, or Country to a blend table changes its grouping before the join. Adding a display dimension only to a chart can also change final grouping, but it is not the same operation as changing a source table's dimensions. State which editor stage you are modifying.

For an original test, begin with one campaign-level row on each side. Add Device to the revenue table and observe that A now matches two rows. Remove Device again and reconcile the campaign total. This controlled change identifies the stage that introduced repetition.

Hide-repeated-join-field presentation options do not establish unique rows or remove duplicated measure values. A cleaner field list can still contain a many-to-many result. Inspect the included dimensions and counts rather than assuming the visible labels describe cardinality.

A join on a campaign name may also be weaker than one on a stable campaign identifier. Names can collide, change, or be reused. If multiple accounts share a name, the composite key may need AccountID and CampaignID, plus the appropriate date grain.

What evidence makes a blend diagnosis reviewable?

Save a small source fixture, the dimensions and metrics in every blend table, join order and type, key uniqueness checks, table filters, and the final chart configuration. Then write expected rows and totals by hand before reproducing the report.

Test repeated costs, equal-valued legitimate costs, unmatched keys, null keys, unequal date grains, and zero denominators. Compare source control totals with blend-table totals and final chart totals. A difference at each stage points to a different repair.

A local SQL or Python fixture can prove the fanout arithmetic and filter-order counterexample. It cannot prove connector semantics, caching, native report rendering, or viewer credential behavior. Test the final blend in the real report and record the connector and configuration used.

For Looker Studio interview questions, close with the exact grain error and the smallest change that restores the metric contract. The following prompts are adjacent dashboard, SQL, and Tableau practice; they do not establish Looker Studio feature behavior or an employer's interview format.

Practice blend and metric reconciliation

Question	Practice focus
Describe building and improving a dashboard	Explain dashboard validation and metric contracts
Compare Tableau blending, joins, and filters	Compare blend and filter placement without equating products
Choose Between JOIN, BLEND, and RELATIONSHIP in Tableau	State grain and choose the right combination model
Clean and Aggregate Transactions for Finance Dashboard	Reconcile input transactions with reported totals
Debug row loss after SQL joins	Trace unmatched keys and join choices

Start with Describe building and improving a dashboard. Explain your assumptions and expected result before implementing the solution.

Sources and further reading

• Google: How blends work
• Google: Blending tips and advanced concepts
• Google: About calculated fields