Hizmetler Arası Abonelikleri Yöneten Bir Mobil Uygulama Oluşturun

Bir Abonelik Yönetimi Uygulamasının Çözmesi Gerekenler

Çoğu insanın “abonelik listesi” yoktur. Her şey parçalanmış halde: bir yayın hizmeti bir karta fatura edilir, bir spor salonu başka bir karta, App Store aboneliği farklı bir hesaba bağlıdır ve bir avuç ücretsiz deneme eski e-postalarda gömülüdür. Sonuç tahmin edilebilir: yinelenen abonelikler, unutulmuş yenilemeler ve sürpriz gibi gelen ücretler.

“Hizmetler arası” gerçekte ne demek

Bir abonelik yönetimi uygulaması, değeri birden fazla kaynaktan resmi bir tablo çıkarabildiğinde kazanır—sadece tek bir banka akışından değil.

“Hizmetler arası” genellikle şunları içerir:

• Banka ve kart işlemleri (tekrarlayan ödemeler ve tüccar düzenleri)
• E-posta ve fişler (yenileme bildirimleri, faturalar, “denemeniz sona eriyor” mesajları)
• Uygulama mağazası satın alımları (iOS/Android abonelikleri)
• Manuel girişler (nakit üyelikler, aile planları, yıllık faturalanan hizmetler)

Her kaynak diğerlerinin kaçırdıklarını doldurur. Bir banka akışı ne ödendiğini gösterir, ancak her zaman plan ayrıntılarını vermez. E-postalar yenileme tarihlerini ve fiyat değişikliklerini ortaya çıkarır, ancak yalnızca kullanıcı o posta kutusunu kullandıysa ve gönderici formatı tanınabiliyorsa.

Kullanıcıların beklediği sonuçlar

Kullanıcılar başka bir tablo aramıyor. İstedikleri şunlar:

• Açıklık: aktif aboneliklerin (ve geçmiştekilerin) tek, güvenilir bir listesi
• Kontrol: etiketleme, gruplama ve “buna hâlâ ihtiyacım var mı?” sorusuna hızlı cevaplar
• Daha az sürpriz: yaklaşan yenilemelerin işlem yapmaya yetecek kadar erken gösterilmesi

İyi bir “ilk kazanım”, birinin bir dakika içinde cevaplayabilmesidir: Her ay ne için ödeme yapıyorum ve bir sonraki ne zaman yenileniyor?

Otomasyon hakkında beklentileri belirleyin

Uygulamanın neleri otomatikleştirebileceği ve neleri yapamayacağı konusunda şeffaf olun.

• Banka verileri ile birçok tekrarlayan ücreti tespit edebilirsiniz, ama tam yenileme koşullarını her zaman bilemeyebilirsiniz.
• E-posta/fiş erişimi ile sıklıkla yenileme tarihlerini ve plan adlarını çıkarabilirsiniz, ancak kapsama alanı gelen kutusu geçmişine, gönderici şablonlarına ve kullanıcının seçtiği e-postaya bağlıdır.
• İptaller genellikle tüm tüccarlar için otomatik yapılamaz; uygulama kullanıcıya bağlantılar ve adımlar göstererek rehberlik edebilir, “her yerde tek dokunuşla iptal” vaat etmeyin.

Bu dürüstlük güven oluşturur ve ileride destek sorunlarını azaltır.

Hedef Kullanıcılarınızı ve Kullanım Senaryolarını Tanımlayın

Bir abonelik yönetimi uygulaması, belirli bir kişi için basit olduğunda gerçekten “basittir”. Özelliklerden önce, kimin için inşa ettiğinizi ve ilk 30 saniyede kullanıcıların uygulamayı açtıklarında ne yapacaklarını tanımlayın.

Tasarım yaparken odaklanılacak ana kullanıcı grupları

Öğrenciler genellikle kısıtlı bütçeyle yayın, müzik, bulut depolama ve uygulama denemelerini idare eder. Hızlı cevaplara ihtiyaç duyarlar: “Bu hafta ne yenileniyor?” ve “Ücret alınmadan önce ücretsiz denemeyi nasıl durdururum?”

Aileler genellikle çoklu hizmetleri paylaşır ve kimin ne ödediğini unutur. İstedikleri netlik: “Hangi abonelikler aile üyeleri arasında yineleniyor?” ve “Planları birleştirebilir miyiz?”

Serbest çalışanlar zaman içinde birçok araç biriktirir (tasarım uygulamaları, hosting, faturalama, AI araçları). Harcamaları kategorize etmek ve aylık maliyeti sessizce artıran fiyat artışlarını görmekle ilgilenirler.

Küçük ekipler daha fazla yayılma yaşar: çoklu kullanıcı lisansları, eklentiler ve yıllık yenilemeler. Ana kullanım durumları hesap verebilirlik ve kontrol: “Bu aboneliğin sahibi kim?” ve “Kart süresi dolarsa ne olur?”

