Müşteri elde tutma oranı, churn ve LTV: hangi metrik neyi ölçer?

Müşteri elde tutma oranı (retention), bir dönemin başında sahip olduğun müşterilerin dönem sonunda hâlâ müşterin olma oranıdır. Churn oranı (müşteri kayıp oranı) aynı tabanın kaybedilen kısmıdır. Müşteri yaşam boyu değeri (LTV) ise bir müşterinin ilişki boyunca bırakacağı tahmini değerdir.

Bu üç metrik müşteri yaşam döngüsünün (lifecycle) temel göstergeleri ama tek başına bir anlam taşımazlar. Birim, dönem ve "hâlâ müşteri" sayılmanın koşulu baştan tanımlanmazsa aynı veriden farklı sonuçlar çıkar.

Bu yazı her metriğin neyi ölçtüğünü, analitik ve faturalama araçlarının bunları nasıl farklı tanımladığını ve iş modeline göre hangi metriğin öne çıktığını anlatıyor. Hesaplamaların kendisi sitedeki hesaplayıcılarda duruyor, yazı formül tekrarlamıyor.

Türkçe kaynaklar aynı metriğe farklı isimler veriyor, o yüzden önce terimleri sabitlemek gerekiyor. Elde tutma oranı, İngilizcede retention rate, bir başlangıç grubunun ne kadarının kaldığını gösterir.

Bu oran müşteri sayısıyla ölçüldüğünde yüzde 0 ile yüzde 100 arasındadır. Eksiye düşemez, çünkü bir gruptan başlangıçtaki sayıdan fazla müşteri kaybedemezsin. Churn oranı aynı grubun kaybedilen payıdır ve müşteri sayısıyla ölçüldüğünde elde tutmanın tümleyenidir.

"Negatif churn" ise bir müşteri kavramı değil, gelir kavramıdır. ChartMogul'un gelir churn'ü sayfası, net gelir churn'ünün eksiye düşebileceğini yazıyor. Bu, mevcut müşterilerin yükseltmelerden gelen ek gelirinin, iptal ve paket düşürmelerden kaybedilen geliri aştığı anlamına gelir. Yeni müşteri kazanmanın negatif churn ile bir ilgisi yok.

Müşteri yaşam boyu değeri için LTV, CLV ve CLTV kısaltmaları kullanılıyor. ChartMogul, LTV sayfasında LTV ile CLV'nin aynı metriğin iki adı olduğunu ve LTV'nin genellikle geçmişin ölçümü değil, ileriye dönük bir tahmin olduğunu belirtiyor. Kohort ise ortak bir başlangıç anını paylaşan müşteri grubudur: aynı hafta uygulamayı kuranlar, aynı ay ilk siparişini verenler ya da aynı ay ilk ödemeyi yapanlar.

İki ekip aynı dönem için farklı churn oranları raporluyorsa sorun çoğu zaman veride değil, tanımdadır. Bir elde tutma sayısının ne anlama geldiğini üç karar belirler: neyi saydığın, "hâlâ müşteri" sayılmanın koşulu ve dönemin nasıl sayıldığı.

Önce birimi seç: kullanıcı, müşteri ya da gelir

Elde tutma kullanıcı, ödeme yapan müşteri ya da gelir üzerinden ölçülebilir ve üçü farklı hikâyeler anlatır. ChartMogul, yalnızca müşteri churn'üne bakmanın yaygın bir hata olduğunu, birkaç yüksek değerli iptalin geliri müşteri sayısının gösterdiğinden çok daha fazla etkileyebileceğini yazıyor. Aynı sayfa, ücretsiz deneme ve ücretsiz plandaki kullanıcıların müşteri churn'ünden çıkarılmasını, yalnızca ödeme yapan müşterilerin sayılmasını öneriyor. Müşteri sayısıyla ölçülen elde tutma oranı için sitedeki elde tutma oranı hesaplayıcısı, gelir tarafı için net gelir elde tutma (NRR) hesaplayıcısı kullanılabilir.

