Apple'ın Zorunlu Hesap Silme Kuralı Nedir? Uygulamanız Bu Yüzden Reddedilebilir

Bu hesap silme kuralı, Yönergeler'in 5.1.1 numaralı "Veri Toplama ve Saklama" bölümünün bir parçasıdır. Dolayısıyla kural, yalnızca sosyal uygulamaları değil; hesap açılışı isteyen e-ticaret, rezervasyon, finans ve SaaS uygulamalarını da kapsar. Madde numaraları zamanla değişebileceği için güncel metni her zaman developer.apple.com üzerinden kontrol edin.

Ekip olarak sık karşılaştığımız bir yanlış kanı şu: kuralın yalnızca büyük ölçekli, milyonlarca kullanıcısı olan uygulamalar için geçerli olduğunu düşünmek. Oysa Apple, bu beklentiyi mağaza büyüklüğüne, bütçeye ya da sektöre bakmadan uygular; bir kişilik ekibin çıkardığı ilk uygulama da aynı standarda tabidir.

İşletme sahibi açısından pratik sonuç şudur: bu kuralı bir "geliştirici detayı" olarak değil, bir ürün kararı olarak ele almak gerekir. Hesap silme akışını tasarım aşamasına dahil etmemek, gönderim gününde beklenmedik bir gecikmeye, dolayısıyla pazarlama takviminde kaymaya yol açabilir.

Bu başlık altında sorduğumuz soru basittir: uygulamanız bir hesap açtırıyor mu? Cevap evetse kural devreye girer. Cevap hayırsa, yani uygulama tamamen anonim çalışıyorsa bu madde sizi ilgilendirmez. Ekip, her proje başında bu kısa soruyu sorarak kapsamı hızlıca netleştirir.

Bu Kural Hangi Uygulamalar İçin Geçerlidir?

Kural, hesap oluşturma seçeneği sunan her uygulamayı kapsar; üyelik modeli, teslimat uygulaması, rezervasyon sistemi ya da kurumsal SaaS paneli arasında fark yoktur. Öte yandan anlamlı hesap tabanlı özelliği olmayan bir uygulama, kullanıcıyı hiç giriş yapmaya zorlamayabilir.

• Üyelik ve sadakat programı uygulamaları
• E-ticaret ve teslimat uygulamaları
• Rezervasyon ve randevu uygulamaları
• Kurumsal SaaS ve panel uygulamaları

Teknoloji tarafında native ya da cross platform seçimi bu zorunluluğu değiştirmez; kural, uygulamanın hangi çerçeveyle yazıldığına bakmaz. Ayrıca kural, ücretsiz ya da ücretli uygulama ayrımı da yapmaz; reklam destekli bir uygulama da tam olarak aynı yükümlülüğü taşır.

Örnek bir senaryo kuralı somutlaştırır: bir randevu uygulaması, kullanıcıdan önce telefon numarasıyla hızlı kayıt ister. Bu kayıt basit görünse de teknik olarak bir "hesap" sayılır; dolayısıyla uygulama, bu kaydı silecek bir yol da sunmalıdır.

Benzer bir örnek, bir SaaS panelinde ücretsiz deneme için açılan hesaptır. Deneme süresi bitse ve kullanıcı ödeme yapmasa da bu kayıt sistemde durur; dolayısıyla panel, bu deneme hesabını da aynı silme akışına dahil etmelidir.

Küçük bir e-ticaret uygulaması da aynı kapsamdadır. Kullanıcı tek seferlik alışveriş için hesap açabilir. Bu hesap az kullanılsa da sistemde kayıtlı kalır. Dolayısıyla uygulama, bu kaydı da silebilen bir yol sunmalıdır. Ekip, bu ayrıntıyı atlarsa gönderim sırasında sürpriz bir ret alabilir.

Hesap Silme Kuralı Hangi Resmi Yönergeye Dayanır?

Hesap silme kuralı, App Store İnceleme Yönergeleri'nin "Account Sign-In" başlıklı 5.1.1(v) alt maddesine dayanır ve bu madde "Veri Toplama ve Saklama" bölümünün altında yer alır. Apple, bu maddeyi resmi geliştirici sitesinde yayınlar.

