RevOps Data Model: Unifying Sales, Marketing, and CS Data

What a RevOps data model actually is

A RevOps data model is the conformed schema that unifies sales, marketing, and customer success data around a single primary entity, then exposes governed metrics marts to every revenue dashboard. It lives in the warehouse, not the CRM. The model defines six canonical tables (account, contact, opportunity, activity, product_usage, revenue), the joins between them, and the lifecycle states each record passes through. Every report any go-to-market leader reads should read from this model.

Direct answer. A RevOps data model unifies sales, marketing, and customer success data around the account as the primary entity, using six conformed tables and five canonical joins. The 7-Layer RevOps Data Model — source, ingestion, identity, canonical entities, lifecycle states, metrics marts, activation — is the architecture every B2B revenue team needs to ship attribution, forecasting, and renewal motions off the same number.

The model matters now because the average B2B revenue team runs eight to twelve source systems and three reporting tools, each with its own definition of "qualified pipeline" (Salesforce, 2025). When the VP of Marketing reports a different funnel number than the CRO, the board loses confidence and the team loses a quarter to reconciliation work. A unified model is the only way out. The Gong Revenue Operations Benchmark reports that teams with conformed warehouse data run forecast reviews twice as fast as teams running off raw CRM exports.

This guide ships the 7-layer architecture, the six-week rollout plan, the joins, the governance rubric, and the six mistakes that quietly break attribution. It is the playbook a head of revenue operations hands to a data engineer on day one. For the role split between Sales Ops and RevOps, see Sales Ops vs RevOps.

Why disconnected GTM data costs you 12% of pipeline

Disconnected go-to-market data costs B2B teams roughly 12 percent of pipeline through misrouted leads, double-counted attribution, stale ICP fits, and churn risk that surfaces too late (Gartner, 2025). The Validity 2025 CRM research finds that 40 percent of CRM records carry at least one stale field, and the Forrester Total Economic Impact study (2024) on a unified RevOps platform pegs the 18-month ROI at 3.4x. The cost compounds because every disconnected report breeds a workaround, every workaround breeds a custom field, and every custom field breeds a new source of truth.

Three failure patterns repeat across teams without a model, and the Bridge Group SaaS AE Metrics study (2025) documents each one as a top-five barrier to quota attainment. First, the funnel splits: Marketing reports 1,200 MQLs, Sales sees 740 in their queue, and 200 are duplicates of accounts already in a closed-won relationship. Second, attribution breaks: the source field is overwritten on every form fill, so the third-touch webinar gets credit the first-touch paid search earned. Third, the renewal motion fails: CS health scores live in Gainsight, opportunity history lives in Salesforce, and neither team sees the joint signal that a champion left two weeks ago.

For the CRM-side cousin of this problem, see CRM data quality and the CRM hygiene glossary entry. A clean CRM is a precondition for a clean model, not a substitute.

The 7-Layer RevOps Data Model: a unifying architecture

The 7-Layer RevOps Data Model is the architecture pattern that unifies every revenue source into a single warehouse-resident schema, then activates the result back into the operational systems reps use. Each layer has one job. Skipping a layer means another layer absorbs work it was not designed for, and the model leaks.

1. 1

   Layer 1: Source systems

   Salesforce or HubSpot for sales, Marketo or HubSpot Marketing for demand, Gainsight or Vitally for CS, Segment or Rudderstack for product telemetry. This is the raw layer; do not query it for reporting.

2. 2

   Layer 2: Ingestion and ELT

   Fivetran, Hightouch, or Airbyte land raw tables in the warehouse on a 15-minute cadence. Snowflake, BigQuery, or Databricks holds the data. Schema names mirror the source.

3. 3

   Layer 3: Cleansing and identity resolution

   Clearbit, ZoomInfo, or Crunchbase resolve company identity. Domain plus normalized name becomes the deterministic account key. Personal-email contacts get matched to the work account by employment data.

4. 4

   Layer 4: Canonical entities

   Six conformed tables: account, contact, opportunity, activity, product_usage, and revenue. Every downstream report joins these. No mart query touches a raw source table.

