Teknik not

Vibe Coding’de ASO: Uygulama Mağazası Rehberi

Vibe coding ASO sürecinde anahtar kelime, ekran görüntüsü ve uygulama özelliklerinin doğrulanarak mağaza sayfasına aktarılmasını gösteren piksel sanat görseli

Vibe coding ASO, yapay zekâ ile hızlı geliştirilen bir mobil uygulamanın mağaza sayfasını sonradan yazılan bir reklam metni olmaktan çıkarır. Uygulama adı, kısa açıklama, ekran görüntüsü, anahtar kelime ve özellik iddiası; ürünün gerçekten yaptığı işle aynı gerçeğe dayanır.

AI ile bir uygulamanın ilk sürümünü hızla üretmek kolaylaştı. Asıl risk, mağaza sayfasının uygulamadan daha fazla şey vaat etmesidir: ekranda gösterilmeyen bir özellik, çalışmayan bir akış, yanlış kategoride konumlanan bir fayda veya kullanıcı aramasına cevap vermeyen soyut bir açıklama. ASO’nun ilk işi anahtar kelime doldurmak değil, vaat ile deneyim arasındaki farkı kapatmaktır.

ASO nedir ve vibe coding’de neden farklıdır?

ASO (App Store Optimization), bir uygulamanın mağaza listelenmesinin bulunabilirlik ve dönüşüm için iyileştirilmesidir. Aramada bulunma; uygulama adı, açıklama, kategori ve yerelleştirilmiş mağaza varlıklarından etkilenir. Dönüşüm ise kullanıcının ilk bakışta “bu uygulama benim sorunum için mi?” sorusuna verdiği cevapla başlar.

Vibe coding’de fark şudur: ürün kararı, uygulama metni, ekran ve teknik özellik çoğu kez aynı hızla değişir. Eğer mağaza varlıkları ayrı bir not dosyasında yaşarsa birkaç geliştirme turunda güncelliğini kaybeder. ASO bilgisini ürün backlog’una ve kabul ölçütlerine bağlamak gerekir.

Mağaza vaadi sözleşmesi kurun

Her mağaza iddiasını uygulamadaki gerçek bir ekrana, kullanıcı akışına veya ölçülebilir özelliğe bağlayın. Buna mağaza vaadi sözleşmesi diyelim. Sözleşme, ajanın metin üretirken var olmayan bir yetenek eklemesini engeller.

Mağaza iddiası Kanıt Kontrol
“Çevrimdışı not alma” Yerel kayıt ve ağ kapalı akışı Uçak modunda yeni not oluştur
“Hatırlatıcı oluşturma” Bildirim izni ve zamanlayıcı ekranı İzin reddedildiğinde güvenli davranış
“Hızlı arama” Arama alanı ve sonuç listesi Boş sorgu ile sonuçsuz sorgu ayrımı
“Cihazlar arası senkron” Hesap, sunucu ve çakışma akışı İki cihazda güncelleme senaryosu

Kanıtı olmayan iddia, mağaza metninden çıkarılmalı veya ürün backlog’una taşınmalıdır.

Önce kullanıcı niyetini, sonra anahtar kelimeyi yazın

“En çok aranan kelime” listesi tek başına iyi ASO stratejisi değildir. Kullanıcının uygulamayı açmadan hemen önce çözmek istediği işi tanımlayın. Niyet, anahtar kelimeden daha dayanıklıdır; çünkü uygulama arayüzü ve mağaza dili değişse bile temel problem aynı kalır.

Basit bir niyet haritası oluşturun:

  • Problem: Kullanıcı neyi zor buluyor?
  • Beklenen sonuç: Uygulamayı kullanınca ne değişecek?
  • Bağlam: Hangi anda, hangi cihazda, hangi kısıtla kullanıyor?
  • Kanıt: Bu sonucu uygulamada hangi ekran veya akış gösteriyor?
  • Arama dili: Kullanıcı bunu nasıl kısa bir ifadeye dönüştürebilir?

Üç katmanlı anahtar kelime haritası

Anahtar kelimeleri tek bir uzun liste yerine üç katmanda tutmak, AI’ın genel ve tekrar eden metin üretmesini azaltır.

  1. Çekirdek problem: Uygulamanın çözdüğü temel iş. Örnek: not alma, bütçe takibi, alışkanlık izleme.
  2. İşlev: Kullanıcının uygulamada gerçekleştirdiği eylem. Örnek: çevrimdışı kaydetme, etiketleme, hatırlatma.
  3. Bağlam: Kullanım koşulu veya hedef kullanıcı. Örnek: öğrenci, seyahat, ortak liste, internet yokken.

