E-ticaret Uygulaması İçin Geliştirici Bulmak: Ticaret Uygulamasını Diğerlerinden Ayıran Şey

E-ticaret uygulaması projelerinin çoğu, sanki teslim edilecek şey uygulamaymış gibi brief'leniyor. Değil. Aslında satın aldığınız şey parayı doğru tahsil eden bir ödeme akışı, depoyla aynı şeyi söyleyen bir katalog ve iade edildiğinde ayakta kalan bir sipariş kaydı. Ekranlar bunun görünen ve kolay olan tarafı.

Ticaret uygulamasında işe alım da bu yüzden hep aynı yerde tökezliyor. Güzel ekran çıkaran biriyle anlaşılıyor, ekranlar aşağı yukarı zamanında geliyor ve proje tam da uygulamanın bir dükkâna dönüşmesi gereken noktada duruyor: mağaza incelemesinden geçen ödeme, satın alma anında doğru olan stok ve "Teşekkürler" ekranından sonra gidecek bir yeri olan sipariş.

Genel süreç aynen geçerli — önce işin ne olduğuna karar verin, sonra kişiyi arayın. Aşağıdakiler, iş ticaret olunca değişenler.

Ticaret uygulaması, mobil cephesi olan bir dükkândır#

İşin ağırlığı nerede duruyor

Son satırı iki kez okuyun. İçerik uygulamasında hata utanç vericidir; ticaret uygulamasında hatanın bir tutarı ve bunu sizden önce fark etmiş bir müşterisi vardır. Bunun ayrı bir işe alım olmasının bütün sebebi bu — ekran satın almıyorsunuz, o satırın yanlış tarafında daha önce bulunmuş birini satın alıyorsunuz.

Mimarinizi belirleyen ödeme kuralı#

Çoğu brief'in geç fark ettiği kısım burası ve herkese açık şekilde yazılı.

Apple'ın App Review Guidelines belgesi 3.1.3(e) maddesinde şunu söylüyor: uygulamanız insanların uygulama dışında tüketilecek fiziksel ürün veya hizmet satın almasını sağlıyorsa, bu tahsilatta uygulama içi satın alma dışında bir yöntem kullanmak zorundasınız — Apple Pay ya da normal kart girişi. Aynı belge 3.1.1'de bunun tersini şart koşuyor: uygulamanın kendi içinde açılan her şey, yani dijital içerik ve özellikler, uygulama içi satın almadan geçmek zorunda.

Google da sınırı aynı yere çiziyor. Play ödeme politikası, yalnızca Play üzerinden dağıtılan uygulamanın dışında tüketilebilen satın almaları Google Play faturalandırma sisteminin dışında tutuyor.

Yani "tam olarak ne satıyoruz" sorusu bir ürün detayı değil. Projenizi üç kurgudan birine yerleştiriyor: fiziksel ürün ve dışarıda tüketilen hizmet — gerçek bir ödeme kuruluşu gerekir, mağaza komisyonu yoktur; dijital içerik — uygulama içi satın alma gerekir ve komisyon ödenir; ya da ikisi birden — her ikisi de, birbirinden temiz ayrılmış şekilde gerekir ve ticaret tecrübesi olmayan ekipler ilk ret cevabını genellikle burada alır.

Kimsenin kapsama almadığı parçalar#

Aşağıdakilerin hepsi ticarette sıradan, "bir uygulama" diye yazılmış brief'lerde ise düzenli olarak yok.

• Katalog doğruluğu. Ürünlerin gerçekte nerede durduğu, uygulamaya nasıl ulaştığı ve bir değişikliğin görünmesinin ne kadar sürdüğü. Fiyat, varyant, görsel ve açıklama sürekli değişir; her birinin bir sahibi olmalı.
• Satın alma anındaki stok. Ekran açıldığı andaki stok değil. Son ürünü aynı dakika içinde iki kişinin alması sıradan bir salı günüdür; istisna değil, tasarım kararıdır.
• Sipariş durumu. Oluşturuldu, ödendi, hazırlandı, kargolandı, teslim edildi, iptal edildi, kısmi iade edildi. Bu makineyi kimse çizmezse uygulama onu kazara icat eder ve müşteri hizmetleri durumu telefonda öğrenir.
• Üyeliksiz alışveriş. İlk satın almadan önce hesap açtırmak, o satışı kaybetmenin en güvenilir yoludur. Buna izin verip vermemeniz veri modelinizi değiştirir.
• Arama ve filtreleme. Elli üründe sorunsuz, beş bin üründe gerçek bir mühendislik işi — ve brief aşamasında ikisi birbirine benziyor.
• Anlamı olan bildirim. "Siparişiniz kargoda" ile "Bu hafta sonu %50" aynı teknik kanal, tamamen farklı iki izin harcamasıdır.
• İade ve yayından sonraki hafta. "Siparişim nerede" sorusunu birileri cevaplayacak. O kişiyi adıyla belirleyin ve ona bir ekran verin.

İşe alımı nasıl yürütmeli#

