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?
Store in database if used frequently. Calculate on the fly if used rarely. Frequency matters. If custom metric is referenced in fifty dashboards, store in database (fast, consistent). If custom metric is used in one report, calculate in that report. Balance performance and simplicity. With WEMASY's website builder, you can set this up directly on your website.
How do we handle custom metrics with multiple valid definitions?
Create separate metrics. Sales defines churn as customers who did not renew contract. Product defines churn as customers who did not log in for thirty days. Conflict. Rename: contract-churn and activity-churn. Different names, different definitions, no confusion. Document both in metric dictionary.
What if custom metric calculation is expensive (slow)?
Cache it. Calculate once daily or once hourly. Store result. Dashboards pull cached value instead of calculating on demand. Caching is fast. Calculation is slow. Cache balances speed and freshness.
How do we prevent custom metrics from drifting from their definition?
Quarterly audit. Pull custom metric. Recalculate manually using definition. Do numbers match. If not, something is wrong. Definition changed, calculation changed, or understanding changed. Investigate. Fix.
Should we expose calculation logic to users or keep it hidden?
Expose it. Every dashboard should show: revenue is defined as X. Calculation is Y. Users should understand metric. Transparency prevents misuse. If user does not understand calculation, they cannot correctly interpret metric.
How many custom metrics should a dashboard have?
Three to five maximum. Too many custom metrics are hard to understand and maintain. Keep custom metrics to those that directly answer business questions. Everything else is supporting metric in detail dashboard.