Abonelik Kullanım İçgörüleri İçin Mobil Uygulama Nasıl Kurulur

Hedefler, Hedef Kitle ve “Kullanım İçgörüleri” Ne Anlatır

Ekran tasarlamadan veya analitik araç seçmeden önce, uygulamanın kimin için olduğunu ve hangi kararları desteklemesi gerektiğini netleştirin. “Kullanım içgörüleri” yalnızca grafikler değildir—abonelerin ürününüzü nasıl kullandığını ve sonraki ne yapılması gerektiğini anlatan güvenilir sinyallerin küçük bir setidir.

Birincil kullanıcıları (ve sorularını) tanımlayın

Çoğu abonelik kullanım içgörüleri uygulaması birden fazla kitleye hizmet eder:

• Müşteriler (kendi kendine servis): “Değer alıyor muyum?”, “Bu hafta ne kullandım?”, “Limitlere ne kadar yakınım?”, “Bir sonraki denemem gereken özellik hangisi?”
• Destek / Success: “Bu kullanıcı takıldı mı?”, “Ana özellikleri aktifleştirdiler mi?”, “Şikayetten önce ne değişti?”
• Ürün / Büyüme: “Hangi davranışlar yenilemeyi öngörür?”, “Onboarding nerede düşüyor?”, “Hangi segmentler 2. haftadan sonra churn oluyor?”

Bu soruları somut hâle getirin. Eğer soruyu bir cümlede yazamıyorsanız, muhtemelen mobil dostu bir içgörü için çok geniştir.

Uygulamanın hangi kararları almasını sağlamalı

İçgörüler eylemi tetiklemeli. Yaygın karar hedefleri şunlardır:

• Churn azaltma: düşük angajmanı erken tespit etmek ve kurtarma planı tetiklemek.
• Onboarding iyileştirme: eksik aktivasyon adımlarını vurgulamak ve bir sonraki aksiyona rehberlik etmek.
• Upsell veya genişleme: yaklaşan limitleri, ekip benimsemesini veya gelişmiş özelliklerin değerini göstermek.

Başarı kriterleri (nasıl işe yaradığını anlayacaksınız)

Ölçülebilir çıktılar tanımlayın, örneğin:

• Benimseme: hedef kullanıcıların %'si içgörüleri en az bir kez açıyor.
• Angajman: haftalık içgörü görüntüleyenler (WAU) ve geri dönüş oranı.
• İş etkisi: retention artışı, churn azalması veya iyileşmiş aktivasyon oranı.

Bu kılavuzun kapsamı (ve dışındakiler)

Bu rehber metriklerin tanımlanmasına, olayların izlenmesine, veri kaynaklarının birleştirilmesine, gizlilik temellerine ve net mobil panolar ile uyarıların oluşturulmasına odaklanır.

Kapsam dışı: özel ML modelleri, derin deney çerçeveleri ve kurumsal seviye faturalama sistemi uygulamaları.

Abonelik Modelini ve Yaşam Döngüsünü Tanımlayın

Panoları tasarlamadan önce ürününüzde “abonelik”in ne olduğuna dair ortak bir tanıma ihtiyacınız var. Backend, faturalama sağlayıcısı ve analitik ekibi farklı anlamlar kullanırsa, grafikleriniz çelişir ve kullanıcılar güvenini kaybeder.

Raporlayacağınız yaşam döngüsü durumlarını eşleyin

Uygulamanızın tanıyacağı ve görüntüleyeceği yaşam döngüsü aşamalarını yazın. Pratik bir temel şunlardır:

• Trial → kullanıcı erişime sahip ama henüz ödeme yapmamış
• Paid (active) → ödeme alındı ve erişim verildi
• Renewal → yeni fatura dönemi başlar (başarılı veya başarısız)
• Pause → kullanıcının başlattığı askıya alma (erişim kuralları net)
• Cancel → kullanıcı otomatik yenilemeyi sonlandırır (dönem sonuna kadar erişim olabilir)
• Win-back → kullanıcı churn sonrası geri döner (yeni abonelik veya reaktivasyon)

Anahtar nokta: her geçişi hangi olayların tetiklediğini (fatura olayı, uygulama içi aksiyon veya yönetici müdahalesi) tanımlayın ki “aktif aboneler” sayısı tahmine dayanmasın.

