Google Play kodu satmaya başlayan hemen herkes aynı beklentiyle girer: ürün herkesin tanıdığı, talebi sürekli, satması kolay. İlk hafta bunu doğrular gibi olur. Sonra ilk bölge uyuşmazlığı gelir, ardından ilk "kod hesabıma tanımlanmıyor" mesajı, sonra da tedarikçinin sabah sessizce güncellediği fiyat listesi. O noktada anlarsın ki bu ürünün zorluğu satmakta değil, satış sonrasında ayakta kalmakta.
Bu yazıda pazarlama tavsiyesi yok. Google Play kodu satan bir işletmenin operasyonunu kâra geçiren teknik kararları konuşacağız: bölge mantığının yazılıma nasıl gömüleceği, iptal edilen siparişin stoğu neden kirlettiği, fiyat güncellemesinin neden manuel olmaması gerektiği ve bir e-pin satış yazılımının bu üç başlıkta ne yapması, ne yapmaması gerektiği. Amaç net: her siparişin sonunda net kâr bırakmasını sağlamak.
Bölge kilidi neden bu ürünün en pahalı detayı?
Google Play kodları ülke bazlı çalışır. Türkiye hesabına tanımlanmayan bir kod, teknik olarak geçerli olsa bile senin için hatalı satıştır. Müşteri kodu girer, hata alır, sana yazar; sen tedarikçiyi ararsın, tedarikçi "kod sağlam" der ve haklıdır. Kimsenin yalan söylemediği bu tabloda zararı yalnızca sen yazarsın. Bu yüzden bölge bilgisi ürün açıklamasının bir cümlesi değil, sistemin zorunlu bir alanı olmalıdır.
Pratikte kurgusu şöyle olmalı: her ürün varyantı bir ülke koduna bağlanır, stok havuzu o varyanta özeldir, sepet adımında kullanıcı bölgeyi onaylamadan ilerleyemez ve teslimat e-postasında hangi bölgeye ait kod aldığı tekrar yazılır. Bu üç katmanlı uyarı, bölge kaynaklı iptalleri ciddi biçimde düşürür. İyi bir dijital ürün satış scripti bu kuralı esnetmene izin vermez; çünkü esnetilen her kural gün sonunda destek talebi olarak geri döner.
İptal edilen bir sipariş stoğu nasıl kirletiyor?
En sinsi kayıp burada. Müşteri ödemeyi tamamlamaz ya da iade ister; kod ise çoktan rezerve edilmiş, belki de gösterilmiştir. Bu kodu tekrar havuza atarsan, ekranda bir kez görüntülenmiş bir ürünü ikinci kez satmış olursun. Atmazsan da stok sayın gerçeği yansıtmaz. Doğru çözüm ikili durum yönetimidir: rezerve edilen kod ile görüntülenen kod aynı şey değildir.
Sağlam kurgulanmış bir e-pin scripti, kodu ödeme onaylanana kadar rezerve tutar, ödeme başarısız olursa süre dolduğunda havuza otomatik iade eder; ancak kod bir kez müşteriye gösterildiyse artık "yakılmış" sayar ve asla tekrar satışa açmaz. Bu ayrım basit görünür ama uygulanmadığında aylar içinde stok sayısı ile gerçek arasındaki fark büyür ve bir gün satamadığın siparişlerle karşılaşırsın.
| Sipariş durumu | Kodun konumu | Stok sayımına etkisi | Otomatik aksiyon |
|---|---|---|---|
| Ödeme bekliyor | Rezerve | Satılabilir stoktan düşer | 15 dk sonra serbest bırak |
| Ödeme başarısız | Havuza döner | Stok geri artar | Müşteriye hatırlatma gönder |
| Ödeme onaylı | Müşteriye atanmış | Kalıcı düşer | Teslimat ve log kaydı |
| Görüntülendi, iade talebi | Yakılmış | Kalıcı düşer | Tedarikçi itiraz kaydı aç |
| Hatalı bölge | Karantina | Satışa kapalı | Varyant etiketini incele |
| Süresi yaklaşan parti | Öncelikli havuz | İlk çıkacak stok | Kampanya listesine ekle |
Fiyatı elle güncelleyen bir işletme neden kaybetmeye mahkûm?
Google Play kodlarında tedarikçi fiyatı kur ve kampanya hareketiyle gün içinde değişebilir. Fiyat listeni sabahları elle güncelliyorsan, öğleden sonra gelen her sipariş dünün maliyetiyle satılmış olur. Bunu on sipariş için düşünürsen önemsiz görünür; üç yüz sipariş için düşünürsen aylık kârının tamamı olabilir. Fiyatlandırma bir tablo işi değil, bir kural motorudur.
Doğru kurgu maliyet üstüne oran koymaktır: her ürün için minimum kâr yüzdesi, yuvarlama kuralı ve tedarikçi maliyeti tanımlanır; maliyet değiştiğinde satış fiyatı kendiliğinden yeniden hesaplanır. Kurumsal bir epin yazılım kurulumunda ayrıca taban fiyat koruması bulunur: sistem, belirlediğin minimum marjın altında satış yapmana izin vermez. Böylece kampanya yaparken yanlışlıkla zarar yazma ihtimali ortadan kalkar. Hangi kuralların hazır geldiğini özellikler sayfasından karşılaştırabilirsin.
Google Play kodu siparişlerinde başarısız işlem nedenleri
- Ödeme adımında terk 40%
- Bölge/ülke uyumsuzluğu 30%
- Stok tükenmesi 20%
- Riskli işlem engeli 10%
Dolandırıcılık ve ters ibraz riskini yazılım katmanında nasıl kesersin?
Dijital ürün satıcısının en büyük açık yarası çalıntı kartla yapılan alışverişlerdir. Ürün anında teslim edildiği için geri dönüş imkânı yoktur; ödeme sağlayıcı parayı geri aldığında hem malı hem parayı kaybedersin. Bu riski sıfırlayamazsın, ama yazılım seviyesinde ciddi biçimde daraltabilirsin. İlk savunma hattı otomatik risk kurallarıdır: aynı IP'den kısa sürede çoklu sipariş, yeni kayıtlı hesaptan yüksek tutarlı ilk alışveriş, farklı kart ile aynı e-posta denemeleri.
İkinci hat kademeli teslimattır. Belirli bir tutarın üstündeki ilk siparişler otomatik teslim edilmek yerine kısa bir manuel onay kuyruğuna alınır. Bu, gece boyunca gelen düşük riskli siparişlerin akışını bozmaz ama yüksek riskli işlemleri süzer. Üçüncü hat ise kara liste yönetimidir: kötü niyetli e-posta, kart parmak izi ve cihaz bilgisi bir kez işaretlendiğinde sistem aynı kişiyi tekrar içeri almaz. Bu üçlü yapıyı destekleyen bir e-pin satış scripti, aylık kayıp oranını gözle görülür şekilde düşürür.
Yeni kayıt olmuş bir kullanıcının ilk siparişinde tutar eşiği koy. Ters ibrazların büyük bölümü, hesabın açıldığı ilk 24 saat içinde gerçekleşir. Bu tek kural bile riskin önemli kısmını eler.
Toptan alıcıyı sisteme çekmezsen büyüme neden duruyor?
Google Play kodunda perakende satış hacmi sınırlıdır; asıl sıçrama, senden düzenli alan küçük satıcılar geldiğinde olur. İnternet kafeler, mahalle bayileri, sosyal medya üzerinden satış yapan küçük hesaplar. Bu kitle sana tek tek WhatsApp'tan yazdığında büyümez, kendi paneline girip kendi bakiyesinden çektiğinde büyür. Bayi, kendi kendine hizmet edebildiği ölçüde sana kâr bırakır.
Bunun için gereken üç yapı taşı vardır: grup bazlı fiyat kademesi, bakiye yükleme ve toplu kod çekme ekranı. Bayi kendi bakiyesini yükler, kendi indirim kademesini görür, gerektiğinde yüz adet kodu tek seferde alır. Tüm bu hareket senin sisteminde kayıtlıdır; kimin ne kadar aldığını, hangi bayinin büyüdüğünü ve kimin durduğunu raporlardan izlersin. Bu modelin maliyet tarafını fiyat sayfasında değerlendirip hangi paketin bayi hacmine uygun olduğunu görebilirsin.
Hangi kontrol listesiyle kuruluma başlamalısın?
Yeni bir altyapı kurarken en sık yapılan hata, her şeyi aynı anda açmaya çalışmaktır. Doğru yaklaşım, para kaybını durduran maddeleri önce devreye almak, büyüme maddelerini sonraya bırakmaktır. Aşağıdaki liste tam olarak bu önceliklendirmeye göre hazırlandı: üst sıradakiler zararı keser, alt sıradakiler geliri büyütür. Kuruluma her zaman zararı keserek başla.
| Adım | Amaç | Öncelik |
|---|---|---|
| Bölge bazlı varyant yapısı | Yanlış ürün satışını engellemek | 1 |
| Rezerve ve yakılmış kod ayrımı | Stok doğruluğunu korumak | 1 |
| Maliyet üstü otomatik fiyat kuralı | Kur hareketinde zarar yazmamak | 2 |
| Risk kuralları ve kara liste | Ters ibraz kaybını daraltmak | 2 |
| Teslimat log ve kanıt kaydı | İtirazlarda haklılığı ispatlamak | 2 |
| Bayi grubu ve bakiye sistemi | Toptan hacmi sisteme almak | 3 |
| Stok eşiği bildirimi | Satış kesintisini önlemek | 3 |
| Tekrar satın alma raporu | Sadık müşteriyi ölçmek | 4 |
Google Play kodu operasyonunu kural motoruna bağla
Bölge, fiyat, stok ve risk kurallarını tek panelde tanımla; her siparişin kârlı kapanmasını sisteme yaptır.
Google Play kodlarında bölge bilgisini nasıl yönetmeliyim?
Her ülkeyi ayrı bir ürün varyantı olarak tanımla ve her varyanta kendi stok havuzunu bağla. Sepet adımında bölge onayı zorunlu olsun; bu tek uygulama bölge kaynaklı iptallerin çoğunu ortadan kaldırır.
Ödeme tamamlanmadan kod gösterilmeli mi?
Kesinlikle hayır. Kod yalnızca ödeme onaylandıktan sonra görüntülenmeli, o ana kadar rezerve durumda tutulmalıdır. Bir kez görüntülenen kod tekrar satışa açılmamalıdır.
Fiyat güncellemesini tamamen otomatik yapabilir miyim?
Evet. Maliyet üstüne oranlı fiyatlandırma ve taban marj koruması tanımladığında, tedarikçi maliyeti değiştiğinde satış fiyatın kendiliğinden yeniden hesaplanır ve zararına satış engellenir.
Bayi sistemi küçük ölçekli bir işletme için erken mi?
Erken değil, ama sıralaması sonradır. Önce teslimat, stok ve fiyat katmanını sağlamlaştır; düzenli alan üç dört müşterin oluştuğu anda bayi paneli devreye alınmaya hazır demektir.
Google Play kodu satışında kazanan taraf, en ucuz fiyatı veren değil, en az hata yapan taraftır. Bölgeyi doğru etiketleyen, stoğunu kirletmeyen, fiyatını geciktirmeyen ve riskli işlemi zamanında süzen işletme, aynı tedarikçiden alsa bile rakibinden daha çok kâr eder. Bu kuralların yazılım tarafında nasıl göründüğünü kendi gözünle görmek istiyorsan, canlı demo üzerinde bir varyant oluşturup sipariş akışını baştan sona dene; ihtiyacın netleştiğinde kurulum adımına geçmen birkaç dakika sürer.