Article body
Full article
Business discussions often begin with a number—and often stall over one. Does operating revenue include tax? What period does the repeat-purchase rate cover? Which date governs store sales? When these questions are scattered across reports, temporary calculations, and individual experience, a team cannot reliably reuse the same conclusions. HENGSHI puts metric definitions, business-scenario settings, metric analysis, and data-question preparation into a continuous workflow so each business definition has a clear home.
HENGSHI’s view: Trusted analysis starts with shared business definitions. A metric is executable business language: it must state both what is calculated and the business scenario in which it is analyzed.
Define a Metric Before Applying It to a Business Scenario
HENGSHI separates metrics into atomic metrics and business metrics. An atomic metric contains only a metric definition. It expresses a numerical calculation through aggregation functions and can use fields, parameters, user attributes, and filters. A team can define “operating revenue” as an aggregation, for example, and establish its calculation rule first.
A business metric adds business settings to the metric definition so the same numerical calculation corresponds to a specific analytical scenario. Available settings include constraints, analytical dimensions, a time axis, and path attribution. Constraints limit the business scope; dimensions break results down by business object; the time axis defines how time is analyzed; and path attribution connects mutually influential metrics for joint analysis. A date dimension is required for a time axis, and one date field can serve as the time axis of a business metric.
| Object | Role in HENGSHI | Result for the team |
|---|---|---|
| Atomic metric | Defines a numerical rule with an aggregation | A reusable foundational calculation |
| Business metric | Adds constraints, dimensions, a time axis, and path attribution | An analyzable business scenario |
| Metric granularity | Reuses dimensions, a time axis, and constraints | Less repeated configuration for the same scenario |
Check the Data Boundary Before Reusing Configuration
When several business metrics share the same dimensions, time axis, and constraints, the team can define those settings as metric granularity and reference them from each metric. A change to the granularity updates every metric that references it. Conditions such as “by store, by month, completed orders only” can therefore be maintained in one place.
Metric granularity has a clear scope: it currently supports one dataset only. If a business metric selects dimensions or constraints from multiple tables in a data model, the team must configure the metric for that scenario instead of relying on metric granularity for reuse. Recording this limitation in implementation standards prevents multi-table analysis from being configured as single-dataset granularity.
Organize Metric Publishing and Use by Business Topic
HENGSHI metric management organizes content by business topic. A topic can contain metrics and subtopics, and one metric can belong to several topics. Metrics in a topic can be published, unpublished, removed, or refreshed. Users can view and analyze a published metric; once unpublished, it is no longer available to them. Teams can arrange metrics around operating, sales, or supply-chain contexts instead of exposing every calculation rule in one flat list.
Business topics can grant access to managers, editors, viewers, and tenant users. Users with topic access can find its metrics in the Metric Marketplace and analyze them in a metric-analysis dashboard. The Metric Marketplace shows published metrics associated with business topics, including metric charts, definitions, and upstream and downstream production relationships. From creation through publishing and analysis, the metric remains in the same business context.
Make Definitions Work for Visual Analysis and Data Agent
An atomic metric can serve as a measure or filter in a dashboard and can also enter a metric-analysis dashboard. Business users see more than a result: they can return to the metric definition, granularity information, and lineage to verify the calculation. That gives the analysis a traceable basis.
Data Agent also depends on this preparation for accurate interpretation. HENGSHI recommends clear, descriptive names for datasets, fields, and atomic metrics; complete explanations of how fields and metrics are used; and an explicit distinction between field names and metric names. Dataset knowledge management can maintain business terms, synonyms, implicit rules, and mappings to fields and metrics. A team can define the date range of a “fiscal year,” for example, or map “ROI” to an established metric instead of assembling its calculation during each data question.
Establishing reusable business definitions in the data layer and exposing them as metrics can improve the accuracy, stability, and explainability of data-question results. Irrelevant fields can be hidden to narrow Data Agent’s interpretation scope. Business staff should continue to maintain domain rules so names and descriptions reflect their real meanings.
HENGSHI’s Metric Management Method
HENGSHI carries business definitions through a continuous workflow spanning datasets, metric management, metric analysis, and Data Agent. Teams define atomic metrics in a dataset and add business settings to form business metrics. They then publish and authorize those metrics by business topic, use them in the Metric Marketplace and metric analysis, and give Data Agent an understandable semantic foundation through clear field and metric descriptions and maintained business rules.
This method attaches a shared definition to concrete objects and operations. Data teams own calculation rules and data boundaries. Business teams own scenarios, terminology, and explanations. Users view and analyze metrics within the topics they are authorized to access. Each discussion can return to the metric definition and business settings, reducing repeated reconciliation caused by identical names with different meanings.