Logical Example: The “Revenue” Problem

Say three teams each build a report showing “monthly revenue”:

• Finance defines it as invoiced amount minus refunds, recognized in the month the invoice is issued.
• Sales defines it as booked deal value in the month the deal closes, regardless of invoicing.
• Product analytics defines it as payment received in the month the transaction settles.

All three call it “revenue.” All three numbers are legitimate for their purpose, but none of them reconcile. Without a semantic layer, this surfaces months later in a leadership meeting when someone asks why finance’s revenue and sales’ revenue don’t match, and both sides are technically right.

A semantic layer forces the resolution up front: define separate, named metrics,  booked_revenue, invoiced_revenue, recognized_revenue, each with one calculation, documented once. Every dashboard or query pulls the one that matches its purpose by name, rather than reinventing the logic.

Another common case: “active customer.” Marketing might mean logged in within 30 days; finance might mean has a non-zero balance; support might mean has an open ticket. Same term, three different underlying queries. The semantic layer either picks one canonical definition or names them distinctly (active_customer_engagement vs active_customer_billing) so nobody accidentally compares incompatible numbers.

Pages: 1 2 3