Data Modeling
Data modeling is the layer where a business decides what its numbers mean: what counts as a customer, when revenue is recognized, which touches belong to which campaign. Every report embeds these decisions whether anyone made them deliberately or not. When the definitions live inside each report, each report maker decides independently, and the company gets several versions of every number, each defensible and none matching. The model is where those decisions get made once and inherited everywhere.
How it actually works
Ask three teams for last quarter's new customers and you can get three numbers, all correct. One counted signups, one counted first payments, one excluded a subsidiary because its billing runs separately. Each report faithfully implements its own definition. Nothing in any of the three flags that the definitions differ, so the discrepancy surfaces in the meeting where the numbers were supposed to settle a question, and the meeting becomes about the numbers instead.
The fix is structural. Definitions move out of individual reports and into a modeling layer that sits between the warehouse and everything downstream. New customer is defined once, in code, with its edge cases decided: trials, refunds, subsidiaries, reactivations. Every dashboard, export, and model reads the same definition, and a change to it propagates everywhere at once instead of being re-implemented report by report, drifting a little each time.
The most consequential definition is revenue, because the recurring dispute between marketing's revenue number and finance's revenue number is a revenue recognition dispute. Marketing dashboards typically report bookings or gross order value at the moment of the transaction; finance reports recognized net revenue, after returns, discounts, and, for subscriptions and long contracts, spread over the delivery period as accounting standards require. All three numbers are correct and they can differ by large amounts in any given month, so a model that does not carry them as three separately named metrics, with the reconciliation between them defined, guarantees the two departments will keep arguing over which single number is right when the real answer is that they were never the same measurement.
Maintaining that layer is an ownership question: someone has to decide which definition wins. Each definition has an owner, changes are versioned, and when finance and marketing genuinely need different revenue figures, both exist as separately named metrics instead of one name meaning two things. The closest analogy is one the CFO already operates: the semantic layer is a chart of accounts for operating metrics. Every control that makes the general ledger trustworthy, one definition per account, a named owner, versioned changes, and reconciliation to a single source, is the same control this layer applies to customer counts and revenue metrics. The tooling industry sells this as a product category. The product stores the definitions; deciding them, and getting every department to resolve to them, is the work that remains.
In practice
Identifying $12M+ in wasted spend for USCCA required definitions that would hold up under challenge. A line item is only provably waste when everyone agrees on what return means and how it is computed. When each report can supply its own version of the number, every proposed cut gets contested with a competing figure, and the spend survives. The model also depends on what the source system can actually supply. At an organization with an operating budget north of $100 million, the marketing team connected GA4 to BigQuery, and one of the most important data points, the session ID, was not available through the API; Google gates it behind its own cloud environment. Six months building the platform, three months designing the dashboards, and three more months passed before quality assurance asked why data could no longer be tracked by session. A year of work traced to an assumption about an API that went unvalidated in week one ([unmapped dependencies](/insights/why-strategic-initiatives-fail#unmapped-dependencies)).
Where we come in
Data modeling is part of our Revenue Systems Architecture practice: one pipeline from your data sources to the decisions your team makes, with the definitions decided once and read everywhere. We have built this for businesses from new startups to the Fortune 15, and it is the layer that let the USCCA work put a defensible number, $12M+ in identified waste, on spend that had survived prior reviews. We demonstrate ROI before each build, and everything is scoped up front.
Start a Revenue Health Pre-Assessment →See it in action
Related terms
- Semantic layer
- The layer that holds metric definitions between the warehouse and the reports. Every downstream tool reads definitions from it instead of embedding its own.
- Metric definition
- The precise rule for computing a number, including its edge cases. Undefined edge cases are where matching reports diverge.
- Data dictionary
- The documented meaning of each field and metric. It records the decisions the model implements, so the definition outlives the person who made it.
- Grain
- The unit one row represents: one order, one customer, one day. Joining tables of different grains without noticing is a standard source of inflated numbers.
- Revenue recognition
- The accounting rules governing when revenue counts as earned. Bookings, gross order value, and recognized net revenue are three different numbers from the same transactions, and a model that does not name all three leaves marketing and finance reporting different revenue while believing they measure the same thing.
- Data governance
- The ownership and change process around definitions. Without it, the modeling layer drifts back into the reports it replaced.