"Hâlâ müşteri" sayılmanın koşulu

Bir müşterinin ne zaman kaybedilmiş sayılacağı da araçtan araca değişiyor. Stripe'ın faturalama analitiği dokümanına göre bir abonenin bütün abonelikleri iptal edildiğinde ya da ödenmemiş olarak işaretlendiğinde abone kaybedilmiş sayılır. Baremetrics 30 günden uzun süredir ödemesi gecikmiş müşteriyi iptal etmiş sayıyor. Recurly ise beklemeye alınmış bir aboneliği kaybedilmiş saymıyor.

Paydada da fark var. Stripe abone churn oranında son 30 günün yeni abonelerini başlangıç tabanına ekliyor, Baremetrics yalnızca 30 gün önce aktif olan müşterileri kullanıyor, ChartMogul ise dönem başındaki müşterileri alıp aynı dönemde hem katılıp hem ayrılanları ve geri dönenleri çıkarıyor. Bu yüzden iki araçtan gelen iki churn oranını karşılaştırmadan önce tanımlarının aynı olduğundan emin olmak gerekir.

Gün, hafta ve ay her araçta aynı değil

Dönemin nasıl sayıldığı da sonucu değiştirir. Amplitude, zamanın nasıl işlediğini anlattığı sayfada bir günü varsayılan olarak her kullanıcı için farklı başlayan 24 saatlik bir pencere olarak ele aldığını ve bir ayı 30 gün saydığını yazıyor.

Mixpanel'de 1. gün elde tutması, kullanıcının ilk anından sonraki 24 ile 48 saat arasıdır. Google Analytics 4'ün kohort keşfinde ise hafta, kayan bir 7 gün değil, pazardan cumartesiye bir takvim haftasıdır. Aynı kullanıcı grubu bu üç araçta farklı bir 1. hafta elde tutması gösterebilir.

Her iş modelinde "müşteri kaldı mı" sorusunun cevabı farklı bir olaya bağlı. Aboneliği olan bir işte iptal butonu bu cevabı verir, e-ticarette ve mobil uygulamada ise cevabı senin tanımlaman gerekir.

Abonelik: müşteri churn'ü, gelir churn'ü ve NRR

Abonelik işinde iki churn birlikte izlenir: kaç müşterinin ayrıldığı ve ne kadar gelirin kaybedildiği. Net gelir elde tutma (NRR), mevcut müşterilerden yükseltmeler, paket düşürmeler ve iptallerden sonra ne kadar gelirin kaldığını gösterir. Brüt gelir elde tutma (GRR) ise yükseltmeleri saymaz. ChartMogul, GRR'nin tanım gereği yüzde 100 ile sınırlı olduğunu ve birinin GRR'sini başka birinin NRR'siyle karşılaştırmanın yaygın bir hata olduğunu yazıyor.

Pencere de tutarlı olmalı. ChartMogul NRR'nin çoğunlukla 12 ay üzerinden ölçüldüğünü belirtirken Baremetrics NRR ve GRR'yi kayan 30 günlük pencereyle hesaplıyor.

Mobil uygulama aboneliklerinde Apple, gönüllü churn'ü (kullanıcının iptali) gönülsüz churn'den (60 günlük yeniden deneme süresinde kurtarılamayan ödeme sorunu) ayrı raporluyor. İkincisi bir pazarlama mesajıyla değil, ödeme akışıyla çözülür.

E-ticaret: tekrar satın alma ve kendi penceren

E-ticarette kimse aboneliğini iptal etmez, müşteri sadece bir daha gelmez. Shopify'ın müşteri raporları geri dönen müşteriyi, sipariş geçmişinde daha önce en az bir sipariş bulunan müşteri olarak tanımlıyor ve raporların yalnızca seçilen dönemdeki değil, müşterinin bütün sipariş geçmişine dayandığını not ediyor. "Kaybedilmiş müşteri" için hazır bir tanım yok.

