Uygulamada Puan ve Yorum Nasıl İstenir? Kurallara Uygun Rehber

Kısacası iş üç parçadan oluşuyor: doğru araç, doğru zaman ve dürüst bir dil. Bu yazıda Talha Aslan ve ekibi olarak her parçayı resmi kaynaklara dayanarak anlatıyoruz. Önce hızlı bir kontrol yapın:

1. Uygulamanız kendi tasarladığınız bir "bizi puanlayın" penceresi gösteriyorsa, onu mağazanın resmi istemiyle değiştirin.
2. Puan karşılığında indirim, jeton ya da içerik veriyorsanız bu teklifi hemen kaldırın.
3. İstemi uygulamanın ilk saniyesinde gösteriyorsanız, onu başarılı bir işlemin sonuna taşıyın.
4. Olumsuz yorumlara yanıt vermiyorsanız, en düşük puanlı yorumlardan başlayarak yanıt planı kurun.

Mağazalar puan ve yorum konusunda neden bu kadar katı?

Çünkü puan, mağazadaki güvenin ilk göze çarpan işaretidir. Bir kullanıcı uygulamanızı indirmeden önce yıldızlara ve son yorumlara bakar. Bu nedenle Apple ve Google, puanların gerçek deneyimi yansıtmasını korumak için kuralları sıkı tutuyor.

Apple, App Store İnceleme Yönergeleri içinde yorumları ücretli, teşvikli, filtrelenmiş ya da sahte geri bildirimle manipüle etmeye çalışan geliştiriciler için yaptırım öngörüyor. Yönergelere göre bu yaptırım geliştirici programından çıkarılmaya kadar gidebilir. Ayrıca 5.6.3 numaralı keşif sahtekârlığı maddesi, yorumlar dahil mağaza deneyiminin herhangi bir öğesini manipüle etmeyi açıkça yasaklıyor.

Google tarafı da aynı çizgide. Google Play'in kullanıcı puanları, yorumlar ve yüklemeler politikası puan, yorum ve yükleme sayısının her türlü manipülasyonunu yasaklıyor. Yani iki mağazada da asıl soru "nasıl daha çok yıldız toplarım" değil, "gerçek memnuniyeti mağazaya nasıl taşırım" sorusudur.

App Store'da uygulamada puan ve yorum istemenin resmi yolu nedir?

Resmi yol, Apple'ın StoreKit çerçevesindeki değerlendirme istemidir. Yönergelerin 5.6.1 maddesi, kullanıcıdan yorum istemek için sağlanan API'yi kullanmanızı söylüyor. Aynı madde, özel yapım yorum istemlerine izin vermediklerini de açıkça belirtiyor. Dolayısıyla kendi yıldız ekranınızı çizip kullanıcıyı mağazaya göndermek riskli bir yoldur.

Bu istem kullanıcının uygulamadan çıkmadan puan vermesini sağlar. Kullanıcı isterse aynı pencerede kısa bir yorum da yazar. Uzun süre SKStoreReviewController sınıfı bu işi yaptı. Apple'ın güncel belgeleri ise bu sınıfı kullanımdan kalkmış olarak işaretliyor ve yerine RequestReviewAction ile AppStore.requestReview yöntemini öneriyor.

Ekibimiz yeni projelerde her zaman belgede önerilen güncel yöntemi seçiyor. Ancak hangi sınıfı kullandığınızdan çok, onu nerede ve ne zaman çağırdığınız sonuç belirler. Örneğin istemi bir düğmeye bağlamak, Apple'ın açıkça kaçınmanızı istediği bir kullanımdır. Bu konuyu birazdan ayrı bir başlıkta ele alıyoruz.

Google Play In-App Review API nasıl çalışır?

Google Play In-App Review API, kullanıcının uygulamanızdan ayrılmadan puan ve yorum bırakmasını sağlayan resmi arayüzdür. Uygulamanız akışı başlatır, Play Store ise kartı uygulamanızın üstünde gösterir. Kartın görünüp görünmeyeceğine her zaman Google karar verir.

Android geliştirici belgeleri bu kart için net tasarım kuralları koyuyor:

