SMP KPI & Metrics Definition¶

Audience: BA, PM, Ops, Data team · Updated: v3.3

1. Mục đích¶

Tài liệu này định nghĩa chính xác các metrics SMP track ở dashboard. Mỗi metric có: - Definition: nói rõ đo cái gì - Formula: công thức tính (SQL pseudo) - Dimensions: filter/group by gì - Frequency: tính real-time hay batch - Owner: ai quan tâm metric này

Nguyên tắc: nếu BA + Dev + Data đồng ý formula khác nhau → conflict. Phải resolve ở doc này trước khi build dashboard.

2. Business metrics (PM, Founder)¶

2.1 GMV (Gross Merchandise Value)¶

Định nghĩa: Tổng giá trị giao dịch thành công, gồm labor + material + VAT (trước bất kỳ discount/refund nào).

Formula:

SELECT SUM(total_amount + discount_amount) AS gmv
FROM orders
WHERE current_stage IN ('09_completed', '10_rated')
 AND created_at BETWEEN <from> AND <to>;

Dimensions: by period, by partner_id, by service_id, by city/district Frequency: Daily snapshot (cron 00:05 hàng ngày) Unit: VND

2.2 NMV (Net Merchandise Value)¶

Định nghĩa: GMV sau khi trừ discount và refund.

Formula:

SELECT SUM(total_amount) - SUM(refund_amount)
FROM orders
WHERE current_stage IN ('09_completed', '10_rated')
 AND created_at BETWEEN <from> AND <to>;

2.3 SMP Revenue¶

Định nghĩa: Phần SMP giữ lại (commission từ thợ + SaaS fee + material margin).

Formula:

-- Commission từ order labor
SELECT SUM(order_steps.labor_price * commission_rate)
FROM order_steps
JOIN orders ON ...
WHERE orders.current_stage IN ('09_completed', '10_rated')
 AND orders.created_at BETWEEN <from> AND <to>

UNION ALL

-- Material margin
SELECT SUM(material_variants.sell_price - material_variants.cost_price_avg) * quantity
FROM order_step_materials
WHERE source = 'reserved'
 AND order step is completed

UNION ALL

-- SaaS fee
SELECT SUM(partners.supplier_config.saas_fee_monthly)
FROM partners
WHERE supplier_config.model IN ('saas_only', 'hybrid')
 AND active in period

Note: tính 3 nguồn revenue tách biệt, sau đó cộng để có total SMP revenue.

2.4 Order count¶

Định nghĩa: Số đơn theo từng status trong period.

Formula:

SELECT current_stage, COUNT(*)
FROM orders
WHERE created_at BETWEEN <from> AND <to>
GROUP BY current_stage;

Dimensions: by source (customer_direct, partner_customer, contract), by city Frequency: Real-time (Redis counter, sync to MySQL hourly)

2.5 Active customers¶

Định nghĩa: Khách có ≥ 1 đơn hoàn thành trong period.

Formula:

SELECT COUNT(DISTINCT customer_id)
FROM orders
WHERE current_stage IN ('09_completed', '10_rated')
 AND created_at BETWEEN <from> AND <to>;

2.6 Repeat customer rate¶

Định nghĩa: % khách có ≥ 2 đơn hoàn thành.

Formula:

