---
title: "Provider Health Scoring Model"
description: "Travel supplier'larını latency, success, freshness, price accuracy ve commercial quality sinyalleriyle ölçen explainable health score tasarlayın."
slug: "provider-health-scoring-model"
translationKey: "architecture-provider-health-scoring"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["provider","health-score","reliability","price-accuracy","observability"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

Provider health score, “bu supplier iyi mi?” sorusuna tek sayı vermek için değil, **routing, fallback ve operasyon kararlarını tutarlı sinyallerle desteklemek** için kullanılmalıdır.

## Production senaryosu

Bir provider hızlı ama price mismatch oranı yüksek; diğeri yavaş ama çok güvenilir; üçüncüsü belirli markette sık timeout oluyor. Tek latency metriği yeterli değildir.

## Score boyutları

Örnek:

| Boyut | Sinyal |
|---|---|
| Availability | success / timeout / 5xx |
| Latency | p50/p95 |
| Freshness | stale-offer rate |
| Accuracy | price mismatch |
| Handoff | unavailable-after-click |
| Coverage | usable offers/search |
| Commercial | conversion feedback varsa CVR/net value |

## Tek score nasıl hesaplanır?

Her metriği normalize edin ve ağırlıkları use case'e göre belirleyin.

```text
Health =
  0.25 Reliability
+ 0.20 Latency
+ 0.20 PriceAccuracy
+ 0.15 Freshness
+ 0.10 Coverage
+ 0.10 HandoffQuality
```

Bu sadece örnektir; ağırlıklar business contract değildir.

## Global score hatası

Provider performansı market, endpoint ve saat bazında değişebilir. Tek global score yerine:

- provider × market,
- provider × endpoint,
- provider × vertical

gibi segmentler gerekebilir.

## Hysteresis

Bir dakikalık spike yüzünden provider'ı kapatmayın. Score düşüş/iyileşme için farklı threshold ve minimum observation window kullanın.

## Routing'de kullanım

Health score:
- eligibility,
- traffic weight,
- fallback order,
- circuit-breaker input

olarak kullanılabilir.

Ama ranking'de commercial bias'a dönüşmemelidir. Traveler-facing ranking kuralı ayrı ve açıklanabilir olmalıdır.

## Failure modes

- düşük sample ile score oynaklığı,
- bir metriğin tüm score'u domine etmesi,
- recovery'nin çok yavaş olması,
- commercial KPI'ın technical health'e karışması,
- provider'ın yeni markette haksız cezalandırılması.

## Observability

Score'un yalnız sonucunu değil component breakdown'ını gösterin. Operator “62” yerine neden 62 olduğunu görmelidir.

## Alternatifler

Az provider varsa basit red/amber/green health state yeterli olabilir. Weighted score daha çok routing seçeneği ve heterojen kalite olduğunda anlamlıdır.

## Production checklist

- metric normalization
- minimum sample
- rolling window
- hysteresis
- segmented score
- component visibility
- manual override audit
- routing/ranking separation