Apple ayrıca ayrı bir yardım makalesinde uygulama içi silme akışının nasıl kurulması gerektiğini ayrıntılı biçimde anlatır. Bu nedenle ekip olarak her iki kaynağı da gönderim öncesi okumanızı öneririz: App Store İnceleme Yönergeleri ve hesap silme uygulama rehberi.

İki kaynağı ayrı ayrı açmanın pratik bir faydası var: yönergeler maddenin kısa tanımını verir, yardım rehberi ise kabul edilen ve edilmeyen akış örneklerini gösterir. Gönderim öncesi her iki metni birlikte okumak, ret e-postasını baştan okumaktan çok daha az zaman alır.

Ekip olarak bu iki kaynağı periyodik olarak tekrar kontrol etmeyi tavsiye ederiz; Apple, yönergeleri zaman zaman günceller ve madde sıralaması değişebilir. Bu yüzden içeriğimizde kesin madde numarasını verirken bile "güncel metni teyit edin" uyarısını tekrarlarız.

Küçük bir alışkanlık bu riski azaltır. Gönderim öncesi kontrol listesine tek bir satır ekleyin: "madde numarasını resmi sayfadan teyit et." Bu basit adım, eski bilgiyle hareket etme riskini düşürür. Ekip, bu satırı her sürüm döngüsünde tekrar kontrol eder.

Yalnızca Web Sitesine Link Vermek Neden Yetersiz Kalır?

İnceleme ekibi, silme sürecinin uygulama içinde başlamasını bekler; kullanıcı bu seçeneği genellikle hesap ayarları altında bulmalıdır. Destek bileti açmak, e-posta göndermek ya da canlı sohbete bağlanmak zorunda bırakan akışlar yetersiz kalır.

• Yalnızca destek biletiyle çalışan silme talebi
• Yalnızca e-posta ile iletilen silme talebi
• Hesabı kalıcı silmeden yalnızca dondurma seçeneği

Buna karşılık süreç bir web sayfasında tamamlanıyorsa bu durum kabul edilebilir; ancak uygulama, kullanıcıyı o sayfaya doğrudan yönlendiren bir bağlantı sunmalıdır. Yani web sayfası, sürecin tek başlangıç noktası olamaz, yalnızca tamamlama adımı olabilir.

Peki bu fark pratikte ne anlama gelir? Kullanıcı, "hesabımı sil" dediği anda uygulama içinde bir onay ekranı görmelidir; ekran isterse arkasından güvenli bir web bağlantısına geçebilir, fakat başlangıç noktası her zaman uygulamanın kendisi olmalıdır.

Ekip olarak gördüğümüz tipik hata şu: destek ekibi, "bize e-posta atın, hesabınızı kapatalım" cümlesini sıkça kullanır. Bu cümle kullanıcıya nazik görünse de inceleme ekibi için tam olarak yasaklanan desen budur; çözüm, bu cümleyi uygulama içindeki bir düğmeyle değiştirmektir.

Bazı ekipler bu değişikliği küçük bulur. Oysa etkisi büyüktür. İnceleme ekibi, bu tek düğmeyi görmeden uygulamayı onaylamaz. Destek ekibi de her gün aynı e-postayı yazmaktan kurtulur. Kısacası küçük bir arayüz değişikliği, hem gönderimi hem günlük iş yükünü rahatlatır.

Ekip, bu değişikliği uygularken metni de gözden geçirmelidir. "Hesabı sil" ifadesi, "hesabı kapat" ifadesinden daha net bir sinyal verir. Kullanıcı, tıkladığı düğmenin ne yapacağını önceden tam olarak bilmelidir.

Uygulama İçi Hesap Silme Seçeneği Nerede Durmalı?

Seçenek, genellikle hesap ya da profil ayarları altında, kullanıcının kolay bulabileceği bir yerde durmalıdır. Menü derinliklerine gömülü, aranması zor bir silme seçeneği de inceleme sürecinde sorun yaratabilir.