• Kartı olduğu gibi gösterin; boyutunu, saydamlığını ya da şeklini değiştirmeyin.
• Kartın üstüne veya çevresine katman eklemeyin.
• Kart açıldıktan sonra onu kod ile kapatmayın; kullanıcı eylemi ya da Play Store mekanizması kartı kaldırır.
• Kartı göstermeden önce ya da gösterirken kullanıcıya fikir sorusu sormayın.

Üstelik API size kullanıcının puan verip vermediğini ya da kaç yıldız seçtiğini söylemez. Bu bilinçli bir tasarım tercihidir. Böylece geliştirici, sonuca göre kullanıcıya farklı davranamaz. Bu nedenle akışınızı kartın açılıp açılmamasına bağımlı kurmamalısınız.

Gösterim sınırları ne diyor ve neden önemli?

Her iki mağaza da istemin bir kullanıcıya ne sıklıkta görüneceğini sınırlıyor. Apple belgeleri sistemin istemi bir kullanıcıya 365 günlük süre içinde en fazla üç kez gösterdiğini yazıyor. Kullanıcı o cihazda zaten puan verdiyse, istem ancak yeni bir sürüm çıktığında ve önceki yorumun üzerinden 365 günden fazla geçtiğinde yeniden görünüyor.

Google ise zaman sınırlı bir kota uyguluyor, ancak kesin değeri açıklamıyor. Belgeye göre bu değer bir uygulama ayrıntısı ve Google onu haber vermeden değiştirebilir. Belge ayrıca akışı kısa sürede birden fazla kez çağırmanın, örneğin bir aydan kısa aralıklarla, her zaman pencere göstermeyebileceğini belirtiyor.

Bu sınırların pratik anlamı şudur: elinizde çok az hak var. Dolayısıyla her çağrıyı en memnun anınıza saklamalısınız. Ayrıca Apple, kişilerin değerlendirme isteklerini cihazlarında tamamen kapatabileceğini de hatırlatıyor. Kısacası istem hiçbir zaman garanti değildir; güncel sınırları her zaman resmi belgeden kontrol edin.

Puan istemek için en doğru an hangisidir?

En doğru an, kullanıcının uygulamanızdan değer aldığı anın hemen sonrasıdır. Apple, isteği kullanıcının bir eylemi, seviyeyi ya da görevi tamamladığı ve memnun olma ihtimalinin en yüksek olduğu zamana koymanızı öneriyor. Google da kullanıcının yararlı geri bildirim verecek kadar deneyim yaşamasını bekliyor.

Sektöre göre bu an değişir. Aşağıdaki örnek senaryolar, ekibimizin projelerde sıkça kullandığı tetikleyici türlerini gösteriyor:

• Randevu uygulaması: kullanıcı ikinci randevusunu sorunsuz oluşturduktan sonra.
• E-ticaret uygulaması: sipariş "teslim edildi" durumuna geçtikten sonra uygulama tekrar açıldığında.
• Eğitim uygulaması: kullanıcı bir modülü bitirip başarı ekranını kapattıktan sonra.
• Oyun: zorlu bir bölüm geçildikten sonra, bir sonraki bölüm başlamadan önceki doğal duraklamada.

Ortak nokta şu: istem bir başarının ardından gelir ve bir işin ortasına düşmez. Ayrıca tek bir başarı yetmeyebilir. Bu yüzden biz genellikle birkaç olumlu sinyalin birleşmesini bekliyoruz; örneğin belirli sayıda oturum ve son oturumda hata yaşanmamış olması gibi.

Hangi anlarda asla puan istememelisiniz?

Bazı anlar, en iyi kullanıcıyı bile sinirli bir yorumcuya dönüştürür. Apple, istemi kullanıcı uygulamayı başlatır başlatmaz göstermemenizi öneriyor; bu ilk açılış olmasa bile geçerli. Kullanıcı uygulamayı bir iş yapmak için açtı, sizin isteğiniz o işin önüne geçmemeli.

Ekibimizin sahada kaçındığı anlar şunlar:

• Ödeme, form doldurma ya da kayıt gibi bir akışın ortası.
• Uygulamanın hata verdiği, çöktüğü veya ağ bağlantısının koptuğu oturum.
• Kullanıcının destek talebi açtığı ya da şikâyet ettiği gün.
• İlk kullanım ve tanıtım ekranlarının hemen sonrası.
• Kullanıcının bir zamanlayıcı, harita ya da canlı içerik takip ettiği an.

