Beyond System Metrics: Building Effective Business Monitoring for Pricing Services

"Monitoring is not just a technology, it's a culture." – Ed Gorslin

1. Background and Challenges

1.1 Background

In an uncertain world, especially in software systems, we cannot fully predict runtime behavior, making monitoring essential for real‑time observation, problem detection, and root‑cause identification.

Software systems are inherently complex, so achieving comprehensive monitoring is difficult. Many teams think they have adequate monitoring, yet still encounter unexpected online issues due to insufficient coverage.

1.2 Conflict

Although we have many monitors, they often focus only on system‑level and interface‑level metrics. As business complexity grows, these are insufficient; we lack thorough business‑level monitoring.

Example: a bug causes a price calculation error (100 ¥ becomes 120 ¥). System and interface monitors show normal, so only business‑level monitoring can expose the issue.

Over‑emphasis on system and interface monitoring tilts the balance, preventing timely detection of business problems.

1.3 Challenges

Limited experience with business monitoring – industry solutions focus on system and interface dimensions, leaving a methodological gap for business observability.

High accuracy requirements for pricing services

Rapid business changes: most changes affect pricing, requiring frequent updates.

High complexity: multiple inter‑dependent price components increase iteration difficulty.

Stringent correctness: pricing errors cause financial loss, user churn, negative publicity, and reduced driver trust.

2. Solution Approach

2.1 Overall Idea

Monitoring aims to detect anomalies. For pricing services, we treat the entire pricing process as a black box, observing total price trends, while also monitoring intermediate data (e.g., individual fee items, route calculations, coupons) to catch issues that may not affect the final price noticeably.

Result monitoring alone is insufficient; process monitoring (white‑box) is needed to observe internal calculations.

2.2 Result Monitoring

Result data monitoring resembles black‑box testing: we only see requests and their outcomes.

Is the result data normal?

Missing critical data (e.g., base fare or distance) – zero tolerance.

Incorrect exposed data – validate field trends, ranges, and correlations (e.g., base fare should never be negative).

Does the result meet business expectations?

Some issues only appear when comparing related business dimensions. For instance, Model A’s average price should be higher than Model B’s; violations are detected by joint analysis.

2.3 Process Monitoring

Process monitoring (white‑box) examines internal data and logic.

Monitor core intermediate data generated during execution; missing or abnormal data can block the main flow.

Verify that execution follows expected logical paths, including business and feature‑toggle branches.

3. Specific Plan

3.1 Pricing Result Monitoring

Identify non‑negotiable result fields (e.g., base fare must exist; negative values are errors) and define zero‑tolerance thresholds.

Track trends for key metrics such as unit price, request volume, and hit rate across different scenarios (estimation vs. final pricing), regions, and vehicle types.

3.2 Pricing Process Monitoring

Monitor core intermediate data, such as the existence of vehicle‑type pricing, and ensure required third‑party data is available.

Observe execution indicators like feature‑toggle activation to gauge rollout progress and potential impact.

4. Results

Outcomes:

Completed a comprehensive pricing monitoring dashboard covering both result and process data.

Result data includes price curves for various modes, regions, and business lines (over 20 dashboards).

Process data visualizes fee items, distances, and marketing components (30+ key process monitors).

Benefits:

Nearly all online issues are detected instantly.

Early detection of public‑opinion risks, often a week ahead of competitors.

Prompt verification of business actions, enabling rapid health assessment.

Example: a change in an online service triggered a curve‑based alert, allowing us to intervene before the error impacted users.

5. Recommendations

Never underestimate the value of solid business monitoring; prioritize completeness over minimalism.

Consolidate monitors onto a single dashboard for rapid assessment.

Maintain and evolve monitoring continuously; abandoned alerts lose their purpose.

"You cannot prevent what you cannot monitor." – Eric Thomas