How to Define Your Core Metrics in a Semantic Layer: ARR, Churn & Active Customers

Defining a metric in a semantic layer means choosing its dimensions, its measure, its aggregation, and its filters once — so every dashboard, data app, and AI agent returns the same number. This guide gives a reusable template, then applies it to three metrics teams argue about most: ARR, churn rate, and active customers.

TL;DR

• A metric definition = a measure (what you count), an aggregation (how you roll it up), the dimensions you slice by, and the filters/logic that scope it — defined once in the semantic layer.
• ARR: sum of active recurring subscription value, normalized to annual, filtered to live contracts.
• Churn rate: customers (or revenue) lost in a period ÷ the base at the start of the period.
• Active customers: distinct customers meeting an activity rule inside a defined window — the definition everyone disagrees on until it’s written down.
• Define each once, with the business, and the number stops being arguable.

Most metric disputes aren’t math errors — they’re definition gaps. Two people compute “churn” correctly and get different answers because they scoped it differently. The semantic layer exists to end that: define the metric once, and every consumer inherits it. But a semantic layer only helps if the definitions you put in it are right. Here’s a template for defining any metric, then three worked examples.

In Astrato’s Semantic Layer Editor, the measure and aggregation are a measure definition; the dimensions are dimension fields; and the filters/logic live in the measure or a custom SQL expression when the rule is more than a simple aggregation.

How to define ARR in a semantic layer

Annual Recurring Revenue is the normalized annual value of your active recurring contracts. It sounds simple and isn’t — the disputes are all in the filters.

Applying the template

• Measure: recurring contract value (exclude one-off or services revenue).
• Aggregation: sum, normalized to a 12-month value (a monthly plan × 12).
• Dimensions: plan, segment, region, cohort.
• Filters & logic: active contracts only — exclude cancelled, expired, and not-yet-started.

The definition, in words: sum the recurring value of every active subscription, annualized. As logic:

ARR = SUM(normalized_annual_value)

      WHERE contract_status = 'active'

      AND revenue_type = 'recurring'

The trap: teams disagree on whether to include contracts mid-cancellation, or trials. Decide it once, write it into the measure, and every ARR number in the company now agrees. That’s the whole value of putting it in the semantic layer instead of a dashboard formula.

How to define churn rate in a semantic layer

Churn measures what you lost over a period. The two decisions that change the number: customer churn vs revenue churn, and what counts as the starting base.

Applying the template

• Measure: customers lost (customer churn) or recurring revenue lost (revenue churn) in the period.
• Aggregation: count of churned customers, or sum of churned revenue.
• Dimensions: period (month/quarter), cohort, plan, segment.
• Filters & logic: divide by the base at the start of the period; define “churned” (contract ended, or lapsed past a grace window).

As logic, for customer churn:

Churn Rate = COUNT(customers_lost_in_period)

           / COUNT(customers_at_period_start)

Write both a customer-churn and a revenue-churn measure and name them distinctly (“Customer Churn Rate,” “Gross Revenue Churn”) so no one confuses them. Because they’re defined in the layer, a data app or dashboard showing churn is always using the agreed base — not whatever the report author picked.

How to define active customers in a semantic layer

This is the metric teams argue about most, because “active” is a business rule, not a data fact. The semantic layer is where you finally settle it.

Applying the template

• Measure: distinct customers.
• Aggregation: distinct count.
• Dimensions: region, plan, acquisition channel, month.
• Filters & logic: the activity rule and the window — e.g. made a purchase, or logged in, within the last 90 days.

As logic:

Active Customers =

  COUNT(DISTINCT customer_id)

  WHERE last_activity_date >= today - 90

The 90-day window is a choice, not a law — the point is that you make it once, in the layer, so “active customers” means the same thing in the board deck, the churn calc, and the AI answer. Defining it in plain business terms is exactly the kind of task a semantic-layer assistant can help draft, but the decision — 90 days vs 30, purchase vs login — stays with you.

Where Nash AI speeds this up

Defining these metrics is exactly the work Nash AI, Astrato's built-in assistant, is built to accelerate. You don't have to hand-write every measure: describe the metric in plain language — "create a churn rate metric," "define active customers as customers purchasing within the last 90 days," "create gross margin by product category" — and Nash translates that intent into a governed semantic definition that lives in the shared layer, not a one-off dashboard formula. 

It reads your live semantic model as it goes, so it suggests the right measures and dimensions instead of inventing them, and it can build the more involved time-intelligence measures — YTD, MTD, YoY — that teams usually reach for SQL to write. Metric creation becomes a conversation instead of a development ticket.

Two things keep this honest and useful. 

First, the judgment stays with you: Nash drafts the definition, but the decisions this article is really about — 90 days versus 30, purchase versus login, which contracts count toward ARR — are yours to make and confirm. 

Second, in the semantic layer Nash also helps you keep definitions clean as they grow: ask it to describe your model, list every measure with its formula and source, or flag duplicates and gaps, and it surfaces where definitions conflict before they spread. 

Nash isn't a conversational analyst you ask to interpret your business — it's a modelling copilot that makes defining and maintaining governed metrics dramatically faster, which is where the real time goes.

Key takeaways

• Every metric is four parts: measure, aggregation, dimensions, and filters/logic — pin them down before writing a formula.
• ARR = sum of annualized active recurring contract value; the disputes are in the filters, so decide them once.
• Churn = lost customers or revenue over the period base; always define the base and split customer vs revenue churn.
• Active customers = distinct customers meeting an activity rule in a window; the window is a decision to make once.
• Defining metrics in the semantic layer — not in dashboards — is what makes them consistent everywhere.

Frequently asked questions

Where should I define a metric — in the dashboard or the semantic layer?

The semantic layer. A metric defined in a dashboard applies only to that dashboard; defined in the semantic layer, it’s inherited by every dashboard, data app, and AI query, so the number is consistent everywhere.

What’s the difference between a measure and a metric?

A measure is the aggregation in your model (sum of revenue). A metric is the full business definition — the measure plus the filters, window, and logic that make it “ARR” or “active customers.”

Why do two people get different numbers for the same metric?

Almost always a definition gap, not a math error — different filters, windows, or bases. Defining the metric once in the semantic layer removes the gap.

Can I define these metrics without SQL?

Simple measures and aggregations are defined directly in the semantic layer editor. For logic beyond a basic aggregation, a custom SQL expression handles it — but the common metrics here are mostly measure-and-filter definitions.