App Store puanı ve yorum yönetimi, sıralamadan çok kullanıcı güvenine dayanan bir sinyal biriktirme işidir: StoreKit'in requestReview() çağrısını doğru anda tetiklemek, kullanıcıyı kızdırmadan gerçek bir değerlendirme almanın tek güvenilir yoludur. Bu yazıda Apple'ın StoreKit dokümantasyonu ve İnsan Arayüzü Kılavuzu (HIG) ile Google'ın Play Core In-App Review API'sinin resmi kısıtlarını, isteği hangi ana bağlaman gerektiğini ve yorumlara yanıt verirken hangi teknik sınırlarla çalıştığını birebir kaynaklarla anlatıyorum. Amaç, app store puan yorum yönetimi konusunda uydurma bir "en iyi zaman" formülü değil, Apple ve Google'ın kendi dokümanlarında yazdığı kuralları pratiğe dökmek.
💡 Pro Tip: Değerlendirme isteğini bir özellik lansmanına değil, kullanıcının az önce tamamladığı somut bir başarıya bağla — StoreKit bunu "bir dizi olayı başarıyla tamamladıktan sonra" göstermeni öneriyor, Play Core ise kullanıcının faydalı geri bildirim verecek kadar deneyim kazanmış olmasını şart koşuyor.
İçindekiler
- Puanın Sıralama ve Dönüşümdeki Yeri
- Sistem Kotaları: Yılda Kaç Kez İstenebilir
- Değer Anını Tespit Edip İsteği Oraya Bağlamak
- Kullanıcıyı Desteğe Yönlendirme: Resmi API Ne Diyor
- Pratikte Hangi Olay "Değer Anı" Sayılır
- Yorumlara Yanıt Yazma: Kapsam ve Teknik Sınırlar
- Sürüm Sonrası Puan Düşüşünü İzleme
- Yasak Yöntemler: Teşvik ve Filtreleme Neden Riskli
- SSS
- Uygulama içi değerlendirme isteği ne zaman gösterilmeli?
- Kötü yorumlara nasıl yanıt verilmeli?
- Puan ortalaması nasıl toparlanır?
- Android'de kart neden bazen hiç görünmüyor?
- Değerlendirme isteğini reddeden kullanıcıya tekrar sorulabilir mi?
- Güncelleme (Eylül 2026)
- Sonuç
- Kaynaklar
Puanın Sıralama ve Dönüşümdeki Yeri
Puanın App Store veya Google Play'de arama sıralamasını ne kadar etkilediğine dair Apple ya da Google'dan yayımlanmış bir katsayı yok. Elimizde sağlam olan şey şu: her iki platform da değerlendirme isteğini geliştiricinin tasarlayabileceği özel bir arayüz olmaktan çıkarıp sistemin kendi kontrolündeki tek tip bir sorguya indirgemiş durumda.
Android tarafında Google, kart gösterilmeden önce veya gösterilirken kullanıcıya ayrı bir görüş sorusu ("Uygulamayı beğendin mi?") sormanı ya da kartın üzerine kendi tasarımını bindirmeni açıkça yasaklıyor; kart olduğu gibi (as-is) gösterilmeli. Bu kısıt, puanı geliştiricinin ince ayar yapabileceği bir pazarlama metriği olmaktan çıkarıp filtrelemeye kapalı bir kullanıcı memnuniyeti sinyaline dönüştürüyor. Dönüşümle ilişkisi dolaylı: yüksek ve güncel bir puan ortalaması, mağaza sayfasında kullanıcının indirme kararını hızlandıran bir güven işareti olarak çalışır. Apple ve Google bu etkinin büyüklüğünü ölçen bir veri yayımlamıyor. En yakın komşu yazım olan App Store Optimization (ASO) edinme ve sıralama tarafını anlatıyor; bu yazı ise edinildikten sonraki puan/yorum operasyonuna odaklanıyor.
Sistem Kotaları: Yılda Kaç Kez İstenebilir
StoreKit dokümantasyonu kotayı net yazıyor: sistem, değerlendirme istemini bir kullanıcıya 365 günlük bir dönem içinde en fazla üç kez gösterir ("the system displays the review prompt to a user a maximum of three times within a 365-day period"). Apple'ın örnek projesi (StoreKit dokümantasyonundaki kod), mevcut bundle sürümü için daha önce istem gösterilmişse çağrıyı hiç yapmıyor: "a person doesn't receive a prompt to review the same version of an app multiple times." Bu sistemin garantisi değil, senin kodunda tutman gereken bir koşul. Kullanıcı isterse bu istemi tamamen kapatabilir; bu tercih de sistem tarafından hatırlanır.
Android tarafında durum farklı: Google, kota değerinin bir gerçekleştirim ayrıntısı ("implementation detail") olduğunu ve Play tarafından önceden haber verilmeden değiştirilebileceğini açıkça yazıyor. Yani Android'de "yılda X kez" diye sabit bir sayı vermek yanlış olur — kodun launchReviewFlow() her çağrıldığında kartın gösterileceğini varsaymaması, gösterilmezse de akışı kesintiye uğratmaması gerekir.
Platform | Kota | Kaynak davranışı |
|---|---|---|
iOS (StoreKit) | 365 günde en fazla 3 istem | Sürüm bazlı tekrarı engellemek senin kodunun işi; kullanıcı tamamen kapatabilir |
Android (Play Core) | Sabit değil, "implementation detail" | Google önceden haber vermeden değiştirebilir |
swift
1import StoreKit2import UIKit3 4func kullaniciBirDegerTamamladi() {5 // Kullanıcı az önce ölçülebilir bir başarıyı tamamladı (ör. 3. proje dışa aktarımı).6 // Onboarding'de veya bir görevin ortasında ÇAĞIRMA.7 Task { @MainActor in8 if let scene = UIApplication.shared.connectedScenes9 .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene {10 AppStore.requestReview(in: scene)11 }12 }13}kotlin
1val manager = ReviewManagerFactory.create(context)2val request = manager.requestReviewFlow()3request.addOnCompleteListener { task ->4 if (task.isSuccessful) {5 val reviewInfo = task.result6 // Kart gösterilmeyebilir (kota Google'ın kendi kararı) — UI akışını buna göre kurma.7 manager.launchReviewFlow(activity, reviewInfo)8 }9}Değer Anını Tespit Edip İsteği Oraya Bağlamak
StoreKit dokümantasyonu isteği "bir dizi olayı başarıyla tamamladıktan sonra" ("at the end of a sequence of events that they successfully complete") göstermeni söylüyor; ilk açılışta veya bir kullanıcı eyleminin doğrudan yan etkisi olarak değil. HIG bunu netleştiriyor: "Ask for a rating only after people have demonstrated engagement with your app or game" — yani onboarding sırasında sorma, çünkü kullanıcının "uygulamanın değerini net şekilde kavraması için yeterli zamanı olmadı" ("haven't had enough time to gain a clear understanding of your app's value"). Aynı kılavuz, bir görev veya oyun oturumu sırasında araya girmenin "deneyimi bozabileceğini ve bir yük gibi hissettirebileceğini" ("can disrupt the user experience and feel like a burden") de ekliyor.
Android tarafında Google aynı ilkeyi tek cümlede özetliyor: "Trigger the in-app review flow after a user has experienced enough of your app or game to provide useful feedback." Yani tetikleyici, ekran sayısı değil kullanıcının gerçekten faydalı bir görüş verebilecek kadar deneyim kazanmış olması.
Bunu pratiğe dökmenin yolu, "session sayısı N'e ulaştı" gibi kaba bir sayaç değil, kullanıcının tamamladığı somut değer olaylarını (dışa aktarma, senkronizasyon, tamamlanan sipariş, bitirilen antrenman) sayan bir "başarı defteri" tutmak. Bildirim izni istekleri için aynı zamanlama mantığını daha önce Push Bildirim İzin Oranı Optimizasyonu yazısında ayrıntılı işlemiştim; oradaki "izni ilk açılışta değil, değerin görüldüğü anda sor" ilkesi burada da birebir geçerli — StoreKit ve bildirim izni ikisi de sistemin kotaladığı, kullanıcının kalıcı olarak kapatabildiği tek seferlik sistem promptları.
Kullanıcıyı Desteğe Yönlendirme: Resmi API Ne Diyor
Yaygın bir tasarım kalıbı şu: önce "Uygulamayı beğendin mi?" diye sor, "evet" diyeni mağaza puanına yönlendir, "hayır" diyeni destek formuna yönlendir. Bu akış için Apple ya da Google'ın resmi dokümanlarında onaylayıcı bir kaynak yok. Tersine, Android'in In-App Review kılavuzu bunun bir versiyonunu açıkça yasaklıyor: kart gösterilmeden önce veya gösterilirken kullanıcıya ayrı bir görüş sorusu sormak ya da yönlendirici bir soru sormak izin verilmiyor. Kart, olduğu gibi (as-is) sunulmalı; üzerine ek bir katman veya tasarım değişikliği konulamıyor.
Pratikte Hangi Olay "Değer Anı" Sayılır
StoreKit'in "bir dizi olayı başarıyla tamamladıktan sonra" ifadesi soyut kalıyor; somutlaştırmak için uygulama tipine göre birkaç örnek vermek daha faydalı. Bir üretkenlik uygulamasında bu, kullanıcının ilk projesini başarıyla dışa aktardığı an olabilir — dosya indirildi, hata yok, kullanıcı sonucu gördü. Bir fitness uygulamasında, bitirilen üçüncü antrenman ya da tamamlanan ilk haftalık hedef daha anlamlı bir eşik: kullanıcı henüz alışkanlık kurmamışken sorulan bir değerlendirme isteği, HIG'in uyardığı "henüz uygulamanın değerini kavramamış kullanıcı" durumuna tam olarak denk düşer. E-ticaret tarafında en güçlü an, siparişin sorunsuz teslim edildiğinin bildirimidir — ödeme ekranı ya da sepet sayfası değil, çünkü orada kullanıcı hâlâ karar aşamasında ve bir kesinti hissedebilir.
Ben genelde bu eşiği belirlerken tek bir olaya değil, ardışık iki olumlu sinyale bakmayı tercih ederim: örneğin "senkronizasyon başarılı" tek başına yeterli değil ama "senkronizasyon başarılı" + "kullanıcı sonucu açıp en az birkaç saniye inceledi" ikilisi, isteğin bir yük değil doğal bir devam gibi hissettirilmesini sağlıyor. Bunun tersi de doğru: bir hata ekranından, bir crash'ten hemen sonra veya arka arkaya iki başarısız denemenin ardından istek tetiklenmemeli — bu durumda hem HIG'in "deneyimi bozan istek" uyarısına hem de sağduyuya aykırı davranmış olursun.
Kotanın kısıtlı olduğunu unutma: StoreKit'te 365 günde en fazla üç hakkın var, bu üç hakkı en güçlü üç ana harcamak gerekiyor. İlk hakkı erken ve zayıf bir sinyalde (örn. ilk açılıştan bir gün sonra) harcarsan, geri kalan güçlü anlarda isteği gösterme şansın kalmayabilir; bu yüzden isteği tetikleyen olayları kendi analytics katmanında ayrıca loglamak, hangi ana kaç kez başvurduğunu izleyebilmek için tek pratik yöntem.
Başarı defterini kod tarafında basitçe bir sayaç olarak tutabilirsin; kritik nokta, isteği tetiklemeden önce hem eşik sayısını hem de son sürümde bir hata olup olmadığını kontrol etmek:
swift
1enum BasariDefteri {2 private static let sayacAnahtari = "basariliOlayIsayaci"3 private static let esik = 34 5 static func olayKaydet() {6 let mevcut = UserDefaults.standard.integer(forKey: sayacAnahtari)7 let yeni = mevcut + 18 UserDefaults.standard.set(yeni, forKey: sayacAnahtari)9 if yeni == esik {10 kullaniciBirDegerTamamladi() // Yukarıdaki AppStore.requestReview çağrısı11 }12 }13}Bu yüzden pratik öneri şu: memnuniyetsiz kullanıcıyı sistem promptundan önce filtrelemeye çalışma; bunun yerine uygulama içinde her zaman erişilebilir, promptla ilişkilendirilmemiş bağımsız bir destek/geri bildirim kanalı bulundur (ayarlar menüsünde sabit bir "Bize Ulaş" girişi gibi). İzin yönetimiyle ilgili benzer bir "kullanıcıyı doğru kanala yönlendirme" tartışmasını iOS Gizlilik Uyumu ve ATT yazısında da işlemiştim — orada da sistemin kendi kontrolündeki bir izin diyaloğunun önüne geliştiricinin geçememesi aynı mantıkla açıklanıyor.
Yorumlara Yanıt Yazma: Kapsam ve Teknik Sınırlar
Google Play Developer API'nin "Reply to Reviews" dokümantasyonu, yorum yanıtlama için somut ve sayısal sınırlar veriyor: okuma (GET) kotası uygulama başına saatte 200 istek, yanıt gönderme (POST) kotası uygulama başına günde 2000 istek — bu kotalar her uygulama için ayrı ayrı uygulanıyor ve gerektiğinde artırım talebi gönderilebiliyor. Yanıt metni azami 350 karakter ve düz metin olmak zorunda — gönderilen HTML etiketleri temizleniyor. Yalnızca yazılı yorum içeren değerlendirmelere yanıt verilebiliyor (yıldız-only değerlendirmelere değil). Kullanıcıya bildirim yalnızca geliştiricinin ilk yanıtında veya kullanıcının yorumunu güncellediği durumda gidiyor — yani her yanıt kullanıcıya anında bildirim düşmüyor.
Sınır | Değer |
|---|---|
Okuma (GET) kotası | Saatte 200 istek (uygulama başına) |
Yanıt (POST) kotası | Günde 2000 istek (uygulama başına) |
Yanıt metni | Azami 350 karakter, düz metin |
Yanıtlanabilir yorum | Yalnız yazılı metin içeren değerlendirmeler |
Kullanıcı bildirimi | Yalnız ilk yanıtta veya yorum güncellendiğinde |
Apple, App Store Connect yanıtları için yayımlanmış bir karakter sınırı ya da kota vermiyor; elindeki tek sayısal sınır Play tarafındaki 350 karakter. Kapsam olarak önerim: yanıtı kısa tut, somut bir çözüm veya sürüm notuyla bağla, aynı şablonu kopyala-yapıştır yapma — API'nin 350 karakterlik Android sınırı zaten şablon metne izin vermeyecek kadar dar.
Sürüm Sonrası Puan Düşüşünü İzleme
Yeni bir sürüm çıktığında toplu puan ortalamasının düşmesi yaygın bir korkudur; HIG, App Store Connect'te puan geçmişini sıfırlama seçeneğinin var olduğunu ama bunun riskli olduğunu açıkça yazıyor: sıfırlama "genellikle toplam değerlendirme sayısını da azaltır, bu da bazı kullanıcıları uygulamayı indirmekten caydırabilir" ("it also tends to result in having fewer ratings overall, which can discourage some people from downloading your app"). Yani sıfırlama bir "temiz sayfa" değil, ölçülü kullanılması gereken bir değiş tokuş.
Düşüşü izlemenin en sağlam yolu, bir "sihirli araç" değil düzenli takip: her sürümden sonraki ilk hafta puan ortalamasını ve yorum hacmini not al, ani bir düşüş görürsen önce o sürümdeki hangi değişikliğin (yeni ücretlendirme, kaldırılan özellik, artan crash oranı) tetiklediğini bul. Kullanıcı elde tutma eğilimleriyle puan ortalaması arasındaki bağlamı Mobil Retention Metrikleri: D1-D7-D30 yazısındaki kohort mantığıyla birlikte okumak, "düşüş mü yoksa normal dalgalanma mı" sorusunu cevaplamayı kolaylaştırır — ikisi de zaman serisi üzerinden, tek bir günlük rakamdan değil trendden okunmalı.
Yasak Yöntemler: Teşvik ve Filtreleme Neden Riskli
İki resmi gerekçe var. Birincisi Android'den: kart gösterilmeden önce veya gösterilirken kullanıcıya görüş sorusu sormak ya da yönlendirici bir soru sormak yasak; kartın üzerine ayrı bir CTA butonu koymak da önerilmiyor çünkü kota dolduğunda kart hiç görünmez ve o buton kırık bir deneyime dönüşür; bu ihtiyaç varsa kullanıcıyı doğrudan Play Store sayfasına yönlendirmek öneriliyor. İkincisi Apple'ın HIG'inden: tekrar eden, agresif istekler "kullanıcıların uygulama hakkındaki görüşünü olumsuz yönde bile etkileyebilir" ("may even negatively influence people's opinion of your app"). App Store Review Guidelines 5.6.1 de aynı yasağı teknik tarafa taşıyor: "Use the provided API to prompt users to review your app; … and we will disallow custom review prompts."
Filtreleme (yalnız memnun kullanıcıya kart göstermek) ve teşvik (indirim/kredi karşılığı puan istemek) bu yüzden yalnızca "kural ihlali" değil, aynı zamanda API'nin kendi tasarımıyla çelişen bir yaklaşım — her iki platform da kartı segment bağımsız, herkese aynı şekilde sunacak şekilde tasarlanmış. Google Play'in genel politika uyumu çerçevesini daha geniş haliyle Google Play Politika Uyum Rehberi yazısında işlemiştim; oradaki "platformun kendi mekanizmasını manipüle etmeye çalışma" ilkesi burada da geçerli.
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Bu yazıyı sonuna kadar okuduğun için, değerlendirme isteği akışını canlıya almadan önce tek tek işaretleyebileceğin kısa bir kontrol listesi hazırladım — StoreKit ve Play Core dokümantasyonundan çıkardığım kurallar burada tek sayfada.
SSS
Uygulama içi değerlendirme isteği ne zaman gösterilmeli?
İsteği, kullanıcının uygulamayla gerçek bir değer ürettiğini gösteren somut bir olayın hemen sonrasında göster — StoreKit dokümantasyonunun deyimiyle "bir dizi olayı başarıyla tamamladıktan sonra". Onboarding ekranında, ilk açılışta ya da bir görevin ortasında gösterme; HIG bu ikisini de açıkça sakıncalı buluyor çünkü kullanıcı henüz uygulamanın değerini kavramamış ya da o an bir görevin içinde, isteği bir yük gibi hissediyor.
Kötü yorumlara nasıl yanıt verilmeli?
Google Play Developer API üzerinden yazdığın yanıt azami 350 karakter ve düz metin olmak zorunda; şablon cevap kopyalamak yerine sorunu tanıdığını gösteren, mümkünse bir sürüm notuna veya çözüme referans veren kısa bir cümle yaz. Yalnızca yazılı yorum içeren değerlendirmelere yanıt verebildiğini unutma — yıldız-only oylara API üzerinden yanıt seçeneği yok.
Puan ortalaması nasıl toparlanır?
Resmi kaynaklarda sihirli bir "toparlama" mekanizması yok; HIG yalnızca App Store Connect'te puan geçmişini sıfırlama seçeneğinden bahsediyor ve bunun riskli olduğunu, genellikle toplam değerlendirme sayısını azaltarak bazı kullanıcıları caydırabileceğini söylüyor. Daha güvenli yol, kök nedeni (crash, regresyon, kafa karıştırıcı bir değişiklik) düzeltip yeni, temiz bir sürümde değer anına bağlı isteği yeniden başlatmak.
Android'de kart neden bazen hiç görünmüyor?
Çünkü Google kota değerini sabit bir sayı olarak yayımlamıyor; kendi ifadesiyle bu bir "implementation detail" ve önceden haber verilmeden değiştirilebiliyor. launchReviewFlow() başarıyla tamamlansa bile kart gösterilmeyebilir — kodun bunu bir hata değil, olağan bir olasılık olarak ele alması gerekiyor.
Değerlendirme isteğini reddeden kullanıcıya tekrar sorulabilir mi?
iOS'ta evet ama sınırlı: Apple'ın örnek projesi mevcut bundle sürümü için daha önce istem gösterilmişse çağrıyı hiç yapmıyor — bunu kendi kodunda uygulaman gerekiyor; farklı bir sürümde ve 365 günlük pencere dolmadan üçüncü seferi geçmeden tekrar deneyebilirsin. Kullanıcı istemi tamamen kapattıysa bu tercih de sistem tarafından hatırlanıyor. Android'de kota gizli olduğu için "tekrar sorma" zamanlamasını sen değil Play Core belirliyor.
Güncelleme (Eylül 2026)
Bu makale 2025-12-22 tarihindeki StoreKit, HIG ve Play Core dokümanlarına göre yazıldı (yorum yanıtlama sınırları, "Reply to Reviews" dokümanının 2025-12-18 tarihli hâlinden alınmıştır). O tarihten bu yana doğrulanan değişiklikler: Google'ın Play Core "In-App Review" dokümanı 2026-01-30'da güncellendi, ama kota mantığı ("implementation detail, subject to change without notice") aynı kaldı.
Ayrıca dikkat: Apple 2026-01-31 itibarıyla App Store için yeni bir yaş derecelendirme (age rating) sistemine geçti — bu, uygulamaların yaş uygunluğu sınıflandırmasıyla ilgili, bu yazının konusu olan yıldız puanı/kullanıcı yorumuyla karışmamalı; ikisi tamamen ayrı mekanizmalar. 2026-04-28'den itibaren App Store Connect'e yüklenen uygulamalar Xcode 26 ve 26 SDK'larıyla derlenmiş olmak zorunda; yeni bir sürüm çıkaracaksan değerlendirme isteği zamanlamasını da o sürümde gözden geçir. Apple 2026-03-25'te App Store Analytics'e yeni kohort yetenekleri ve iki monetizasyon emsal-grup ölçütü (download-to-paid conversion ve proceeds per download) ekledi; bu ölçütler puan/yorum verisini kapsamıyor.
Sonuç
App store puan yorum yönetimi, kuralları geliştiricinin değil platformun koyduğu bir alan: StoreKit'in 365 günde üç istem kotası, Android'in "as-is kart" zorunluluğu ve Play Developer API'nin 350 karakterlik yanıt sınırı hep aynı ilkeye çıkıyor — isteği manipüle etmeye çalışmak yerine doğru ana bağlamak. Bu yazıda anlatılan başarı defteri deseni ve kontrol listesi, kotayı boşa harcamadan gerçek geri bildirim toplamanın en kestirme yolu.
Konuyu daha geniş bağlamda okumak istersen App Store Optimization (ASO) edinme/sıralama tarafını, Push Bildirim İzin Oranı Optimizasyonu sistem izin promptlarının ortak zamanlama mantığını, iOS Gizlilik Uyumu ve ATT sistem diyaloglarının sınırlarını, Mobil Retention Metrikleri: D1-D7-D30 trend okumayı ve Google Play Politika Uyum Rehberi platform kurallarına uyumu anlatıyor.
Kaynaklar
- Requesting App Store reviews — Apple Developer — StoreKit'in 365 günde en fazla 3 istem kotasının ve örnek projenin sürüm-bazlı tekrar engelleme koşulunun birincil kaynağı.
- Ratings and Reviews — Human Interface Guidelines — isteğin ne zaman gösterilmesi/gösterilmemesi gerektiği, puan sıfırlamanın riskleri ve tekrarlanan isteklerin olumsuz etkisi üzerine Apple'ın resmi tasarım kılavuzu.
- In-app review API — Android Developers — Play Core'un kart tasarımı, tetikleme zamanlaması ve gizli/değişken kota kuralları.
- Respond to reviews — Google Play Console Help / Developer API — yorum yanıtlama için GET/POST kotaları, 350 karakter sınırı ve bildirim davranışı.
- App Store Review Guidelines — Apple Developer — zorla değerlendirme yasağının (3.2.2 x) ve kılavuzun 3. Business bölümü girişindeki "paid, incentivized, filtered, or fake feedback" yasağının yer aldığı resmi politika metni.
- Upcoming requirements for app submissions — Apple Developer — 2026 içindeki yaş derecelendirme ve SDK zorunluluğu tarihlerinin kaynağı (Güncelleme bölümü için).
