The SQL behind every metric in the NorthStar governance framework. Each query includes the calculation logic, edge case handling, and documentation of how cross-team definition conflicts were resolved.
Written for Snowflake SQL dialect · Assumes Salesforce + billing system as source · All queries are dbt-model-ready
Total ACV of open opportunities at Stage 2+ (Qualified or later). This is the single most contested metric in GTM analytics — Sales, Marketing, and Finance almost always define it differently. The SQL below implements the Rev Ops standard: stage-gated, excludes closed deals, and uses the current ACV field (not the original estimate).
-- Qualified Pipeline: Current ACV of all open opportunities at Stage 2+-- Owner: Rev Ops | Refresh: Daily 6:00 AM ET | Source: Salesforce OpportunityWITH stage_map AS (SELECT stage_name,CASE stage_nameWHEN 'Prospecting' THEN 1WHEN 'Qualified' THEN 2WHEN 'Demo' THEN 3WHEN 'Proposal' THEN 4WHEN 'Negotiation' THEN 5WHEN 'Closed Won' THEN 6WHEN 'Closed Lost' THEN 7END AS stage_orderFROM salesforce.opportunity)SELECTo.owner_name AS rep,a.specialty_segment AS specialty,o.lead_source AS source_channel,COUNT(DISTINCT o.opportunity_id) AS deal_count,SUM(o.acv) AS pipeline_acv,AVG(o.acv) AS avg_deal_size,MEDIAN(o.acv) AS median_deal_sizeFROM salesforce.opportunity oJOIN salesforce.account aON o.account_id = a.account_idJOIN stage_map smON o.stage_name = sm.stage_nameWHERE sm.stage_order BETWEEN 2 AND 5 -- Qualified through NegotiationAND o.is_closed = FALSE -- Exclude won and lostAND o.acv >= 5000 -- Floor: exclude sub-$5K trialsAND o.is_deleted = FALSEGROUP BY 1, 2, 3ORDER BY pipeline_acv DESC;
Sales wants to include Stage 1 (Prospecting) to show larger pipeline. Marketing wants to include MQLs that haven't converted to Opportunity yet. Finance wants Stage 3+ only (post-demo). The resolved standard uses Stage 2+ as the compromise — validated by Sales but not yet requiring a completed demo.
These queries are written for Snowflake SQL and designed to be implemented as dbt models with schema tests (not_null, unique, accepted_values) and freshness checks. In production, each metric would be a dbt model in a marts/gtm_analytics/ directory with a corresponding YAML schema file documenting the column definitions, tests, and metadata. The conflict resolution notes map directly to the NorthStar Metric Registry — each resolved conflict becomes a documented decision in the governance layer.