5. 5

   Layer 5: Funnel and lifecycle states

   Account lifecycle stage, contact stage, and opportunity stage live as slowly changing dimensions. Every change writes a row in account_stage_history so velocity reports work without a guess.

6. 6

   Layer 6: Metrics marts

   Pipeline_metrics, funnel_metrics, retention_metrics, attribution_marts. Each mart is a single dbt model with a defined grain. Looker, Tableau, Hex, and the CRM dashboard all read from here.

7. 7

   Layer 7: Activation

   Reverse ETL via Hightouch or Census pushes scores, lifecycle stage, and health signals back into Salesforce, HubSpot, Marketo, and Outreach. The reps and the marketers see the same number the dashboard shows.

The Activation layer (Layer 7) is the one most teams skip and the one that drives adoption. A health score that lives only in a Looker dashboard does not change rep behavior. The same score, pushed into Salesforce on the account record and surfaced in the rep's sales workflow, changes the next call. The reverse-ETL step is what closes the loop between the warehouse and the field.

Pick your primary entity: account, contact, or opportunity

The account is the primary entity for B2B revenue teams. It is the only object that survives a deal cycle, a renewal, an expansion, a champion change, and a rep handoff. Contact and opportunity are children of the account through employment and through deal context. Lead is a temporary state of contact, not a peer entity. Pick this choice and every downstream join becomes deterministic.

The trade-offs across the three candidate primaries:

Verdict. Pick the account for any B2B team selling to companies with a multi-stakeholder buying motion. The account survives the deal; the deal does not survive the account. The only reason to deviate is a product-led-growth motion where individual users buy before companies do, in which case promote the contact to primary until the conversion event.

The five canonical joins every RevOps model needs

Five canonical joins unify the model. Each join has a known grain, a known cardinality, and a known failure mode. Get these five right and every downstream report is a straightforward dbt model. Get them wrong and every report has a footnote.

1. 1

   account ↔ contact (one-to-many)

   Joined on account_id, where account_id is resolved by domain plus normalized name during ingestion. Failure mode: personal-email contacts orphan to a null account; route to a review queue, not a hidden bucket.

2. 2

   account ↔ opportunity (one-to-many)

   Joined on account_id. Every opportunity belongs to exactly one account. Failure mode: opportunity_id changes on stage migrations; lock the surrogate key in Layer 4 to survive Salesforce schema changes.

3. 3

   contact ↔ activity (one-to-many)

   Joined on contact_id, with a fallback join on account_id for activities logged at the account level. Failure mode: dialer and email tools log to different identity fields; resolve in Layer 3 with a unified person key.

4. 4

   account ↔ product_usage (one-to-many)

   Joined through a tenant_id-to-account_id mapping table maintained by Customer Success. Failure mode: free trials and pilots create tenant rows before the account exists; backfill on conversion.

5. 5

   opportunity ↔ revenue (one-to-one)

   Joined on opportunity_id at closed-won, with a separate billing_account_id for downstream invoicing. Failure mode: bookings versus revenue mismatch; pick one definition per metric and stick with it.

Governance: who owns each field across Sales, Marketing, and CS

Governance fails when every team thinks it owns every field. The fix is a four-column rubric (Read, Write, Trigger, Audit) assigned per field, per team. Sales writes opportunity stage. Marketing writes MQL date. CS writes health score. RevOps writes lifecycle stage because the lifecycle spans all three motions.

The rubric drives a one-page data contract. Publish it. Every field on the data contract has a single Write owner. Every change to a Write-owned field gets logged. Every Trigger entry has a documented downstream workflow so a Marketing automation cannot silently overwrite a Sales-owned field. The contract is the artifact a new ops hire reads on day one to know who to ask about which number.

How to roll out a RevOps data model in six weeks

A six-week rollout ships a 6-table canonical model on a single warehouse with one to three sources. The plan front-loads scope decisions and back-loads activation, so the team can stop after week four if the budget runs short and still have a usable foundation. Add two weeks per additional source.

1. Week 1

   Audit and freeze scope

   Inventory every report any GTM leader looks at. Pick the 12 that matter. Freeze the rest. This is the only contract you ship to.