Her kelimenin yanında “uygulama bunu gerçekten sunuyor mu?” sütunu yer almalıdır. Hayır olanları aday metinden çıkarın.

ASO anahtar kelime kaydı

İfade: çevrimdışı not alma
Katman: işlev + bağlam
Kullanıcı niyeti: bağlantı yokken notu kaybetmemek
Ürün kanıtı: yeni not ekranı, yerel kayıt, bekleyen senkron durumu
Mağaza yeri: kısa açıklama + 1. ekran görüntüsü
Durum: doğrulandı

Başlık ve kısa açıklama için “tek iş” kuralı

Başlıkta her özelliği sıralamaya çalışmak, hem okunurluğu hem konumlandırmayı zayıflatır. Başlık, uygulamanın kim için hangi temel işi yaptığını söylemelidir. Kısa açıklama ise birincil faydayı ve ayırt edici mekanizmayı tamamlar.

AI’a şu görevi verin:

Başlık için tek bir çekirdek problemi seç. Kısa açıklamada yalnızca uygulamada kanıtlanan iki işlevi kullan. Karşılaştırılamaz üstünlük, “en iyi”, “garantili” veya ölçülmeyen performans iddiası ekleme.

Ekran görüntüsü metni bir test senaryosudur

Mağaza ekran görüntüsü yalnızca estetik bir görsel değildir. Kullanıcı ekrandaki metni, uygulamanın ilk açılış deneyimiyle karşılaştırır. Bu nedenle her kare bir kullanıcı senaryosu kanıtlamalıdır.

  1. İlk kare: Çekirdek problemi ve ana faydayı gösterir.
  2. İkinci kare: Faydanın nasıl gerçekleştiğini bir akışla kanıtlar.
  3. Üçüncü kare: Sınır durumunu veya güven unsurunu gösterir.
  4. Dördüncü kare: Kullanıcının geri dönmesini sağlayan devamlılık değerini anlatır.

Görseldeki metin, uygulama içinde olmayan menü adı veya sonuç vaat etmemelidir. AI ile üretilen metinleri ekran görüntüsü tasarımına koymadan önce ürün sahibi kontrol etmelidir.

AI’dan ASO metni isterken bağlam paketi verin

“Bu uygulama için ASO yaz” istemi, çoğu zaman genelleştirilmiş iddialar üretir. Bunun yerine ürün gerçeğini küçük bir paketle verin.

Ürün: Çevrimdışı not uygulaması

Doğrulanmış özellikler:
- Notu cihazda anında kaydetme
- Bağlantı gelince senkron kuyruğu
- Etiket ile filtreleme

Yapmadıkları:
- Ses kaydı yok
- Ortak düzenleme yok
- Masaüstü uygulaması yok

Hedef kullanıcı: seyahatte veya bağlantısı kararsız çalışan kişiler
Ton: açık, sakin, abartısız

Çıktı:
- 5 başlık alternatifi
- 5 kısa açıklama alternatifi
- 4 ekran görüntüsü için kanıtlanabilir başlık
- Her iddianın ürün kanıtı

Negatif özellik listesi neden gereklidir?

AI kodlama ve metin araçları, benzer uygulamalarda sık görülen özellikleri doğal olarak önerir: yapay zekâ asistanı, ekip paylaşımı, bulut yedekleme, widget, analitik veya sınırsız kullanım. Bunlar ürününüzde yoksa ASO metnine girmemelidir.

Bu nedenle bağlam paketine “yapmadıkları” bölümü ekleyin. Bu küçük sınır, hem yanlış vaatleri hem de sonradan teknik borca dönüşen gereksiz özellik beklentilerini azaltır.

Yerelleştirme: Kelimeyi değil niyeti taşıyın

Mağaza metnini yalnızca doğrudan çevirerek yerelleştirmek, kullanıcı dilini kaçırabilir. Yerelleştirilmiş metin için şu sırayı izleyin: önce çekirdek problem, sonra kullanıcıların doğal ifadesi, ardından mağaza alanının karakter sınırı ve ekran görüntüsündeki görsel alan.