Öte yandan "olumsuz deneyim yaşayanlara hiç sormayalım" yaklaşımına da dikkat edin. Mutsuz kullanıcıyı sistematik olarak dışarıda bırakmak, yönergelerin bahsettiği filtrelenmiş geri bildirime yaklaşır. Biz zamanlamayı kullanıcının memnuniyetine göre değil, işin doğal akışına göre kuruyoruz. Böylece hem kurala uyar hem de rahatsız etmeyen bir deneyim sunarsınız.

"Bizi değerlendirin" düğmesi koymak yasak mı?

Düğme koymak yasak değil, ama düğmeyi resmi isteme bağlamak yanlış. Apple belgesi, API her zaman pencere göstermeyebileceği için onu bir düğme dokunuşuna veya kullanıcı eylemine yanıt olarak çağırmamanızı söylüyor. Kullanıcı düğmeye basar, hiçbir şey olmaz ve uygulama bozuk izlenimi verir.

Google da aynı uyarıyı yapıyor. Kullanıcı kotasını doldurmuş olabilir, bu yüzden API'yi tetikleyen bir eylem düğmesi koymamanızı istiyor. Bunun yerine kullanıcıyı doğrudan Play Store sayfasına yönlendirmenizi öneriyor.

Doğru kurgu iki ayrı yol içerir. Birincisi, sistemin kendi zamanlamasıyla açılan resmi istem. İkincisi, ayarlar ya da "hakkında" ekranında duran ve kullanıcıyı mağaza sayfasına götüren sade bir bağlantı. Apple'ın örnek kodu bu ikinci yol için uygulama sayfası adresine write-review eylem parametresi ekliyor. Böylece kullanıcı doğrudan yorum yazma ekranına ulaşıyor.

Ödül karşılığı yorum neden yasak ve sınır nerede?

Ödül karşılığı yorum, iki mağazada da açık bir ihlaldir. Google Play politikası, yüksek puan karşılığında indirim teklif eden bir bildirimi doğrudan ihlal örneği olarak veriyor. Apple yönergeleri de teşvikli geri bildirimle yorum manipülasyonunu yaptırım sebebi sayıyor.

Sınırı doğru çizmek önemli. Apple'ın 3.2.2 maddesi, uygulamaların işlev ya da içeriğe erişim için kullanıcıyı puan vermeye zorlamasını yasaklıyor. Aynı madde, uygulama içinde bir seviyeyi tamamlamak gibi başka eylemleri teşvik etmeye izin veriyor. Yani ödül sistemi kurmak serbest, ama ödülü puana veya yoruma bağlamak serbest değil.

Uygulamada şu ayrımı kullanıyoruz:

• Serbest: görev tamamlayana rozet vermek, bir seviye bitince bonus açmak.
• Yasak: "5 yıldız verene kupon" mesajı, puan sonrası kilitli içerik açmak.
• Yasak: yorum yazmayı bir özelliğe erişim şartı yapmak.
• Bunu da yapmayın: yorumlara kupon kodu, e-posta adresi veya başka uygulama bağlantısı yazdırmaya teşvik etmek.

Son madde gözden kaçar. Google politikası bu tür promosyon içerikli yorumları teşvik etmeyi de ihlal örnekleri arasında sayıyor.

"Uygulamamızı beğendiniz mi?" ön sorusu sorulabilir mi?

Google Play için cevap net bir hayırdır. Belge, puan kartını gösterirken ya da göstermeden önce kullanıcıya hiçbir soru sormamanızı istiyor. Bu kapsama "Uygulamayı beğendiniz mi?" gibi fikir soruları ve "5 yıldız verir misiniz?" gibi yönlendirici sorular da giriyor.

Uzun yıllar yaygın olan "önce memnuniyeti sor, memnunsa mağazaya, değilse destek formuna gönder" kalıbı tam olarak bu yüzden sorunludur. Bu kalıp, olumsuz görüşleri mağazadan uzak tutup olumlu olanları mağazaya akıtır. Dolayısıyla yönergelerin yasakladığı filtreli geri bildirime çok yaklaşır.

