Understanding and Building an Indicator System: Definitions, Lifecycle, and Productization

1. What Is an Indicator System

An indicator system is a collection of metrics used to assess a company's business status from multiple dimensions; it combines indicators (quantifiable measurements) with a structured framework, essentially "indicator + system".

Indicators quantify business units, making goals describable, measurable, and decomposable, serving as the statistical foundation for evaluating outcomes.

Indicators are mainly divided into result‑type and process‑type:

Result‑type indicators measure outcomes after a user action, often observed later and hard to intervene.

Process‑type indicators capture metrics during the user action and can be influenced by operational strategies.

The system consists of dimensions, which are the perspectives through which users observe and describe phenomena; without dimensions, indicators lack context.

Dimensions are categorized as qualitative (e.g., city, gender, occupation) and quantitative (e.g., income, age), the latter requiring numerical grouping.

2. Indicator System Lifecycle

The lifecycle includes definition, production, consumption, and deprecation. Continuous operation, quality assurance, and data‑operation activities are required to maintain reusability and reduce user costs.

3. Why Build an Indicator System

3.1 Understand Business Status

An indicator system provides objective data that aligns understanding of business conditions across departments.

3.2 Identify Business Pain Points

Using frameworks such as the AARRR pirate metrics model, one can locate issues in acquisition, activation, retention, revenue, and referral stages.

3.3 Guide and Drive Business

Indicators enable result prediction, early warning, and abnormal data attribution, helping uncover business flaws.

3.4 Optimize Product or Logic

Funnel analysis reveals where significant drop‑offs occur, allowing targeted optimization.

4. How to Build an Indicator System

4.1 Indicator Value

Technical goal: unify indicator and dimension management, standardize naming and calculation, ensure consistency.

Business goal: provide a unified data export covering multiple scenarios.

Product goal: deliver a tool that streamlines definition, production, and consumption of indicators.

4.2 Model Architecture

4.2.1 Business Lines

Business modules are abstracted at the logical layer and subdivided physically, with up to three hierarchical levels.

4.2.2 Standard Definitions

Data domain: abstract collection of business processes or dimensions; processes are indivisible events, dimensions are the measurement context.

Business process: indivisible business events such as order placement or payment.

Time period: defines the statistical window (e.g., last 30 days, natural week).

Modifier: non‑dimensional qualifiers (e.g., APP, PC) that specify the scenario.

Metric/Atomic indicator: the smallest, non‑decomposable measurement (e.g., transaction amount).

Dimension: the environment for a metric, forming a set of attributes (e.g., geographic, temporal).

Dimension attribute: specific properties belonging to a dimension (e.g., city name, ID).

Indicator classification: atomic, derived, and derived‑type indicators.

Atomic indicator: a basic metric tied to a business event.

Derived indicator: atomic indicator + optional modifiers + time period.

Derived indicators split into transaction‑type (measuring process performance) and stock‑type (measuring entity state). Stock‑type indicators often use a time period like historical up to the current moment .

Derived‑type indicators: ratios, growth rates, statistical averages built on transaction or stock indicators.

4.3 Indicator System Construction Process

4.3.1 Collaboration Workflow

4.3.2 Naming Conventions

Atomic indicator = business process + metric. Example: use trd_pay_amt for transaction payment amount to avoid conflict with generic pay_amt .

Derived indicator = atomic indicator + modifier + time period. Modifiers appear after the atomic part to preserve inheritance and readability. If no defined modifier, use a three‑digit code for uniqueness. Example: trd_pay_amt_7d for payment amount over the last 7 days.

4.3.3 Indicator Model Construction

The modeling process abstracts business requirements into thematic groups, standardizes terminology, and reduces duplication. Kimball dimensional modeling is used, comprising dimensions and fact tables.

Data Model

Model Definition Specification

5. Productizing the Indicator System

5.1 Indicator Product Overview

The product suite follows the indicator lifecycle, providing tools that automate, standardize, and streamline indicator management, thereby turning data into business value.

Key product functions include enforcing management standards, automatically generating consistent indicators, and exposing standardized metric definitions and metadata.

5.2 Tool Design Process

5.2.1 Metadata Management

5.2.2 Indicator Definition

5.2.3 Indicator Production

5.2.4 Indicator Consumption

Conclusion

The article outlines the methodology for constructing an indicator system and the associated product tools. The data‑indicator and development tools have been integrated internally, and future integration with data‑consumption products will expose services via DataAPI.

The indicator system tool is already deployed across core business units and will continue to evolve.