# Aggregations
URL: https://pro.rv-grid.com/guides/pivot/concepts/aggregations/
Source: src/content/docs/guides/pivot/concepts/aggregations.mdx
Description: Learn how Pivot measures work, how aggregators are resolved, and how to design reliable summaries.
Aggregations turn raw field values into Pivot measures. A value field points to a source field, and an aggregator describes how that field should be summarized inside each Pivot cell.

## Dimension vs Measure

- A `dimension` groups facts.
- A `measure` summarizes facts.

In RevoGrid Pivot, both are built from the same field model. The difference is how you place them:

- `rows` and `columns` use a field as a grouping dimension.
- `values` uses a field as a measure source.

## Basic Value Configuration

```ts
values: [
  { prop: 'sales', aggregator: 'sum' },
  { prop: 'sales', aggregator: 'avg' },
  { prop: 'orders', aggregator: 'count' },
]
```

Each value becomes a separate measure in the generated Pivot output.

## How Aggregator Resolution Works

`values[].aggregator` is a string id. Pivot resolves that id against the matching dimension's `aggregators` map. If you use the configurator, those same registered aggregator ids populate the measure selector.

```ts
dimensions: [
  {
    prop: 'sales',
    name: 'Sales',
    aggregators: {
      sum: commonAggregators.sum,
      avg: commonAggregators.avg,
    },
  },
],
values: [{ prop: 'sales', aggregator: 'avg' }]
```

If the dimension does not expose the aggregator id, the measure cannot be resolved correctly.

## Built-In Summary Functions

The public remote/server-side summary model supports these stable ids:

- `sum`
- `min`
- `max`
- `avg`
- `count`

Client-side Pivot can also use custom aggregator functions through the dimension model.

## Multiple Measures

When you define multiple values, Pivot generates one measure per configured entry. That is useful for layouts like:

- Sales sum by quarter
- Margin avg by quarter
- Order count by quarter

On the client side, each generated value column uses the measure's `prop` and `aggregator`. On the remote side, result ids are stable summary ids such as `SalesAmount_sum` and `SalesAmount_avg`.

## Formatting Measures

Formatting belongs in the dimension metadata used by the generated columns. For example, attach a numeric column type or a custom template to the measure dimension so generated cells inherit the right rendering behavior.

## Custom Aggregators

Custom aggregators are useful when:

- you need a domain-specific summary
- the display value is not one of the common numeric summaries
- you are staying on the client-side path

Keep them lightweight. Client-side aggregators are run while materializing Pivot output, so very expensive functions will slow down large pivots.

## Average And Derived Measures

`avg` deserves special attention in OLAP-style systems:

- It is not additive.
- Correct remote planning often requires `sum + count` internally.
- Totals must be computed from underlying facts, not from already-averaged child cells.

The remote planner layer in this repository already models `avg` as a derived summary when planning server-side requests.

## Best Practices

- Prefer additive measures like `sum` and `count` when possible.
- Only expose aggregators that make business sense for the field.
- Keep stable aggregator ids across saved states and remote APIs.
- Name measures clearly in examples and UI text so users know whether they are looking at a sum, avg, or count.

## Next

Continue with [Configuration Reference](/guides/pivot/configuration-reference/) for the full `PivotConfig` surface.