Apple tarafında da özel yapım yorum istemlerinin yasak olduğunu unutmayın. Bu nedenle biz geri bildirim toplamayı ve mağaza puanı istemeyi tamamen ayırıyoruz. Uygulama içi "sorun bildir" ya da "öneri gönder" alanı her zaman açık durur. Mağaza istemi ise bu alanla hiç bağlantı kurmadan, kendi zamanlamasıyla çalışır.

iOS ve Android kuralları arasındaki farklar neler?

Temel ilke aynı olsa da ayrıntılar farklıdır. Aşağıdaki tablo, resmi belgelerde doğruladığımız noktaları yan yana koyuyor:

Tablodaki değerler mağazaların kendi belgelerinden geliyor. Ancak mağazalar bu belgeleri zamanla günceller. Bu yüzden yayın öncesinde her satırı resmi kaynaktan bir kez daha kontrol edin.

Tablodan çıkan pratik sonuç şu: iki platform için tek bir mantık kurun, ama iki ayrı uygulama katmanı yazın. Tetikleme koşulları, bekleme süresi ve ölçüm olayları ortak kalsın. Buna karşılık çağrılan yöntem, test yolu ve mağaza bağlantısı her platformda kendi belgesine uysun. Böylece kod tabanınız sade kalır ve bir kural değiştiğinde yalnız ilgili katmanı güncellersiniz.

Uygulamada puan ve yorum isteme akışını adım adım nasıl kurarsınız?

Sağlam bir akış, kodu yazmadan önce kâğıt üzerinde başlar. Ekibimizin projelerde izlediği sıra şöyle:

1. Uygulamanızın "değer anını" tanımlayın: kullanıcının asıl işi başarıyla bitirdiği an hangisi?
2. Uygunluk koşullarını yazın; örneğin en az birkaç oturum, son oturumda hata olmaması.
3. Yerel bir sayaç tutun ve istemi en son ne zaman tetiklediğinizi kaydedin.
4. Kendi bekleme sürenizi koyun; mağaza kotasına güvenmek yerine daha seyrek isteyin.
5. iOS'ta güncel StoreKit yöntemini, Android'de In-App Review API'yi başarı ekranından sonra çağırın.
6. Ayarlar ekranına mağaza sayfasına giden ayrı bir "değerlendir" bağlantısı ekleyin.
7. Tetikleme olaylarını analitik aracınıza yazın ve sürüm bazında izleyin.

Dördüncü adım önemlidir. Mağaza kotası sizi teknik olarak korur, fakat kullanıcı deneyimini korumaz. Kendi kuralınız daha nazik olmalıdır.

Bu akışı sıfırdan kurmak istemiyorsanız, uygulamanızı biz geliştirir ve mağazaya biz çıkarırız. Mobil uygulama geliştirme hizmetimiz, puan istemi dahil mağaza kurallarını baştan hesaba katan bir yapı sunar; projeniz için teklif alabilirsiniz.

İstemi yayından önce nasıl test edersiniz?

Test konusunda iki platformun davranışı farklı, bu yüzden planı ayrı yapın. Apple belgesine göre uygulama geliştirme modundayken StoreKit istemi her zaman gösterir. Böylece arayüzü ve akışı rahatça denersiniz. Ancak aynı yöntem TestFlight ile dağıttığınız beta sürümlerde hiçbir etki göstermez.

Android tarafında Google birkaç yol tanımlıyor. Dahili test kanalından indirdiğiniz uygulamada Google kotayı devreye sokmuyor. Bu kanalda test etmek için hesabın test listesinde olması, uygulamayı Play Store'dan indirmiş olması ve henüz yorum yazmamış olması gerekir. Dahili uygulama paylaşımıyla kurulan sürümde ise yorum gönderemezsiniz; Google düğmeyi bilerek pasif bırakıyor.

Ayrıca birim ve entegrasyon testleri için FakeReviewManager sınıfı var. Bu sınıf arayüzü göstermez, yalnızca akışın başarıyla tamamlandığını taklit eder. Yani kartın gerçekten açıldığını bu sınıfla değil, gerçek dahili test kanalında yanıtlarsınız. Test kurulumunun ayrıntıları için Android geliştirici belgelerindeki uygulama içi yorum test rehberine bakın.