Kendi müşterilerinin iki sipariş arasında genellikle ne kadar beklediğine bakıp bir pencere belirlemen ve dönemleri karşılaştırırken bu pencereyi sabit tutman gerekir. Son siparişten bu yana geçen süreye göre müşterileri bölümlemek, son satın alma, sıklık ve harcamaya (Recency, Frequency, Monetary) bakan RFM analizi yazısının konusu.

Mobil uygulama: N. gün ve "o gün ya da sonrası"

Mobil uygulamalarda elde tutma, bir başlangıç olayından (genellikle kurulum ya da ilk açılış) sonra kullanıcının geri gelip gelmediğiyle ölçülür. İki temel yöntem var. N. gün elde tutması, kullanıcının tam olarak N. gün geri gelip gelmediğine bakar. "O gün ya da sonrası" elde tutması ise kullanıcının N. gün ya da herhangi bir sonraki günde geri dönüp dönmediğine bakar.

Amplitude elde tutma dokümanında bu iki yöntemi "Return On" ve "Return On or After" olarak adlandırıyor. Amplitude ve Mixpanel varsayılan olarak ikinciyi, PostHog ise birinciyi kullanıyor.

İkinci yöntem her zaman daha yüksek bir sayı verir, bu yüzden iki yöntemden gelen sonuçlar karşılaştırılamaz. Hangisinin uygun olduğu, uygulamanın ne sıklıkla kullanılması gerektiğine bağlı: her gün kullanılan bir uygulamada N. gün, ayda birkaç kez açılan bir uygulamada "o gün ya da sonrası" daha anlamlı sonuç verir.

Farkın ne kadar büyük olabileceğini varsayımsal bir örnek gösteriyor. Aynı gün uygulamayı kuran 1.000 kullanıcıdan 120'si tam 7. gün uygulamayı açsın, 7. gün ya da sonrasında en az bir kez açanların sayısı ise 310 olsun. Aynı kohort için iki yöntem şu sonuçları verir:

İki sayı da doğru ama farklı soruları cevaplıyor. Bir ekibin %31'lik "o gün ya da sonrası" sonucunu başka bir ekibin %12'lik N. gün sonucuyla yan yana koymak, kullanıcıların iki buçuk kattan fazla daha iyi tutulduğu izlenimini verir. Oysa farkın tamamı yöntemden gelir.

Uygulama mağazalarının kendi sayıları da farklı şeyler ölçüyor. Apple'ın App Store Connect elde tutma tanımı, uygulamayı kurup belli gün sonra açan cihazları sayıyor ve hiç açılmayan kurulumları hesaba katmıyor. Google Play Console'daki elde tutulan yükleyiciler ise uygulamayı cihazında tutan kullanıcıları sayıyor ve bu süre içinde uygulamanın açılmış olması gerekmiyor.

Tek bir aylık elde tutma oranı, farklı zamanlarda gelen müşterileri bir arada ortalar. Kohort analizi ise her başlangıç grubunu ayrı bir satırda izler ve hangi kohortun daha iyi ya da daha kötü tutulduğunu gösterir. Kohortu tek bir olaya bağlamak gerekiyor: uygulamada kurulum, e-ticarette ilk sipariş, abonelikte ilk ödeme. Shopify'ın varsayılan kohort raporu müşterileri ilk siparişlerinin tarihine göre, Stripe ise aboneleri ilk kez gelir üretmeye başladıkları aya göre gruplandırıyor.

Kohortları okurken iki tuzağa dikkat etmek gerekiyor. Birincisi tamamlanmamış dönemler. Amplitude, analiz süresi henüz bitmemişken elde tutma eğrisinin yukarı kıvrılıp artıyor gibi görünebileceğini ve doğru bir okuma için dönemin tamamlanmasını beklemek gerektiğini yazıyor.

