Google play test kullanıcısı bulma çilesine son: 2026 i̇çin pratik çözüm yolları

Aylarca ürün geliştiriyorsunuz. Akışlar tamam, crash’ler büyük ölçüde temizlenmiş, store listing hazır, ekip artık yayına çıkmayı bekliyor. Sonra süreç bir teknik bug’da değil, insan bulma probleminde takılıyor. Google Play’e çıkmak için gereken kapalı test, birçok ekipte ürün yol haritasını değil, sabrı test ediyor.

Sorun şu: çoğu ekip test kullanıcısı bulmayı tek seferlik bir operasyon sanıyor. Oysa 2026 şartlarında bu iş, doğru kanal seçimi, iyi davet metni, düzenli takip, geri bildirim toplama ve veri uyumu gerektiren tam bir operasyon akışı. “12 kişi bulalım, gerisi gelir” yaklaşımı bu yüzden sık çöküyor.

Bu yazı, google play test kullanıcısı bulma çilesine son: 2026 i̇çin pratik çözüm yolları arayan ekipler için hazırlanmış bir saha rehberi. Liste usulü öneriler yerine çalışan bir sistem kurmaya odaklanıyor.

Giriş: Google Play Test Sürecinin 2026 Gerçekleri

Release adayı hazır oluyor. Ekip “bu hafta yayındayız” diye plan yapıyor. Sonra takvim, bir crash yüzünden değil, 14 günlük kapalı test düzeni yüzünden kayıyor.

2026’da yeni geliştirici hesapları için gerçek darboğaz kod tarafı değil, kapalı testi operasyon gibi yönetebilmek. Google Play tarafında beklenti net. Uygulamanın kapalı testte yeterli sayıda gerçek kullanıcıyla, yeterli süre boyunca, düzenli kullanım sinyali üretmesi gerekiyor. Sadece kurulum almak yetmiyor. Davet gönderip beklemek de yetmiyor.

Sahada gördüğüm temel hata aynı. Ekipler bu süreci “12 kişi bulalım, biter” diye kurguluyor. Oysa işin zor kısmı insan bulmak kadar, doğru kanalı kurmak, daveti doğru yazmak, katılımı takip etmek, geri bildirimi sınıflandırmak ve kişisel veri tarafını temiz yürütmek. Bu nedenle 14 günlük test, birçok ekipte bir yayın engeli gibi yaşanıyor.

Doğru kurulduğunda tablo değişiyor.

Kapalı test dönemi, yalnızca Play Console gereğini karşılamak için kullanılmamalı. Bu dönem; onboarding kopuşlarını, ilk oturumdaki sürtünmeleri, cihaz bazlı hataları ve yanlış kullanıcı beklentisini erken yakalamak için en ucuz kalite turudur. Store sayfasında verdiğiniz söz ile uygulama içindeki ilk deneyim birbirini tutmuyor mu, bunu da burada görürsünüz. Bu açıdan test verilerini uygulama mağazası görünürlüğünü artıran ASO çalışmalarıyla ilişkilendirmek erken aşamada ciddi avantaj sağlar.

Sahadaki gerçek: Süreci geçen ekipler daha fazla mesaj atan ekipler değil. Test akışını baştan sona işleten ekipler.

Bu girişte akılda kalması gereken çerçeve şu:

• Kapalı test, yeni geliştirici hesapları için gerekli aşama.
• Aktif kullanım sinyali gerekir. Yalnızca yükleme sayısı yeterli olmaz.
• 14 gün boyunca devamlılık gerekir. İlk gün girip bırakan tester havuzu kırılgan yapı oluşturur.
• Yedekli havuz kurmak gerekir. Çünkü davet kabul eden herkes test disiplinini sürdürmez.
• Geri bildirim ve veri uyumu baştan planlanmalıdır. Sonradan toparlamak hem yavaş hem risklidir.

Kısacası sorun tester bulma çilesi değil. Sorun, test kullanıcı bulmayı, onboarding’i, takip mesajlarını, geri bildirim toplamayı ve KVKK/GDPR uyumunu tek bir operasyon akışında birleştirememek. 2026’da fark yaratan ekipler tam olarak bunu yapıyor.

Adım 1: Play Console Test Kanallarını Doğru Yapılandırma