Olumsuz yorumlara nasıl yanıt vermelisiniz?

Olumsuz yoruma kısa, saygılı ve somut bir yanıt verin. Apple, ideal yanıtın kısa olmasını ve kullanıcının geri bildirimini net biçimde ele almasını öneriyor. Yanıtta kişisel bilgi, pazarlama dili veya spam olmamalı. Her yoruma yetişemiyorsanız, Apple en düşük puanlı yorumlara ve güncel sürümdeki teknik sorunlardan bahsedenlere öncelik vermenizi tavsiye ediyor.

Google tarafında Play Console yardım sayfası her yoruma bir herkese açık yanıt yazabileceğinizi ve onu sonra düzenleyebileceğinizi söylüyor. Kullanıcı yanıtınızı hem anlık bildirim hem e-posta olarak alıyor. Üstelik kullanıcı puanını ve yorumunu istediği zaman değiştirebiliyor.

Ekibimizin kullandığı yanıt kalıbı şu:

1. Sorunu kullanıcının kendi kelimeleriyle kabul edin.
2. Ne yaptığınızı ya da hangi sürümde düzelttiğinizi açıkça yazın.
3. Gerekirse destek kanalınıza yönlendirin, ama müşteri verisi istemeyin.
4. Puanı değiştirmesini rica etmeyin; düzeltmeyi gösterin, kararı kullanıcıya bırakın.

Google'ın yanıt yönergeleri de yanıtta bir şey talep etmemenizi ve tanıtım yapmamanızı istiyor.

Puanınız düştüyse nasıl toparlarsınız?

Önce düşüşün sebebini bulun, sonra yeni puan isteyin. Sırayı tersine çevirmek, sorunu yaşayan kullanıcılardan daha fazla düşük puan toplamak demektir. Play Console puan dağılımını ülke, dil, uygulama sürümü, Android sürümü ve cihaz modeli gibi boyutlarda gösteriyor. Bu kırılım çoğu zaman sorunun tek bir sürüme ya da cihaz grubuna bağlı olduğunu ortaya çıkarır.

Örnek senaryo: bir sipariş uygulamasında yeni sürümden sonra yıldızlar düşüyor. Ekip kırılıma bakıyor ve düşüşün belirli bir Android sürümünde yoğunlaştığını görüyor. Sorun, ödeme ekranındaki bir çökme. Ekip düzeltmeyi yayınlıyor, şikâyet eden yorumlara hangi sürümde düzelttiğini yazıyor ve ancak ondan sonra puan istemini tekrar açıyor.

Ayrıca puan istemini geçici olarak durdurmak için uzaktan yönetilen bir anahtar kullanın. Böylece kriz anında yeni sürüm yayınlamadan istemi kapatırsınız. Google, gösterilen puanın son puanlara dayandığını belirtiyor. Dolayısıyla düzeltmeden sonra gelen memnun kullanıcılar puanı zamanla yukarı taşır. Kullanıcı kaybının diğer sebepleri için kullanıcıların uygulamayı neden sildiğini anlatan yazımıza da bakın.

App Store'da özet puanı sıfırlamak mantıklı mı?

Bazen mantıklı, ama nadiren. Apple'ın puanlar ve yorumlar sayfası, özet puanın App Store'daki her ülke için ayrı tutulduğunu yazıyor. Yeni bir sürüm yayınladığınızda bu özet puanı sıfırlayabilirsiniz. Ancak Apple bu özelliği idareli kullanmanızı öneriyor.

Sıfırlamanın sınırı da önemli. Apple, özet puanı sıfırlamanın yazılı yorumları sıfırlamadığını açıkça belirtiyor. Yani eski şikâyetler sayfada okunmaya devam eder. Üstelik sıfırlama sonrası düşük sayıda puan, yeni kullanıcıya güven vermeyebilir.