Temel varlıkları (ve ID'lerini) belirleyin

Abonelik kullanım içgörüleri uygulamanız tipik olarak aşağıdaki varlıklara ihtiyaç duyar; her birinin sabit bir tanımlayıcısı olmalıdır:

• User (kişi)
• Account (ev/takım/şirket)
• Device (mobil atıf ve çoklu cihaz kullanımı için önemli)
• Subscription (ölçtüğünüz kontrat)
• Plan (fiyat/özellik paketi)
• Invoice / payment (faturalama sonuçları)

Hangi ID'nin birleşimler için “gerçek kaynağı” olacağına (örneğin faturalama sisteminizden subscription_id) erken karar verin ve bunun analitikte akmasını sağlayın.

Kullanıcı/hesap başına birden fazla abonelikle başa çıkma

Birçok ürün zamanla birden fazla aboneliği destekler: eklentiler, birden çok koltuk veya ayrı hesaplar. Kurallar belirleyin:

• Bir kullanıcı birden fazla aktif aboneliğe sahip olabilir mi?
• Bir hesap birden fazla aboneliğe sahipse, erişimi hangi abonelik belirler?
• Kullanımı vs yetkilendirmeyi gösterirken, yetkilendirme plana mı, subscriptiona mı yoksa accounta mı bağlı?

Bu kuralları açıkça yapın ki panolar gelirleri çift saymasın veya kullanımı düşük göstermesin.

Hikayeyi değiştiren kenar durumları belgeleyin

Kenar durumlar genellikle raporlama sürprizlerine yol açar. Bunları baştan yakalayın: iadeler (tam vs kısmi), yükseltmeler/düşürmeler (anında vs sonraki yenileme), grace periodler (başarısız ödemeden sonra erişim), chargeback'ler ve manuel krediler. Bunlar tanımlandığında churn, retention ve “aktif” durumu tutarlı şekilde modelleyebilirsiniz.

Doğru Kullanım Metriklerini ve Segmentleri Seçin

Uygulamanızın “kullanım içgörüleri”, burada yaptığınız seçimlerin kalitesi kadar iyidir. Amaç, yenilemeyi, yükseltmeyi ve destek yükünü öngören aktiviteyi ölçmektir — sadece yoğun görünen şeyleri değil.

Ürününüz için “kullanım” ne demek karar verin

Abone için değer yaratan aksiyonları listeleyin. Farklı ürünlerin değer anları farklıdır:

• Oturumlar (uygulama açıldı, aktif dakika)\n- Özellik aksiyonları (dışa aktarım, kaydetme, yükleme, arama, düzenleme)\n- Üretilen değer (kazanılan zaman, tamamlanan görevler, işlenen dosyalar)\n- Tüketilen içerik (tamamlanan dersler, izlenen videolar, okunan makaleler)

Mümkünse saf aktivite yerine üretilen değeri tercih edin. “3 rapor oluşturuldu” genellikle “12 dakika uygulamada”dan daha anlamlıdır.

İlk 10–20 metrikten başlamak (etkili, gösterişli değil)

Başlangıç setini küçük tutun ki panolar mobilde okunabilir kalsın ve ekipler gerçekten kullansın. İyi başlangıç metrikleri genellikle şunlardır:

• Aktif aboneler (günlük/haftalık/aylık)
• Aktivasyon oranı (ana değer anına ulaştı)
• Ana özellik benimsemesi (Özellik X en az bir kez kullanıldı)
• Kullanım sıklığı (haftada aktif günler)
• Derinlik (aktif gün başına aksiyonlar)
• İçerik tamamlama (tamamlama %'si)

Vanity metriklerden kaçının; “Toplam kurulumlar” genellikle abonelik sağlığı için faydalı değildir.

Her metriği kesin tanımlayın (herkes aynı şekilde okusun diye)

Her metrik için yazın:

• Pay / payda (örn. onboarding adım 3'ü tamamlayan aboneler / onboarding başlatan aboneler)
• Zaman penceresi (son 7 gün, mevcut fatura döngüsü, son 30 gün)
• Filtreler (dahili kullanıcılar hariç, denemeler hariç, sadece ücretli)
• Sayım kuralları (benzersiz kullanıcı vs event, dedupe mantığı, timezone)

Bu tanımlar panonun yanında sade bir not olarak bulunmalı.

“Neden”i açıklayan segment boyutları ekleyin

Segmentler tek bir sayıyı teşhise çevirir. Birkaç sabit boyutla başlayın:

• Plan / seviye (basic vs premium)
• Bölge (ülke, saat dilimi)
• Kazanım kanalı (organik, reklam, yönlendirme)
• Cihaz OS (iOS vs Android)

İlk başta segmentleri sınırlayın—çok fazla kombinasyon mobil panoları taranması zor ve yanlış yorumlanmaya açık hale getirir.

Olay Takibi Planı ve Şeması Oluşturun

Bir abonelik kullanım içgörüleri uygulaması topladığı olaylar kadar iyidir. Herhangi bir SDK eklemeden önce ne ölçmeniz gerektiğini, nasıl adlandıracağınızı ve her olayın hangi veriyi taşıması gerektiğini yazın. Bu, panoları tutarlı kılar, “gizemli sayıları” azaltır ve sonraki analizleri hızlandırır.

1) Bir olay taksonomisi tasarlayın (isimler + özellikler)

Tam bir kullanıcı yolculuğunu kapsayan küçük, okunabilir bir olay kataloğu oluşturun. Açık, tutarlı isimlendirme kullanın—genellikle snake_case—ve clicked gibi belirsiz olaylardan kaçının.

Her olay için dahil edin:

• Olay adı (örn. subscription_started, feature_used, paywall_viewed)
• Ne anlama geldiği sade İngilizceyle
• Ne zaman tetiklendiği (ekran, tetikleyici, zamanlama)
• Gerekli özellikler (zorunlu)
• Opsiyonel özellikler (iyi olur)
• Örnek payload

Hafif bir örnek:

{
  "event_name": "feature_used",
  "timestamp": "2025-12-26T10:15:00Z",
  "user_id": "u_123",
  "account_id": "a_456",
  "subscription_id": "s_789",
  "feature_key": "export_csv",
  "source": "mobile",
  "app_version": "2.4.0"
}

Bu kod bloğu olduğu gibi korunmalıdır.

2) Tanımlayıcıları dikkatle ekleyin

Kullanımı faturalamaya bağlayabilmek için kimlikleri baştan planlayın:

• user_id: oturum açıldıktan sonra sabit; e-posta ID olarak kullanılmasın.
• account_id: takım/çalışma alanı ürünleri için.
• subscription_id: kullanımı belirli bir plan ve fatura dönemine bağlar.
• device_id: hatalar ve offline teslimat için faydalı, ancak hassas kabul edin.

Guest kullanıcılar (geçici ID'ler) ve oturum açma sırasında ID birleştirme kurallarını kararlaştırın.

3) Offline mod ve gecikmeli gönderim

Mobil izleme zayıf bağlantılarla başa çıkmalıdır. Cihaz üzerinde bir kuyruk kullanın ve:

• Backoff ile yeniden denemeler
• Duplication önleme anahtarları (event_id UUID her olay için)
• Güvenli toplu gönderim (zaman aşımını önlemek için küçük partiler)

Ayrıca maksimum bir saklama penceresi belirleyin (örneğin X günden eski olayları at) ki geç gelen aktiviteler yanıltıcı raporlamaya yol açmasın.

4) Şemanın evrilebilmesi için versiyonlama

