Simple Metrics

Simple metrics are defined on the Semantic Models page. They specify the basic aggregation behavior Athenic should apply when querying a column. In most cases, simple metrics are created from numeric columns, but Athenic also supports a few common aggregations on non-numeric fields: Count Distinct on Category columns, and Count Distinct, Min, or Max on Time (date/timestamp) columns.

The image contains example Simple metrics for a Sales Invoice semantic model.

Fields

Label (required)

A unique name for the metric across your project. This is the name users will select in questions and charts.

Description (required)

Provide context about what the aggregation represents and any complexities for using this aggregation. This will be used by Athenic for generating results for user questions.

Aggregation (required)

The aggregation to aggregate over the data.

Possible Values:

• Sum

• Average

• Min

• Max

• Count Distinct — used to get metrics like number of orders

• Percentile

The aggregation types are restricted based on the semantic type of the data column.

• Simple Metric - supports Sum, Average, Min, Max, Count Distinct, Percentile

• Time - supports Min, Max, Count Distinct

• Primary Key - supports Count Distinct

• Foreign Key - supports Count Distinct

• Category - supports Count Distinct

Aggregation Time Dimension (required)

The aggregation time dimension is the time dimension (or date column) that you want to aggregate over. For example, revenue is the sum of sales orders across the order creation date. Metrics are fundamentally aggregations over time, so a time dimension is required.

Special case for Dimension tables with no time dimension

If you have a special case where a time dimension does not exist naturally, you can work around this situation. For example, if you have a product dimension table that only contains product information and you would like to add a Simple Metric for the number of distinct products, you will need to edit your dataset to add a time dimension using your SQL database's NOW() or CURRENT_DATE() functions.

This is partially outside the scope of metrics, but it will work as long as it is not combined over time with other metrics (since there would be only one time value).

Non-Additive Time Dimensions (optional)

In this example, we are indicating that Total Invoice Amount is a snapshot-style metric across time. When querying a date range, Athenic will NOT add up values across all dates; Instead, it will select the MINIMUM Invoice Created Date within the range per Subsidiary ID, and then compute the SUM on that "as-of" date to avoid double counting when rolling up time.

Some numeric values should not be summed across time because summing produces incorrect results. These values represent a state at a point in time (a snapshot), not activity over a period.

For example:

• Account balance: you don’t sum daily balances to get a monthly balance; you want the ending (or beginning) balance.

• Monthly recurring revenue (MRR) stored daily: you don’t sum daily MRR to get monthly MRR; you want the MRR value as-of the end of the month (or start).

To support this, you can configure Non-Additive Dimensions for the Simple metric. This will essentially tell the semantic model:

When users group by a non-additive dimension (like month), pick a single row per group using a window function instead of summing across rows

Configuration:

1. Dimension Column - The time dimension that the metric should use but not be aggregated over.

2. Window Choice - Select which value within the time window represents the metric:

   • min: use the value at the beginning of the period (e.g., starting balance)

   • max: use the value at the end of the period (e.g., ending balance)

3. Window Groupings - The entity columns that define one independent series of values. Athenic will compute the min/max within each grouping.

   • Common groupings: account_id, user_id, subscription_id, customer_id, plan_id

Example Scenario: End-of-month Account Balance

You have a daily snapshot table that records each account's balance at the end of every day and you want a Simple metric of Total Balance.

Account ID	Snapshot Date	Balance
Account 1	2026-01-01	100
Account 1	2026-01-02	120
Account 1	2026-01-03	90
Account 2	2026-01-01	50
Account 2	2026-01-02	60
Account 2	2026-01-03	70

If a user asks for "Total balance for January 2025", a normal SUM of all account balances over the month will add up every day's balance which is incorrect.

Account 1: 100 + 120 + 90 = 310
Account 2: 50 + 60 + 70 = 180
Total = 490 (INCORRECT)

What we actually want is an "as-of" value which in this case, is the end-of-month balance. In this case, we have the following Simple metric fields:

• Aggregation Type: SUM (sum balances across accounts)

• Aggregation Time Dimension: Snapshot Date

• Non-Additive Dimension:

  • Dimension Column: Snapshot Date

  • Window Choice: MAX

  • Window Groupings: Account ID

Account 1: 90 (latest)
Account 2: 70 (latest)
Total = 160 (CORRECT)