Akış, hesabın kendisini ve kullanıcıya ait içerikleri; yorumları, fotoğrafları ve paylaşımları kapsamalıdır. Ekip isterse ek seçenekler de sunabilir, örneğin yalnızca belirli verileri silme ya da bildirim tercihlerini kapatma gibi.

Bu yüzden tasarım ekibi, "hesabı sil" butonunu ayarlar menüsünün en az üç tıklama derinliğinde değil, birinci ya da ikinci seviyede konumlandırmalıdır. Kullanıcı testleri, bu basit yerleşim değişikliğinin destek taleplerini bile azalttığını gösterir.

Kapsam ayrıca sipariş geçmişi, ödeme bilgisi ve kullanıcı tarafından yüklenen dosyaları da içermelidir. Ekip, bu kalemleri tek tek listelemek yerine "hesapla ilişkili tüm kişisel veri" ifadesiyle genel bir kapsam tanımlayabilir, ardından arka planda bu kapsamı teknik olarak uygular.

Bu kapsamı belirlerken ürün ve hukuk ekibi birlikte çalışmalıdır. Pazarlama ekibi de sürece dahil olmalıdır, çünkü silinen hesapla ilişkili e-posta listeleri de kapsama girer. Üç ekip aynı masada buluşursa kapsam tanımı daha sağlam çıkar.

Bu toplantıyı erken yapmak büyük fark yaratır. Son dakikada eklenen bir hukuk şartı, geliştirme planını değiştirebilir. Baştan ortak bir kapsam listesi çıkarmak, bu tür sürprizleri önler. Bu liste, aynı zamanda yeni ekip üyeleri için faydalı bir referans belgesine dönüşür ve her yeni sürümde kolayca güncellenebilir, ekip içinde paylaşılabilir ve farklı projelerde tekrar kullanılabilir pratik bir çalışma dosyası görevi görür.

Hesap Dondurma ile Hesap Silme Arasındaki Fark Nedir?

Hesap dondurma, veriyi sunucuda tutarak girişi geçici olarak kapatır; hesap silme ise kaydı ve ilişkili kişisel veriyi tamamen kaldırır. Apple'ın hesap silme kuralı, sadece dondurma sunan uygulamaları yeterli bulmaz.

Kısacası ekip, iki seçeneği birlikte sunabilir; fakat yalnızca dondurma seçeneği varsa inceleme sürecinde ret riski doğar. Bu yüzden silme seçeneğini her zaman ayrı ve net bir buton ya da menü satırı olarak tasarlayın.

Öte yandan iki seçeneği birlikte sunmak kullanıcı deneyimine de katkı sağlar; aceleyle hesabını silen bir kullanıcı yerine, önce dondurup sonra karar veren bir kullanıcı elde edersiniz. Ekip, bu ikili seçimi hesap ayarlarında yan yana iki buton olarak gösterebilir.

Analitik tarafında da fark büyüktür: dondurulan hesap sayısı, ürün ekibine "kullanıcı neden ayrılıyor" sorusuna dair ipucu verir; silinen hesap sayısı ise daha kesin bir kayıp göstergesidir. İki rakamı ayrı takip etmek, karar vericiye daha doğru bir tablo sunar.

Ekip, bu iki rakamı aylık bir panelde yan yana gösterebilir. Dondurma sayısı artıyorsa ürün ekibi bunu bir uyarı sinyali olarak okur. Silme sayısı artıyorsa sorun daha köklü olabilir. Her iki durumda da erken fark etmek, geç müdahaleden daha ucuzdur.

Sağlıklı Bir Hesap Silme Akışı Hangi Aşamalardan Geçer

Sağlıklı bir akış, kullanıcıyı sürpriz bırakmaz ve her adımda net bilgi verir. Bu tasarımı, ilk sürüm planlamasına dahil etmek, sonradan ek geliştirme maliyetini azaltır.