İkincisi ortalama. PostHog, ağırlıklı ortalamanın kohort büyüklüklerini hesaba kattığını, basit ortalamanın ise bütün kohortlara eşit davrandığını belirtiyor. Birkaç yüz kişilik bir kohortla on binlerce kişilik bir kohort aynı ağırlıkla ortalanırsa sonuç yanıltır.

Araçlar aynı kelimeyi farklı anlamlarda kullandığı için iki aracın sayılarını karşılaştırmadan önce şu farklara bakmak gerekiyor:

• "Rolling" kelimesi: Amplitude ve Mixpanel'de her kullanıcının kendi başlangıcından itibaren 24 saatlik pencereler, PostHog'da "o gün ya da sonrası" elde tutması, GA4'ün kohort keşfinde o döneme kadar her dönemde geri dönmek, Baremetrics ve Braze'de ise geriye dönük 30 günlük pencere anlamına geliyor.
• "Geri dönen kullanıcı": GA4'te siteyi ya da uygulamayı daha önce en az bir kez ziyaret etmiş kullanıcı, Google Play'de uygulamayı silip yeniden kuran kullanıcı, Shopify'da sipariş geçmişinde daha önce sipariş olan müşteri.
• "Yeni kullanıcı": Amplitude yeni kullanıcıyı seçilen olayın ilk yapıldığı ana göre değil, hesabın ilk görüldüğü zamana göre sınıflandırıyor.
• Cihaz ve kimlik: GA4'ün kohort keşfi yalnızca cihaz verisine dayanıyor ve kullanıcı kimliğini (User-ID) hesaba katmıyor.

LTV, bir müşterinin ne kadar değerli olduğunu gösteren bir planlama sayısıdır, kesin bir ölçüm değildir. Araçlar onu farklı formüllerle tahmin ediyor.

Stripe ve Baremetrics kullanıcı başına ortalama geliri churn oranına bölüyor. ChartMogul aynı hesaba brüt marjı da ekliyor ve temel formülün churn'ü doğrusal varsaydığını, oysa churn'ün ilk aylarda en yüksek olduğunu, bunun da LTV'yi olduğundan yüksek gösterdiğini yazıyor. Klaviyo'nun tahmine dayalı analizi ise geçmiş siparişlerin değerini (geçmiş CLV) ve varsayılan olarak bir yıllık tahmini (tahmini CLV) toplayarak toplam CLV'yi buluyor.

Analitik araçları da belirli bir pencere içindeki geliri kullanıyor. GA4 yeni kullanıcıların ilk 120 gündeki ortalama gelirini gösteriyor, Amplitude da bir kohortun ilk N gün içinde ürettiği toplam geliri.

Bu farkların pratik sonucu şu: iki LTV'yi karşılaştırmadan önce hangi modelin kullanıldığına, gelirin mi marjın mı hesaplandığına ve hangi pencereye bakıldığına bakmak gerekir. Geçmiş sipariş verisinden basit ya da marja göre düzeltilmiş bir LTV çıkarmak için LTV hesaplayıcısı kullanılabilir. Tek tek müşteriler için üretilen churn ve CLV tahminlerini yapay zeka ile CRM pazarlaması yazısında anlattım.

LTV:CAC ve geri ödeme süresi edinme planlamasına aittir

LTV en çok müşteri edinme maliyetiyle (CAC) birlikte kullanılır. ChartMogul, CAC'nin tek başına harcamanın karşılığını alıp almadığını söylemediğini ve CAC geri ödeme süresi ile LTV:CAC oranıyla birlikte okunması gerektiğini yazıyor. Aynı sayfa, iki şirket ya da iki kanal arasında CAC'yi karşılaştırırken aynı kapsamlı tanımın kullanılıp kullanılmadığını kontrol etmemenin yaygın bir hata olduğunu belirtiyor. Oranın iki tarafı da aynı müşteri tanımına ve aynı döneme dayanmalı.

