Steam wishlist konusu biraz şehir efsanesine döndü. “Şu sayıya ulaşırsan algoritma seni açar”, “7 bin altı çıkış yapma”, “wishlist conversion şu olmak zorunda” gibi çok kesin cümleler dolaşıyor. Valve’ın kendi dokümanı daha sakin bir şey söylüyor.
Biz wishlist’i kitle ilgisi + bildirim kanalı + pazarlama teşhis metriği olarak görürüz. Tek başına başarı puanı değil.
Wishlist ne işe yarıyor?
Mağaza sayfanız herkese açıldıktan sonra oyuncular oyunu wishlist’e ekleyebilir. Steam çıkışta ve belirli indirim durumlarında bu oyunculara bildirim gönderebilir. Steamworks raporlarında eklemeleri, silmeleri ve wishlist’ten satın alma davranışını görebilirsiniz.
Gizli minimum wishlist eşiği yok
Valve açıkça “Steam’in oyunu göstermeye başlaması için minimum wishlist sayısı yok” diyor. Yani internetteki hedef sayılar platform kuralı değil. Benchmark olarak kullanılabilir, o ayrı.
Wishlist çoğu görünürlük alanında doğrudan algoritma düğmesi değil
Steam’in Visibility dokümanında wishlist’lerin çoğunlukla algoritmik görünürlüğün doğrudan faktörü olmadığı, Popular Upcoming gibi istisnalar bulunduğu yazıyor. Bu önemli. Çünkü hedefi “sayıyı şişir”den “doğru oyuncuyu getir ve hangi kanalın çalıştığını anla”ya çeviriyor.
Biz ne ölçerdik?
- Günlük/haftalık wishlist ekleme.
- Hangi kampanya veya içerikten sonra artış geldiği.
- Ülke/bölge dağılımı.
- Demo oynayanlardan wishlist davranışı.
- Fragman veya store copy değişikliğinden önce/sonra trend.
- Etkinlik günleri ile normal günlerin farkı.
Wishlist spike geldiğinde sadece sevinmeyin, nedenini etiketleyin
Bir creator videosu çıktı, 380 wishlist geldi diyelim. Bunu takvime yazın. İki ay sonra “hangi kanal iyi çalışıyordu?” diye hatırlamaya çalışmayın. Basit bir sheet bile yeterli.
Wishlist → satış formüllerine dikkat
Valve, herkesin wishlist kullanma sebebi farklı olduğu için satışları doğru tahmin eden tek bir formül olmadığını söylüyor. Fiyat, tür, ülke, wishlist’in yaşı, launch zamanı, demo ve kampanya kalitesi sonucu değiştiriyor.
Uygulanabilir küçük plan
- Mağaza sayfasını yeterince iyi olduğunda erken aç.
- Her önemli pazarlama hareketini tarih/saat ile kaydet.
- Wishlist değişimini düzenli çek.
- Spike’ları kampanyalarla eşleştir.
- Bölgesel veriye bak.
- En çok doğru oyuncu getiren 2–3 kanalı tekrar dene.
- Sadece ucuz trafik getiren ama oyunu anlamayan kitleyi başarı sayma.
Son söz
Wishlist önemli, evet. Ama oyun iyi anlatılmıyorsa, demo oyuncuyu ikna etmiyorsa veya mağaza sayfası yanlış beklenti yaratıyorsa tek sayı sizi kurtarmıyor. Ben olsam “kaç wishlist var?” sorusunun yanına mutlaka “nereden geldi ve neden geldi?” sorusunu koyarım.
Kaynaklar
Bunu gerçek projede nasıl uygularız?
Ben bu konuyu doğrudan bir sonraki build’e bağlamayı tercih ederim. steam wishlist nasıl artırılır için ayrı bir doküman yazıp unutmak yerine, tek bir feature veya oyuncu akışı seç. Önce mevcut davranışı kaydet. Sonra değişiklik yap. Sonra aynı ölçümü tekrar al. Bu kadar. Küçük deney daha az havalı görünüyor ama hangi kararın işe yaradığını gerçekten anlatıyor.
Örneğin önce bir “başlangıç durumu” kaydı açabiliriz: hangi build, hangi oyuncu grubu, hangi sistem ayarı, beklenen sonuç ne? Ardından kararın sahibini ve geri dönüş koşulunu yaz. Bir değişiklik kötü giderse “ne zaman geri alacağız?” sorusunun cevabı olay anında tartışılmamalı. Önceden belli olsun.
Mini karar günlüğü
| Alan | Ne yazacağız? |
|---|---|
| Problem | Oyuncu veya üretim tarafında ne bozuk? |
| Hipotez | Hangi değişiklik neden düzeltecek? |
| Risk | En pahalı yan etki ne? |
| Sinyal | İşe yaradığını hangi veri gösterecek? |
| Rollback | Hangi durumda eski davranışa döneceğiz? |
Yayınladıktan veya uyguladıktan sonra neye bakmalı?
İlk gün çok gürültülü olabilir. Birkaç yüksek sesli yorumla komple yön değiştirmek yerine davranış sinyalini, hata oranını ve qualitative feedback’i birlikte oku. Aynı sorun üç farklı kanalda görünüyorsa daha güçlü sinyal. Sadece tek yorum varsa backlog’a yaz, hemen mimariyi sökme.
Bir de “başarı”yı sadece pozitif metrik diye düşünmemek lazım. Bazen amaç hata oranını düşürmek, support yükünü azaltmak veya ekipte aynı işin iki kere yapılmasını önlemek. Steam Wishlist Nasıl Artırılır? Indie Geliştiriciler İçin Ölçülebilir Rehber için doğru sonuç, konuya göre değişir. O yüzden başta hangi davranışı koruduğumuzu yazmıştık zaten.
Benim özellikle kaçınacağım şeyler
- Tek bir benchmark’ı evrensel doğru kabul etmek.
- Ölçmeden önce büyük refactor yapmak.
- Rollback yolu olmadan canlı değişiklik açmak.
- “Best practice böyle” deyip ürünün gerçek ihtiyacını unutmak.
- Başarısız denemeyi dokümantasyondan silmek. En faydalı not bazen o.
Kısacası, Taktik listesi yerine funnel, source tracking and iteration. Fakat bunu gerçekten değerli yapan şey örnek, ölçüm ve karar bağlamı. Yazıyı yayınladıktan sonra kendi proje ekran görüntümüzü veya küçük bir before/after tablosunu eklemek de bu yüzden iyi fikir.
Uygulama öncesi son kontrol
- Kapsam: Bu değişiklik tam olarak hangi oyuncu akışını veya üretim problemini etkiliyor?
- Veri: Değişiklikten önce elimizde karşılaştırabileceğimiz bir baseline var mı?
- Uyumluluk: Eski save, eski client, farklı platform veya eski config bu karardan etkileniyor mu?
- Sahip: Son karar ve rollback kimin sorumluluğunda?
- İletişim: Oyuncuya veya support ekibine açıklanması gereken bir davranış değişikliği var mı?
steam wishlist nasıl artırılır hakkında sık yapılan yanlış çıkarım
Bir yöntemin başka stüdyoda çalışması onun bizim oyunda aynı sonucu vereceği anlamına gelmiyor. Tür, oyuncu davranışı, ekip büyüklüğü ve mevcut teknik borç sonucu değiştiriyor. Dışarıdaki örnek başlangıç noktası. Kararımızın kanıtı değil.
O yüzden son adım basit: küçük uygula, gözle, yaz. İyi gittiyse genişlet. Kötü gittiyse geri dön ve nedenini sakla. Bir sonraki feature’da o not muhtemelen işimize yarayacak.
Küçük bir örnekle karar akışı
Diyelim bir sistemde sorun görüyoruz. İlk gün direkt çözüm yazmak yerine önce bir cümle kuruyoruz: “Oyuncular X noktada beklediğimiz davranışı göstermiyor.” Sonra iki veya üç olası sebep çıkarıyoruz. Her sebep için gözlemleyebileceğimiz sinyal belirliyoruz. Böylece tartışma “bence” seviyesinden çıkıyor.
Değişiklik yaptıktan sonra sadece ortalamaya bakmıyoruz. Yeni oyuncu, eski oyuncu, farklı platform veya farklı build gibi segmentlerde ters sonuç var mı kontrol ediyoruz. Genel sayı düzelirken küçük ama önemli bir grup bozulabilir. Canlı üründe en can sıkıcı sürprizlerden biri bu.
Son olarak kararı kapatıyoruz: devam, geri al veya bir tur daha test et. Açık karar bırakmamak önemli. Yoksa üç hafta sonra kimse mevcut ayarın neden böyle olduğunu hatırlamıyor.
Bu yazıyla aynı içerik kümesindeki ana rehberlere geç.