Bahis Operatörü için KPI Takibi: Hangi Metrikleri İzlemeli?

Her şeyi ölçen bir ekip çoğu zaman hiçbir şeyi yönetemez. KPI takibinde amaç çok sayıda grafik üretmek değil, karar vermeni sağlayacak birkaç metriği düzenli ve tutarlı biçimde izlemektir. Bu yazıda bir bahis operasyonu için anlamlı operasyonel ve finansal metrikleri, her birinin nasıl hesaplandığını ve LLCBullet verisini kendi KPI tablona nasıl aktarabileceğini anlatıyoruz.

İyi bir KPI'ın özellikleri

• Tanımı nettir: Kim hesaplarsa hesaplasın aynı sonucu verir. "Erişilebilirlik" derken hangi siteleri, hangi zaman aralığını ve hangi kontrol sonucunu kastettiğin yazılıdır.
• Aksiyona bağlıdır: Metrik kötüleştiğinde ne yapacağın bellidir. Kimsenin davranışını değiştirmeyen bir sayı KPI değil, süstür.
• Düzenli ölçülür: Aynı kaynaktan, aynı sıklıkta toplanır; böylece dönemler birbiriyle karşılaştırılabilir.
• Sahibi vardır: Her metriğin takibinden sorumlu bir kişi ya da ekip bellidir.

Operasyonel metrikler

Erişilebilirlik oranı

Belirli bir dönemde yapılan kontrollerden kaçının erişilebilir sonuç verdiğini gösterir. Formülü basittir: erişilebilir kontrol sayısı bölü toplam kontrol sayısı. Oranı site, altyapı ve dönem bazında ayrı ayrı izlemek, sorunun nerede yoğunlaştığını gösterir.

Yanıt süresi

Ortalama tek başına yanıltıcı olabilir; birkaç çok yavaş yanıt ortalamayı fazla etkilemez ama kullanıcı deneyimini bozar. Mümkünse ortalamanın yanında yüzdelik değerleri, örneğin en yavaş yüzde beşlik dilimi de takip et.

Tespit ve çözüm süresi (MTTD ve MTTR)

MTTD, bir sorunun başlamasından fark edilmesine kadar geçen ortalama süredir; MTTR ise fark edilmesinden çözülmesine kadar geçen süre. Tespit süresini büyük ölçüde kontrol sıklığın belirler: her 30 dakikada bir çalışan bir kontrol, bir kesintiyi en kötü durumda yarım saat geç fark eder. Yani kontrol aralığını seçmek aslında tespit süresi hedefini seçmektir. Ayrıntılar için site kontrol sıklığı yazımıza bakabilirsin.

Görev başarı oranı

Otomasyonun kendisinin sağlıklı çalışıp çalışmadığını gösterir. Başarısız görev oranı yükseliyorsa diğer operasyonel metriklerin güvenilirliği de düşer, çünkü ölçüm aracın eksik veri üretiyordur. Bu metriği erişilebilirlik oranıyla karıştırma: erişilemeyen site bulan bir kontrol görevi başarısız sayılmaz, işini yapmış ve sorunu tespit etmiştir.

Ödeme başarı oranı

Başlatılan ödemelerden kaçının tamamlandığını gösterir. Düşüş genellikle bir ödeme sağlayıcısındaki soruna, yanlış ağ seçimi gibi kullanıcı hatalarına ya da ödeme ekranındaki bir tasarım sorununa işaret eder. Oranı ödeme yöntemi ve kripto tarafında ağ bazında ayrı izlemek, sorunun kaynağını daraltır.

Finansal metrikler

• GGR (brüt oyun geliri): Alınan bahisler eksi ödenen kazançlar.
• NGR (net oyun geliri): GGR'dan bonuslar, promosyonlar ve anlaşmana göre vergi gibi kalemler düşüldükten sonra kalan tutar.
• Aktif oyuncu başına gelir: Dönem geliri bölü aktif oyuncu sayısı; büyümenin kalitesini gösterir.
• Müşteri edinme maliyeti: Pazarlama harcaması bölü yeni oyuncu sayısı. Ayrıntılar müşteri edinme maliyeti yazımızda.
• Kesintinin gelire etkisi: Erişilemeyen sürelerin gelire yansıması; hesaplama yöntemi için downtime maliyeti yazımıza göz at.