Yaygın sorun noktaları (churn oluşturan anlar)

Kullanım senaryolarınız, insanların zaten hissettiği sıkıntılara doğrudan karşılık vermelidir:

• Ücretlenen unutulmuş denemeler
• Bir sonraki tahsilata kadar fark edilmeyen fiyat artışları
• Yinelenen hizmetler (iki müzik planı, birden fazla bulut depolama, örtüşen üretkenlik uygulamaları)
• Banka ekstesinde görünen tüccar adının uygulama adıyla eşleşmemesi nedeniyle “gizemli” ücretler

Erişilebilirlik ve düşük sürtünmeli kurulum

Finansla ilgili uygulamalar davetkar hissettirmelidir. Öncelik verin:

• Açık dil kullanılan etiketler (“Yapılacak bir sonraki ücret” yerine “Bir sonraki ücret” gibi)
• Büyük metin desteği ve net kontrast
• Kullanıcılar ilk günde banka hesabı bağlamak istemese bile işe yarayan bir kurulum yolu (manuel giriş + isteğe bağlı tarama/içe aktarım daha sonra)

Öncelikli platformu önce seçin

Erken kitleniz ücretli abonelikleri, Apple Pay’i ve Apple abonelik ekosistemini daha olası kullanıyorsa iOS ilk seçin; sıkı kontrol ve hızlı QA sağlar.

Daha geniş cihaz kapsaması, fiyat hassasiyeti yüksek pazarlar veya kullanıcıların kart ve operatör faturalamasıyla ödeme yapma eğiliminde olduğu pazarlar hedefleniyorsa Android ilk seçin.

Her iki durumda da, “birincil kullanıcıyı” bir cümleyle yazın (ör. “artık kullanmadığı araçlar için ödeme yapmayı bırakmak isteyen bir serbest çalışan”). Bu sonraki tüm ürün kararlarını yönlendirir.

MVP Kapsamı ve Özellik Önceliklendirmesi

Bir abonelik yönetimi uygulaması için MVP, bir soruya hızlıca yanıt vermelidir: “Ne için ödeme yapıyorum ve ne zaman yenileniyor?” İlk oturum karmaşık veya yoğun hissederse, kullanıcılar kalmaz—özellikle finansal konulara dokunan bir ürün için.

MVP’niz: günlük değer sunan en küçük set

Kolay anlaşılır ve hızlı tamamlanabilir özelliklerle başlayın:

• Abonelik ekleme (önce manuel): hizmet adı, fiyat, faturalama döngüsü, ödeme yöntemi (opsiyonel) ve kategori
• Yenileme tarihleri: bir sonraki ücret tarihi ve yaklaşan yenilemeler için basit bir zaman çizelgesi
• Hatırlatıcılar: varsayılan bir hatırlatıcı (ör. yenilemeden 3 gün önce) ve tek dokunuşla açık/kapalı
• Harcama özeti: aylık toplam ve kategoriye göre hızlı döküm (yayın, üretkenlik, teslimat vb.)

Bu MVP entegrasyonlar olmadan da çalışır. Ayrıca daha sonra otomasyon için temiz bir temel veri sağlar.

Güzel ama ertelenebilir özellikler

Bu özellikler güçlü olabilir, ancak karmaşıklık, köşe durumlar veya üçüncü taraf bağımlılıkları getirir:

• İptal bağlantıları ve adım adım iptal rehberliği
• Paylaşılan abonelikler (maliyet paylaşımı, hane takibi)
• Fiyat değişikliği uyarıları (güvenilir tespit ve kullanıcı güveni gerektirir)

Çaba vs. etkiyle önceliklendirin

Basit bir 2×2 kullanın: yüksek etki/düşük çaba öğelerini önce gönderin (ör. hızlı ekleme akışı, daha iyi hatırlatıcı varsayılanları). Yüksek çaba/belirsiz etki öğelerini (ör. birden çok hanede paylaşılan planlar) talep görene kadar geciktirin.

Başarıyı basit dille tanımlayın

Gerçek kullanıcı kazanımlarını yansıtan metrikler yazın:

• “Bir kullanıcı 5 aboneliği 5 dakikada ekleyebiliyor.”
• “Kullanıcıların %80’i ilk oturumda en az bir hatırlatıcı ayarlıyor.”
• “Kullanıcılar bir sonraki yenileme tarihini 10 saniyeden kısa sürede bulabiliyor.”

Kolay ölçemiyorsanız, şu an öncelik olmamalıdır.

Veri Modeli: Abonelikler, Yenilemeler ve Köşe Durumlar

Bir abonelik yönetimi uygulamasının başarısı, gerçeği temsil edip edememesine bağlıdır. Modeliniz çalışacak kadar basit, ancak karışık faturalama desenleri için yeterince esnek olmalıdır.

Temel nesneler (ayrı tutun)