Biz şu durumda sıfırlamayı değerlendiriyoruz: eski puanı aşağı çeken büyük bir sorunu kalıcı olarak çözdüğünüz ve uygulamayı ciddi biçimde yenilediğiniz bir sürüm. Küçük bir hata düzeltmesi için sıfırlama genellikle gereksizdir. Google Play'de ise benzer bir sıfırlama anlatılmıyor; orada gösterilen puan zaten son puanlara ağırlık veriyor.

Puan ve yorumlar mağaza görünürlüğünü nasıl etkiler?

Puan, mağaza sayfanızın dönüşüm oranını doğrudan etkiler. Kullanıcı arama sonucunda simgeyi, adı ve yıldızı birlikte görür. Bu nedenle puan, uygulama mağazası optimizasyonunun temel parçalarından biridir. Bu konunun bütününü ASO nedir yazımızda anlattık; burada tekrar etmiyoruz.

Yorum metinleri de ayrıca önemli. Yeni kullanıcı son yorumlarda kendi kaygısına cevap arar: teslimat gecikiyor mu, ödeme sorunsuz mu, uygulama şarjı tüketiyor mu? Dolayısıyla güncel ve somut yorumlar, yıldız ortalaması kadar ikna edicidir.

Puan tek başına yetmez. Mağaza sayfasındaki görseller de kullanıcının ilk izlenimini belirler. Bu yüzden puan çalışmasını mağaza ekran görüntülerini hazırlama rehberimiz ile birlikte ele alın. Yorum sayısının genel olarak satın alma kararını nasıl etkilediğini merak ediyorsanız, ürün yorum sayısı yazımız da faydalı olur.

Yeni bir uygulamada ilk puanları nasıl toplarsınız?

Yeni uygulamada sorun puanın düşük olması değil, puanın hiç olmamasıdır. Kullanıcı az olduğu için her istem hakkı daha değerlidir. Bu nedenle ilk haftalarda acele etmeyin ve istemi yalnız gerçekten değer alan kullanıcılara gösterin.

Örnek senaryo: yeni yayına çıkan bir randevu uygulaması düşünün. Ekip ilk sürümde istemi kapalı tutuyor, önce çökme ve hata oranlarını izliyor. İkinci sürümde akış sağlamlaşınca istemi ikinci başarılı randevudan sonra açıyor. Böylece ilk puanları, uygulamanın en sağlıklı hâlini deneyen kullanıcılar veriyor.

Öte yandan yakın çevrenizden toplu yorum istemek cazip gelebilir. Ancak bu yol, mağazaların sahte ya da yönlendirmeli geri bildirim saydığı alana çok yaklaşır. Biz bunun yerine erken kullanıcılarla düzenli iletişim kurmayı, geri bildirimlerini ürüne yansıtmayı ve puanın doğal gelmesini öneriyoruz.

Bildirim, e-posta veya web sitesinden puan istemek kurallara uygun mu?

Uygulama dışından mağaza sayfanıza davet etmek kendi başına yasak değil, ama aynı ilkeler geçerli. Google Play politikası, yüksek puan karşılığı indirim teklif eden bir bildirimi açıkça ihlal örneği olarak gösteriyor. Yani sorun kanal değil, teşvik ve yönlendirmedir.

Dolayısıyla davetiniz sade olmalı: "Deneyiminizi mağazada paylaşmak isterseniz bu bağlantıyı kullanabilirsiniz" gibi. Yıldız sayısı önermeyin, ödül vaat etmeyin ve sadece memnun müşteri listesine göndermeyin. Ayrıca bu davetleri seyrek tutun; sık bildirim, uygulamanın bildirim iznini kapattırmanın en kısa yoludur.

Hangi ölçümleri takip etmelisiniz?

Ölçmediğiniz istemi iyileştiremezsiniz; uygulamada puan ve yorum akışı da bunun istisnası değil. Ancak mağaza API'leri size kullanıcının puan verip vermediğini söylemez. Bu yüzden ölçümü dolaylı kurarsınız: kendi tarafınızdaki tetikleme olaylarını, mağaza panelindeki puan eğilimiyle karşılaştırırsınız.

Takip ettiğimiz temel göstergeler şunlar:

• İstemin tetiklendiği oturum sayısı ve tetikleyici türü.
• Sürüm bazında ortalama puan ve yeni puan adedi.
• Yorumlarda tekrar eden konu başlıkları.
• Olumsuz yorumlara yanıt oranı ve yanıt süresi.
• Yanıt sonrası puanını güncelleyen kullanıcıların oranı.

