Ana Sayfa / Blog / Subscription analytics: RevenueCat vs custom implementation

Subscription analytics: RevenueCat vs custom implementation

iOS abonelik analytics'i için RevenueCat SDK mı, custom implementation mı? 12 uygulamada denediklerim.

iOS abonelik modeli kurduğunda bir noktada analytics ihtiyacı ortaya çıkıyor. Hangi abonelik planını kaç kişi aldı? Trial bitip ücretli’ye geçiş oranı? Churn rate ne? Cohort-based MRR?

İki yaklaşım var: RevenueCat gibi third-party SDK veya kendi backend’de tracking. 12 uygulamamda ikisini de denemişim. Bu yazıda pratik karşılaştırma.

RevenueCat: pros and cons

RevenueCat iOS + Android subscription management için SaaS. iOS tarafında StoreKit wrapper + dashboard veriyor.

Avantajlar:

  • Setup 30 dakika. SDK install, Apple Connect keys, 1 gün sonra data geliyor.
  • Pre-built dashboards. MRR, ARR, churn, retention, conversion, cohort analysis, LTV, revenue by country. Hepsi hazır.
  • Cross-platform aggregation. iOS + Android abonelik’leri tek dashboard’da.
  • Receipt validation otomatik. Apple’a server-side validation yapıyor. Security hazır.
  • Paywall A/B testing. Experiments feature’ı A/B test kuruyor, reporting.
  • Webhooks. Subscription event’lerinde webhook. Kendi backend’ine integrate ediyorsun.
  • Free tier: $2500 MTR’a kadar ücretsiz. Küçük scale’de maliyetsiz.

Dezavantajlar:

  • Dependency: Üçüncü parti servise bağımlısın. Down olursa subscription flow problem.
  • Pricing: $2500 MTR üstü ücretli. $10K MTR’da $500+/ay olabiliyor.
  • Vendor lock-in: Başka servise geçmek zor (tüm user data RevenueCat’te).
  • Customization limit: Specific business logic’i sınırlı.
  • Ek SDK: App binary size 500KB+ artıyor.

Custom implementation

Kendi backend’inde subscription state’i tutmak. StoreKit’ten event al, backend’e işle.

Kurulum:

  1. StoreKit 2 transaction listener’ı (async stream)
  2. Each transaction’ı backend’e send et
  3. Backend Apple’a receipt validation yapıyor
  4. User subscription state’ini DB’ye yazıyor
  5. Server-to-server notification’ları (Apple’ın ASSNs) endpoint’te receive
  6. Event’leri analytics DB’sine yazıyor

Avantajlar:

  • Full control. Kod senin, davranış senin.
  • No vendor dependency. Kendi infrastructure.
  • No monthly cost. Sadece AWS/hosting maliyeti.
  • Custom business logic. Özel kurallar, segmentation.
  • Data privacy. Kullanıcı data third party’ye gitmiyor.

Dezavantajlar:

  • Development time: 2-4 hafta production-ready için.
  • Edge cases: Apple’ın receipt validation tuhaflıkları, refund handling, grace period, family sharing… her biri ayrı baş ağrısı.
  • Dashboard yok: Data tutuyorsun ama görselleştirme yapacak tool yok (kendin ya da Metabase, Retool, etc.).
  • Testing zor: Apple sandbox environment tricky. Test account’lar, subscription lifecycle simülasyonu.
  • Maintenance: Apple StoreKit değiştirdiğinde kod’unu güncellemek zorundasın.

Karar kriterleri

RevenueCat seç:

  • Küçük ekip (1-3 kişi)
  • MRR $2500’un altında başlangıçta
  • Dashboard’a hızlıca ihtiyaç
  • A/B testing yapacak
  • iOS + Android paralel gidiyor
  • Cross-platform subscription management

Custom implementation seç:

  • Büyük scale ($10K+ MTR)
  • Mühendislik ekibi var
  • Özel business logic kritik
  • Data privacy concerns (GDPR, özel data rezervleri)
  • Vendor lock-in’den kaçınmak istiyorsan

Benim pragmatic yaklaşımım

Benim 12 uygulamamın çoğu RevenueCat’te. Neden?

  • Hepsi solo geliştirici (ben)
  • Çoğu $2500 MTR altında
  • Dashboard’u zaten var, ayrıca build etmek için haftalar
  • A/B test yapıyorum (pricing experiments)

Parademi ve GO HERO daha büyük ölçekte, yine de RevenueCat’te kalıyorum çünkü migration pahalı ve RevenueCat işini yapıyor.

