The Dashboard That Invented RevenueWarehouse · hard · ~13 minMarketing's new dashboard reports $4.2M in attributed campaign revenue for October. Finance's books say total October revenue was $3.1M — across ALL channels. The dashboard is reporting more attributed revenue than the company earned.The dashboard's author is a competent analyst. The model behind it joins fct_orders (one row per order) to fct_campaign_touches (one row per marketing touch — email opens, ad clicks) on customer_id, filters to October, and sums order_amount.Every individual number in both source tables is correct. The join is syntactically fine. The dbt tests (not-null, accepted-values) all pass. You're explaining to the CMO why the dashboard is wrong — and to the data team why this class of bug needs a structural fix, not a code review.Evidence

The numbers

The model (simplified)

Context

Checkpoints

Every source number is correct and every test passes, yet the sum is inflated. Name the mechanism.

With average 2.7 touches per ordering customer, roughly what inflation factor should you expect from this join shape — and does it explain the gap? (Answer the factor as a number.)

Which rewrite produces a correct attributed-revenue metric?

Third incident this year, different authors each time. Argue why the checklist proposal won't end the class of bug, and design the structural fix — including what a semantic layer's typed entities would have done with this exact query request.