1. Ne sattığınızı adlandırın — fiziksel ürün, telefondan bağımsız kullanılan bir hizmet, dijital içerik ya da karışık. Bu tek cümle ödeme altyapısını ve mimarinin yarısını seçer.
2. Yayında bir ticaret uygulaması isteyin — portfolyo sayfası değil, açabileceğiniz bir mağaza bağlantısı. "E-ticaret uygulaması yaptık" ile "işte linki" farklı iddialardır.
3. Oradan bir şey satın alın — en ucuz ürünü, kendi kartınızla. Onların ödeme akışı, hata durumları ve sipariş e-postaları hakkında yirmi dakikada üç görüşmeden fazlasını öğrenirsiniz.
4. Ödeme ilişkisinin sahibini sorun — ödeme kuruluşu hesabı, mağaza hesapları, anahtarlar. Bunlar başkasının adınaysa dükkânınız ödünçtür.
5. "Teşekkürler" ekranından sonrasını sorun — sipariş durumları, iadeler, kısmi iptaller ve bunları hangi insanın gördüğü. Buradaki muğlak cevap en güvenilir erken uyarıdır.
6. Projeden önce bir hafta satın alın — gerçek bir dilim, tercihen canlı bir test ortamına bağlanmış ödeme akışı. Para işin içindeyken bir şey bozulunca karşınızdakinin nasıl davrandığını gösteren tek test budur.

Bunun toplam maliyeti kendi değişkenleri olan ayrı bir soru ve kapsam, saat ücretinden çok daha fazla oynatır — aynı hesap burada da geçerli, ticaret sadece oynatılacak kapsamı artırır.

Aynı kontrolü bize de uygulayın#

Az önce anlattığımız kontrol herkes için geçerli, biz de dahil. Mağaza sayfalarından doğrudan okunan hâliyle yayında olan uygulamalarımız şunlar:

Her biri bir tık uzakta: Glamour — Color Analysis & Glow Up, HairMaxx — AI Hair Style & Care ve Tattoo Genie — AI Designer. Bu kaydın ne olduğuna ve ne olmadığına dikkat edin: yayında sayfası, gerçek değerlendirmesi ve uygulama içi satın almayla işleyen aboneliği olan üç tüketici uygulaması — arkasında deposu olan bir dükkân değil. Kurgunuzun merkezinde fiziksel bir katalog varsa bunu görüşmede doğrudan bize sorun, mağaza sayfasının o soruyu kapattığını varsaymayın. Aynısını değerlendirdiğiniz herkese sorun ve kendinden emin cevap yerine somut cevabı tercih edin.

Sık sorulan sorular#

Uygulamamda ürün satmak için uygulama içi satın alma gerekir mi?

Fiziksel ürün için hayır — dahası, kullanmanıza izin verilmiyor. Apple'ın 3.1.3(e) maddesi, uygulama dışında tüketilen ürün ve hizmetler için uygulama içi satın alma dışında bir yöntem şart koşuyor; Google Play de aynı satın almaları kendi faturalandırma sisteminden muaf tutuyor.

Uygulama içi satın alma ters yönde zorunlu hâle geliyor: uygulamanın kendisinin açtığı her şey — dijital içerik, ek özellikler, bunlara yapılan abonelikler — mağazanın sisteminden ve komisyonundan geçmek zorunda.

E-ticaret geliştiricisinde normal bir mobil geliştiricide aranmayan ne var?

Para yolunun ve onu izleyen durumların tecrübesi: mağaza incelemesinden geçmiş bir ödeme entegrasyonu, stoğun gerçekten durduğu yerle senkron kalan bir katalog, iptal ve kısmi iadelerde ayakta kalan bir sipariş modeli ve düzgün hata veren bir ödeme akışı.

Ekranlar, yetkin her mobil geliştiricinin yapabileceği kısım. Diğer dördünü sorun ve her biri için yayına girmiş bir örnek isteyin.

Mevcut internet mağazamı uygulamaya sarmam yeterli olmaz mı?

Nadiren, ve Apple bunu doğrudan söylüyor: 4.2.2 maddesi, kataloglar dışında uygulamaların ağırlıklı olarak tanıtım malzemesi, web kırpıntısı, içerik toplayıcı ya da bağlantı listesi olmaması gerektiğini yazıyor. Mağazanızın etrafına sarılmış bir web görünümü klasik ret sebebidir.

Ticari bir sebebi de var. Mobil sitenin zaten verdiğinin ötesinde bir şey sunmayan uygulama — kayıtlı ödeme, gerçek bildirim, çevrimdışı gezinme, daha hızlı ödeme akışı — müşteriye kurmak için hiçbir sebep vermez.

Bir e-ticaret geliştiricisini işe almadan önce nasıl kontrol ederim?

Yaptıkları bir ticaret uygulamasının yayındaki mağaza sayfasını açın ve en ucuz ürünü kendi kartınızla satın alın. Ödeme akışını, hata durumlarını, gelen e-postayı ve siparişin sonrasında nasıl göründüğünü izleyin.

Sonra sizin projenizde ödeme kuruluşu hesabının ve mağaza hesaplarının kimin adına açılacağını sorun. Cevap "sizin adınıza" değilse, bulgu budur ve portfolyo sayfasındaki her şeyden daha önemlidir.