En azından şu dört şeyi ayrı tutun:

• Merchant/Service: “Netflix,” “Adobe,” “Apple” vb. Marka adı, kategori ve daha sonra eşleştirme için saklanacak tanımlayıcılar
• Subscription: kullanıcının o servisteki ilişkisi (plan adı, fiyat, para birimi, durum, başlama tarihi)
• Renewal cycle: faturalamanın nasıl tekrarlandığı (aylık, yıllık, her 4 hafta, özel aralık) artı bir sonraki yenileme tarihi
• Payment method: kart, banka hesabı, uygulama mağazası faturalaması, PayPal—kullanıcının kullandığı her şey

Bir abonelik zaman içinde ödeme yöntemini değiştirebilir, bu yüzden ödeme kaynağını abonelik kaydına kalıcı olarak gömmeyin.

Bu ayrım, bir tüccarın birden fazla aboneliği olduğunda (ör. iki farklı Google hizmeti) veya bir aboneliğin birden fazla ücreti olduğunda (vergiler, eklentiler) yardımcı olur.

Başlangıçta desteklemeniz gereken zor durumlar

Bazı köşe durumları yaygındır, nadir değildir:

• Yıllık planlar: yılın çoğunda “sessiz” görünür—hem aralığı (1 yıl) hem de son/bir sonraki ücret tarihlerini saklayın ki hatırlatıcılar çalışsın
• Ücretsiz denemeler: bir deneme bitiş tarihi, ücretli fiyat ve otomatik dönüşme bilgisi saklayın
• Askıya alınmış planlar: askıya alma, iptal ile aynı değildir—“askıya alındığı tarihe kadar” veya bir askıya alma penceresi ekleyin
• Paketler: bir ücret birden fazla hizmeti kapsıyorsa (ör. Apple One)—ödeme çoğaltmadan dahil edilen hizmetleri bağlantılı şekilde modelleyin

Durum: ne anlama gelir ve kim ayarlayabilir

Durumu dikkatli tanımlayın. Pratik bir set: aktif, iptal edilmiş ve bilinmiyor:

• Aktif: yakın zamanda faturalama kanıtı var veya kullanıcı onayladı
• İptal edilmiş: kullanıcı açıkça iptal olarak işaretledi (veya doğrulanmış bir iptal tespit edildi)
• Bilinmiyor: bir kez bir şey tespit ettiniz, ama devam edip etmediğini doğrulayamıyorsunuz

Kullanıcıların durumu geçersiz kılmasına izin verin ve kafa karışıklığını önlemek için küçük bir denetim kaydı tutun (“kullanıcı … tarihinde iptal olarak işaretledi”).

Çoklu para birimi ve zaman dilimleri (başlangıçtan planlayın)

Para değerlerini tutar + para birimi kodu olarak saklayın (örn. 9.99 + USD). Zaman damgalarını UTC olarak saklayın ve kullanıcı yerel saat diliminde gösterin—çünkü “1’inde yenilenir” ifadesi, kullanıcı seyahat ettiğinde veya yaz/kış saati değiştiğinde farklılık gösterebilir.

Abonelikleri Hizmetler Arasında Nasıl Keşfedeceksiniz

Abonelik keşfi “girdi sorunu”dur: öğeleri kaçırırsanız, kullanıcılar toplamlara güvenmez; kurulum zahmetliyse, tamamlamazlar. Başarılı uygulamaların çoğu, kullanıcıların hızlı başlamasını sağlayıp zamanla doğruluğu artıracak birden çok yöntem kombinesi kullanır.

Dört yaygın edinme yöntemi

Manuel giriş en basit ve en şeffaftır: kullanıcı hizmeti, fiyatı, faturalama döngüsünü ve yenileme tarihini yazar. Doğrudur (çünkü kullanıcı onaylar) ve her sağlayıcı için çalışır—ancak kurulum zaman alır ve kullanıcı tüm ayrıntıları hatırlamayabilir.

Fiş tarama (fiş veya uygulama mağazası fişlerinin kamerayla OCR’ı) hızlıdır ve sihirli hissi verir, ancak doğruluk ışıklandırma, belge düzeni ve dil etkilerine bağlıdır. Ayrıca fiş formatları değiştikçe sürekli ayar gerektirir.

E-posta ayrıştırma “fiş”, “yenileme” veya “deneme bitiyor” gibi sinyalleri arar, sonra tüccar/tutar/tarihi çıkarır. Güçlü olabilir, ama sağlayıcı şablon güncellemelerine hassastır ve gizlilik endişeleri doğurur. Açık izin istemleri ve kolay “bağlantıyı kes” seçeneği gerektirir.

Banka akışları (kart/banka işlemlerinden çıkarılan tekrarlayan ödemeler) kullanıcıların unuttuğu abonelikleri yakalamada iyidir. Dezavantajlar: düzensiz tüccar adları, yanlış sınıflandırma (üyelikler vs tek seferlik satın almalar) ve banka bağlantısı olan uygulamalarda ek uyumluluk/destek yükü.

