Makine Öğrenimi ile Müşteri Terk Analizi: Mimari ve Tanı

Makine Öğrenimi ile Müşteri Terk (Churn) Analizi: Tanılama, Mimari ve Çözüm Yaklaşımı

Giriş

Endüstriyel ölçekte çalışan SaaS ve telekom servisleri gibi sistemlerde müşteri terk (churn) analizi, operasyonel kararların doğrudan kârlılığa etkilediği bir alandır. Saha deneyimim, müşteri davranışı sinyallerinin üretim hattı sensör verilerinden daha titiz bir şekilde ele alınması gerektiğini gösterdi: verideki gecikme, bağlam kaybı ve etik sınırlamalar karar kalitesini etkiliyor.

Operasyonel risk; yanlış tahminlerin müşteri sadakatini bozması, gereksiz promosyon maliyetleri ve destek yükünü artırmasıdır. Bir modelin üretimde yanlış alarmlar (%false positive) veya gözden kaçan churn vakaları (%false negative) yaratması, aylık gelirde iki haneli yüzdelere kadar dalgalanmaya sebep olabilir.

Bu yazıda hem mimari hem de pratik tanılama yöntemlerini, ölçülebilir parametrelerle ve saha davranışı örnekleriyle sunuyorum. Amaç; saha mühendisleri, veri mühendisleri ve ML uygulayıcılarının, gerçek üretim koşullarında tekrarlanabilir ve ölçülebilir sonuçlar almasıdır.

Unutmayın: Tahmin doğruluğu tek başına yeterli değildir — gecikme, model tazeliği ve izlenebilirlik üretim başarısında eşit derecede kritiktir.

Kavramın Net Çerçevesi

Müşteri terk analizi, bir müşterinin belirli bir zaman penceresinde ürünü veya servisi kullanmayı bırakma olasılığını tahmin eden bir sistemdir. Ölçülebilir sınırlar; tahmin periyodu (ör. 30 gün), doğruluk metrikleri (AUC, precision, recall) ve işletme sınırlamaları (örn. aylık kampanya bütçesi) ile belirlenir.

Sistem bileşenleri tipik olarak veri toplama pipeline'ı, özellik mühendisliği katmanı, çevrimiçi/çevrimdışı model servisleri ve karar katmanından oluşur. Bu katmanlar arasındaki kayma (feature drift) veya gecikme (feature freshness) başarımı doğrudan etkiler. Örneğin, bir telekom operatöründe özelliğin tazeliği 10 dakikayı aştığında gerçek terk tespitinde %15 sapma gözlenebilir.

Churn analizi, zaman pencereleri ve iş kuralları ile tanımlanmış bir tahmin problemidir; başarılı uygulama veri gecikmesini, özellik tutarlılığını ve model izlemeyi eş zamanlı yönetir.

Model performansını iş metriklerine bağlamak zorunludur: yüksek AUC iş değeri garantilemez; geri kazanım (retention uplift) yüzde puanları ile raporlanmalıdır.

Kritik Teknik Davranışlar ve Risk Noktaları

1) Veri Gecikmesi ve Özellik Tazeliği

Veri pipeline'larında meydana gelen gecikmeler, online skorlamada yanlış veya gecikmiş sinyaller üretir. Özellikle streaming olmayan ETL süreçlerinde feature freshness 30 dakikadan fazla olduğunda gerçek zamanlı müdahaleler etkisiz kalır.

İki ölçülebilir parametre: veri pipeline gecikmesi (ms veya dakika), feature freshness süresi (dakika). Örnek saha davranışı: CRM güncellemesi ile model girdisi arasında 45 dakikalık fark olması, kampanya hedeflemesinde %12 daha düşük geri kazanım oranına neden olur.

Ölçüm yöntemi: log korelasyonu ile olay zaman damgalarının karşılaştırılması ve per-kaynak histogram analizi. Aşağıdaki beş adımlık liste uygulanabilir:

• Pipeline gecikmesini ölçmek için tüm kritik olaylara ingest ve işlem zaman damgası ekleyin (ms hassasiyet).
• Feature freshness SLA'sı belirleyin (örn. <5 dakika) ve buna göre uyarı tanımlayın.
• Shadow scoring ile gecikmeli özelliklerin model çıktısına etkisini karşılaştırın.
• Akış bazlı (stream) değişiklikleri micro-batch'e çevirip gecikmeyi benchmark edin (ör. 1, 5, 15 dakikada TPS ölçümleri).
• Özellik çekiminde cache tutma oranını ve cache staleness süresini (saniye/dakika) düzenli raporlayın.

2) Model Performans Bozulmaları ve Drift

Modellerin üretimde performans kaybetmesi genellikle veri dağılımındaki değişikliklerden kaynaklanır. Aylık drift oranı %2–%5 seviyelerinde bile uzun vadede anlamlı gelir kayıplarına dönüşebilir.