Eğer enterprise ölçekte bir subscription platform kursam (20K+ MTR), custom’a geçmeyi düşünürüm.

RevenueCat integration gotchas

RevenueCat kullanmaya karar verdiysen dikkat:

1. App User ID mapping. RevenueCat’e kendi user ID’ni de göndermen lazım. Yoksa anonymous user analytics.

Purchases.logIn(userId)

2. Entitlements model anlamak. RevenueCat “product” yerine “entitlement” kullanıyor. “Premium”, “Pro” gibi. Product’ları entitlement’lara mapliyorsun.

3. Attribution bilgisi. Install source, marketing campaign data RevenueCat’e gönder. Sonra LTV-by-campaign analizi yapabilirsin.

4. StoreKit 2 migration. RevenueCat yeni StoreKit 2 desteği var ama legacy kod’unu güncellemen gerekebilir.

5. Test environment: RevenueCat’in sandbox environment’ı var. Production data ile karışmıyor.

Custom implementation gotchas

Custom gidersen dikkat edilmesi gereken edge case’ler:

1. Receipt validation hatası. Apple sometimes 500 dönüyor, retry mantığı lazım.

2. Introductory offer eligibility. Apple ID başına lifetime’da 1 kez. Client’ta check et, mismatch olursa purchase fail ediyor.

3. Grace period handling. Ödeme başarısız, user 3-16 gün hâlâ premium olabilir. Kod bunu handle etmeli.

4. Family sharing. Aile’den biri satın aldı, 5 aile üyesi access. Her birini ayrı “subscribed user” olarak handle.

5. Refund webhook. Apple kullanıcıya iade verdi (user yaşı dolmadı, yanlış charge, vs). Senin backend bunu öğrenmeli, premium’u kes.

Her biri ayrı bir gün uğraş. Toplam 2-4 haftalık iş.

Analytics metrics that matter

Hangisini kullanırsan kullan, şu metric’leri izlemelisin:

1. Monthly Recurring Revenue (MRR). Aylık tekrar eden gelir. Trend kritik.

2. Conversion rate (install → paid). Trial başlatanların kaç %’si ödemeye geçiyor.

3. Trial conversion rate. Trial kullananların kaç %’si ödeme yapıyor.

4. Churn rate. Ayda kaç % abone iptal ediyor?

5. Customer Lifetime Value (LTV). Ortalama bir kullanıcı toplam ne kadar ödeme yapıyor (çıkmadan önce)?

6. Average Revenue Per User (ARPU). Ay başı ortalama revenue.

7. Retention cohorts. Ocak’ta subscribe olanlar şu an hangi orandan aktif?

Bu 7 metric subscription sağlığının temel göstergesi. RevenueCat hepsini pre-built veriyor.

Hybrid approach

Aralarda bir opsiyon: RevenueCat primary, custom supplementary.

  • RevenueCat subscription state ve standard analytics
  • Ek custom event’ler kendi analytics’ine (Mixpanel, Amplitude)
  • Webhook’lar backend’e, custom business logic için

Bu approach RevenueCat’in value’sunu alıyor ama özel logic için kapı açık bırakıyor.

Migration stratejisi

RevenueCat’e başladın, ölçek büyüdü, custom’a geçmek istiyorsun. Nasıl?

  1. Dual write. RevenueCat’e de yazıyor, custom backend’e de. 2-3 ay paralel.
  2. Data migration. RevenueCat’ten historical data export. Custom backend’e import.
  3. Feature parity check. Custom’un tüm dashboard’ları RevenueCat’inkilerle aynı mı?
  4. Switchover. Custom’u primary yap, RevenueCat’i backup olarak tutmaya devam.
  5. Eventual removal. 6 ay sonra RevenueCat SDK’yı kaldır.

Bu migration 3-6 aylık bir proje. Ön görülerek planlamak önemli.

Sonuç

Subscription analytics critical bir konu. Doğru yönetilmezse product growth görünmüyor, gelir kayıplarını yakalamıyorsun.

Küçük-orta ölçekte RevenueCat optimal. Quick setup, good dashboard, reasonable price. Büyük ölçekte custom implementation düşünülebilir ama ciddi investment.

Metric’leri izle: MRR, conversion, churn, LTV. Bunlar hangi tool’u kullanırsan kullan aynı. Tool araç, metric’ler hedef.

Bu konuda bir projeniz mi var?

Kısa bir özet bırakın, 24 saat içinde size dönüş yapayım.

İletişime Geç