LLCBullet verisini KPI tablona taşımak

LLCBullet finansal metrik üretmez; ancak operasyonel tarafın ham verisini üç yoldan sağlar:

• Rapor görevi: Günlük ya da haftalık özetini Telegram'a gönderir: çalıştırma sayıları, site kontrolleri, erişilebilirlik oranı ve en yakın paket bitişi.
• İstatistikler bölümü: Otomasyon sayfasında görevlerinin altyapı bazında başarı oranlarını ve yanıt sürelerini gösterir.
• Webhook görevi: Belirlediğin zamanlamayla site listesini imzalı JSON olarak kendi sunucuna gönderir; veriyi kendi veritabanında saklayıp istediğin gibi hesaplarsın.

Webhook gövdesindeki her site kaydı kimlik, ad, durum (up, down ya da unknown) ve milisaniye cinsinden yanıt süresi içerir. Her teslimat, o anki son durumların bir anlık görüntüsüdür. Aşağıdaki örnek, gelen bir teslimattan altyapı bazında erişilebilirlik oranı ve ortalama yanıt süresi çıkarır:

// payload: imzası doğrulanmış webhook gövdesi
export function summarize(payload) {
  const checked = payload.sites.filter((s) => s.status !== "unknown");
  const up = checked.filter((s) => s.status === "up");
  const latencies = up
    .map((s) => s.latencyMs)
    .filter((ms) => typeof ms === "number");
  const avgLatencyMs = latencies.length
    ? Math.round(latencies.reduce((a, b) => a + b, 0) / latencies.length)
    : null;
  return {
    infrastructure: payload.infrastructure,
    at: payload.scheduledFor,
    availability: checked.length ? up.length / checked.length : null,
    avgLatencyMs,
  };
}

Bu özetleri zaman damgasıyla sakladığında günlük ve haftalık oranları, hatta bir sitenin ilk kez "down" göründüğü an ile yeniden "up" olduğu an arasındaki süreyi kendin hesaplayabilirsin. İmzanın nasıl doğrulanacağı webhook rehberinde anlatılıyor.

Hedefleri nasıl belirlemeli?

Sektörde dolaşan hazır hedef rakamları yerine kendi geçmiş verinle başla. İlk birkaç haftayı yalnızca ölçüm için kullan, mevcut seviyeni gör, sonra ulaşılabilir bir iyileşme hedefi koy. Hedefi dönem sonunda gözden geçir; altyapı sayın, kontrol sıklığın ya da site portföyün değiştiyse hedefin de değişmelidir.

Haftalık KPI gözden geçirme rutini

Metrikler ancak düzenli konuşulduğunda davranışa dönüşür. Kısa ve sabit gündemli bir haftalık toplantı çoğu ekip için yeterlidir:

1. Geçen haftanın erişilebilirlik oranını ve yanıt süresini altyapı bazında önceki haftalarla karşılaştır.
2. Hafta içinde yaşanan kesintileri tek tek listele; her biri için tespit ve çözüm süresini not et.
3. Başarısız ya da atlanan görev çalıştırmalarının nedenlerini gözden geçir.
4. Finansal metriklerdeki sapmaları operasyonel olaylarla eşleştir; bir gelir düşüşü bir kesintiyle aynı güne denk geliyor mu?
5. Bir sonraki hafta için en fazla iki somut aksiyon belirle ve her birine sorumlu ata.

Sık yapılan hatalar

• Bakım dönemlerini hesaba katmamak: bakımdaki siteler kontrol dışı kaldığı için bu dönemleri raporunda ayrıca işaretle.
• "unknown" kayıtlarını erişilemez saymak: bu kayıtlar henüz kontrol edilmemiş ya da izlenmeyen siteleri gösterebilir.
• Tek haftalık veriden sonuç çıkarmak: kısa dönemler tesadüfi dalgalanmalara açıktır.
• Çok fazla KPI tanımlamak: düzenli toplantılarda konuşulmayan metrik, zamanla kimsenin bakmadığı bir sayıya dönüşür.

Panelde rapor görevi kur