İki farklı tetikleyiciyi karşılaştırmak isterseniz, kullanıcıları gruplara ayırıp sonucu ölçebilirsiniz. Böyle bir karşılaştırmada farkın anlamlı olup olmadığını A/B testi hesaplama aracımızla kontrol edebilirsiniz. Ancak testte bile her grubun istemi kurallara uygun biçimde görmesi gerekir.

Sık yapılan hatalar nelerdir?

Projelere sonradan dahil olduğumuzda aynı hataları tekrar tekrar görüyoruz. En yaygın olanlar şunlar:

• Özel yapım yıldız penceresi göstermek ve beş yıldız seçeni mağazaya, diğerlerini forma göndermek.
• İstemi ilk açılışta ya da tanıtım ekranlarından hemen sonra açmak.
• "Puan ver" düğmesini doğrudan resmi isteme bağlamak.
• Puan karşılığında kupon, jeton ya da ek içerik vaat etmek.
• Olumsuz yorumları yanıtsız bırakmak ya da kopyala yapıştır yanıt vermek.
• Yanıtta kullanıcıdan puanını yükseltmesini istemek.
• Kriz sürümünde istemi açık bırakmak.

Bu hataların bir kısmı mağaza incelemesinde sorun çıkarabilir. İnceleme ve politika süreçlerini merak ediyorsanız en sık red nedenleri yazımıza göz atın. Uygulamanız zaten politika gerekçesiyle kaldırıldıysa, Google Play itiraz rehberimiz ilk adımları anlatıyor.

Yayından önce son kontrol listesi neleri içermeli?

Sürümü mağazaya göndermeden önce şu kısa listeyi kullanın. Her maddeyi tek tek işaretlemek, sonradan çıkacak sorunların çoğunu önler:

1. Resmi istem dışında hiçbir özel yıldız penceresi yok.
2. İstemi yalnız bir başarı anından sonra ve kendi bekleme kuralınızla açıyorsunuz.
3. İstemden önce ya da sırasında memnuniyet sorusu yok.
4. Puan veya yorumla bağlantılı hiçbir ödül, kupon ya da kilit yok.
5. Ayarlarda mağaza sayfasına giden ayrı bir bağlantı var.
6. İstemi uzaktan kapatabileceğiniz bir anahtar hazır.
7. Olumsuz yorumlar için yanıt sorumlusu ve yanıt kalıbı belli.

Bu liste kısa duruyor, ama her madde bir kuralı ya da bir deneyim dersini temsil ediyor. Böylece hem incelemeyi rahat geçer hem de kullanıcıyı yormazsınız.

Listeyi her büyük sürümde yeniden gözden geçirin. Çünkü yeni bir özellik, farkında olmadan istemi yanlış bir ana taşıyabilir. Örneğin ödeme akışına eklenen yeni bir onay ekranı, eski "başarı anı" tanımınızı geçersiz kılabilir. Bu yüzden tetikleyici tanımını kod içinde değil, ürün belgenizde de yazılı tutun.

Bu işi profesyonel bir ekiple yürütmek ne kazandırır?

Çoğu kişi puan istemini birkaç satır kod sanıyor, ama arkasında ürün kararı, analitik ve mağaza politikası vardır. Doğru zamanlama için uygulamanın değer anını bilmek gerekir. Doğru ölçüm için analitik olaylarını baştan planlamak gerekir. Kural uyumu için ise iki mağazanın değişen belgelerini takip etmek gerekir.

Talha Aslan ve ekibi olarak uygulamanızı tasarlıyor, geliştiriyor ve App Store ile Google Play'e biz çıkarıyoruz. Puan istemini, yorum yanıt sürecini ve mağaza sayfasını da bu sürecin parçası olarak kuruyoruz. Mobil uygulama geliştirme sayfamızdan projenizi anlatın ve size özel teklif alın.

Kısacası uygulamada puan ve yorum toplamak, iyi deneyimin doğal sonucudur. Kurallara uygun bir istem, o deneyimi mağazaya taşıyan köprüdür; fazlası değil.