Planlamanız gereken ödünleşmeler

• Doğruluk vs. otomasyon: daha fazla otomasyon daha fazla yanlış pozitif/negatif demektir
• Kullanıcı güveni: e-posta/banka erişimi müdahaleci gelebilir—ne okuduğunuzu ve neden okuduğunuzu açıkça belirtin
• Sürekli bakım: ayrıştırma kuralları ve tüccar eşleme düzenli güncelleme gerektirir

Otomasyon başarısız olduğunda güvenli bir geri dönüş

“Önerilen eşleşme + onay” akışı kullanın:

1. Algılanan ücreti/mesajı öneri olarak gösterin (“Görünüyor: Netflix — aylık $15.49”).
2. Onay ve eksik alanları (faturalama döngüsü, yenileme tarihi) isteyin.
3. Kullanıcının “Bu bir abonelik değil” demesine izin verin, böylece kurallarınızı eğitirsiniz ve tekrar önlersiniz.

Lansmanda desteklenecek (ve desteklenmeyecek) kaynaklar

Başlangıçta ve gizlilik mesajlaşmasında net olun:

• Lansmanda desteklenecek: manuel giriş + banka akışıyla tekrarlayan tespit (ya da manuel + fiş tarama—bir otomasyon yolunu seçin)
• İlk aşamada erteleyin: tüm e-posta gelen kutusu ayrıştırması, uluslararası banka bağlantıları ve niş faturalama sistemleri (ör. kurumsal faturalama), hedef kitleniz için merkezi değilse

Burada açıklık, destek taleplerini azaltır ve bozuk beklentileri önler.

Entegrasyon Stratejisi ve Kategorizasyon Kuralları

Entegrasyonlar, bir abonelik yönetimi uygulamasını gerçekten kullanışlı veya sinir bozucu yapan yerdir. Çoğu kullanıcı için işe yarayan bir yaklaşım hedefleyin; kimseyi ilk günde her şeyi bağlamaya zorlamayın.

Entegrasyonların nasıl çalıştığı (bağla, içe aktar, kategorize et)

Aynı dahili boru hattını besleyen birkaç net “girdi” ile başlayın:

• Hesap bağlama: banka hesaplarını ve kartları bağlayarak işlemleri otomatik içe aktarın
• İçe aktar: bankalardan CSV içe aktarma veya temiz tüccar verisi göstermeyen sağlayıcılar için e-posta/fiş yönlendirme
• Uygulama mağazası sinyalleri (opsiyonel): doğruluğu artırmak için Apple/Google abonelik fişlerini veya durumunu içe aktarın

Kaynağı ne olursa olsun, veriyi tek bir formata (tarih, tüccar, tutar, para birimi, açıklama, hesap) normalleştirin, sonra kategorizasyon çalıştırın.

Akıllı hissi veren kurallara dayalı kategorizasyon

Pratik bir başlangıç noktası, daha sonra geliştirebileceğiniz bir kurallar motorudur:

• Tüccar adı desenleri: “NETFLIX.COM” ve “Netflix”i takma adlar ve regex-benzeri desenlerle aynı sağlayıcıya eşleyin
• Tutar + sıklık: ~30 günde bir $9.99 bir güçlü işarettir, tüccar metni karışık olduğunda bile
• Plan tespiti: yaygın katmanları tutar aralıklarına göre izleyin (örn. $9.99 vs $15.49) ve “Basic/Standard/Premium” etiketleyin
• Esneklik pencereleri: gerçek dünya sapmalarını kabul edin (28–33 gün, hafta sonları, tatiller, yıllık yenilemeler)

Kategorizasyonu açıklanabilir yapın. Bir ücret bir abonelik olarak etiketlendiğinde “neden”i gösterin (eşleşen tüccar takma adı + tekrarlayan aralık).

Düzenle ve düzelt döngüsü

Kullanıcılar hataları düzeltecek; bunu daha iyi eşleşmelere dönüştürün:

• Kullanıcıların sağlayıcı, faturalama döngüsü ve kategoriyi değiştirmesine izin verin
• “Geçmişe/ileriye uygula” seçeneği sunun ki yapılan düzeltmeler kalıcı olsun
• Kullanıcıya özel takma adlar (örn. “SPOTIFY*US” → Spotify) kaydedin, global kuralları bozmadan

Sağlayıcıya bağımlılığı azaltın

Entegrasyon sağlayıcıları fiyatlandırma veya kapsama alanı değiştirebilir. Riski azaltmak için entegrasyonları kendi arayüzünüzün arkasına soyutlayın (örn. IntegrationProvider.fetchTransactions()), yeniden işleme için ham kaynak yüklerini saklayın ve kategorizasyon kurallarını tek bir entegrasyona bağımlı olmayacak şekilde tutun.