Akış genelde şu noktada kırılıyor: Uygulama hazır görünüyor, davet linki gönderiliyor, ilk birkaç kişi “katıldım” sanıyor ama Play Store tarafında erişim tamamlanmadığı için build’i hiç göremiyor. Ekip bunu kullanıcı isteksizliği zannediyor. Oysa sorun tester bulmak değil, test kanalını yanlış kurmak.

Bu adım operasyonun temelidir. Kanal yapısı baştan temiz kurulursa davet, onboarding, takip mesajları ve geri bildirim akışı ölçülebilir hale gelir. Kötü kurulumda ise 14 günlük test süresi daha ilk günden yanlış veri üretir.

Hangi kanal ne zaman kullanılır

Dahili test, geliştirici ve QA ekibinin hızlı kontrol turu içindir. Sürüm dakikalar içinde dağıtılır. Login, ödeme, push, crash gibi temel kırılmaları burada ayıklarsınız. Ama gerçek kullanıcı davranışı üretmez ve yeni geliştirici hesabı için gereken kapalı test akışının yerini tutmaz.

Kapalı test, yayın öncesi ana çalışma alanıdır. Davet ettiğiniz kişileri kontrollü biçimde içeri alırsınız. Kim kabul etti, kim erişti, kim kurulumu tamamladı gibi operasyonel noktaları burada daha net yönetirsiniz. 2026 kuralları altında asıl disiplin burada gerekir.

Açık test, ürün artık daha geniş denemeye hazırsa anlamlıdır. Organik davranış görmek, farklı cihazlardan hata toplamak ve mağaza metinlerinin beklenti yaratıp yaratmadığını test etmek için faydalıdır. Fakat yeni hesapların zorunlu kapalı test ihtiyacını tek başına çözmez.

Kısa karar kuralı şudur: Dahili test hata ayıklar, kapalı test süreci doğrular, açık test ölçekli davranış sinyali toplar.

Kurulumda en sık yapılan yanlışlar

Sahada aynı hataları tekrar tekrar görüyorum. Özellikle küçük ekiplerde problem teknik değil, dağınık operasyon oluyor.

• Erişim modelini sonradan düşünmek. Önce link üretip sonra kimin hangi hesapla katılacağını toparlamaya çalışmak.
• Build hazır değilken davet çıkmak. İlk deneyimi bozuk yaşayan tester ikinci kez dönmüyor.
• Farklı listeleri farklı yerlerde tutmak. Bir kısım Google Group’ta, bir kısım Sheet’te, bir kısım WhatsApp mesajında kalıyor.
• Opt-in akışını kendi hesabınızla test etmek. Kendi cihazınızda çalışan süreç, dışarıdaki kullanıcıda çalışmayabiliyor.
• Katılımı yalnızca yükleme olarak saymak. Uygulama kuruldu diye test başlamış sayılmaz.

Buradaki temel trade-off açık. Sıkı kontrol isterseniz kurulum yükü artar. Dağınık ilerlerseniz yönetim kolay görünür ama veri kalitesi düşer. Benim tercih ettiğim model, ilk günde biraz fazla operasyon yükü alıp sonraki 14 günde sürprizi azaltmak.

Kanal seçimini tabloyla netleştirelim

Tablodaki ayrım basit görünüyor ama pratikte birçok ekip üç kanalı birbirine karıştırıyor. Özellikle kapalı test davetini, dahili test mantığıyla “linki attım, girerler” seviyesinde yönetmek başarısızlığın en yaygın nedeni.

Temiz kurulum akışı

Benim sahada en az sorun çıkardığını gördüğüm akış şu:

1. Test segmentlerini baştan ayırın. İç ekip, arkadaş çevresi, mevcut kullanıcılar, topluluk tester’ları ve ücretli tester’lar aynı listede olmamalı.
2. Kapalı testi ana kanal olarak açın. Dahili testi sadece ön kontrol için kullanın.
3. Tek bir kayıt kaynağı belirleyin. Google Sheet, Airtable veya Notion fark etmez. Tek gerçek liste olsun.
4. Katılım bilgisini standartlaştırın. Ad, Gmail hesabı, cihaz modeli, Android sürümü, ülke ve kabul tarihi gibi alanları sabitleyin.
5. Opt-in linkini dışarıdan doğrulayın. Ekip hesabı olmayan en az iki farklı cihazda akışı baştan sona test edin.
6. İlk gün görevini kısa tutun. Yükle, giriş yap, ana akışı tamamla, tek bir geri bildirim bırak.
7. Yedek kanal hazırlayın. Davet maili düşmezse veya grup erişimi takılırsa kullanıcıyı yeniden içeri alacak net bir destek akışınız olsun.

