Two dashboards can disagree while both queries run successfully. One counts orders created, another counts orders completed, and neither label explains the distinction. Before commissioning the interface, agree exactly what each important measure means and who can change that meaning.
Related service: CRM, ERP and web application development- 01Name the decision the number supports.
- 02Define included records and time basis.
- 03Calculate a small example manually.
- 04Implement and compare the result.
- 05Approve and version later changes.
SECTION 01
Specify the records before choosing a chart
Describe one record in the calculation: an order, an order line, a customer or a status event. Choose the time field and timezone. State whether cancellations, test data and missing values are included. For a percentage, define both the numerator and denominator, including what the screen shows when the denominator is zero.
The dbt metric documentation illustrates explicit metric types and filters, while PostgreSQL documents aggregation behavior. These are technical references, not a requirement to buy either platform. Your agency still needs an approved business definition. A mathematically valid sum can answer the wrong question if it includes the wrong records.
SECTION 02
Illustrative example: combining two response queues
Suppose queue A has two completed requests taking ten minutes each, while queue B has eight taking thirty minutes each. Averaging the two queue averages gives twenty minutes. Combining all ten requests gives twenty-six minutes. The difference comes from weighting, not a broken chart. These are invented figures for explaining the calculation.
Decide whether waiting time, paused requests and reopened work belong in the measure. If one team excludes weekends and another does not, their averages cannot be compared without explanation. Ask for the small input dataset, the intermediate totals and the expected final result so nontechnical owners can review the implementation.
SECTION 03
Make changes visible to report readers
Keep a named owner for each important measure and record why a definition changes. A revised cancellation rule may require recalculating history or marking a break in the trend. Do not quietly replace a formula while keeping the same label and implying that every historical point remains comparable.
Acceptance should compare the dashboard, drill-down records and export using the same filters. Test empty periods, duplicate source records and late updates. Begin with a small set of decisions the team actually makes; adding dozens of ambiguous measures creates more reconciliation work than useful insight. The handoff should include definitions and sample tests, not only screenshots.
SECTION 04
Frequently asked questions
Who should approve metric definitions?
The business owner responsible for the decision, with the agency documenting how source data and calculation rules implement it.
Can a chart be correct while its export differs?
Only if the difference is intentional and explained. Otherwise, compare filters, date fields, aggregation and data refresh timing.
Should missing data become zero?
Not automatically. Zero and unknown have different meanings; choose a rule that fits the measure and display it clearly.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Metric definitions and typesdbt Labs
- Aggregate functionsPostgreSQL
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy