---
title: "metric definition | Skills We Assign For | Azendo"
description: "Defining metrics precisely — the edge cases that cause disputes, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/metric-definition/"
---

[Skills](https://azendo.co/skills/) Analytics and BI 

# metric definition.

Metric definition is the precise specification of what a number counts: which events, which filters, which time basis, which exclusions. It is where most disagreements about data actually originate.

## Where metric definition fits on a long engagement.

Most arguments about conflicting numbers are not about correctness; both calculations are defensible. They differ on details nobody wrote down: whether refunds are netted, whether internal accounts are excluded, whether the date is order time or settlement time, whether currency is converted at transaction or period rate.

Writing the definition down in enough detail to be unambiguous is genuinely difficult, and it surfaces real business disagreements that were previously hidden by everyone assuming their own interpretation. That discomfort is the value, not a side effect.

## What an assigned team does with metric definition.

Definitions have to live somewhere versioned, with a record of when they changed. A metric that quietly changed meaning in March makes every year-on-year comparison wrong, and without a history nobody can identify why the trend broke.

Keeping that in version control alongside the transformations is the practice that makes numbers auditable, assigned under [data engineering outsourcing](https://azendo.co/services/data-engineering/).

## What we use metric definition for.

* Edge cases written down Refunds, internal accounts and timing decided explicitly rather than per analyst.
* Definitions under version control A history of what changed and when, so a broken trend is explainable.
* Disagreements surfaced rather than buried Making implicit interpretations explicit, which is where the real value sits.

## How metric definition capacity is assigned.

Metric work is assigned inside data capacity, with definitions held in version control rather than in a document that drifts.

## Roles we assign metric definition for

* [Data Analyst Data science](https://azendo.co/services/data-science/data-analyst/)

## Service lines it sits in

* [Data science](https://azendo.co/services/data-science/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in analytics and bi

* [Power BI — skill we assign for](https://azendo.co/skills/power-bi/)
* [Tableau — skill we assign for](https://azendo.co/skills/tableau/)
* [semantic layers — skill we assign for](https://azendo.co/skills/semantic-layers/)
* [A/B testing — skill we assign for](https://azendo.co/skills/a-b-testing/)
* [experimentation design — skill we assign for](https://azendo.co/skills/experimentation-design/)
* [causal inference — skill we assign for](https://azendo.co/skills/causal-inference/)
* [cohort analysis — skill we assign for](https://azendo.co/skills/cohort-analysis/)
* [segmentation — skill we assign for](https://azendo.co/skills/segmentation/)

## Tell us what your roadmap needs metric definition for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)