Burada amaç yalnızca erişim vermek değil. Ölçülebilir bir test operasyonu kurmak. Sonraki adımlarda kullanıcı havuzu kurarken, davet metnini optimize ederken ve geri bildirimi otomatik toplarken işinizi kolaylaştıran zemin tam olarak bu yapıdır.

Kapalı testte “kullanıcı pasif kaldı” ile “erişim akışı bozuktu” sonucu dışarıdan aynı görünür. Bu ikisini ayırmadan sağlıklı karar veremezsiniz.

İyi yapılandırılmış kanal, tester sayısını sihirli biçimde artırmaz. Ama elinizdeki kullanıcıyı kaybetmez, hangi noktada düştüğünü gösterir ve 14 günlük süreci kör ilerlemek yerine yönetilebilir hale getirir.

Adım 2: Sıfırdan Test Kullanıcısı Havuzu Oluşturma Yöntemleri

Test kullanıcısı havuzu, ilan açıp bekleyerek kurulmaz. İnsanlar size iyilik olsun diye 14 gün disiplinli davranmıyor. Onlara açık görev, düşük sürtünme ve makul beklenti sunmanız gerekiyor.

İnfografik olarak düşünmek isteyenler için temel yöntemler burada özetleniyor:

Türkiye’de bağımsız geliştiricilerin %65’i 12 tester bulmak için 7+ gün harcıyor. Kurumsal firmalarda bu oran %25 seviyesine düşüyor. Topluluk forumları öne çıkıyor; Donanımhaber’de 162+ ilan dikkat çekiyor. Profesyonel tarafta freelancer’lar 50-100 TL saatlik ücretle 14 günlük aktiflik sağlayabiliyor. Bu bilgiler kapalı test üzerine TR odaklı derlemede yer alıyor.

Kanal seçimini bütçe değil kullanım senaryosu belirler

Sosyal medya grupları hızlı erişim sağlar. Ama motivasyon düşüktür. Buradan gelen kullanıcı, uygulamanızı merak ettiği için değil, ilanı gördüğü için gelir. Onboarding zayıfsa hızla düşer.

Karşılıklı test forumları, özellikle geliştirici topluluklarında işe yarar. Fakat geri bildirim kalitesi dalgalıdır. İnsanlar çoğu zaman sizin akışınızı anlamaya değil, kendi uygulamasına dönüş beklemeye odaklanır.

Profesyonel tester veya freelancer hattı, özellikle süre sıkıştığında daha öngörülebilir olur. Dezavantajı şudur: gerçek hedef kitlenin doğal davranışını her zaman yansıtmaz.

En sağlıklı kombinasyon

Tek kanal yerine karışık havuz kurun:

• Çekirdek grup profesyonel veya güvenilir tester’lardan oluşsun.
• İkinci halka mevcut çevreniz ve iş ağı olsun.
• Üçüncü halka forumlar ve topluluklardan gelsin.
• Hedef kitle temsilcileri mutlaka ayrıca eklensin. Özellikle fintech, sağlık, eğitim ve e-ticaret gibi alanlarda bu kritik.

Bu yaklaşımın sebebi basit. Bir grup istikrar sağlar, diğer grup gerçek kullanım senaryosu üretir.

Bir örnek video incelemesi görmek isterseniz aşağıdaki içerik, farklı yaklaşım biçimlerini kıyaslamak için yararlı bir başlangıç noktasıdır.

Kopyalanabilir davet mesajı

Aşağıdaki metin, gereksiz süs olmadan en çok çalışan formattır:

Merhaba, Android uygulamamız için Google Play kapalı test süreci yürütüyoruz. Katılım için uygulamayı yükleyip 14 gün boyunca günde en az bir kez açmanızı rica ediyoruz. İlk kullanımda şu akışları denemeniz yeterli: kayıt olma, giriş yapma, ana ekranı açma ve temel özelliği kullanma. Karşılığında geri bildiriminizi öncelikli olarak değerlendireceğiz ve süreç boyunca destek vereceğiz. Katılmak isterseniz e-posta adresinizi paylaşın, davet linkini iletelim.