Hesap için LTV:CAC oranı hesaplayıcısı ve CAC geri ödeme süresi hesaplayıcısı kullanılabilir. Bu iki metrik daha çok edinme bütçesini planlamaya yarar. Lifecycle ekibinin günlük kararları ise elde tutma ve churn üzerinden yürür.

Bir müşteri aktif olmaktan kaybedilmiş olmaya bir günde geçmez ve geri kazanılan bir müşteri, hiç gitmemiş bir müşteriyle aynı şey değildir. Amplitude'un yaşam döngüsü grafiği aktif kullanıcıları yeni, mevcut ve yeniden canlanan (daha önce pasif olan) olarak üçe ayırıyor ve önceki dönemde aktif olup bu dönemde aktif olmayanları uykuda (dormant) sayıyor. PostHog da bu durumu tanımlarken önemli bir uyarı yapıyor: seçilen dönem ürünün doğal kullanım sıklığıyla uyumlu değilse sonuçlar yanıltabilir.

Geri kazanılan müşterileri ayrı saymanın bir nedeni daha var. Bir geri kazanım kampanyası başarılı olduğunda, geri gelen müşteriler elde tutma oranının içine karışırsa oran, mevcut müşterilerin daha iyi tutulduğunu gösteriyormuş gibi görünür. ChartMogul müşteri churn oranında dönem içinde ayrılıp geri dönen müşterileri çıkarıyor, Baremetrics ise geri dönen bir müşteriyi kohortuna yeniden ekliyor. Hangisini seçersen seç, geri kazanılanların sayısını ayrıca raporlaman programın etkisini daha doğru gösterir.

Bu üç durumun her biri farklı bir müşteri ilişkileri yönetimi (CRM) akışı gerektirir. Journey kütüphanesindeki bazı akışlar örnek olarak:

• Churn riskine kademeli müdahale: Kaybolmaya başlayan müşteri için, risk sinyaline göre müdahale seviyesi seçilir.
• Eski müşteriyi geri kazanma: Belirlenen pencerede sipariş vermemiş, kaybedilmiş sayılan müşteri için.
• Kullanım alışkanlığını geri kazanma: Kullanım sıklığı düşen uygulama kullanıcısı için.

Bir CRM programını başlattıktan sonra elde tutma oranı arttıysa bunun programdan mı, mevsimden mi, yeni bir ürün özelliğinden mi kaynaklandığını tek başına bu sayı söylemez. Programın etkisini görmek için programa dahil olmayan, rastgele seçilmiş bir grubu dışarıda tutmak ve iki grubun elde tutmasını aynı tanım ve aynı pencereyle karşılaştırmak gerekir. Pencere, programın amaçladığı davranışa uygun olmalı. Bir onboarding akışı için ilk 30 gün, bir geri kazanım akışı için müşterinin normal sipariş aralığı anlamlı bir pencere olabilir.

Kanal metrikleri elde tutma metriği değildir. Bir e-mailin açılma ya da tıklanma oranı, bir uygulama içi mesajın kapatılma oranı, mesajın görülüp görülmediğini anlatır, müşterinin kalıp kalmadığını değil. Bu metrikleri ve neyi ölçtüklerini e-mail teslim edilebilirliği ve uygulama içi mesaj ile push bildirim yazılarında ayrıca anlattım.

Bir lifecycle raporunu ilk kez hazırlamadan önce ekibin birkaç tanım üzerinde yazılı olarak anlaşması, sonraki bütün tartışmaları kısaltır. Aşağıdaki tablo bir abonelikli mobil uygulama için doldurulmuş örnek bir tanım sayfası. Kendi iş modeline göre her satırı yeniden yazman gerekir.

Bu sayfa bir kez yazıldıktan sonra sabit kalmalı. Tanım değişirse eski ve yeni dönemler karşılaştırılamaz hale gelir. Tanımı değiştirmen gerekiyorsa, değişikliğin tarihini ve nedenini raporun yanına not etmek, aylar sonra rakamlar arasındaki kırılmayı açıklamanın en kolay yolu.