Semantic Layer for Revenue
One Governed Definition of What Revenue Means
The Convertmax semantic layer defines what your revenue metrics mean and how your records are allowed to connect, so humans and AI agents can query the Revenue Graph without inventing their own joins.
What the semantic layer governs
| Governs | Example |
|---|---|
| Meaning | Collected cash, refunds netted, test accounts excluded |
| Connection | Which sessions, people, accounts, and deals may touch revenue |
| Enforcement | Ask Max, dashboards, exports, and the API read the same rules |
Where the rules apply
- 1
Ask Max
Every query starts from certified entities and approved join paths.
- 2
Dashboards
Certified metrics carry their calculation and owner.
- 3
Exports and API
The connected model stays portable under governed access.
The problem
A column called amount is not revenue
A warehouse has a column called amount. That column is not revenue. Revenue is amount where the order completed, minus refunds, excluding internal test accounts, converted to USD at the booking-date rate. Somebody had to decide which date matters. Somebody had to decide whether revenue here means booked revenue or collected cash.
That gap between raw data and business meaning gets closed by someone, somewhere, every single time anyone asks a question. A semantic layer is what stops it from being closed a different way each time.
The harder half: which records may touch it?
Say the definition is settled. Revenue means collected cash, refunds netted, test accounts excluded. Finance agrees. Marketing agrees. The word is nailed down.
Then someone asks: which campaigns created that revenue? No definition answers that. Relationships do. Which sessions belong to which person. Which person belongs to which account. Which calls, opportunities, and orders attach to that person and sit before the close.
Get those wrong and you produce a precise, confident, completely false number. Definitions don't prevent that. Rules about connection do.
What the semantic layer defines
Six things, declared once, enforced downstream
Most semantic layers stop at metrics. Revenue meaning needs one more thing: which records are allowed to touch a revenue outcome.
Entities
The nouns of a revenue business. Person, account, session, campaign, channel, touchpoint, call, opportunity, order, invoice, revenue event. Typed, so the system knows what something is before anyone asks about it.
Metrics and dimensions
Certified definitions for the numbers leadership argues about. Attributed revenue, pipeline created, pipeline influenced, closed-won, collected revenue, refunds, ROAS, CAC, LTV, payback, win rate, sales cycle. Each one carries its calculation, its revenue semantics, and whether it's certified or ad hoc.
Grain
The level at which a fact is true. Revenue at the revenue-event grain doesn't sum cleanly against touchpoints at the session grain, and pretending otherwise is how teams double count. Convertmax declares grain explicitly and surfaces it in answers instead of burying it.
Join paths
Approved relationships between entities, with direction and cardinality. A person-to-opportunity path and a session-to-account path behave nothing alike. Only one of them is safe for revenue credit.
Permissions and scope
Who can see which entities, metrics, and rows. Governed access means a definition you can't reach is never silently swapped for a nearby one.
Certification state
Which definitions are trusted, which are local experiments, which are deprecated. Users can tell the difference. So can agents.
Three layers, one answer
The Revenue Graph holds structure. The semantic layer holds meaning.
Max is the harness that works the two together.
| Layer | What it holds | What breaks without it |
|---|---|---|
| Revenue Graph | Entities and edges: people, sessions, campaigns, calls, opportunities, orders, revenue events | Journeys collapse back into disconnected tables |
| Semantic layer | Definitions, grain, approved join paths, permissions, certification | Every consumer invents its own version of the truth |
| Max (AI harness) | Investigation, signal detection, and answers grounded in both | Fluency without grounding. The wrong KPI, stated confidently |
Five properties, tested against revenue data
Judge a semantic layer by why people route around it
Teams route around a layer when it's too slow to change, doesn't fit their tools, forces duplicate copies, can't answer the question, or isn't trusted.
Flexible
An analyst should be able to build a calculation, test it against real data, and refine it without filing a ticket. If it proves useful, it gets promoted into the shared model through review instead of living forever in a spreadsheet. Revenue logic moves with pricing, markets, return policy, and channel restructures — a layer that needs a two-week release to absorb any of that gets bypassed inside a month.
Interoperable
Real paths out: MCP for approved agents, APIs for internal tools, warehouse exports for teams who want the model sitting next to the rest of their data estate. Governed access, customer control, genuine portability. A semantic layer that only works inside one interface isn't a layer — it's a destination with better vocabulary.
Extensible
Teams, regions, divisions, clients each need their own view of the same truth without forking the model into copies that drift apart by Q3. Shared definitions of revenue and conversion hold across clients; client-specific defaults, filters, formatting, and stage mappings extend from that base instead of duplicating it.
Comprehensive
A metric dictionary doesn't give an agent enough context to answer a revenue question correctly. It needs valid aggregations, permitted combinations of measures, realistic cycle lengths, and a worked example showing how attributed revenue by channel should be assembled. One sample query teaches an agent more than three paragraphs of prose.
Governable
Enforcement, not guidance. Someone has to own each definition — finance owns revenue semantics, marketing owns campaign taxonomy, RevOps owns identity keys. What matters is what happens the day the model is wrong: who can fix it, how long they wait, who reviews the change, and whether the fix reaches everyone before the next question arrives.
Join governance, not just metric governance
Where a revenue semantic layer earns its keep
An agent with beautiful definitions and no join discipline will cheerfully report that a single campaign generated billions in pipeline, because it fanned one account's contacts out against one deal. It had the right definitions. It had no rule about connection.
| Failure | What it looks like | What prevents it |
|---|---|---|
| Fanout | One account's contacts multiplied against one deal. Pipeline reported in the billions | Declared cardinality on account-to-opportunity paths |
| Double counting | Session-level and event-level revenue summed together | Explicit grain with valid aggregation rules |
| Metric drift | Marketing, sales, and finance each reporting a different revenue number | One certified definition with a named owner |
| Blind joins | B2B journey credited on a same-day session window that never existed | Approved join paths with realistic cycle semantics |
| Ambiguous terms | Revenue means booked in one report and collected in another | Revenue semantics declared on the metric, not the report |
| Unexplained answers | A number arrives with no indication of which definition produced it | Certification surfaced in every response |
How AI stays grounded
Max runs on the same semantic model as the rest of the platform
That's the only durable way to keep an AI system honest about revenue. Grounding isn't accuracy — a grounded system built on a wrong definition is still wrong. But it tells you which definition it used, which turns a wrong definition into a fixable problem instead of an unexplainable one.
Every query starts in the semantic layer
Max builds questions from certified entities, metrics, and approved join paths. It can compose and extend within the model. It doesn't write its own joins against raw tables and hand you the result as an answer.
Ambiguity gets resolved, not guessed
When revenue could mean pipeline or collected cash, the model decides from context, the same way a scope decides which definition applies. An agent that pauses mid-analysis is more useful than one that silently picks a definition and keeps going.
Answers show their work
Max can indicate which definitions and metrics produced a result, so a number traces back to the model instead of being taken on faith. When two reports disagree, that trail is the explanation.
Warehouse semantic layers
Complementary, not competing
If your data team runs Cube, dbt Semantic Layer, LookML, AtScale, or Power BI semantic models, this is complementary. Those tools define meaning for the warehouse estate and they're good at it. Convertmax defines meaning for the customer journey and the revenue it produced — the relationships that mostly live outside the warehouse or arrive there flattened.
| Warehouse semantic layer | Convertmax semantic layer | |
|---|---|---|
| Primary subject | Warehouse tables and metrics | People, touchpoints, and revenue outcomes |
| Strongest at | Certified metrics, SQL compilation, BI delivery | Journey relationships, attribution grain, join safety |
| Typical consumer | BI tools, analysts, data teams | Growth, revenue, finance, agency, and AI consumers |
| Join safety | Declared by the modeling team | Declared and enforced across journey and revenue entities |
| Relationship | The system of record for warehouse truth | The governed meaning layer over the Revenue Graph |
The two should meet. Convertmax exports the connected revenue model so it can be combined with the rest of your data estate, and a data team keeps its warehouse definitions authoritative for the tables it owns.
Ownership
Semantic layers fail socially before they fail technically
No owner, and the definition drifts. The practical test isn't whether the model is complete — it's what happens when the business changes and a definition goes wrong.
| Definition | Natural owner | What they decide |
|---|---|---|
| Revenue semantics | Finance | Pipeline vs booked vs collected, refund treatment, currency |
| Campaign and channel | Marketing | Parameter hygiene, channel taxonomy, attribution windows |
| Identity keys | RevOps | Which keys join records and when a match is trusted |
| Journey grain | Analytics | Which facts may be aggregated together |
| Model policy per decision | Leadership | Which model answers which question |
In practice
Questions the semantic layer should answer well
- What did we collect last quarter, under one revenue definition finance agrees with?
- Which campaigns created pipeline that closed, allowing for a 180-day B2B cycle?
- Which channels produce customers with the highest repeat rate, not just the lowest first-purchase CAC?
- How do attribution models compare on the same facts, so we can change weights without changing the story?
- Why does platform-reported ROAS disagree with attributed revenue, and which definition is each number using?
- Which revenue metrics are certified, and which are local calculations someone built last week?
Scope
What this is not
Governed definitions don't guarantee correct answers. They make wrong answers findable — so a bad number traces back to the definition that produced it.
- Not a replacement for your warehouse, your BI tool, or your data team's semantic model.
- Not a claim that governed definitions guarantee correct answers. They make wrong answers findable.
- Not a data catalog. A catalog describes what exists. This defines what things mean and how they may be read.
- Not legal or compliance advice for consent and data processing.
- Not a closed destination. Your revenue context stays portable through MCP, APIs, and warehouse exports, under your control.
FAQ
Semantic layer questions
What the Convertmax semantic layer is, how it relates to warehouse models, and how Max stays grounded in it.
Is Convertmax a semantic layer or an attribution platform?
Both, and the order matters. The semantic layer is what makes the attribution trustworthy, because it defines what a campaign, a channel, a conversion, and a unit of revenue mean before any model assigns credit.
Do we need a warehouse semantic layer to use this?
No. Convertmax collects first-party journeys and connects revenue sources directly, then governs meaning on top of that connected model. If you already run a warehouse semantic layer, the two meet through exports.
How is this different from defining metrics in dbt or LookML?
Those define meaning for warehouse tables and they're excellent at it. Convertmax also governs the relationships between journey records and revenue outcomes. Which records may connect, at what cardinality, with what grain. That's the part that decides whether an attribution number is real.
Can Max write its own queries?
Max builds answers from certified entities, metrics, and approved join paths rather than composing joins against raw tables. The constraint is deliberate. It's the difference between an AI system that's useful for revenue decisions and one that's merely fluent about them.
Is our revenue context locked into Convertmax?
No. MCP, APIs, and warehouse exports exist so the connected revenue model can be used in the environment your team already works in. Governed access and clear permissions still apply. Portability is the design intent.
Get started
Better Definitions or Better Decisions?
A revenue question deserves one answer. Convertmax gives you the governed meaning layer over the Revenue Graph, so the humans and the agents asking that question are reading the same rules.