Bu mesajın çalışmasının nedeni açık olmasıdır. Süreyi, beklentiyi ve yapılacak işi gizlemiyor.

Tester onboarding kontrol listesi

Davet kabul edildikten sonra işi kolaylaştırın:

1. E-posta doğrulaması alın.
2. Katılım adımlarını tek mesajda gönderin.
3. Ekran görüntülü kısa kurulum notu ekleyin.
4. İlk gün yapılacak 3 görevi yazın.
5. Sorun bildirimi için tek kanal verin. WhatsApp, Telegram ya da form.
6. Günlük hatırlatmayı sade tutun.
7. Pasif kalanları ikinci günden itibaren takip edin.

Hangi kanal ne zaman mantıklı

Pratikte en çok hata, her kanala aynı mesajı atmak. LinkedIn’de işe yarayan metin, forumda itici durur. Freelancer’a gönderdiğiniz brief ile mevcut kullanıcıya giden mesaj da aynı olmamalı.

Adım 3: Davet ve Onboarding Süreçlerini Mükemmelleştirme

Çoğu ekip “tester bulduk” anında rahatlıyor. Asıl iş o noktada başlıyor. Çünkü kapalı testte kayıp, çoğunlukla insanın fikir değiştirmesinden değil, sürecin belirsizliğinden yaşanıyor.

YouTube’daki kapalı test analizine göre, test kullanıcılarının %70-85’i süreci başarıyla tamamlarken %15-30’u ya test etmeyi unutuyor ya da teknik sorun yaşıyor. İyi onboarding, bu tabloyu anlamlı şekilde iyileştirebiliyor.

İyi davet metni ne yapar

Kötü davet metni “uygulamamızı dener misin?” der. İyi davet metni ise görevi tanımlar. İnsan ne kadar süre ayıracağını, ne yapacağını ve sorun yaşarsa nereye yazacağını bilir.

En etkili davetlerde şu üç unsur var:

• Süre netliği. Katılım bir kerelik değil, günlük.
• Görev netliği. Hangi ekranlar kritikse baştan söylenir.
• Destek netliği. Teknik sorun yaşarsa nereyi kullanacağı bellidir.

İlk oturum tasarımı, tester sadakatini belirler

Tester uygulamayı açtığında ne görür? Eğer daha ilk dakikada karmaşık kayıt akışı, belirsiz izin ekranları ve yönlendirmesiz bir ana ekranla karşılaşıyorsa kayıp başlar. Burada ürün ekibi, normal kullanıcı onboarding’ine gösterdiği özeni test kullanıcıları için de göstermeli.

Özellikle ilk oturumda şu düzen çalışır:

1. Hoş geldin ekranı.
2. Testte özellikle görmek istediğiniz iki ya da üç özellik.
3. Sorun bildirme kısayolu.
4. Ertesi gün tekrar açması için net sebep.

Arayüz tarafında sadeleştirme gerekiyorsa kullanıcı dostu mobil arayüz tasarımı üzerine bu rehber iyi bir referans olur.

Testçi, ürününüzü “öğrenmek” istemez. Testçi, kendisinden ne beklendiğini hızla anlamak ister.

Operasyonel takip sistemi

Tester yönetimi sohbet kutusunda yapılmamalı. Küçük ekiplerde bile tablo şart.

Aşağıdaki alanları takip edin:

• Davet durumu
  Gönderildi, kabul edildi, erişti, yükledi.
• İlk açılış durumu
  İlk oturum tamamlandı mı, hata aldı mı.
• Günlük aktivite notu
  Açtı, açmadı, sorun bildirdi.
• Geri bildirim sınıfı
  Bug, UX, performans, içerik, güven.
• Risk etiketi
  Pasifleşme riski, teknik engel, ilgisiz katılımcı.

Hatırlatma dili nasıl olmalı

Sert takip ters teper. Aşırı samimi ton da ciddiyeti düşürür. En iyi çalışan ton kısa ve profesyoneldir:

Merhaba, kapalı test sürecimiz devam ediyor. Bugün uygulamayı kısa bir oturumla açıp ana akışı kontrol edebilir misiniz? Eğer erişim veya performans sorunu varsa bu mesaja yanıt vermeniz yeterli.