2. Week 2

   Source map and identity

   Map every source table to one of the six canonical entities. Resolve account identity on domain plus normalized name. Reject ambiguous matches into a queue, do not silently merge.

3. Week 3

   Build canonical entities

   Ship dbt models for account, contact, opportunity, activity, product_usage, revenue. Define grain in YAML. Test for uniqueness and not-null on every primary key.

4. Week 4

   Funnel stage history

   Backfill account_stage_history and opportunity_stage_history from CRM history tables. Validate that every closed-won account has at least one MQL row upstream.

5. Week 5

   Metrics marts and the 12 reports

   Rebuild the 12 frozen reports off the marts. Compare every number against the legacy report. Resolve every variance over 2 percent before signoff.

6. Week 6

   Activation and rollback plan

   Reverse-ETL lifecycle stage, health score, and account tier back into the CRM. Document the rollback path on a one-page runbook. Then hand reads to GTM.

The week-one freeze is the single most important step. Most data model projects fail not because the engineering is hard but because scope grows every Monday morning. Twelve reports is the cap. Anyone who wants a thirteenth report waits until phase two. The team that ships phase one in six weeks earns the political capital to take on the next twelve.

For the forecasting layer that consumes this model, see AI sales forecasting. For the field-level CRM cleanup that precedes the model build, see CRM data quality and the sales pipeline glossary entry.

RevOps data model mistakes that quietly break attribution

Six mistakes break the model after rollout. Each one looks like a small operational choice in the moment and a structural problem at the next quarterly business review. The remediation is rarely a rebuild; it is a contract change plus a backfill.

The most expensive of the six is stage-as-single-field. The first time the VP of Sales asks how long deals spend in Demo Scheduled and the report cannot answer because the stage history was never captured, the model loses credibility. Treat every stage column on every entity as a slowly changing dimension from day one. Backfilling history three months later is a four-week project; capturing it from day one is a YAML configuration.

1. 1

   Reporting off raw source tables

   A schema rename in Salesforce silently breaks the funnel report. Always read from canonical entities.

2. 2

   Lifecycle stage as a single overwriteable field

   You lose the answer to "how long did this account sit in MQL". Use a slowly changing dimension and a history table.

3. 3

   Silent account merges

   Dedupe scripts that merge in the dark destroy attribution. Route ambiguous matches to a review queue.

4. 4

   Multiple Write owners per field

   Marketing automation overwrites a Sales-owned status. Publish the data contract and lock Write rights.

5. 5

   No Layer 7 activation

   The score lives in Looker and never reaches the rep. Reverse-ETL to the CRM, the dialer, and the cadence tool.

6. 6

   Scope creep past the twelve-report freeze

   Phase one slips from six weeks to twenty. Lock the cap, defer the rest.

How Gangly fits the RevOps data workflow

Gangly sits at Layer 7 of the model. The warehouse ships the conformed account, opportunity, and activity tables; Gangly turns them into the next action a rep takes on the next call. Signal Detection reads the canonical signal stream, Call Prep Engine pulls the brief from the account row, Post-Call Notes writes the activity row back, and CRM Hygiene Engine keeps the source-system fields the model depends on clean. The model is the architecture; Gangly is the surface that activates it.

• Signal Detection : reads the canonical signal stream from the warehouse and routes the next-best account to the right rep within minutes.
• Call Prep Engine : pulls the account, contact, opportunity, and activity history from the conformed model so the brief is one screen instead of seven tabs.
• Post-Call Notes : writes the activity row back to the source system in the schema the model expects, so the warehouse receives clean inputs the next morning.
• CRM Hygiene Engine : suggests stage progressions, close-date updates, and field corrections that keep Layer 1 healthy enough for Layer 4 to trust.

Reps using Gangly Post-Call Notes and CRM Hygiene Engine post 71 percent fewer null-value activity rows to the warehouse (Gangly customer benchmark, 2026). That is the difference between a forecast the CRO commits to and a forecast the CRO discounts.

Frequently asked questions

Common questions on the model, the joins, the rollout, and the governance.