1. Kullanıcı, hesap ayarlarında silme seçeneğini kolayca bulur.
2. Uygulama, niyeti onaylatan bir uyarı gösterir.
3. Gerekirse kimlik doğrulama adımı devreye girer.
4. Uygulama, süreç ne kadar sürecekse bunu kullanıcıya bildirir.
5. İşlem bittiğinde kullanıcıya bitiş bildirimi ulaşır.

Her aşama, güven duygusunu korur ve destek ekibine gelen soru sayısını düşürür. Böylece hem kullanıcı deneyimi iyileşir hem de inceleme süreci daha sorunsuz ilerler.

Bu beş adımı ilk sürümden itibaren ürün gereksinimine yazmak, ekibi sonradan "unutulan bir özellik" paniğinden kurtarır. Çünkü hesap silme akışı, genelde en son düşünülen ama en çok zaman kaybettiren detaylardan biridir.

Gönderim öncesinde akışı gerçek bir cihazda uçtan uca test etmek de önemlidir; yalnızca tasarım dosyasında doğru görünen bir akış, gerçek cihazda farklı bir sonuç verebilir. Test ekibi, hesabı silip aynı bilgilerle yeniden kayıt açarak sürecin gerçekten tamamlandığını doğrulamalıdır.

Bu test, yalnızca ana akışı değil kenar senaryoları da kapsamalıdır. Kötü bir internet bağlantısında akış ne yapar? Kullanıcı işlemi yarıda keserse ne olur? Bu soruların cevabı, gönderim öncesi raporda yazılı olmalıdır. Ekip, bu raporu her sürüm için ayrı tutarsa zamanla değerli bir referans arşivi oluşur.

Kimlik Doğrulama Adımını Nasıl Kurarsınız?

Apple, silme isteğini onaylamak için yeniden kimlik doğrulama ya da hesapta kayıtlı e-posta ya da telefona kod gönderme gibi adımlara izin verir. Önemli şart, bu adımın gereksiz yere zorlaştırıcı olmamasıdır.

Örneğin kullanıcıdan şifreyi tekrar girmesini istemek makul bir doğrulamadır; buna karşılık noter onayı ya da fiziksel belge istemek gibi ağır adımlar inceleme sürecinde soru işareti yaratır. Doğrulama, güvenliği korurken süreci sürüncemede bırakmamalıdır.

Ekip, bu dengeyi kurarken tek bir soru sorar: bu ek adım, gerçek bir güvenlik riskini mi önlüyor yoksa kullanıcıyı yıldırmak için mi var? Cevap ikincisiyse adımı sadeleştirmek, hem kullanıcıyı hem inceleme sürecini rahatlatır.

Sosyal giriş kullanan uygulamalarda doğrulama daha basittir; kullanıcı zaten ilgili sağlayıcı üzerinden oturum açtığı için ek bir şifre istemeye gerek kalmaz. Bu durumda tek onay adımı, "hesabımı kalıcı olarak silmek istiyorum" ifadesini tekrar yazdırmak kadar basit olabilir.

Ekip, doğrulama adımını tasarlarken riski sınıflandırmalıdır. Finansal veri içeren bir uygulama, daha sıkı bir doğrulama gerektirir. Basit bir içerik uygulaması ise tek tıkla onay yeterli olabilir. Bu ayrım, hem güvenliği korur hem de kullanıcıyı gereksiz yere yormaz.

Abonelikli Hesaplarda Silme Süreci Nasıl İşler?

Abonelik, Apple ya da Google üzerinden faturalandırılıyorsa hesap silindiğinde fatura döngüsü otomatik durmaz; kullanıcı aboneliği mağaza ayarlarından ayrıca iptal etmelidir. Bu fark, uygulama içi satın alma ile web ödemesi arasındaki komisyon ve kontrol farkıyla da ilgilidir.

Ekip, hesabı aboneliğin bitiş tarihine kadar planlı olarak silebilir; ancak kullanıcıya her zaman anında silme seçeneği de sunmalıdır. Peki bu iki seçenek nasıl bir arada durur? Arayüzde net bir açıklama yeterlidir; örneğin "hesabınızı hemen silersiniz, aboneliği ise mağaza üzerinden ayrıca iptal edersiniz" gibi bir uyarı işi netleştirir.