UX ve Gezinme: Düzenli Kalmayı Kolaylaştırın

Bir abonelik yönetimi uygulaması, kullanıcıların “Bir sonraki ücretim ne ve değiştirebilir miyim?” sorusuna saniyeler içinde cevap verebildiğinde başarılı olur. UX hızlı tarama, az dokunuş ve tahmini olmadan kullanım için optimize edilmelidir.

Deneyimi sabitleyecek ana ekranlar

Familiar ve çoğu yolculuğu kapsayan dört çekirdek ekranla başlayın:

• Gösterge paneli: yaklaşan 7/30 gün önizlemesi, beklenen toplam harcama ve uyarılar (fiyat artışları, biten denemeler)
• Abonelik listesi: temiz, aranabilir bir dizin; filtreler (aktif, denemeler, iptal edilmiş, yıllık) ve basit sıralama (bir sonraki yenileme, en yüksek maliyet)
• Abonelik detayı: plan, yenileme takvimi, ödeme kaynağı, geçmiş ve notlar için tek bir yer
• Takvim: “bu hafta kartıma ne düşecek?” sorusunu görsel olarak yanıtlayan bir görünüm

Netlik zekâsızlıktan üstündür

Liste ve kartlarda, ana bilgileri bir bakışta gösterin:

• Bir sonraki ücret tarihi (sadece “aylık yenilenir” demeyin)
• Tutar (faturalama döngüsü ile)
• Ödeme kaynağı (kart/hesap etiketi)

Bu üç öğeyi her ekranda tutarlı gösterin ki kullanıcı kalıbı bir kere öğrensin.

Sürtünmeyi azaltan hızlı eylemler

İnsanlar bu uygulamayı işlem yapmak için açar, gezinmek için değil. Abonelik detayında (ve istenirse liste üzerinde kaydırma eylemleriyle) hızlı eylemler koyun:

• İptal olarak işaretle (opsiyonel “iptal tarihinde” alanı)
• Yenileme tarihini değiştir (tespit edilen tarih yanlışsa veya kullanıcı plan değiştirdiyse)
• Not ekle (örneğin “aileyle paylaşılıyor”, “sezon finalinden sonra iptal et”)

Minimum onboarding, sonra isteğe bağlı güç

Onboarding’i hafif tutun: manuel eklemeyi bir dakikadan kısa sürede yapmayı hedefleyin (isim, tutar, yenileme tarihi). Kullanıcı değer gördükten sonra, isteğe bağlı bağlantılar/içe aktarmalar “seviye atlama” olarak sunulsun, zorunlu olmasın.

Kullanıcıların Kapatmayacağı Hatırlatmalar ve Bildirimler

Bildirimler, uygulamayı ara sıra açılan bir uygulamadan gerçekten güvenilen bir araca çevirir. Hatırlatıcılar zamanında, alakalı ve kullanıcının kontrolünde hissettiğinde işe yarar.

Desteklenmesi gereken çekirdek bildirim türleri

Gerçek “para/ zaman kazandıran” anlara denk gelen küçük bir setle başlayın:

• Yaklaşan yenileme: “Netflix yarın yenileniyor — $15.99.” Bu temel değerdir.
• Deneme bitişi: öne çıkarılmalı, çünkü genellikle ücretli plana dönüşür
• Fiyat değişikliği: bir artış (veya azalma) tespit edildiğinde uyarı
• İnaktiflik kontrolü: “Spotify’ı 30 gündür kullanmadınız—hala gerekli mi?” gibi nazik bir hatırlatma (MVP’de kullanıcı girdisi veya hafif kestirimlere dayanır)

Bildirim içeriğini tutarlı tutun: hizmet adı, tarih, tutar ve net bir eylem (detayları aç, iptal olarak işaretle, ertele).

Kullanıcılara gerçek kontrol verin (ayarları gömmeyin)

Kullanıcılar spamlandıklarını hissettiklerinde bildirimleri kapatır. Basit ve görünür kontroller oluşturun:

• Zamanlama: örn. yenilemeden 1 gün, 3 gün, 7 gün önce
• Sessiz saatler: “Gece beni bilgilendirme”
• Frekans/toplama: günlük özet vs tek tek uyarılar
• Abonelik bazlı anahtarlar: asla iptal etmeyecekleri “sabit” abonelikler için hatırlatmaları kapatma

Kullanışlı bir desen: yararlı ayarları varsayılan olarak açık bırakın, sonra hatırlatıcılar UI’sinden erişilebilen net bir “Özelleştir” girişi sunun.

Kanallar: push, uygulama içi, e-posta (MVP için ne seçilmeli)

MVP için genellikle push + uygulama içi yeterlidir: push zamanında aksiyon almayı sağlar, uygulama içi geçmişi gözden geçirme imkanı verir.

E-posta sadece net bir gerekçe varsa ekleyin (ör. push izin vermeyen kullanıcılar veya aylık özet). E-posta dahilse, isteğe bağlı ve kritik uyarılardan ayrı tutun.

Uyarı yorgunluğunu önlemek için akıllı varsayılanlar

Gürültü yaratmamak için makul toplama kullanın:

• Birden fazla abonelik yakında yenilenecekse, tek bir özet gönderin (“Bu hafta 3 yenileme var”) ve tıklanınca listeyi gösterin
• Sadece yüksek etkili olaylar için yükseltin: deneme yarın bitiyor, olağandışı büyük yenileme, fiyat artışı
• Kullanıcı bir aboneliği iptal olarak işaretlediyse, gelecekteki hatırlatmaları derhal durdurun

Amaç basit: hatırlatıcılar kişisel bir asistan gibi hissettirsin—pazarlama kanalına dönüşmesin.

Gizlilik, Güvenlik ve Kullanıcı Güveni

Abonelik yönetimi uygulaması hızla “finansa yakın” olur; hatta para hareketi yoksa bile. Kullanıcılar hesapları yalnızca ne topladığınızı, nasıl koruduğunuzu ve nasıl çıkabileceklerini anlıyorlarsa bağlar.

Hangi hassas verilere dokunabilirsiniz bilmek

Abonelik keşfi yöntemlerinize bağlı olarak şunlarla uğraşabilirsiniz:

• E-posta içeriği ve meta verileri (gönderen, konu satırı, zaman damgaları)
• İşlem detayları (tüccar adı, tutar, para birimi, tarih)
• Hesap tanımlayıcıları (banka bağlantı tokenları, maskelenmiş hesap numaraları)
• Abonelik tanımlayıcıları (servis kullanıcı ID’leri, fatura numaraları)
• Cihaz tanımlayıcıları ve push bildirim tokenları
• Kişisel profil verileri (isim, bölge, tercihler)

Bunların hepsini hassas kabul edin. Hatta “sadece tüccar adları” bile sağlık, ilişki veya siyasi eğilimler gibi hassas bilgileri açığa çıkarabilir.

Güveni koruyan ilkeler

Veri minimalizasyonu: sadece temel değeri sunmak için gerekeni toplayın (örn. yenileme tarihi ve tutar), tam mesajlar veya tüm işlem akışları yerine özetlerle yetinin.

Kullanıcı onayı: her bağlayıcı açık olmalı. E-posta tabanlı keşif sunuyorsanız, bu isteğe bağlı ve hangi verilerin okunacağı/ saklanacağı açıkça belirtilmiş olmalı.

Açık izinler: “e-postanıza erişim” gibi belirsiz istemlerden kaçının. Kapsamı açıklayın: “Bilinen abonelik tüccarlarından fişleri bulmak için faturaları arıyoruz.”

Güvenli saklama ve erişim kontrolleri

Temel ama iyi yapın:

• Veritabanı ve yedekler için dinamik şifreleme (encryption at rest)
• Güvenli anahtar yönetimi (platform KMS kullanın; sırları uygulamaya gömmeyin)
• En az ayrıcalık prensibi ile iç servisler ve personel sadece gerekli verilere erişsin
• Token yönetimi: üçüncü taraf erişim tokenlarını güvenli saklayın, mümkünse döndürün ve analitik sistemlerden izole edin
• Günlük kaydı hijyeni: loglarda ham e-postalar, tam işlemler veya tokenlar yer almasın

Üçüncü taraf veri sağlayıcıları kullanıyorsanız, hangi veriyi onların sakladığını ve sizin neyi sakladığınızı belgeleyin—kullanıcılar genellikle tüm zinciri sizin yönettiğinizi varsayar.

Kullanıcıların gerçekten anlayabileceği gizlilik UX’i

Gizliliği yasal metin değil ürün özelliği yapın:

• Onboarding ve ayarlarda basit bir “Ne topluyoruz / Neden / Ne kadar süreyle” sayfası
• Granüler anahtarlar (örn. “E-posta fiş taraması”, “Banka bağlantısı”, “Pazarlama analitiği”)
• Net veri dışa aktarma ve verimi sil işlemleri ile beklenen zaman çizelgeleri

Yardımcı bir desen: bir veri kaynağını bağlamadan önce uygulamanın neleri kaydedeceğinin ön izlemesini (tüccar, fiyat, yenileme tarihi) gösterin.

İlgili kararlar için, bildirim stratejinizi güven ile hizalayın (bakınız: /blog/reminders-and-notifications-users-wont-disable).

Uygulama Mimarisi ve Teknoloji Seçimleri (Düz İngilizceyle Özet)

Mimari, verinin nerede saklandığı ve nasıl hareket ettiğidir. Bir abonelik yönetimi uygulaması için en büyük erken karar öncelikle yerel mi yoksa bulut senkronizasyonu mu olacağıdır.

Yerel-öncelikli vs. bulut senkronizasyonu

Yerel-öncelikli demek, aboneliklerin öncelikle telefonda saklanması demektir. Hızlı açılır, çevrimdışı çalışır ve daha mahrem hissedilir. Dezavantajı, telefon değiştirme veya çok cihazlı kullanım durumlarında ek ayarlar (içe/dışa aktarma, yedekleme veya isteğe bağlı senkron) gerektirmesidir.

Bulut senkronizasyonu ise verinin sunucularınızda saklandığı ve telefona aynalandığı modeldir. Çoklu cihaz desteği daha kolaydır ve paylaşılmış kurallar/kategorizasyon güncellemeleri daha basittir. Dezavantajı hesap yönetimi, güvenlik ve kesinti yükümlülükleriyle daha yüksek karmaşıklıktır.

Pratik orta yol: yerel-öncelikli + isteğe bağlı oturum açma ile senkron/yedekleme. Kullanıcı uygulamayı hemen deneyebilir, sonra isteğe bağlı katılabilir.

Gerekli temel bileşenler (muhtemel)

• Mobil uygulama (iOS/Android): UI, yerel veritabanı, bildirim zamanlama ve “son bilinen durum”
• Arka uç API (MVP’de isteğe bağlı): oturum açma, senkron, cihazda çalışması zor entegrasyonlar ve paylaşılan kategorizasyon kuralları
• Veritabanı: kullanıcılar (varsa), abonelikler, tüccarlar, kurallar ve denetim geçmişini saklama
• Arka plan işleri: entegrasyon güncellemelerini alma, döviz kuru yenileme, e-posta/push gönderimi ve temizlik/yeniden deneme işleri

Hızlı başlamak için Koder.ai ile geliştirme (prototipten üretime)

Hız sizin en büyük kısıtınızsa, Koder.ai gibi bir platform, ürün spesifikasyonundan çalışan bir abonelik takipçisine hızla geçmenize yardımcı olabilir—sizi bir no-code kilidine sokmadan. Koder.ai, sohbet arayüzü ve ajan tabanlı LLM iş akışı etrafında kurulu bir vibe-coding platformu olduğundan, ekipler çekirdeği (abonelik ekle → yenileme takvimi → hatırlatıcılar) günler içinde iterasyona açıp gerçek kullanıcı geri bildirimleriyle rafine edebilir.

Koder.ai bu tür bir uygulama için özellikle uygundur çünkü yaygın yığınlarla iyi uyum sağlar:

• Web: yönetim panoları için React (kurallar motoru, tüccar takma ad yönetimi, destek araçları)
• Arka uç: Go + PostgreSQL (abonelikler, yenilemeler, denetim izleri ve arka plan işleri)
• Mobil: Flutter ile çapraz platform iOS/Android teslimi

Daha fazla kontrol gerektiğinde, Koder.ai kaynak kodu ihracı destekler, ayrıca dağıtım/barındırma, özel alan adları, anlık görüntüler ve geri alma özellikleri sunar—bildirim mantığını veya kategorizasyon kurallarını ayarlarken güvenli sürümler için faydalıdır. Fiyatlandırma ücretsiz, pro, business ve enterprise seviyelerini kapsar; paylaşırsanız öğrendiklerinizi, erken geliştirme maliyetlerini telafi edecek kredi kazanma programı ve yönlendirmeler de vardır.

Senkron davranışı: çevrimdışı, çakışmalar, yeniden denemeler

Senkron destekliyorsanız, iki cihazda eş zamanlı düzenlemeler olduğunda “hangisi kazanır”ı tanımlayın. Yaygın seçenekler:

• Son düzenleme kazanır (basit, birçok alan için kabul edilebilir)
• Alana göre birleştirme (notlar/etiketler için daha güvenli)

Uygulamayı çevrimdışı kullanılabilir yapın: değişiklikleri yerelde sıraya alın, sonra senkron edin ve idempotent isteklerle (ağ dalgalanması çoğaltma yaratmasın) güvenle yeniden deneyin.

Performans: hızlı, sessiz, pil dostu

Yerel veritabanından önce okuyarak anında açılma hedefleyin, sonra arka planda yenileyin. Pil kullanımı düşük tutmak için ağ çağrılarını toplu yapın, sürekli yoklamadan kaçının ve OS arka plan zamanlamasını kullanın. Yaklaşan yenilemeler ve aylık toplam gibi ortak ekranları önbelleğe alın ki kullanıcı her açışta hesap beklemesin.

Test Planı: Doğruluk, Güvenilirlik ve Köşe Durumları

Abonelik yönetimi uygulaması, tutarlı doğru sonuçlar verdikçe güven kazanır. Test planınız doğruluk (tarihler, toplamlar, kategoriler), güvenilirlik (içe aktarma ve senkron) ve gerçek faturalama sistemlerinde görülen köşe durumlarına odaklanmalıdır.

