Tüm yazılar

Mobil Uygulamada Hesap Silme Akışı Nasıl Tasarlanır?

WebinleYayımlanma: Güncellenme:

Mobil uygulamada hesap silme neden ayrı bir ürün akışıdır?

Mobil uygulamada hesap silme, ayarlar ekranına eklenen tek bir düğmeden ibaret değildir. Kullanıcı kimliğinin doğrulanması, hangi verilerin hemen silineceği, yasal veya operasyonel nedenle hangi kayıtların belirli süre korunacağı, aktif aboneliğin nasıl ele alınacağı ve bağlı sistemlere hangi talimatların gönderileceği birlikte planlanmalıdır.

Kullanıcı açısından beklenti nettir: hesabını uygulama içinden bulabilmeli, işlemin sonucunu anlayabilmeli ve gereksiz engellerle karşılaşmamalıdır. İşletme açısından ise yanlış hesabın silinmesini önlemek, talebi izlenebilir biçimde yürütmek ve geri döndürülemeyen adımları açıkça anlatmak gerekir. İyi tasarlanan akış, kullanıcı kontrolünü güçlendirirken destek ekibinin belirsiz taleplerle uğraşmasını azaltır.

Hesap silme ile uygulamayı kaldırmayı ayırın

Telefon üzerinden uygulamayı kaldırmak, sunucudaki kullanıcı hesabını veya verileri otomatik olarak silmez. Bu ayrım ayarlar ve yardım metinlerinde açıkça anlatılmalıdır. Kullanıcı uygulamayı sildiğinde oturum anahtarı cihazdan kalkabilir; ancak profil, sipariş geçmişi, tercihler veya diğer sunucu kayıtları varlığını sürdürebilir.

Hesap kapatma, geçici dondurma ve kalıcı silme seçenekleri de aynı işlem gibi sunulmamalıdır. Dondurma özelliği gerçekten destekleniyorsa kapsamı açıklanabilir. Desteklenmiyorsa kullanıcıyı vazgeçirmek için varmış gibi gösterilmemelidir. Kalıcı silme seçeneği görünür, anlaşılır ve uygulamanın genel gezinme yapısı içinde erişilebilir olmalıdır.

Silinecek veri kapsamını envanterle belirleyin

Hesap verisi çoğu zaman tek bir veritabanı tablosunda bulunmaz. Profil bilgileri, dosyalar, bildirim tercihleri, cihaz anahtarları, destek kayıtları, analiz kimlikleri ve üçüncü taraf sistemlerdeki kayıtlar farklı yerlerde tutulabilir. Önce hangi sistemin hangi kullanıcı verisini tuttuğu çıkarılmalıdır.

Veri envanterinde şu başlıklar yer alabilir:

  • Kullanıcının doğrudan sağladığı profil ve iletişim bilgileri
  • Uygulama kullanımında oluşan içerik, favori ve tercih kayıtları
  • Sipariş, fatura veya sözleşme gibi işlem kayıtları
  • Bildirim anahtarları ve bağlı cihaz bilgileri
  • CRM, destek veya e-posta hizmetindeki ilişkili kayıtlar
  • Yedekleme sistemleri ve teknik loglardaki kullanıcı tanımlayıcıları

Her kayıt için silme, anonimleştirme veya zorunlu saklama kararı belgelenmelidir. Hukuki yorum gerekiyorsa yetkili danışmanla değerlendirilmelidir; ürün ekibi kendi başına kesin saklama süresi uydurmamalıdır.

Kullanıcı kimliğini yeniden doğrulayın

Aktif oturum, her zaman geri döndürülemeyen işlem için yeterli güvence olmayabilir. Telefon başkasının eline geçmiş, oturum uzun süredir açık kalmış veya cihaz ortak kullanılıyor olabilir. Risk seviyesine göre parola, tek kullanımlık kod ya da yeniden oturum açma adımı istenebilir.

Doğrulama yöntemi kullanıcıyı gereksiz yere kilitlememelidir. Sosyal giriş kullanan kişinin hiç oluşturmadığı bir parolayı girmesi istenmemelidir. E-posta veya telefon erişimini kaybeden kullanıcı için destek süreci tanımlanabilir; bu süreçte kimlik doğrulama için gereğinden fazla kişisel veri istenmemelidir. Başarısız denemeler sınırlandırılmalı ve güvenlik kayıtları izlenebilir tutulmalıdır.

Onay ekranında ne anlatılmalı?

Silme öncesindeki onay ekranı kısa fakat açıklayıcı olmalıdır. Hesabın kapanacağı, erişimin sona ereceği, kullanıcı tarafından oluşturulan içeriklerin durumu ve işlemin geri alınıp alınamayacağı anlaşılır dilde belirtilmelidir. Belirli kayıtlar hemen silinmiyorsa bunun nedeni genel bir ifadeyle açıklanmalı; kullanıcıdan gizlenmemelidir.

Düğme metni “Devam” yerine eylemi açıkça ifade etmelidir. Birden fazla onay kutusuyla kullanıcıyı yormak yerine kritik sonucu tek bir net doğrulama adımında göstermek daha uygundur. Karanlık tasarım kalıpları, düğmeyi görünmez kılmak veya kullanıcının kararını değiştirmek için art arda ekran göstermek güveni zedeler. Alternatifler yalnızca gerçekten faydalıysa sunulmalıdır.

Abonelikler ve uygulama içi satın almalar