Bu noktada ekip, kullanıcıyı suçlamayan bir dil seçmelidir. Abonelik iptalinin ayrı bir adım gerektirmesi kullanıcının hatası değildir; bu, mağaza altyapısının doğal bir sonucudur ve arayüz bunu sakin bir üslupla anlatmalıdır.

Apple'ın sunduğu mağaza içi abonelik yönetim ekranına doğrudan bağlantı vermek de pratik bir çözümdür; kullanıcı, uygulamadan çıkmadan aboneliğini görür ve iptal edebilir. Bu küçük ayrıntı, hem kullanıcı deneyimini kısaltır hem de destek yükünü azaltır.

Yasal Olarak Saklanması Gereken Veriler Ne Olacak?

Bazı veriler, muhasebe ya da yasal yükümlülük nedeniyle belirli bir süre saklanabilir; kural bu durumu yasaklamaz, sadece şeffaflık ister. Uygulama, kullanıcıya hangi verinin neden tutulduğunu açıkça anlatmalıdır.

Bu konu, KVKK ve GDPR uyumlu web sitesi rehberindeki veri saklama mantığıyla örtüşür. Önemli not: bu yazı hukuki danışmanlık değildir, saklama süreleri için mali müşavirinize ya da hukuk danışmanınıza başvurun.

Pratik bir yöntem, silme ekranına kısa bir dipnot eklemektir: "fatura kayıtları yasal süre boyunca saklanır, diğer tüm verileriniz kalıcı olarak kaldırılır" gibi. Bu tek satır, hem şeffaflığı sağlar hem de kullanıcı güvenini korur.

Bu dipnotu gizlilik politikası sayfasıyla da eşleştirmek faydalıdır; kullanıcı, uygulamadaki kısa açıklamayı okuduktan sonra isterse tam metne gider. Ekip, bu iki metni birbirinden bağımsız yazarsa zamanla çelişen ifadeler ortaya çıkabilir.

Misafir ve Otomatik Oluşan Hesaplar Kuralın Dışında mı?

Hayır, kural misafir girişiyle ya da otomatik olarak açılan hesapları da kapsar. Kullanıcı fark etmeden açılan bir hesap da silme kapsamına girer.

Bu yüzden ekip, hesap oluşturma mantığını tasarlarken her senaryoyu; kayıtlı giriş, sosyal giriş ve misafir girişini birlikte düşünmelidir. Aksi halde bir senaryo gözden kaçar ve inceleme sırasında sürpriz bir ret gelir.

Kurumsal uygulamalarda bu konu daha da karmaşıktır. Bir firma hesabı, birden çok kullanıcıyı barındırabilir. Yönetici hesabı sildiğinde diğer kullanıcılara ne olacağı net olmalıdır. Ekip, bu çoklu kullanıcı senaryosunu da baştan tasarlamalıdır, aksi halde silme talebi yarım kalır.

Pratik bir çözüm, hesap türlerini tek bir listede toplamaktır. Ürün ekibi, kayıtlı, sosyal ve misafir girişini aynı tabloya yazar. Her satıra "silme akışı var mı" sorusunu ekler. Bu küçük tablo, eksik kalan bir senaryoyu gönderim öncesi ortaya çıkarır.

Örnek senaryo: bir uygulama, kullanıcıya cihaz kimliğiyle otomatik bir misafir profili açar. Kullanıcı bunu fark etmese de bu profil sunucuda bir kayıttır; dolayısıyla uygulama, bu kaydı da silebilen bir yol sunmalıdır.

Benzer bir durum, Apple ile tek tuşla giriş özelliğinde de ortaya çıkar; kullanıcı silme işlemini tamamladığında uygulamanın sunucu tarafı, ilgili belirteci de geçersiz kılmalıdır. Aksi halde hesap görünürde kapanır, ancak arka planda eski oturum açık kalabilir.

Hesap Silme Kuralı ile Guideline 4.3 Spam Reddi Arasındaki Fark Nedir?