Şemanız değişecek. schema_version ekleyin (veya merkezi bir kayıt tutun) ve basit kurallar uygulayın:

• Önce yeni alanları opsiyonel olarak ekleyin
• Alanları yeniden adlandırmayın; eski → yeni eşlemesi yapın
• Değişiklikleri ve sürüm notlarını analistler ve geliştiricilerle belgeleyin

Açık bir takip planı kırık grafikleri önler ve kullanım içgörülerinizin ilk günden güvenilir olmasını sağlar.

Veri Kaynakları ve Nasıl Birleştireceğiniz

Kullanım, ödemeler ve müşteri bağlamını birleştirdiğinizde abonelik içgörüleri “doğru” hisseder. Panoları tasarlamadan önce hangi sistemlerin kayıt kaynağı olduğunu ve bunları nasıl güvenilir şekilde ilişkilendireceğinizi kararlaştırın.

Dahil edilecek temel veri kaynakları

Çoğu abonelik sonucu aşağıdaki dört kategori açıklıyor:

• Uygulama eventleri: özellik kullanımı, oturum aktivitesi, ana aksiyonlar (örn. “rapor dışa aktarıldı”, “ders izlendi”, “proje oluşturuldu”). Bu davranışsal “neden”dir.
• Faturalama sağlayıcısı: plan, fiyat, yenilemeler, yükseltme/düşürmeler, iadeler, başarısız ödemeler, denemeler, iptaller. Bu gelirsel “ne”dir.
• CRM / destek: hesap sahibi, müşteri seviyesi, biletler, CSAT, iptal nedenleri, destek notları. Bu bağlam “nasıl gidiyor” bilgisidir.
• Pazarlama attribüsyonu: kanal, kampanya, kurulum kaynağı, yönlendiren, promosyon kodları. Bu “nereden geldiler” bilgisidir.