İki ölçülebilir parametre: model AUC/ROC, haftalık veri dağılım farkı (% JS divergence veya KL divergence). Örnek saha davranışı: ödeme yöntemlerinde yeni bir girişim sonrası ödemeye dayalı churn sinyallerinde haftalık yüzde 7 değişim gözlenebilir.

Ölçüm yöntemi: histogram karşılaştırmaları ve cohort analizi ile giriş özelliklerinin istatistiksel sapmasını takip edin. Uygulanabilir adımlar:

• Her model için günlük ve haftalık AUC, precision ve recall raporu oluşturun.
• Feature distribution monitoring kurun; JS divergence eşiği belirleyin (örn. 0.05 üzerinde alarm).
• Shadow model çalıştırarak yeni ve eski modellerin skor farkını yüzdelik bazda ölçün.
• Model geri çağrma (roll-back) stratejisini canary dağıtımla test edin; canary %1 trafikle başlatın.
• Veri sürümlerini (data schemas) immutable olarak saklayın; schema change detection ile pipeline kırılmalarını önleyin.

3) Tahmin Gecikmesi ve Servis SLA'ları

Gerçek zamanlı uygulamalarda tahmin gecikmesi doğrudan kullanıcı deneyimini etkiler. Örneğin online scoring latency'nin 50ms'i geçmesi, mikroservis mimarisinde çağrı zincirini uzatır ve 3. taraf hizmetlerde zaman aşımına (timeout) yol açar.

İki ölçülebilir parametre: p95 tahmin latansı (ms), model servis throughput (TPS). Örnek saha davranışı: peak saatlerde p95 latency 180ms'e çıktığında öneri motoru geri çağırma oranı %8 artar.

Ölçüm yöntemi: load test ve dağıtılmış tracing kullanarak uçtan uca latency ölçümü. Uygulanabilir adımlar:

• Model servislerini p95 ve p99 latency SLA'sı ile dağıtın (örn. p95 < 50ms, p99 < 200ms).
• Batch scoring ihtiyacını belirleyin; online ihtiyacı yoksa batch ile maliyeti düşürün (ör. günlük 300 TPS yerine gece 20 TPS ile çalıştırma).
• Modelı hafifletmek için quantization veya distillation uygulayın ve latency kazanımını ölçün (% latency düşüşü hedefi verin).
• Caching katmanı ekleyerek yüksek frekanslı skorların %70'ini cache'den servis edin.
• Otomatik ölçeklendirme (autoscale) kuralları ile peak TPS artışında tepki süresini 60 saniyenin altına indirin.

4) Karar Katmanı ve İş Kurallarının Uyumsuzluğu

Model çıktısının iş kurallarıyla uyumsuzluğu, yanlış müdahalelere veya maliyet-fayda dengesizliğine sebep olur. Modelin önerdiği hedeflemeler, iş kuralı limiti (ör. aylık promosyon bütçesi) tarafından filtrelenmediğinde maliyet kontrolden çıkar.

İki ölçülebilir parametre: kampanya maliyeti sapması (%), eylem dönüşüm oranı (conversion %). Örnek saha davranışı: model yüksek churn riskli 10k kullanıcı önerirken iş kuralı bütçeyi 3k kullanıcı ile sınırlıyorsa, yanlış önceliklendirme nedeniyle beklenen churn azalma hedefinin %40'ı kaçabilir.

Ölçüm yöntemi: log korelasyonu ile model önerileri ve uygulanan eylemler arasındaki farklılığı ölçün; A/B test ile iş kuralı etkisini izole edin. Uygulanabilir adımlar:

• Model kararlarını iş kurallarına bağlayan bir karar motoru uygulayın; kurallar versiyon kontrollü olsun.
• Her müdahale için maliyet ve beklenen fayda (expected uplift) hesaplayın; ROI eşiği belirleyin.
• A/B testler ile model müdahalesinin gerçek geri kazanımı ölçülsün (ör. beklenen uplift hedefi %2 puan artırma).
• Müdahale önceliklendirmesi için skor+cost fonksiyonu geliştirin; günlük optimizasyon uygulayın.
• Geribildirim döngüsü kurarak uygulama sonucu etiketlerini model eğitimine geri besleyin (label latency < 24 saat hedefi).

5) İzlenebilirlik, Denetim ve Gizlilik Uyumluluğu

Churn modelleri müşteri verisi kullandığından izlenebilirlik ve GDPR/KVKK uyumluluğu kritik önemdedir. Veri erişim logları olmadan hatalı kararların kök nedenini saptamak imkansızlaşır.

İki ölçülebilir parametre: erişim kayıtlarının kapsama oranı (%), denetim sorgularına yanıt süresi (saniye/dakika). Örnek saha davranışı: bir kampanya sonrası itirazlarda adli inceleme gerektiğinde, sadece %60 erişim logu mevcutsa hata kök nedeninin tespiti günler sürebilir.