Bu tarz takip, insanı zorlamadan aksiyon aldırır. Aynı zamanda teknik sorun ile ilgisizliği ayırmanızı sağlar.

Adım 4: Geri Bildirim Toplama, Analiz ve Yasal Uyum (KVKK/GDPR)

Kapalı testin asıl değeri “uygulamayı açtılar mı” bilgisinden gelmez. O bilgi sadece eşik kontrolüdür. Değer, hangi ekranlarda takıldıklarını, hangi cihazlarda hata aldıklarını ve hangi adımda güven kaybı yaşadıklarını sistemli biçimde toplamaktan gelir.

Kurumsal ekipler için bir ayrım daha var. Google’ın 2025 sonu güncellemesiyle Türkiye’de kurumsal test kullanıcılarının %30’u için managed Google Play hesapları zorunlu hâle geldi. Bu durum özellikle fintech ve sağlık gibi hassas alanlarda KVKK uyumlu test ortamlarının önemini artırdı. İlgili çerçeve Google Play yardım dokümanında belirtiliyor.

Yapılandırılmamış geri bildirim neden zayıf kalır

“Uygulama kasıyor”, “giriş zor”, “bir şeyler garip” gibi yorumlar ürün toplantısında konuşulur ama geliştirme kuyruğuna sağlıklı girmez. Bu yüzden geri bildirim formunu rastgele bırakmayın. Kategorileri baştan tanımlayın.

İyi bir test formunda şu alanlar bulunur:

• Ekran veya akış adı
• Sorunun tekrarlanma durumu
• Beklenen davranış
• Gerçekleşen davranış
• Cihaz ve işletim sistemi bilgisi
• Ekran görüntüsü veya kısa video
• Etkisi
  Engelliyor, yavaşlatıyor, rahatsız ediyor

Google Forms, Typeform, Airtable Form ya da ürün içine gömülü araçlar burada iş görür. Firebase App Distribution veya benzeri akışlar da dağıtım ve not toplama tarafında yardımcı olur. Araçtan çok şablon önemlidir.

Managed Google Play ne zaman düşünülmeli

KOBİ ve startup tarafında bu başlık çoğu zaman gereksiz karmaşıklık gibi görülüyor. Oysa kurumsal cihaz, çalışan erişimi, veri ayrışması veya hassas veri politikası varsa managed yapı düşünülmeli. Aksi durumda test erişimi teknik olarak açık görünür, fakat kurum içi cihaz politikaları yüzünden fiilen kırılır.

Özellikle şu durumlarda managed yaklaşım mantıklıdır:

• Kurumsal cihaz kullanımı varsa
• Fintech, sağlık, sigorta gibi hassas alanlardaysanız
• Test verisi ile canlı veri net ayrılmalıysa
• Erişim denetimi kayıt altına alınacaksa

En pahalı hata, geri bildirim toplamak değil. Kimin hangi veriye neden eriştiğini açıklayamamaktır.

KVKK ve GDPR tarafında minimum disiplin

Hukuk metni yazmadan da temel hijyen sağlanabilir:

1. Teste özel aydınlatma metni hazırlayın.
2. Açık rıza gereken noktaları ayırın.
3. Canlı veri yerine test verisi kullanın.
4. Ekran kayıtlarını sınırlı yetkiyle erişilebilir tutun.
5. Gereksiz kişisel veri toplamayı bırakın.

Bu disiplin, sadece yasal risk azaltmaz. Tester güvenini de artırır. Güven arttığında geri bildirim daha açık ve daha faydalı gelir.

Adım 5: Süreci Ölçeklendirme ve Sonuç

Bir uygulama için zor kurulan test düzeni, ikinci projede sıfırdan kuruluyorsa ekip aynı çileyi tekrar yaşıyor. Oysa kapalı test süreci birikimli yönetildiğinde sonraki yayınlarda ciddi rahatlık sağlar. Buradaki hedef tek seferlik çözüm değil, tekrar kullanılabilir sistem kurmaktır.

Kendi güvenilir tester havuzunuzu kurun

Her kapalı testten sonra iyi katılımcıları kaybetmeyin. İsim, iletişim tercihi, cihaz tipi, ilgi alanı, sektör tecrübesi ve geri bildirim kalitesi notu tutun. Bir süre sonra elinizde “kim sadece yükler”, “kim gerçekten akışı dener”, “kim hata tarifini düzgün yazar” bilgisi oluşur.