Veriyi nerede saklayıp dönüştüreceksiniz

Genel olarak iki yolunuz var:

1. Data warehouse-first (örn. BigQuery/Snowflake): verileri temiz tablolara dönüştürürsünüz ve panolar tek kaynaktan beslenir.

2. Managed analytics-first: daha hızlı kurulum için, faturalama/destek birleştirmeleri için hafif bir warehouse katmanı ile.

Gelir odaklı içgörüler (MRR, churn, LTV) gösterecekseniz, eninde sonunda bir warehouse (veya ona benzer bir katman) zorunlu hale gelebilir.

Kimlik çözümleme: birleştirmeleri güvenilir kılmak

Çoğu birleştirme problemi kimlikten kaynaklanır. Planlayın:

• Guest → oturum açmış linking: anonim cihaz/kullanıcı id'si saklayın, sonra signup/login ile user_id'ye bağlayın.
• Çapraz cihaz kullanım: doğrulanmışsa kararlı account/user identifier kullanın.
• Hesap birleştirme: aynı e-posta, aynı fatura müşteri veya manuel destek birleştirmeleri için kurallar tanımlayın ve bir audit izi tutun.

Basit bir yaklaşım, anonim ID'leri, user ID'leri ve faturalama müşteri ID'lerini ilişkilendiren bir identity map table tutmaktır.

Veri tazeliği: gerçek zaman vs günlük

Kullanım durumuna göre tazeliği tanımlayın:

• Gerçek zaman veya yakın gerçek zaman: uyarılar için (başarısız ödeme, kullanım düşüşü, deneme bitimine yaklaşma).
• Günlük özetler: eğilimler, kohortlar ve haftalık/aylık raporlar için.

Burada açık olmak, günlük bir güncellemenin ürünü karşılayacağı durumlarda boru hatlarını gereksiz yere büyütmenizi engeller.

Gizlilik, Onay ve Veri Minimizasyonu

Kullanım içgörüleri ancak insanların veriyi nasıl ele aldığınıza güvendiklerinde uzun vadede çalışır. Gizliliği bir ürün özelliği gibi ele alın: anlaşılır, kontrol edilmesi kolay ve gerçekten ihtiyaç duyduğunuzla sınırlı olsun.

Ne topladığınızı ve nedenini söyleyin

Sade dil kullanarak iki soruyu yanıtlayın: “Ne izliyorsunuz?” ve “Bundan ne kazanıyorum?” Örnek: “Hangi özellikleri ve ne sıklıkta kullandığınızı izliyoruz; böylece panonuz aktivite eğilimlerinizi gösterir ve kullanılmayan katmanlar için ödeme yapmanızı önler.” “Hizmetlerimizi geliştirmek” gibi belirsiz ifadelerden kaçının.

Bu açıklamayı izin isteme anına yakın tutun ve Ayarlar içinde kısa bir “Veri ve Gizlilik” sayfasında yansıtın.

Bölgenize göre onay akışları tasarlayın

Onayı tek seferlik bir ekran değil, yapılandırılabilir bir akış olarak inşa edin. Operasyon gösterdiğiniz yerlere ve politikalara göre gerekebilir:

• Opt-in analitik için (daha sıkı rejimlerde yaygın)
• Opt-out; karanlık desenlerden kaçının
• Ürün analitiği, kişiselleştirme ve pazarlama için ayrı seçimler

Ayrıca “onayı geri çekme” davranışını planlayın: event göndermeyi hemen durdurun ve önce toplanmış verilerin ne olacağını belgeleyin.

Hassas verileri minimize edin (ve erken agregasyon yapın)

Varsayılan olarak tanımlayıcı olmayan veriyi tercih edin. Ham içerik yerine sayaçlar, zaman aralıkları ve kaba kategoriler kullanın. Örnekler:

• Video başlıkları yerine “watched_video=true” takip edin
• E-posta yerine hashlenmiş veya dahili ID'ler kullanın
• Kullanıcı-düzeyi detay gerekmiyorsa cihaz veya sunucu tarafında günlük/haftalık agregasyon yapın

Saklama ve erişim kontrolü

Amaç bazlı saklama süreleri tanımlayın (örn. eğilimler için 13 ay, ham loglar için 30 gün). Kullanıcı düzeyi verilere kimlerin erişebileceğini sınırlayın, rol bazlı erişim kullanın ve hassas dışa aktarımlar için audit izi tutun. Bu hem müşterileri korur hem de iç riski azaltır.

Mobil UX: Küçük Ekranlarda Açık Panolar

Mobil panolar, her ekranın bir soruyu hızlıca cevapladığı zaman başarılı olur. Bir web analitik UI'sını küçültmek yerine, başparmakla taramaya uygun tasarlayın: büyük sayılar, kısa etiketler ve net “ne değişti?” sinyalleri.

Ana ekranları taslaklayın (ve odaklı tutun)

Gerçek kararlarla eşleşen küçük ekran setiyle başlayın:

• Genel Bakış: birkaç üst abonelik KPI'sı (örn. aktif aboneler, churn, gelir), her biri küçük bir trend ile kart olarak.
• Eğilimler: bir kerede tek bir metrik, tarih aralığı seçici ve basit bir karşılaştırma (önceki döneme göre).
• Kohortlar: kompakt retention görünümü (örn. hafta 0–8), dokununca açıklama ve segment değiştirme seçeneği.
• Plan karşılaştırma: kullanım dağılımı ve % limit aşımları gibi ana farkları gösteren yan yana plan kartları.
• Kullanıcı detayları (drill-down): zaman çizelgesi stilinde etkinlik ve abonelik durumu, artı “önerilen sonraki adım” (örn. yükseltme önerisi, iletişim isteği).

Mobil dostu görsel desenler

Kartlar, sparklines ve tek amaçlı grafikler (bir eksen, bir legend) kullanın. Filtreler için chip ve alt sayfalar/bottom sheet tercih edin ki kullanıcılar bağlamı kaybetmeden segmentleri değiştirebilsin. Filtreleri minimal tutun: segment, plan, tarih aralığı ve platform genellikle yeterlidir.

Yoğun tabloları tercih etmeyin. Eğer tablo gerekiyorsa (örn. en iyi planlar), kaydırılabilir ve sabit başlıklı yapın, ayrıca açık bir “sırala” kontrolü ekleyin.

Boş durumlar ve “bu ne demek”

Analitik ekranlar genellikle boş başlar (yeni uygulama, düşük hacim, sıfır filtre). Buna hazırlıklı olun:

• Net bir neden: “Bu dönem/segment için veri yok.”
• Bir sonraki adım: “Tarih aralığını genişletin” veya “Enterprise filtresini kaldırın.”
• Her metrik altında kısa bir tanım (“bu ne anlama geliyor”) ve daha derin açıklama için dokunma hedefi.

Dışa aktarma ve paylaşma

Paydaşların uygulama dışında da aksiyon alması gerekiyorsa, hafif paylaşım seçenekleri ekleyin:

• Tablolar ve kohortlar için CSV dışa aktarımı
• Belirli görünüme işaret eden Paylaşılabilir bağlantı (izinlere saygı göstererek)
• İç rapor: mevcut pano anlık görüntüsünü e-posta/Slack'e gönderme

Bu seçenekleri her ekran için tek bir “Paylaş” butonunda toplayın ki UI temiz kalsın.

Abonelik KPI'ları ve Dahil Edilecek Kohortlar

Bir kullanım içgörüleri uygulaması, KPI'ları gerçek davranışla yan yana koyabildiği ölçüde faydalıdır. Yöneticilerin tanıdığı sıkı bir abonelik metrik setiyle başlayın, sonra retention ile ilişkilendiren “neden” metriklerini katın.

Temel abonelik KPI'ları (vazgeçilmezler)

Günlük iş yönetimi için kullanılan metrikleri dahil edin:

• MRR/ARR: mevcut değer ve net değişim (yeni, genişleme, daralma, churn).
• Renewal rate: özellikle yıllık planlar ve kurumsal kontratlar için.
• Churn: logo churn (müşteri kaybı) ile gelir churn (MRR kaybı) ayrı gösterin.
• ARPU: kullanıcı/hesap başına ortalama gelir; plan ve segment karşılaştırmaları için faydalı.
• LTV: basit bir modelle başlamak bile retention önceliklendirmede yardımcı olur.

Kullanımdan reteniyona bağlantılar (metrikleri açıklamaya çevirin)

Abonelik KPI'larını, retention'ı öngören küçük bir kullanım sinyali setiyle eşleştirin:

• Aktivasyon: yeni abonelerin belirli bir süre içinde “aha” eylemini tamamlayan %'si.
• Alışkanlık oluşumu: haftalık aktif günler, ardışıklıklar veya ana aksiyonun tekrar oranı.
• Özellik benimsemesi: 1–3 yapışkan özellik, tüm özellikler değil.

Amaç: biri “Churn arttı—aktivasyon mu düştü yoksa ana özellik mi kullanılmamaya başlandı?” sorusuna cevap verebilsin.

Mobilde önemli kohortlar

Kohortlar küçük ekranlarda trendleri okunur kılar ve yanlış sonuçları azaltır.

• Deneme (trial) kohortu: deneme başlangıç haftasına göre dönüşüm ve erken kayıplar.
• Ay-0 kohortu: ilk ödeme sonrası ilk 30 günde retention ve kullanım.
• Plan seviyesinde kohortlar: Basic vs Pro vs yıllık ve gerekliyse eklentiler.

Yanıltıcı grafiklere karşı koruyucular

Hafif ama görünür koruyucular ekleyin:

• Minimum örnek büyüklüğü göstergesi (örn. “n < 30” uyarısı).
• Mevsimsellik notları (tatiller, promosyon dönemleri) retention ve yenileme görünümlerinde.
• Tanım ipuçları (churn, aktif, yenileme ne sayılır) ki ekipler sayılar üzerinde tartışmasın.

Hızlı referans için kısa bir sözlük sayfasına bağlayın örn. /docs/metrics-glossary.

Uyarılar, Bildirimler ve Eyleme Dönük Öneriler

Kullanım içgörüleri uygulaması, insanların değişiklikleri fark etmesine ve bir şey yapmasına yardım ettiğinde en değerli olur. Uyarılar mobilde özellikle dikkat dağıtıcı olabilir—bu yüzden yardımcı bir asistan gibi hissettirmeli, yüksek sesli alarm gibi değil.

Gerçek kararlara uyan uyarı tiplerini seçin

Yüksek sinyalli küçük bir uyarı setiyle başlayın:

• Anomaliler: “Kullanım olağan haftalık deseninizden 3× fazla.”
• Kullanım düşüşü: “Takım aktivitesi geçen haftaya göre %40 düştü.”
• Limitlere yaklaşma: “Koltuk/kredi/API çağrısının %85'ini kullandınız.”
• Yenileme riski sinyalleri: “Son 14 günde düşük kullanım; yenileme 10 gün içinde.”

Her uyarı iki soruyu yanıtlamalı: Ne değişti? ve Neden umursamalıyım?

Kanalları beklentilerle seçin

Acilik ve kullanıcı tercihine göre kanalları kullanın:

• Uygulama içi: Bağlamsal dürtmeler ve gözden geçirilebilen bir “bildirim merkezi” için en iyisi.
• Push bildirimleri: Zaman duyarlı öğeler (limitler, başarısız ödemeler, yaklaşan yenilemeler) için ayrın. Kısa tutun ve doğrudan ilgili ekrana bağlayın.
• E-posta özetleri (opsiyonel): Haftalık özetler ve uygulamayı her gün açmayan paydaşlar için uygun.

Kurallar anlaşılır—ve ayarlanabilir olsun

Kullanıcılar şu şeyleri ayarlayabilmeli:

• Eşikler: örn. %70 / %85 / %95 limit eşikleri
• Sıklık: anlık vs günlük özet
• Erteleme (snooze): 1 gün / 1 hafta sessize al

Kuralları sade bir dille açıklayın: “4 haftalık ortalamaya göre haftalık kullanım %30'dan fazla düştüğünde beni uyar.”

Her zaman bir sonraki adım sunun

Uyarıları önerilen aksiyonlarla eşleştirin:

• Eğitim: “Manuel işi azaltmak için ‘Automations’ özelliğini deneyin.”
• Özellik ipuçları: “Benimsemeyi artırmak için ekip arkadaşlarını davet edin.”
• Plan değişiklikleri: “Aşım ücreti almamak için yükseltin” veya “%30'un altındaysanız düşürün.”

Amaç: her uyarı net, düşük eforlu bir iç eyleme götürmeli.

Mimari ve Teknoloji Yığını Seçenekleri

Bir abonelik kullanım içgörüleri uygulamasının iki görevi vardır: olayları güvenilir şekilde toplamak ve bunları telefonda hızlı, okunabilir panolara dönüştürmek. Basit bir zihni model kapsamı kontrol altında tutmanıza yardımcı olur.

Pratik yüksek seviyeli mimari

Genel akış şöyledir:

Mobile SDK → ingestion → processing → API → mobil uygulama.

SDK olayları yakalar (ve abonelik durum değişikliklerini), toplu gönderir ve HTTPS üzerinden gönderir. Bir ingestion katmanı bu olayları alır, doğrular ve dayanıklı bir depoya yazar. Processing, olayları günlük/haftalık metriklere ve kohort tablolarına agregate eder. API, ön-agrege edilmiş sonuçları uygulamaya sunar ki panolar hızlı yüklensin.

Ekibinize uyan teknik yaklaşımı seçin

Ekip kapasitenize göre seçim yapın:

• Mobil uygulama: En iyi performans ve platform UI desenleri için Native (Swift/Kotlin); tek kod tabanı ve hızlı yineleme için cross-platform (Flutter/React Native).
• Backend: Herhangi bir tanıdık web framework işe yarar (Node, Python, Go, Java). Auth, rate limiting ve caching için güvenilir kütüphaneler tercih edin.
• Depolama/analitik: Agregatlar ve kullanıcı/hesap meta verisi için ilişkisel veritabanıyla başlayın. Eğer hali hazırda bir warehouse kullanıyorsanız, mobil dostu sorgular için warehouse'tan servis veritabanına agregatlar yayınlayın.

E2E prototip yapmak istiyorsanız (özellikle “mobil UI + API + DB” döngüsü), Koder.ai gibi bir vibe-coding platformu, dashboard ekranlarını, event ingest uçlarını ve agregasyon tablolarını tek bir sohbet odaklı iş akışında doğrulamanıza yardımcı olabilir. Bu, veri kontratları ve UI durumları (boş durumlar, yükleme, kenar durumlar) üzerinde yinelemeyi hızlandırır ve dağıtım/rollback'i snapshotlarla basitleştirir.

Erken planlamanız gereken ölçeklenebilirlik temelleri

Cihazda eventleri toplu gönderin, yüklemeleri kabul edin ve ingestion'ı korumak için rate limit uygulayın. “En iyi öğeler” listeleri için sayfalandırma kullanın. Birçok kullanıcının sık açtığı pano uç noktaları için cache (ve gerekliyse CDN) ekleyin.

Güvenlik esasları

Kısa ömürlü tokenlar (OAuth/JWT) kullanın, least-privilege rolleri uygulayın (ör. viewer vs admin) ve iletimi TLS ile şifreleyin. Event verisini hassas kabul edin: ham eventleri kimlerin sorgulayabileceğini kısıtlayın ve özellikle destek iş akışları için erişimi denetleyin.

Veri Kalitesi, Test ve Gözlemlenebilirlik

Veriniz doğru değilse pano güven kırıcı olur. Veri kalitesini bir ürün özelliği gibi ele alın: öngörülebilir, izlenen ve düzeltmesi kolay olsun.

Her gün çalışacak veri kalitesi kontrolleri

Abonelik kullanım içgörüleri için en yaygın hataları yakalayacak otomatik kontrollerle başlayın:

• Eksik alanlar: olay adı, user ID, zaman damgası, abonelik durumu/plan, uygulama versiyonu.
• Aykırılıklar: “trial_started”da ani sıçramalar, negatif süreler, saatte 10.000 oturum gibi imkansız değerler.
• Çoğaltmalar: retry'ler, offline kuyruk veya çift enstrümantasyon nedeniyle tekrar eden olaylar.
• Geç olaylar: saatler/günler sonra gelen olaylar; bu kohortları ve churn metriklerini bozabilir.

Bu kontrolleri ekibe görünür yapın (sadece veri ekibi gelen kutusunda gizli olmasın). Admin görünümünde basit bir “Veri Sağlığı” kartı genellikle yeterlidir.

Yeni olaylar için QA iş akışı

Yeni olaylar doğrudan üretim panolarına gitmemeli.

Hafif bir doğrulama akışı kullanın:

1. Staging pipeline üretimi yansıtır şekilde olsun.
2. Test hesapları bilinen davranışlarla (trial başlat, iptal et, yenile, yoğun kullanım) olsun.
3. Golden sorgular yayın öncesi sayıları ve ana oranları doğrulasın.

Şema değiştiğinde hangi uygulama sürümlerinin etkilendiğini bilmenizi sağlayacak bir “versiyonlu şema” zihniyeti ekleyin.