Ölçüm yöntemi: log korelasyonu ve veri erişim audit trail analizi. Uygulanabilir adımlar:

• Her model skoruna ilgili veri ve özellik versiyon kimliği ekleyin; bu referans immutable olmalıdır.
• Veri erişim loglarını merkezi SIEM veya log havuzunda saklayın; kapsama oranını %99 hedefleyin.
• Anonimleştirme stratejilerini uygulayın; izleme için masked feature versiyonları tutun.
• Denetim sorgularına otomatik rapor üreten bir arayüz sağlayın; yanıt süresini <1 saat hedefleyin.
• Model karar ağaçlarını ve feature önemlerini saklayarak açıklanabilirlik gereksinimlerini karşılayın (SHAP gibi metriklerin günlük raporu).

Teknik Durum Tablosu

Sorunu Sahada Sistematik Daraltma

Sorunu daraltırken fiziksel katmandan uygulama katmanına doğru sistematik ilerlemek gerekir; böylece en sık rastlanan saha hatalarını hızla elersiniz.

1. Fiziksel/altyapı kontrolleri: ağ gecikmeleri, disk I/O, CPU yükü ölçümleri al. (ping, iostat, top; eşiği p95 network < 20ms)
2. Platform ve servis kontrolü: container restart oranı, servis hata oranı (% error rate), log korelasyonu yap.
3. Veri pipeline doğrulama: ingest time vs event time farkı, feature staleness ölçümü.
4. Uygulama ve model seviyesi: model scoring latency, serve TPS, A/B sonuçları ve geri bildirim etiketleri analiz et.

Bu adımlar saha mühendisliğiyle birlikte yürütüldüğünde ilk 48 saatte hatanın kök nedenine ulaşma olasılığı artar.

Gerçekçi saha senaryosu örneği:

Bir telekom müşterisinde aylık churn oranı aniden %1,2'den %2,4'e yükseldi. İlk varsayım; tarif değişiklikleri veya kampanya hatasıydı. Ancak sistematik log korelasyonu, online scoring pipeline'ında bir Kafka gecikmesi olduğunu gösterdi; bazı kritik özellikler 40 dakikaya kadar gecikiyordu. Kök neden, yeni abonelik eventi üreten microservice'in partition sayısındaki yanlış konfigürasyondu.

Kalıcı çözüm olarak partition ayarı düzeltilip pipeline buffering yeniden konfigüre edildi; shadow scoring ile doğrulama yapıldı ve feature freshness <5 dakika seviyesine geri getirildi. Sonuç: 30 gün içinde churn %25 oranında azaldı ve kampanya maliyet verimliliği %18 iyileşti.

Uzun Vadeli Dayanıklılık ve Ölçüm Disiplini

Uzun vadeli başarı, model ve veri pipeline'larının otomatik izlenmesi ve performans disiplininin kurumsallaşmasına bağlıdır.

• Günlük model sağlık paneli (AUC, precision, recall, data drift) oluşturun.
• Feature freshness ve label latency SLA'larını izleyin (örn. <5 dakika, <24 saat).
• Model versiyonlama ve deney izleme (experiment tracking) zorunlu olsun.
• A/B testleri sürekli yapın; her değişikliğin ROI etkisini ölçün.
• Operasyonel runbook ve ilkyardım prosedürleriyle olay yanıt süresini kısaltın.

Bella Binary yaklaşımı, izlenebilirlik ve otomasyonu temel alır: model kararını, veri versiyonunu ve iş kuralını tek bir referansla ilişkilendirir; böylece hataların kök nedeni 24 saatten kısa sürede tespit edilebilir.

Sonuç

Müşteri terk analizi çok katmanlı bir çözümdür; veri pipeline'dan karar katmanına kadar her bileşende ölçülebilir SLA'lar ve uyarılar olmalıdır. Tek bir yüksek doğruluklu model, gecikme, drift veya iş kuralı uyumsuzlukları nedeniyle değersiz hale gelebilir.

Ölçüm ve izleme kültürü olmadan tekrar eden üretim sorunları kaçınılmazdır. Bella Binary olarak saha testleri, shadow scoring ve canary dağıtımlarını içeren pratik mimariler öneriyor ve uyguluyoruz; böylece ilk 90 günde operasyonel stabilite ve %15–%30 arasında gözlemlenebilir churn düşüşü hedefleniyor.

Eğer bu mimarilerden biri kurumunuz için uygulanabilir görünüyorsa, saha bulgularımızı proje bazlı olarak paylaşmaktan memnuniyet duyarız. Birlikte bir pilot tasarlayıp 30–90 günlük ölçülebilir hedefler koyabiliriz.