WITH customer_orders AS (
 SELECT customer_id, COUNT(*) AS cnt
 FROM orders
 WHERE current_stage IN ('09_completed', '10_rated')
 GROUP BY customer_id
)
SELECT 
 SUM(CASE WHEN cnt >= 2 THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS repeat_rate_pct
FROM customer_orders;

2.7 AOV (Average Order Value)¶

Formula:

SELECT AVG(total_amount)
FROM orders
WHERE current_stage IN ('09_completed', '10_rated')
 AND created_at BETWEEN <from> AND <to>;

3. Operational metrics (Ops Manager)¶

3.1 Order completion rate¶

Định nghĩa: % đơn hoàn thành (vs tổng tạo).

Formula:

SELECT 
 SUM(CASE WHEN current_stage IN ('09_completed', '10_rated') THEN 1 ELSE 0 END) * 100.0 / COUNT(*)
FROM orders
WHERE created_at BETWEEN <from> AND <to>;

Target: ≥ 90%

3.2 Cancellation rate¶

Formula:

SELECT 
 SUM(CASE WHEN current_stage = 'cancelled' THEN 1 ELSE 0 END) * 100.0 / COUNT(*)
FROM orders
WHERE created_at BETWEEN <from> AND <to>;

Sub-dimension: cancellation reason (customer_cancel, no_agent_available, quote_rejected, payment_failed)

Target: ≤ 5%

3.3 Dispatch SLA¶

Định nghĩa: % đơn assigned to agent trong N phút sau khi tạo.

Formula:

SELECT 
 SUM(CASE 
 WHEN TIMESTAMPDIFF(MINUTE, created_at, accept_at) <= 5 
 THEN 1 ELSE 0 END
 ) * 100.0 / COUNT(*)
FROM (
 SELECT o.created_at, MIN(log.created_at) AS accept_at
 FROM orders o
 JOIN order_stage_log log ON log.order_id = o.id
 WHERE log.to_stage = '03_survey_accepted'
 GROUP BY o.id
) t;

Target: 95% within 5 phút

3.4 Average time to assign¶

Formula:

SELECT AVG(TIMESTAMPDIFF(SECOND, created_at, accept_at)) AS avg_seconds
FROM ...

3.5 Average order duration (created → completed)¶

Formula:

SELECT AVG(TIMESTAMPDIFF(HOUR, created_at, completed_at))
FROM orders
WHERE current_stage IN ('09_completed', '10_rated');

3.6 Stuck orders count (alert)¶

Định nghĩa: Đơn ở 1 stage quá lâu so với threshold.

Stages + threshold: | Stage | Max time | If exceeded | |---|---|---| | 01_created | 5 min | Dispatch issue | | 02_dispatched_survey | 15 min | No agent accepting | | 03_survey_accepted → 04_arrived_survey | 60 min | Agent late | | 05_surveyed → 06_quote_approved | 24h | Customer not responding | | 07_dispatched_execution | 15 min | No agent accepting | | 08_in_progress | service duration × 2 | Step too long |

SELECT id, current_stage, TIMESTAMPDIFF(MINUTE, last_stage_change, NOW) AS stuck_min
FROM orders
WHERE current_stage NOT IN ('09_completed', '10_rated', 'cancelled')
 AND TIMESTAMPDIFF(MINUTE, last_stage_change, NOW) > <threshold>;

Frequency: Real-time alert (every 5 min cron)

3.7 Manual dispatch ratio¶

Định nghĩa: % đơn cần ops dispatch tay (sau 3 rounds fail).

Formula:

SELECT 
 SUM(CASE WHEN manual_dispatched = TRUE THEN 1 ELSE 0 END) * 100.0 / COUNT(*)
FROM orders
WHERE current_stage IN ('09_completed', '10_rated')
 AND created_at BETWEEN <from> AND <to>;

Target: ≤ 3%

4. Agent metrics (Agent Squad)¶

4.1 Agent utilization¶

Định nghĩa: % thời gian agent đang trong job (vs online time).

Formula:

WITH agent_time AS (
 SELECT 
 agent_id,
 SUM(TIMESTAMPDIFF(MINUTE, online_start, online_end)) AS online_minutes
 FROM agent_sessions
 WHERE date BETWEEN <from> AND <to>
 GROUP BY agent_id
),
agent_busy AS (
 SELECT 
 execution_agent_id AS agent_id,
 SUM(TIMESTAMPDIFF(MINUTE, started_at, completed_at)) AS busy_minutes
 FROM order_steps
 WHERE status = 'completed'
 AND started_at BETWEEN <from> AND <to>
 GROUP BY execution_agent_id
)
SELECT t.agent_id, b.busy_minutes * 100.0 / t.online_minutes AS utilization_pct
FROM agent_time t
LEFT JOIN agent_busy b ON t.agent_id = b.agent_id;

Target: 50-70% (cao quá → quá tải, thấp quá → lãng phí)

4.2 Active agents (DAU, MAU)¶

Định nghĩa: Số agent có ≥ 1 đơn completed trong period.

Daily: WHERE completed_at >= today_start Monthly: WHERE completed_at >= month_start

4.3 Agent rating average¶

Formula:

SELECT agent_id, AVG(rating) AS avg_rating, COUNT(*) AS cnt
FROM order_ratings
WHERE rated_at BETWEEN <from> AND <to>
GROUP BY agent_id;

4.4 Agent earnings¶

Per period:

SELECT 
 os.execution_agent_id,
 SUM(os.labor_price * (1 - commission_rate)) AS earnings
FROM order_steps os
WHERE os.status = 'completed'
 AND os.completed_at BETWEEN <from> AND <to>
GROUP BY os.execution_agent_id;

4.5 Agent acceptance rate¶

Định nghĩa: % đơn agent accept khi nhận invitation (vs decline/timeout).

Formula:

SELECT 
 agent_id,
 SUM(CASE WHEN response = 'accept' THEN 1 ELSE 0 END) * 100.0 / COUNT(*)
FROM dispatch_invitations
WHERE created_at BETWEEN <from> AND <to>
GROUP BY agent_id;

Note: agent có acceptance rate < 30% → flag for ops review (low engagement).

4.6 No-show rate¶

Định nghĩa: % đơn agent accept nhưng không đến.

Formula:

SELECT 
 agent_id,
 SUM(CASE WHEN no_show = TRUE THEN 1 ELSE 0 END) * 100.0 / total_assigned
FROM agent_performance
WHERE date BETWEEN <from> AND <to>;

Target: ≤ 1%

5. Partner metrics (Partner Squad)¶

5.1 Partner GMV¶

Định nghĩa: GMV của các đơn có source = partner_customer cho partner cụ thể.

Formula:

SELECT SUM(total_amount)
FROM orders
WHERE source = 'partner_customer'
 AND partner_id = <partner>
 AND current_stage IN ('09_completed', '10_rated')
 AND created_at BETWEEN <from> AND <to>;

5.2 Partner active rate¶

Định nghĩa: % partner có ≥ 1 đơn trong period (vs tổng active partners).

SELECT 
 SUM(CASE WHEN order_count > 0 THEN 1 ELSE 0 END) * 100.0 / COUNT(*)
FROM (
 SELECT p.id, COUNT(o.id) AS order_count
 FROM partners p
 LEFT JOIN orders o ON o.partner_id = p.id AND o.created_at BETWEEN <from> AND <to>
 WHERE p.status = 'active'
 GROUP BY p.id
) t;

5.3 Partner wallet health¶

Định nghĩa: % partner có balance < 7 ngày spending average (alert).

WITH partner_daily_spend AS (
 SELECT partner_id, AVG(daily_amount) AS avg_daily
 FROM (
 SELECT partner_id, DATE(created_at) AS d, SUM(total_amount) AS daily_amount
 FROM orders
 WHERE source = 'partner_customer'
 AND created_at >= NOW - INTERVAL 30 DAY
 GROUP BY partner_id, d
 ) t
 GROUP BY partner_id
)
SELECT 
 p.id, p.business_name, p.customer_config->>'$.wallet_balance' AS balance, 
 ds.avg_daily * 7 AS reserve_needed,
 CASE WHEN balance < ds.avg_daily * 7 THEN 'LOW' ELSE 'OK' END AS status
FROM partners p
JOIN partner_daily_spend ds ON ds.partner_id = p.id;

Trigger: nếu LOW → email partner_finance role với "Cần nạp ví"

5.4 Partner outstanding invoice¶

Formula:

SELECT partner_id, SUM(total_amount) AS outstanding
FROM partner_invoices
WHERE status IN ('sent', 'overdue')
GROUP BY partner_id;

5.5 Partner agent count¶

Formula:

SELECT 
 partner_id,
 SUM(CASE WHEN status = 'active' THEN 1 ELSE 0 END) AS active_count,
 COUNT(*) AS total_count
FROM agents
WHERE partner_id IS NOT NULL
GROUP BY partner_id;

6. Quality metrics (Quality Squad)¶

6.1 Average rating¶

Formula:

SELECT AVG(rating)
FROM order_ratings
WHERE rated_at BETWEEN <from> AND <to>;

Target: ≥ 4.5

6.2 Rating distribution¶

Formula:

SELECT rating, COUNT(*) 
FROM order_ratings
WHERE rated_at BETWEEN <from> AND <to>
GROUP BY rating;

6.3 NPS (Net Promoter Score)¶

Định nghĩa: % promoters (9-10) - % detractors (0-6) (giả định scale 0-10).

Note: SMP đang dùng scale 1-5 sao, chuyển đổi: - Promoters: 5 sao - Passives: 4 sao - Detractors: 1-3 sao

WITH t AS (
 SELECT 
 SUM(CASE WHEN rating = 5 THEN 1 ELSE 0 END) AS promoters,
 SUM(CASE WHEN rating <= 3 THEN 1 ELSE 0 END) AS detractors,
 COUNT(*) AS total
 FROM order_ratings
)
SELECT (promoters - detractors) * 100.0 / total AS nps FROM t;

Target: ≥ 50

6.4 Dispute rate¶

Formula:

SELECT COUNT(disputes) * 100.0 / total_orders
FROM ...

Target: ≤ 2%

6.5 Average dispute resolution time¶

Formula:

SELECT AVG(TIMESTAMPDIFF(HOUR, opened_at, resolved_at))
FROM disputes
WHERE resolved_at IS NOT NULL
 AND resolved_at BETWEEN <from> AND <to>;

Target: ≤ 48h

6.6 Free-form material rate¶

Định nghĩa: % step có free-form material (vs reserved).

Formula:

SELECT 
 SUM(CASE WHEN source = 'free_form' THEN 1 ELSE 0 END) * 100.0 / COUNT(*)
FROM order_step_materials
WHERE created_at BETWEEN <from> AND <to>;

Target: ≤ 10% (cao quá → BOM coverage kém)

6.7 Variance review rate¶

Định nghĩa: % BOM có actual khác > 5% expected.

Formula: tính từ comparison BOM expected vs actual per step.

7. Financial metrics (Finance Squad)¶

7.1 Cash collected vs receivable¶

Formula:

SELECT 
 SUM(CASE WHEN payment_status = 'paid' THEN total_amount ELSE 0 END) AS collected,
 SUM(CASE WHEN payment_status = 'pending' THEN total_amount ELSE 0 END) AS receivable
FROM orders
WHERE created_at BETWEEN <from> AND <to>;

7.2 Refund rate¶

Formula:

SELECT SUM(refund_amount) / SUM(total_amount) * 100.0
FROM orders WHERE ...;

7.3 Pending payouts to agents/partners¶

Formula:

SELECT SUM(net_amount) FROM partner_payouts WHERE status = 'pending';
SELECT SUM(amount) FROM agent_payouts WHERE status = 'pending';

7.4 Material margin¶

Formula:

SELECT 
 SUM((mv.sell_price - mv.cost_price_avg) * osm.quantity) AS total_margin
FROM order_step_materials osm
JOIN material_variants mv ON osm.material_variant_id = mv.id
WHERE osm.source = 'reserved'
 AND osm.step is completed
 AND period;

8. Technical metrics (Engineering)¶

8.1 API latency (p50, p95, p99)¶

Source: Prometheus Dashboard: Grafana

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

SLO targets: - Read endpoints: p95 < 300ms - Write endpoints: p95 < 500ms - Dispatch: p95 < 2s

8.2 Error rate (5xx)¶

sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

SLO: < 0.1%

8.3 Webhook delivery success rate¶

SELECT 
 SUM(CASE WHEN status = 'success' THEN 1 ELSE 0 END) * 100.0 / COUNT(*)
FROM webhook_delivery_log
WHERE sent_at BETWEEN <from> AND <to>;

8.4 Event log DLQ depth¶

Source: MongoDB count Alert: > 100 entries

8.5 Cache hit ratio¶

Source: Redis INFO Target: > 80% for cached endpoints

9. Dashboard mapping¶

Dashboard 1 · Executive overview (PM, Founder)¶

GMV (this month + last month + YoY if available)
Order count
Active customers
Top services by revenue
Top partners by GMV
Rating average + NPS

Dashboard 2 · Operations live (Ops Manager)¶

Orders in progress (by stage breakdown)
Stuck orders count + list
Active agents (online now)
Dispatch queue depth
Manual dispatch tasks
Pending material verifies

Dashboard 3 · Agent performance (Agent Squad)¶

Total agents · active vs pending KYC
DAU / MAU
Utilization distribution
Top performers (orders + rating)
Bottom performers (acceptance rate)

Dashboard 4 · Partner overview (Partner Squad)¶

Total partners · active
Partner GMV ranking
Wallet health alerts
Outstanding invoices
Recent KYC pending

Dashboard 5 · Quality (Quality Squad)¶

Rating average trend
Dispute count + resolution time
Free-form rate trend
BOM variance trend
Recent dispute list (open)

Dashboard 6 · Finance (Finance Squad)¶

Cash collected
Pending payouts
Material margin
Refund rate
Outstanding invoices aging

Dashboard 7 · Tech health (Engineering)¶

API latency
Error rate
Webhook delivery
DLQ depth
Pod CPU/RAM

10. Data pipeline¶

10.1 Real-time (Redis counters)¶

Orders count by status (TTL 24h)
Active agents (sets)
Dispatch queue depth

10.2 Near real-time (5-min aggregations)¶

Stuck orders alert
Webhook delivery success
Error rate

10.3 Hourly batch¶

Order completion rate
Average duration
Cancellation reasons breakdown

10.4 Daily batch (00:05)¶

GMV, NMV, SMP Revenue
Partner GMV, wallet health
Agent utilization, earnings
Material margin

10.5 Tooling¶

Prometheus for tech metrics
Custom Go cron jobs for business metrics → write to smp_analytics MySQL DB
Grafana queries smp_analytics for dashboards
Phase 2: dbt + ClickHouse for heavy analytics

10.6 · v4.0 architecture · CQRS Read Model¶

Quan trọng: từ v4.0, hầu hết dashboard queries chuyển sang Elasticsearch read model thay vì query MySQL primary trực tiếp. Lý do: scale + decouple workload analytic khỏi transactional.

10.6.1 Architecture diagram¶

┌─────────────────────────────────────────────────────────────────┐
│ WRITE SIDE (Commands) │
│ │
│ API → service → MySQL primary │
│ │ │
│ │ binlog │
│ ▼ │
│ ┌──────────┐ │
│ │ Debezium │ CDC connector │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ Kafka topics │ │
│ └────────┬───────┘ │
└───────────────────────┼─────────────────────────────────────────┘
 │
┌───────────────────────┼─────────────────────────────────────────┐
│ ▼ READ SIDE (Queries) │
│ ┌────────────────┐ │
│ │ ES sink │ (Kafka Connect) │
│ │ Connector │ │
│ └────────┬───────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ Elasticsearch │ ◄── read model │
│ │ indices: │ │
│ │ orders-YYYY-MM│ (daily, denormalized) │
│ │ agents │ │
│ │ partners │ │
│ │ dispatch-runs │ │
│ └────────┬───────┘ │
│ │ │
│ ┌──────────────┼──────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌──────────┐ ┌──────────┐ │
│ │Grafana │ │Admin UI │ │Reports │ │
│ │dashboard│ │analytics │ │CSV/Excel │ │
│ └─────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────┘

10.6.2 Query routing matrix¶

Cập nhật cách truy vấn từng metric:

Metric category	v3.x source	v4.0 source	Latency	Fallback
Real-time counts (Section 3.6 Stuck orders)	MySQL primary	Redis (unchanged)	<100ms	n/a
Hourly aggs (Section 3.1 Completion rate)	MySQL replica	Elasticsearch	1-5s lag	MySQL replica
Daily aggs (Section 2.1 GMV)	MySQL replica + cron	Elasticsearch + scheduled refresh	1-5s lag	MySQL replica
Search queries (Customer support find order)	MySQL LIKE	Elasticsearch full-text	50-200ms	MySQL LIKE (slow)
Map visualizations (heatmap orders by district)	MySQL geospatial	Elasticsearch geo_point	<500ms	n/a
Financial reports (Section 7.x)	MySQL primary (auditable)	MySQL primary (unchanged)	n/a	n/a

Note: Financial reports KHÔNG migrate sang ES vì cần exact consistency cho audit. Eventual consistency 1-5s không acceptable cho accounting close.

10.6.3 Sample queries · before/after¶

Example 1: GMV by district (Section 3.x)

-- ❌ v3.x: SQL on MySQL replica
SELECT
 district,
 SUM(total_amount) AS gmv,
 COUNT(*) AS order_count
FROM orders
WHERE completed_at_utc >= DATE_SUB(NOW, INTERVAL 1 DAY)
 AND status = 'paid'
GROUP BY district
ORDER BY gmv DESC;
-- ~3-5 seconds with 1M orders

// ✅ v4.0: Elasticsearch aggregation
POST /orders-*/_search
{
 "size": 0,
 "query": {
 "bool": {
 "filter": [
 {"range": {"completed_at_utc": {"gte": "now-1d/d"}}},
 {"term": {"status": "paid"}}
 ]
 }
 },
 "aggs": {
 "by_district": {
 "terms": {"field": "district", "size": 100, "order": {"gmv": "desc"}},
 "aggs": {
 "gmv": {"sum": {"field": "total_amount"}}
 }
 }
 }
}
// ~200-500ms với same data

Example 2: Order full-text search (admin support)

-- ❌ v3.x: MySQL LIKE on multiple columns
SELECT * FROM orders
WHERE customer_name LIKE '%nguyen%'
 OR address_line LIKE '%nguyen%'
 OR notes LIKE '%nguyen%'
ORDER BY created_at DESC LIMIT 50;
-- 2-5 seconds, no index usage

// ✅ v4.0: Elasticsearch multi_match
POST /orders-*/_search
{
 "query": {
 "multi_match": {
 "query": "nguyen",
 "fields": ["customer_name^3", "address_line", "notes"],
 "fuzziness": "AUTO"
 }
 },
 "sort": [{"created_at_utc": "desc"}],
 "size": 50
}
// 50-100ms với analyzer + inverted index

10.6.4 Eventual consistency · UX guidance¶

Dashboard hiển thị data lag indicator: - Lag < 5s: "Real-time" badge (green) - Lag 5-60s: "Updated X seconds ago" (yellow) - Lag > 60s: Banner "Data may be stale - last sync: HH:MM" + fallback to MySQL replica - Lag > 5min: Critical alert, page on-call

Critical UX rule: không hiển thị dashboard mà không có lag indicator — user phải biết data tươi/cũ thế nào.

10.6.5 Elasticsearch index design¶

Daily rolling indices cho orders:

orders-2026-05-28 ← hot (today, write + read)
orders-2026-05-27 ← hot (yesterday)
orders-2026-05-26 ← warm (older, read-only)
...
orders-2026-04-* ← warm → cold tier

Index template (Elasticsearch):

PUT /_index_template/orders-template
{
 "index_patterns": ["orders-*"],
 "template": {
 "settings": {
 "number_of_shards": 3,
 "number_of_replicas": 1,
 "refresh_interval": "5s"
 },
 "mappings": {
 "properties": {
 "order_id": {"type": "keyword"},
 "customer_id": {"type": "keyword"},
 "customer_name": {
 "type": "text",
 "fields": {"keyword": {"type": "keyword"}}
 },
 "country_code": {"type": "keyword"},
 "currency": {"type": "keyword"},
 "total_amount": {"type": "long"},
 "status": {"type": "keyword"},
 "district": {"type": "keyword"},
 "city": {"type": "keyword"},
 "location": {"type": "geo_point"},
 "created_at_utc": {"type": "date"},
 "completed_at_utc": {"type": "date"}
 }
 }
 }
}

ILM (Index Lifecycle Management): - Hot phase: 7 days, fast SSD, write enabled - Warm phase: 60 days, slower disks, read-only, force_merge - Cold phase: 1 year, archive, very slow access - Delete phase: > 1 year, auto-delete

10.6.6 Failover¶

Primary path: Service → ES query
 ▼ if ES down
Fallback path: Service → MySQL replica
 ▼ if also down
Emergency: Service → return cached snapshot (1h old) + alert

Circuit breaker pattern: nếu ES timeout > 3 lần trong 1 phút, mở circuit, route 100% traffic sang MySQL fallback trong 30s.

11. Validation¶

Cuối tháng, Finance đối chiếu: - SMP Revenue formula (Section 2.3) vs accounting books - Pending payouts (Section 7.3) vs bank statements - GMV vs invoice totals

Bất kỳ discrepancy > 1% → investigate + fix formula or data pipeline.

12. Change management¶

Khi đổi formula 1 metric: 1. Tạo PR với new formula + old formula side-by-side comparison 2. Test trên historical data 30 ngày 3. PM + Finance approve 4. Deploy + recalculate historical metrics 5. Notify all dashboard users 6. Document change in this doc + changelog