“Doğru” ne anlama geliyor yazın

Test etmeden önce geçme/kalma kurallarını belirleyin. Örnekler:

• Yenileme tarihi doğruluğu: bir sonraki yenileme zaman dilimleri arasında ve plan değişikliklerinde doğru olmalı
• Toplamlar: aylık ve yıllık harcama, desteklenen takvim programına göre (vergiler/ücretler dahilse) eşleşmeli
• Kategorizasyon: aynı tüccar her seferinde aynı kategoriye eşlenmeli ve kullanıcı düzeltmeleri geri dönmemeli

Otomatikleştirmeye değer köşe durumları

Tekrarlayan ödemeler karmaşık tarih hesapları içerir. Otomatik testler oluşturun:

• Yaz/kış saati değişiklikleri (bildirim zamanı ve yenileme tarihi beklenmedik şekilde kaymasın)
• Artık yıllar (29 Şubat davranışı)
• Ay 29/30/31’e faturalama olan durumlar (kısa aylarda ne olur)
• Çoklu para birimi abonelikleri (dönüşüm, yuvarlama ve gösterim kuralları)
• Denemeden ücrete geçiş, askıya alma, iade ve döngü ortasında plan yükseltmeleri

Her sürüm için tıklama akışları (QA checklist)

Tekrarlanabilir bir kontrol listesi tutun:

• Onboarding (manuel giriş vs. kaynak bağlama)
• Kaynak bağlama (izinler, hatalar, yeniden denemeler)
• İçe aktarma ve çoğaltma engelleme
• Abonelik düzenleme (fiyat, döngü, kategori, tüccar adı)
• Bildirim kurulumu, teslimi ve “ertele” davranışı

Yayından sonra izleme

Testler lansmanla bitmez. İzleme ekleyin:

• Çökme raporlaması ve yavaş ekranlar
• İçe aktarma hataları (sağlayıcı, hata türü, sıklık)
• Bildirim teslim sorunları (planlanan vs teslim edilen, izin değişiklikleri)

Her destek bileti yeni bir test vakasıdır—böylece doğruluk zamanla gelişir.

Lansman, İterasyon ve Başarıyı Ölçme

Bir abonelik yönetimi uygulamasını başlatmak tek seferlik bir olay değildir—kontrollü bir açılıştır; insanların gerçekte ne yaptığını (ve nerede takıldıklarını) öğrenir, sonra haftalar içinde deneyimi sıkılaştırırsınız.

Pratik bir lansman sıralaması

İlk olarak küçük bir alfa grubu (10–50 kişi) ile başlayın; bu kullanıcılar pürüzleri tolere eder ve detaylı geri bildirim verir. Birçok aboneliği ve farklı faturalama alışkanlıkları (aylık, yıllık, denemeler, aile planları) olan kullanıcılar arayın.

Sonra kapalı bir beta (birkaç yüz ila birkaç bin) yapın. Burada ölçeklenmiş güvenilirliği doğrulayın: bildirim teslimi, abonelik tespit doğruluğu ve eski cihazlarda performans. Basit bir uygulama içi geri bildirim düğmesi koyun ve hızlı yanıt verin—hız güven oluşturur.

Halihazırda çekirdek döngü: abonelik ekle → hatırlatıcı al → istenmeyen yenilemeleri önleme çalışıyorsa, genel sürüme geçin.

Hızla değeri anlatan mağaza varlıkları

Ekran görüntüleriniz vaadi saniyeler içinde iletmelidir:

• “Abonelikleri tek yerde bulun ve takip edin”
• “Gelecek hafta ne yenileniyor bilin”
• “Yenilenmeden önce hatırlatıcılar alın”

Pazarlama yoğun grafikler yerine gerçek UI kullanın. Bir ücretli duvarınız varsa, mağaza listelemesinin ima ettiğiyle tutarlı olduğundan emin olun.

Churn önleyen onboarding desteği

İlk abonelik eklendiğinde kısa bir ipucu, “Neden X algılanmadı?” sorusunu cevaplayan bir SSS ve açık destek yolu (e-posta veya form) ekleyin. Bunları Ayarlar ve onboarding’den erişilebilir kılın.

Bir sonraki düzeltilecekleri söyleyen metrikler

Lansman sonrası birkaç metrik izleyin:

• Aktivasyon: 24 saat içinde en az 1 abonelik ekleyenlerin oranı
• Tutunma: 1. hafta ve 1. ay geri dönüş oranı
• Aktif kullanıcı başına eklenen abonelik sayısı
• Uyarılara tepki: açılma oranı ve “işlendi olarak işaretleme” oranı

Bunları kullanarak yinelemeleri önceliklendirin: sürtünmeyi kaldırın, tespiti geliştirin ve hatırlatıcıları gürültü değil yardımcı olacak şekilde ayarlayın.