Custom metrics and calculated fields: building meaningful numbers

Home / Everything About / Everything About Analytics / Custom metrics and calculated fields: building meaningful numbers

Most metrics come directly from database. Revenue is reported revenue. Traffic is reported traffic.

Custom metrics are calculated from other metrics. Example: profit is revenue minus cost. Example: customer acquisition cost is marketing spend divided by new customers. Example: customer lifetime value is average revenue per customer times average customer lifespan.

Custom metrics are powerful because they combine multiple data points into one meaningful number. But they are dangerous if calculated wrong.

When to use custom metrics

Use custom metric when simple metrics do not answer question

Question: are we profitable. Answer requires: revenue minus cost. Simple metrics (revenue alone, cost alone) do not answer question. Custom metric (profit) answers it.

Use custom metric when metric is used across organization

All dashboards and reports reference same metric. Centralized definition ensures consistency.

Do not use custom metric for one-off questions

If only one dashboard needs profit calculation, calculate in that dashboard. Do not create custom metric. Custom metrics should be reused.

How to calculate custom metrics

Document calculation

Profit is calculated as: total revenue minus total expenses. Total revenue is defined as: completed transactions in period. Total expenses is defined as: actual expenses minus one-time items. Documentation prevents confusion.

Validate calculation

Calculate by hand for sample data. Verify automatic calculation matches hand calculation. Example: revenue is one hundred thousand, expenses are sixty thousand, profit should be forty thousand. Verify calculation produces forty thousand.

Audit regularly

Monthly audit: is custom metric still accurate. Has underlying data source changed. Is definition still valid. Recalculate sample data. Verify it still produces correct answer.

Document assumptions

Profit calculation assumes all revenue is realized (no pending transactions). Profit calculation excludes one-time charges. Document these assumptions so user knows what profit includes and excludes.

Real example: customer lifetime value calculation

Definition

Customer lifetime value is average annual revenue per customer times average customer lifespan in years.

Data

Average annual revenue per customer: one thousand dollars. Average customer lifespan: three years. Calculated CLV: one thousand times three equals three thousand.

Validation

Sample customer: signed contract year one, bought services all three years, canceled year four. Total revenue: three thousand. CLV calculation is correct.

Another sample customer: signed contract, bought year one only, canceled year two. Total revenue: one thousand. Below CLV. This customer has low lifetime value. Calculation is working.

Reality check: CLV three thousand seems reasonable for product at one thousand dollars per year.

Usage

Sales dashboard uses CLV to show customer quality (this segment has CLV three thousand, that segment has CLV one thousand). Product dashboard uses CLV to justify investments (if feature increases customer lifespan by one year, CLV increases by one thousand, feature is worth it). Finance dashboard uses CLV to forecast revenue (if we sign one hundred customers, expected revenue is three hundred thousand).

All dashboards use same CLV definition. Consistency prevents conflicts.

Common custom metric mistakes

Mistake one: calculating wrong

CLV calculation uses average revenue but forgot to account for one-time setup fees. CLV is overstated.

Mistake two: calculation changes over time

Year one, CLV is calculated as revenue times lifespan. Year two, somebody changes calculation to revenue times lifespan minus churn cost. Now year two CLV is not comparable to year one. Consistency is broken.

Mistake three: calculation is too complex

Custom metric is calculated using query that is five hundred lines long. Only one person understands it. Person leaves. Knowledge is lost. Calculation is broken.

Mistake four: calculation is not documented

Custom metric exists. Definition is not written down. Different people calculate it differently. CLV in dashboard A is different from CLV in dashboard B. Confusion.

How to prevent mistakes

Keep calculation simple

If calculation cannot be explained in one sentence, it is too complex. Example: profit is revenue minus expenses. Simple. Example: customer health score is weighted combination of feature adoption thirty percent plus support satisfaction twenty percent plus payment history thirty percent plus tenure twenty percent. Complex. Too complex.

Document thoroughly

Write definition, calculation, assumptions, validation, examples. Documentation is single source of truth.

Version calculations

When calculation changes, version it. CLV v1 was revenue times lifespan. CLV v2 is revenue times lifespan minus churn cost. Versioning allows historical comparison (v1 in 2024, v2 in 2025).

Audit regularly

Monthly or quarterly audit. Is calculation still producing correct answer. Is definition still valid. Is anyone calculating it differently.

Frequently asked questions

Should custom metrics be stored in database or calculated on the fly?

How do we handle custom metrics with multiple valid definitions?

What if custom metric calculation is expensive (slow)?

How do we prevent custom metrics from drifting from their definition?

Should we expose calculation logic to users or keep it hidden?

How many custom metrics should a dashboard have?