İki konu, isim benzerliği yüzünden sık karışır; ancak kapsamları tamamen farklıdır. Hesap silme kuralı, var olan bir hesap özelliğinin nasıl sonlandırılacağıyla ilgilidir; Guideline 4.3 spam reddi ise uygulamanın şablon kopyası ya da özgünlükten uzak bir ürün sayılmasıyla ilgilidir.

Dolayısıyla bir uygulama, 4.3 anlamında tamamen özgün olsa bile hesap silme akışı eksikse inceleme ekibi uygulamayı yine reddeder. Bu iki konuyu ayrı tutmak, ret e-postasını doğru okumanızı ve doğru bölümü düzeltmenizi hızlandırır.

Kısa bir karşılaştırma şöyle: 4.3 reddi genelde "bu uygulama başka bir şablonla aşırı benzer" mesajı taşır, hesap silme reddi ise genelde "hesap oluşturma ve silme" ifadesine doğrudan atıf yapar. Ret e-postasını bu iki ifadeye göre okumak, doğru düzeltmeye daha hızlı ulaştırır.

İki konuyu karıştırmanın somut bir maliyeti vardır: ekip, yanlış maddeye odaklanıp günler harcayabilir. Ret e-postasındaki tam cümleyi dikkatle okumak ve hangi maddeye atıf yaptığını netleştirmek, bu kaybı baştan önler.

Uygulama Reddinin Tüm Nedenlerini Nerede Görebilirsiniz?

Hesap silme kuralı, tek bir ret nedenidir; ret mektubu her zaman bu maddeye işaret etmez. Ret nedenlerinin genel haritasını görmek için uygulama reddi nedenleri yazımıza bakabilirsiniz; bu yazı tüm yaygın ret kalıplarını tek yerde toplar.

Buradaki içerik ise kasıtlı olarak tek bir maddeyi ele alır, böylece hesap silme konusunu ayrıntılı ve karıştırmadan anlatabiliriz. İki yazıyı birlikte okumak, hem genel haritayı hem bu maddenin ayrıntısını aynı anda görmenizi sağlar.

Ekip olarak önerimiz şu: gönderim öncesi önce genel haritayı tarayın, ardından uygulamanızın hesap özelliği varsa bu yazıdaki kontrol listesine dönün. Bu sıralama, kontrolü hem hızlı hem de kapsamlı hale getirir.

Android Tarafında Benzer Bir Zorunluluk Var mı?

Evet, Google Play Geliştirici Program Politikaları da kullanıcı verisinin silinmesine yönelik benzer bir beklenti taşır. Ancak madde numarası ve tam kapsam zamanla değişebilir, bu yüzden kesin metni uydurmak yerine güncel bilgiyi Google Play geliştirici destek sayfasından kontrol edin.

Her iki platform için ortak ilke aynıdır: hesap açan uygulama, kapatma yolunu da kolay erişilebilir biçimde sunmalıdır. Ekip olarak hem iOS hem Android gönderimlerinde bu ilkeyi aynı titizlikle kontrol ederiz.

Pratikte bu, tek bir mühendislik kararı almanız gerektiği anlamına gelir: hesap silme uç noktasını bir kere kurup hem iOS hem Android arayüzünden aynı servise bağlayabilirsiniz. Bu yaklaşım, iki mağaza için ayrı ayrı çözüm üretmekten çok daha az zaman alır.

Karar verici için önemli nokta, bu uyumu gönderim takviminin başında planlamaktır. İki mağazaya aynı anda gönderim yapan ekipler, hesap silme akışını tek seferde kurduğunda hem zaman kazanır hem de tutarsız kullanıcı deneyiminden kaçınır.

Küçük bir detay da fark yaratır. iOS ve Android sürümleri aynı metni kullanmalıdır. Kullanıcı, iki cihaz arasında geçiş yaptığında aynı adımları görmelidir. Bu tutarlılık, markaya güveni güçlendirir ve destek sorularını azaltır.