Bu havuzu segmentleyin:

• Genel kullanıcı segmenti
• Sektör uzmanı segmenti
• Kurumsal cihaz kullanan segment
• Hızlı erişim sağlayan çekirdek grup

Böylece her yeni sürüm için herkese aynı çağrıyı yapmak zorunda kalmazsınız.

Geri bildirimi operasyonel veriye çevirin

Başarı oranını yükseltmek için test kullanıcılarının bağlantıyı aldıktan sonra uygulamayı her gün açması kritik. Ayrıca test geri bildirimlerini ChatGPT veya Claude gibi araçlarla yapılandırılmış hâle getirmek, geliştirme döngüsünü hızlandıran değerli veri noktaları üretiyor. Bu pratik yaklaşım kapalı test süreci anlatımında açıkça vurgulanıyor.

Buradaki püf nokta şu: AI aracı geri bildirimin yerine geçmez. Ham notları sınıflandırır, tekrar eden problemleri kümeler, ekip için daha okunabilir hâle getirir. Yani testçiden “gerçek davranış”, araçtan ise “temizlenmiş yorum katmanı” alırsınız.

Daha hızlı ürün iterasyonu kurmak isteyen ekipler için erken aşama startup’larda growth odaklı deney yaklaşımı da test süreciyle birlikte düşünülmeli. Çünkü kapalı test sadece onay eşiği değil, erken öğrenme mekanizmasıdır.

Çalışan sistemin özeti

Aşağıdaki model, sahada en az sürpriz üreten yaklaşımdır:

Kapalı test, yayın öncesi formalite değil. İyi ekipler onu mini bir kalite laboratuvarı gibi kullanır.

Sık sorulan sorular

Testçilere ödeme yapmalı mıyım

Bazen evet. Özellikle süre baskısı varsa, profesyonel tester veya freelancer hattı daha öngörülebilir olabilir. Ama ödeme yapılan tester ile hedef kullanıcıdan gelen doğal geri bildirim aynı şey değildir. En iyi sonuç genelde karma modelden çıkar.

Bir testçi sürecin ortasında pasif kalırsa ne olur

Bu yüzden minimum sayıya değil, yedekli havuza oynayın. Operasyonel olarak başlangıçta daha geniş katılımcı havuzu kurmak daha güvenlidir. Pasiflik çoğu zaman isteksizlikten değil, unutma veya teknik problemden gelir.

Rastgele e-posta listesiyle ilerlemek mantıklı mı

Genelde hayır. Rastgele davet, kurulum üretse de düzenli kullanım üretmeyebilir. Davet edilen kişinin ne yapacağını anlaması ve motive olması gerekir.

Geri bildirimi nasıl daha işe yarar hâle getiririm

Serbest metin yerine şablonlu form kullanın. Sorunu ekran bazında, tekrarlanma durumu ile ve mümkünse görsel destekle toplayın. Sonra bu notları sınıflandırın.

AI araçları sahte geri bildirimin yerini tutar mı

Hayır. Gerçek kullanıcı davranışının yerine geçmez. Ama gelen geri bildirimleri temizlemek, özetlemek ve geliştirme backlog’una dönüştürmek için çok faydalıdır.

Son söz net. Google Play’in kapalı test kuralı can sıkıcı olabilir, ama yönetilemez değil. Ekipler bu süreci son dakika görevinden çıkarıp standart operasyon hâline getirdiğinde, yayın gecikmesi azalır, ürün kalitesi artar ve mağaza onayı daha öngörülebilir olur. Google play test kullanıcısı bulma çilesine son: 2026 i̇çin pratik çözüm yolları arayan herkes için çözüm, daha çok ilan açmak değil, daha iyi sistem kurmaktır.

Mobil ürününüz için kapalı test, yayın hazırlığı, ASO, UI/UX ve ölçeklenebilir uygulama geliştirme süreçlerini birlikte ele almak isterseniz İpek Yazılım ile iletişime geçebilirsiniz. Özellikle erken aşama girişimler, KOBİ’ler ve kurumsal ürün ekipleri için uçtan uca mobil yayın operasyonu kurmak, bu süreci çok daha öngörülebilir hâle getirir.