Analitik sisteminin kendisi için gözlemlenebilirlik

Boru hattını diğer ürün sistemleri gibi instrument edin:

• Boru hattı gecikmesi: olay oluşturulmadan panoya gelene kadar geçen süre.
• Drop oranları: şema hataları veya boyut limitleri nedeniyle reddedilen olaylar.
• Join kapsamı: olayların yüzde kaçı başarıyla abonelik kayıtlarına bağlanıyor.

Bozuk metrikler için sakin bir oyun kitabı

Bir metrik bozulduğunda tekrarlanabilir bir yanıtınız olsun:

• Etkilenen pano karosunu net bir notla dondurun (“iOS 5.2 için veri gecikmesi”).
• Kapsamı belirleyin (platform, sürüm, plan segmenti).
• Backfill veya yeniden işlem yapın, sonra neden ve önleyici adımı belgeleyin.

Bu oyun kitabı paniği önler ve paydaşların sayılara güvenini korur.

MVP Lansmanı, Geri Bildirim Döngüsü ve İterasyon Yol Haritası

Bir abonelik kullanım içgörüleri uygulaması için MVP, insanların uygulamayı açıp gördüklerini anlayabildiğini ve anlamlı bir aksiyon alabildiğini kanıtlamalıdır. İlk sürümü kasıtlı olarak dar tutun — sonra gerçek kullanım verisine göre genişletin.

"İnce ama kullanışlı" bir MVP tanımlayın

Küçük bir metrik seti, tek bir pano ve temel uyarılarla başlayın.

Örneğin MVP şuları içerebilir:

• 3–5 temel metrik (örn. aktif aboneler, yenilemeler, churn oranı, denemeden ücretliye dönüşüm)
• Birincil segmente geçiş (örn. plan seviyesi veya yeni vs mevcut aboneler)
• Mobil taramaya optimize edilmiş tek bir pano ekranı (üst KPI'lar + bir trend grafik)
• Basit eşik tabanlı uyarılar (örn. “haftalık churn %20 arttı” veya “yenilemeler son 7 güne göre düştü”)

Amaç netliktir: her kart bir cümlede “peki ya ne?” sorusunu yanıtlamalıdır.

Odaklı bir beta çalıştırın ve geri bildirim toplayın

Önce dahili ekiplerle (destek, pazarlama, operasyon), sonra güvenilir birkaç müşteriyle beta yapın. Onlara şu görevleri verin: “Bu hafta gelirin neden düştüğünü bul” ve “Hangi plan churn'a yol açıyor?” gibi.

Geri bildirimi iki akışta yakalayın:

• Nitel: hızlı görüşmeler + 1–2 uygulama içi soru (“Bu içgörü net miydi?”)
• Nicel: insanların gerçekte neye tıkladığı ve neyi görmezden geldiği

İçgörü özelliğinin kullanımını takip edin

Analitik UI'nızı bir ürün olarak ele alın. Şunları takip edin:

• Pano görüntülemeleri ve tekrar ziyaretler
• Kullanılan filtre/segmentler (ve hiç kullanılmayanlar)
• Uyarı etkileşimi (açılma oranı, kapatma, uyarı sonrası alınan aksiyonlar)

Bu, içgörülerin gerçekten yardımcı olup olmadığını ya da sadece “güzel grafikler” olup olmadığını gösterir.

İterasyon yol haritasını planlayın

Küçük sürümlerle yineleyin:

1. Yeni metrikleri, mevcut olanlar düzenli kullanıldığında ekleyin.

2. Açıklamaları geliştirin (sade dil ipuçları, “neden değişti” notları).

3. Hangi soruların en çok sorulduğunu öğrendikten sonra daha akıllı segmentasyon (yeni vs tutulan kullanıcılar, yüksek-değer vs düşük-değer planlar) ekleyin.

Sonraki adımlar

• MVP kapsamınızı iş hedeflerinizle karşılaştırın
• Paketleme fikirlerini inceleyin: /pricing
• Daha fazla rehber için /blog sayfalarını keşfedin

Eğer bunu yeni bir ürün hattı olarak inşa ediyorsanız, tam bir mühendislik döngüsüne başlamadan önce hızlı bir prototip geçişi yapmayı düşünün: Koder.ai ile mobil panoları çizebilir, Go + PostgreSQL backend kurabilir ve “planlama modunda” yineleme yapabilirsiniz; hazır olduğunuzda kaynak kodu dışa aktararak geleneksel bir repoya geçebilirsiniz.