Hesabın silinmesi, uygulama mağazasındaki aboneliği her durumda otomatik iptal etmeyebilir. Kullanıcıya abonelik durumunun nereden yönetildiği açıkça anlatılmalıdır. Silme ekranı aktif aboneliği kontrol edebiliyorsa ilgili mağaza yönetim bağlantısını gösterebilir. Ancak uygulama, gerçekleştiremediği bir iptal işlemini tamamlanmış gibi sunmamalıdır.

Satın alınan hakların, geri yükleme kayıtlarının veya fatura bilgilerinin silme sonrasında nasıl ele alınacağı ürün modeline göre değişir. Bu kararlar geliştirme başlamadan önce netleştirilmelidir. Mobil uygulamalarda abonelik altyapısı ile hesap silme akışı aynı hak yönetimi kurallarına dayanmalıdır.

Arka planda silme işi nasıl yürütülür?

Talep onaylandığında işlem tek bir uzun API çağrısında bütün sistemleri temizlemeye çalışmamalıdır. Hesap önce girişe kapatılabilir, silme işi benzersiz işlem kimliğiyle kuyruğa alınabilir ve bağlı sistemler sırayla işlenebilir. Her adım başarılı, bekliyor veya hata durumuyla kaydedilmelidir.

Tekrar denemeler aynı işlemi güvenli biçimde sürdürebilmelidir. Bir sistem yanıt vermediğinde daha önce tamamlanan adımlar geri alınmamalı veya aynı kayıt yanlışlıkla yeniden oluşturulmamalıdır. Kalıcı hata oluşursa destek veya teknik ekibe, kişisel veriyi gereksiz yere içermeyen bir uyarı gönderilmelidir. Silme tamamlandığında eski oturumlar, yenileme anahtarları ve bildirim tokenları geçersiz kılınmalıdır.

Kullanıcıya durum ve sonuç bilgisi verin

Bazı silme işlemleri anında, bazıları ise bağlı sistemler nedeniyle gecikmeli tamamlanabilir. Kullanıcı uygulamadan çıkartıldığında ne olacağını ve doğrulama mesajının hangi kanaldan geleceğini bilmelidir. E-posta gönderilecekse mesajda gereksiz hesap ayrıntıları yer almamalı, kötüye kullanılabilecek bağlantılar sınırlı süreli olmalıdır.

İşlem bekleme sürecindeyse kullanıcı tekrar giriş yaptığında açık bir durum ekranı gösterilebilir. İptal süresi sunuluyorsa ne zamana kadar geçerli olduğu ve iptal edildiğinde hangi verilerin geri geleceği açıklanmalıdır. Böyle bir özellik yoksa varmış gibi umut verilmemelidir. Tamamlanma kaydı destek ekibinin doğrulayabileceği şekilde tutulmalıdır.

Bağlı sistemleri ve yedekleri unutmayın

CRM, e-posta gönderim servisi, müşteri destek aracı ve dosya depolama hizmeti silme planına dahil edilmelidir. Ana veritabanındaki kullanıcıyı kaldırıp bu sistemlerdeki tanımlayıcıları bırakmak eksik bir uygulamadır. Her sağlayıcının API sınırları, hata yanıtları ve silme yeteneği önceden kontrol edilmelidir.

Yedeklerden tek bir kullanıcı kaydını anında ayıklamak her zaman mümkün olmayabilir. Bu durumda geri yüklenen yedeğin silme talepleriyle yeniden uzlaştırılacağı bir süreç gerekir. Amaç, geçmiş yedek geri getirildiğinde silinmiş hesabın yeniden aktif hâle gelmesini önlemektir. Teknik ve hukuki gereksinimler kayıt altına alınmalı, kullanıcıya verilen açıklamalar gerçek sistem davranışıyla uyumlu olmalıdır.

Test senaryoları ve kalite kontrol

Yeni hesap, eski hesap, sosyal giriş, aktif abonelik, birden fazla cihaz ve bağlantı kesintisi senaryoları test edilmelidir. Kullanıcının onay ekranından vazgeçmesi, işlemi art arda başlatması ve silme sürerken yeniden giriş yapması kontrol edilmelidir. Erişilebilirlik açısından ekran okuyucu etiketleri, odak sırası ve hata mesajları incelenmelidir.

Test ortamındaki silme talepleri canlı veriye bağlanmamalıdır. Bağlı servisler için deneme hesapları kullanılmalı ve her sistemde beklenen sonucun oluştuğu doğrulanmalıdır. Uygulama mağazasında yayımlanmadan önce destek metinleri, gizlilik açıklamaları ve uygulama içindeki yol aynı davranışı tarif etmelidir.

Güvenilir hesap silme akışının özeti

Sağlıklı mobil uygulamada hesap silme akışı; görünür erişim, yeniden kimlik doğrulama, açık sonuç anlatımı, belgelenmiş veri envanteri ve güvenli arka plan işlemlerinden oluşur. Kullanıcıyı vazgeçirmeye çalışan tasarım yerine kararını anlayan ve uygulayan bir deneyim kurulmalıdır.

Profesyonel mobil uygulama geliştirme sürecinde hesap yaşam döngüsü, kayıt ve giriş ekranları kadar erken planlanmalıdır. Böylece gizlilik talepleri sonradan eklenen kırılgan bir özellik olmaz; uygulamanın veri modeli, destek süreci ve mağaza yayın hazırlığıyla birlikte çalışan sürdürülebilir bir ürün özelliğine dönüşür.