Örneğin “offline notes” ifadesi farklı pazarlarda aynı kelimeyle aranmayabilir. Ancak “bağlantı yokken notu kaydetme” niyeti değişmez. AI’dan adaylar isteyin, ancak yerel dildeki anlamı ve ürünle uyumu insan kontrolüyle doğrulayın.

Mağaza vaadi ile onboarding’i eşleyin

Kullanıcı mağaza sayfasında gördüğü ana faydayı ilk oturumda bulamazsa dönüşüm kazanılmış olsa bile güven kaybedilir. İlk açılış akışı, ilk ekran görüntüsündeki vaade mümkün olduğunca kısa yol sunmalıdır.

Mağaza mesajı İlk oturumda görünmesi gereken
“İnternetsiz not kaydet” Yeni not eylemi ve yerel kayıt geri bildirimi
“Harcamayı kategorilere ayır” Kategori seçimi ve ilk özet
“Günlük alışkanlığını izle” İlk alışkanlık ekleme ve gün işaretleme

Yayın öncesi ASO doğrulama kapısı

Mağaza varlıklarını koddan bağımsız bir pazarlama işi gibi değerlendirmeyin. Her sürümde kısa bir doğrulama kapısı çalıştırın:

  • Başlık ve kısa açıklamadaki her iddia uygulamada var mı?
  • Ekran görüntüsü gerçek sürümden mi alındı?
  • Ekran görüntüsü metni kullanıcı akışını doğru anlatıyor mu?
  • Anahtar kelime, problem ve ürün kanıtı aynı satırda eşleşiyor mu?
  • İzin, ödeme, çevrimdışı kullanım veya senkron gibi hassas iddialar test edildi mi?
  • Yerelleştirilmiş metin ürünün o dildeki arayüzüyle uyumlu mu?

ASO performansını nasıl öğrenirsiniz?

Sıralama tek metrik değildir. Kullanıcının mağaza sayfasını görmesi, sayfayı açması, yüklemesi, ilk değer anına ulaşması ve geri dönmesi birlikte değerlendirilmelidir. Bir açıklama daha çok ziyaret getirip yanlış kullanıcıları çekiyorsa yükleme sonrası kalite düşebilir.

Her denemede tek ana değişken değiştirin: örneğin ilk ekran görüntüsünün fayda cümlesi veya kısa açıklamadaki işlev sırası. Aynı anda hem başlığı, hem görselleri, hem ürün onboarding’ini değiştirirseniz sonucun nedenini anlayamazsınız.

Vibe coding akışında ASO’nun yeri

Vibe coding fikri hızlıca çalışan bir ürüne dönüştürür. Eval-driven development, uygulamanın kritik davranışlarını kanıtlar. ASO vaadi sözleşmesi ise bu kanıtı mağaza sayfasına doğru taşır.

Birlikte düşünüldüğünde akış şudur: ürün özelliği tanımlanır, testle doğrulanır, mağaza iddiasına bağlanır, ekran görüntüsüyle gösterilir ve ilk oturumda aynı değer yeniden sunulur.

30 dakikalık başlangıç planı

  1. İlk 10 dakika: Uygulamanın tek çekirdek problemini, üç doğrulanmış özelliğini ve üç yapmadığını yazın.
  2. Sonraki 10 dakika: Beş anahtar kelime adayını ürün kanıtıyla eşleştirin.
  3. Sonraki 5 dakika: İlk dört ekran görüntüsünün her biri için bir kullanıcı senaryosu seçin.
  4. Son 5 dakika: Başlık, kısa açıklama ve ekran görüntüsü metnini mağaza vaadi tablosuna bağlayın.

Sonuç

Vibe coding’de ASO, daha fazla kelime ekleme sanatı değildir. Kullanıcının aradığı problem, uygulamanın gerçek davranışı ve mağaza sayfasındaki kanıt arasında tutarlı bir yol kurmaktır. Bu yolu sözleşme hâline getirdiğinizde AI araçları metin üretimini hızlandırır; fakat ürün gerçeğini değiştiremez.

Bir sonraki sürümünüzde mağaza açıklamasını yazmadan önce “bu cümleyi uygulamada nerede kanıtlıyorum?” sorusunu sorun. Cevabı olan her vaat daha güvenilir, daha anlaşılır ve daha sürdürülebilir bir ASO temelidir.

Kaynak

Apple Developer: Product Page

1 yorum

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir