Bahis Yazılımında Ölçülmesi Gereken 7 Performans Göstergesi

Panelin başına geçtiğimde ilk baktığım şey reklam harcaması ya da kampanya takvimi değil; operasyonun gerçek sağlığını gösteren ham veriler. Yıllardır orta ölçekli bir bahis operatöründe ürün tarafında çalışıyorum ve şunu net söyleyebilirim: bahis yazılımı seçimi, bir tedarikçi ilişkisi değil, doğrudan kâr marjınızı belirleyen bir finansal karardır. Bu yazıda, bir bahis yazılımı tedarikçisinden talep etmeniz gereken yedi performans göstergesini, kabul edilebilir aralıkları ve kırmızı bayrak eşiklerini paylaşacağım. Değerlendirme sürecinde PlaybetAi gibi turnkey ve white label çözümler sunan sağlayıcıların teknik dokümantasyonu, bu metriklerin hangi sıklıkta ve hangi granülerlikte raporlanabildiğini görmek açısından iyi bir başlangıç noktası oluyor.

1. Bahis Motoru Gecikmesi (Bet Placement Latency)

Bir kullanıcının kuponu onayladığı an ile sistemin bahsi kabul ettiği an arasındaki süre, operatörün en görünmez ama en pahalı metriğidir. Ben bu metriği iki katmanda ölçüyorum: ortalama gecikme ve 95. yüzdelik dilim (p95). Ortalama değer sizi yanıltır; çünkü bir maçın son dakikasında yaşanan 400 ms’lik bir gecikme, günün ortalamasını bozmaz ama o dakikadaki dönüşümü yok eder.

Benchmark olarak, Avrupa merkezli sunuculardan hizmet veren bir altyapıda p95 değerinin 250 ms’nin altında kalması beklenir. 400 ms’nin üzeri sarı alarm, 700 ms’nin üzeri ise kırmızı bayraktır. Kırmızı bayrak durumunda kullanıcı “bahis alınamadı” hatası görür, tekrar dener, bazen iki kez bahis oynar ve ardından müşteri hizmetlerine iade talebi gelir. Bu döngünün maliyeti hem işlem ücreti hem de güven kaybıdır. Tedarikçi sözleşmesine bu metrik için bir SLA maddesi koymak, sonradan yaşanan tartışmaların çoğunu ortadan kaldırır.

2. Oran Güncelleme Gecikmesi ve Veri Akışı Tazeliği

Oran beslemesi (odds feed) gecikmesi, bahis motoru gecikmesinden farklı bir sorundur ve çoğu operatör bunu karıştırır. Motor hızlıdır ama oran 12 saniye geç geliyorsa, kullanıcı canlı bahis sekmesinde eski fiyatı görür. Bu da ya arbitraj fırsatı yaratan kullanıcıların sistemi sömürmesine ya da tam tersi, doğru fiyatlanmış fırsatları kaçırmanıza yol açar.

Ölçüm yöntemim basit: veri sağlayıcının zaman damgası ile bizim veritabanına yazılan zaman damgası arasındaki farkı sürekli loglarım. Popüler futbol liglerinde bu fark 2 saniyenin altında olmalı. 5 saniyeyi geçtiğinde canlı bahis marjınız matematiksel olarak bozulmaya başlar. 10 saniyenin üzeri, artık canlı bahis ürününüzü sunmamanız gerektiği anlamına gelir. Turnkey bir çözümde bu katman genellikle hazır gelir; white label modelinde ise hangi feed sağlayıcısının kullanıldığını ve yedek feed’in otomatik devreye girip girmediğini mutlaka sorun.

3. Eşzamanlı Kullanıcı Kapasitesi ve Yük Altında Davranış

“Sistemimiz 10.000 eşzamanlı kullanıcıyı kaldırır” cümlesi tek başına anlamsızdır. Doğru soru şudur: 10.000 kullanıcı yükü altında bahis motoru gecikmesi kaç ms’ye çıkıyor? Büyük bir derbi maçının ilk 15 dakikasında trafik normalin sekiz katına çıkar. Bu pencerede sistemin davranışı, yılın geri kalanındaki performanstan daha önemlidir.

Talep etmeniz gereken şey bir yük testi raporu değil, gerçek trafik verisiyle yapılmış bir kapasite analizidir. Benchmark: tepe yükün 1,5 katında sistem çökmeden, gecikme en fazla iki katına çıkarak yanıt vermeli. Tepe yükte %5’in üzerinde hata oranı (5xx yanıtları) görüyorsanız, altyapı otomatik ölçeklendirme yapmıyor demektir. Bu, kırmızı bayraktır ve genellikle turnkey sağlayıcının sunucu mimarisinin tek bölgeye bağımlı olduğunu gösterir.

4. Ödeme İşlem Süresi ve Finans Yönetimi Doğruluğu

Finans yönetimi, bahis yazılımının en az konuşulan ama en çok şikâyet üreten modülüdür. Burada iki metriği ayrı ayrı izliyorum: para yatırma onay süresi ve para çekme işlem süresi. Kullanıcı açısından ikincisi çok daha kritik; çünkü çekim gecikmesi doğrudan güven kaybına ve dolayısıyla churn oranına yansır.

Kabul edilebilir aralık: otomatik onaylı çekimlerde 5 dakikanın altı, manuel inceleme gerektiren durumlarda 4 saatin altı. 24 saati aşan çekimler, operatörün ödeme sağlayıcı entegrasyonunda ya da mutabakat (reconciliation) sürecinde sorun olduğunu gösterir. Daha da önemlisi, finans modülünün çift kayıt (double-entry) mantığıyla çalışıp çalışmadığını sorun. Günlük mutabakat farkı %0,1’in üzerindeyse, muhasebe ekibiniz her ay ekstra mesai yapıyor demektir. Slot oluşturucu ve jackpot yönetimi gibi modüller de bu finans katmanına bağlanır; jackpot havuzlarının gerçek zamanlı doğru hesaplanması, ayrı bir denetim kalemi olarak ele alınmalıdır.

5. Oyun ve Slot Yükleme Süresi

Casino tarafında kullanıcı sabrı bahis tarafından daha kısa. Bir slot oyununun açılması 3 saniyeyi geçtiğinde, mobil kullanıcıların önemli bir kısmı oyunu kapatıp başka bir sağlayıcıya geçiyor. Bu metriği oyun bazında ölçmek gerekiyor; çünkü ağır grafikli tek bir oyun, tüm kategorinin ortalamasını aşağı çekebilir.

Benchmark: ilk anlamlı boyama (first contentful paint) 1,5 saniyenin altında, oyun tamamen etkileşime hazır hâle 2,5 saniyede gelmeli. 4 saniyenin üzerindeki oyunları katalogdan çıkarmak ya da sağlayıcıdan optimize edilmiş sürüm talep etmek gerekir. Slot oluşturucu araçlarıyla kendi oyunlarınızı üretiyorsanız, bu metrik doğrudan sizin geliştirme kalitenizin göstergesidir. Varlık boyutları, sprite atlasları ve önbellekleme stratejisi burada belirleyici olur.

6. API Yanıt Süreleri ve Entegrasyon Kararlılığı

CRM, bonus motoru, risk yönetimi ve raporlama araçları bahis yazılımına API üzerinden bağlanır. Bu API’lerin yanıt süresi, operasyon ekibinizin günlük iş hızını belirler. Bir bonus kampanyasını 40.000 kullanıcıya uygulamak istediğinizde, API’nin toplu işlem (bulk operation) desteği olup olmadığı kritik hâle gelir.

Ölçüm: tek kayıt okuma istekleri 100 ms altında, toplu yazma işlemleri saniyede en az 500 kayıt hızında olmalı. API hız sınırı (rate limit) dokümantasyonunun net olmaması kırmızı bayraktır; çünkü bu genellikle altyapının beklenmedik yüklerde çöktüğünün işaretidir. Ayrıca webhook tabanlı olay bildirimlerinin (bahis kazanma, çekim talebi, jackpot tetiklenmesi) kayıp yaşamadan iletilip iletilemediğini test edin. En az bir kez yeniden deneme (retry) mekanizması ve idempotency anahtarı olmalı.

7. Uptime, Hata Oranı ve Olay Müdahale Süresi

Yıllık %99,9 uptime kulağa iyi gelir ama yılda 8,7 saat kesinti demektir. Bu kesintinin cumartesi akşamı bir derbi sırasında mı yoksa salı sabahı mı yaşandığı, finansal etkiyi on kat değiştirir. Bu yüzden uptime’ı tek bir yüzde olarak değil, zaman dilimine göre ayrıştırılmış olarak talep ediyorum.

Asıl ayırt edici metrik ise olay müdahale süresi (MTTR). Bir kesinti başladığında tedarikçinin tespit süresi 5 dakikanın altında, ilk müdahale 15 dakikanın altında olmalı. 30 dakikayı aşan tespit süreleri, izleme (monitoring) altyapısının yetersiz olduğunu gösterir. Sözleşmede bu metrikler için finansal yaptırım maddesi olup olmaması, tedarikçinin kendi altyapısına ne kadar güvendiğinin en dürüst göstergesidir. PlaybetAi gibi sağlayıcılarla görüşürken bu SLA maddelerini doğrudan talep etmek, değerlendirmeyi pazarlama sunumundan teknik gerçekliğe taşır.

Metrikleri Satın Alma Kararına Dönüştürmek

Bu yedi metriği bir tabloya döktüğünüzde, tedarikçi karşılaştırması öznellikten çıkar. Her satıra bir benchmark, bir sarı alarm ve bir kırmızı bayrak eşiği yazın; ardından her adaydan bu değerleri yazılı olarak isteyin. Sözlü olarak “çok hızlıyız” diyen herkes, sayı istediğinizde ya susar ya da belirsiz aralıklar verir.

Kendi operasyonumuzda bu yaklaşımı uyguladığımızda, ilk aşamada cazip görünen iki tedarikçiyi elemek zorunda kaldık; çünkü p95 gecikme verilerini paylaşamadılar. Buna karşılık turnkey ve white label modellerini net SLA’larla sunan sağlayıcılar, teknik ekibinizin yükünü de ciddi biçimde azaltıyor. Doğru soru “hangi yazılım en çok özelliğe sahip” değil; “hangi yazılım en kötü senaryoda nasıl davranıyor” sorusudur. Çünkü kârınız, sistemin en iyi gününde değil, en yoğun gecesinde belirlenir.