Bu Kuralı Görmezden Gelirseniz Ne Kaybedersiniz?

Ret aldığınızda uygulama yeniden gözden geçirme kuyruğuna girer; bu da lansman tarihini günler, bazen hafta uzatabilir. Pazarlama takvimi, reklam bütçesi ve ekip motivasyonu bu gecikmeyi doğrudan hisseder.

Düzeltme çalışması, çoğu zaman beklenmedik ek geliştirme süresi gerektirir; bu konu mobil uygulama geliştirme maliyetini belirleyen etkenler yazımızdaki bütçe kalemleriyle de ilişkilidir. Garanti vermeyiz; ancak akışı en baştan doğru kurmak, bu riski büyük ölçüde azaltır.

Üstelik tekrarlanan ret döngüsü, yalnızca takvimi değil ekip içi güveni de zorlar; herkes "neden yine reddedildik" sorusunu sorar. Hesap silme kuralını baştan kontrol listesine koymak, bu yorucu döngüyü büyük ölçüde engeller.

Kullanıcı tarafında da bir maliyet vardır: hesabını silemeyen bir kişi, mağaza yorumlarına olumsuz not düşebilir. Bu tür yorumlar, yeni kullanıcı kazanımını yavaşlatır ve mağaza optimizasyonu çalışmanızın etkisini azaltır.

Bu nedenle ekip, hesap silme konusunu yalnızca bir inceleme şartı olarak görmemelidir. Konu, aynı zamanda bir marka güveni meselesidir. Kullanıcı, hesabını kolayca silebildiğini bildiğinde uygulamaya daha rahat güvenir. Bu güven, uzun vadede elde tutma oranını da destekler.

Rakip uygulamalar arasında seçim yapan bir kullanıcı, genelde çıkış yolunu da gözden geçirir. Hesap silme adımı kolaysa kullanıcı uygulamayı denemeye daha rahat karar verir. Paradoksal biçimde, iyi tasarlanmış bir çıkış yolu, daha fazla kullanıcıyı içeri çekebilir.

Bu bakış açısı, pazarlama ekibiyle ürün ekibi arasındaki geleneksel ayrımı ortadan kaldırır. İkisi de aynı hedefe hizmet eder: güvenilir ve şeffaf bir uygulama deneyimi. Hesap silme kuralı, bu hedefin küçük ama etkili bir parçasıdır.

Hazırlık İçin Kısa Kontrol Listesi

Gönderim öncesi son bir tur yapmak, sürpriz bir reddi önler. Aşağıdaki liste, hesap silme kuralı açısından hızlı bir öz denetim sunar.

• Hesap ayarlarında net bir "hesabı sil" seçeneği var mı?
• Seçenek, yalnızca dondurma değil tam silme yapıyor mu?
• Web sayfasına ihtiyaç varsa doğrudan bağlantı ekli mi?
• Abonelik ve yasal saklama bilgisini kullanıcıya net biçimde anlatıyor musunuz?
• Mağaza optimizasyonu ve açıklama metni bu akışla uyumlu mu?

Bu listeyi mağaza görünürlüğü çalışmanıza da bağlayabilirsiniz; detaylar için uygulama mağazası optimizasyonu (ASO) yazımıza göz atın. Hesap silme akışını ve genel gönderim sürecini baştan sağlam kurmak isteyen ekipler, mobil uygulama geliştirme hizmetimize göz atabilir.

Son olarak bu kontrol listesini tek seferlik bir görev değil, her büyük sürüm öncesi tekrarlanan bir alışkanlık haline getirin. Yeni bir özellik, genelde yeni bir hesap senaryosu ekler ve bu senaryo da aynı hesap silme kuralına tabi olur.

Ekip, bu listeyi ürün dokümantasyonuna da ekleyebilir. Yeni bir geliştirici projeye katıldığında listeyi okur. Böylece hesap silme kuralı, tek bir kişinin hafızasında kalan bir ayrıntı olmaktan çıkar. Kural, ekibin ortak standardı haline gelir ve ekip bu kuralı her gönderimde aynı titizlikle kontrol eder.