IdeaSoft kullanan mağazalarda uygulama projelerinin çoğu aynı yerde tökezliyor: kapsam. Panelde bir özellik vardır, satıcı onu uygulamada da görmek ister, geliştirme başlar ve o özelliğin dışarıya açılan bir karşılığı olmadığı ortada anlaşılır. Ne olur? Ya kapsam daralır ya takvim uzar; ikisi de kimsenin istemediği konuşmadır.
Bu yüzden IdeaSoft tarafında doğru sıralama şudur: önce kapsam haritası, sonra tasarım, en sonda kod. Aşağıda bu haritanın nasıl çıkarıldığını, erişimin nasıl kurulduğunu, istek limitlerinin uygulamayı nasıl etkilediğini, üyelik ve siparişin neden panelde kalması gerektiğini ve fiyatı hangi kalemlerin belirlediğini anlatıyoruz. Altyapıdan bağımsız mobil başlıklar mobil uygulama yaptırma rehberinde duruyor.
IdeaSoft mobil uygulama veriyi nereden alır?
IdeaSoft, barındırılan ve kapalı kaynak bir e-ticaret altyapısıdır; sunucudaki uygulama katmanına erişemezsiniz. Dışarıyla veri alışverişi, panelden tanımlanan bir entegrasyon ve ona verilen yetki üzerinden yürür. Ürün, kategori, varyant, stok, fiyat, üye ve sipariş verisi bu yol üzerinden okunur; sipariş oluşturma gibi yazma işlemleri de aynı kanaldan yapılır.
Erişim süreli bir jetonla yetkilendirilir. Bunun iki pratik sonucu var. Birincisi, jetonun süresi dolmadan yenilenmesi gerekir; bu iş tek bir bileşene bağlanmazsa eşzamanlı isteklerde birbirini geçersiz kılan yenilemeler ortaya çıkar. İkincisi, jeton ve erişim bilgisi uygulamanın içinde durmamalıdır. Uygulama paketi çözülebilir bir dosyadır; içine konan her bilgi okunabilir hale gelir. Yetkilendirme kendi sunucunuzdaki servis katmanında kalmalı, uygulama yalnızca kendi kullanıcısının oturum bilgisini taşımalıdır.
Kapsam haritası: projenin ilk gerçek çıktısı
Kapsam haritası, uygulamada planlanan her ekranın hangi veriye ihtiyaç duyduğunu ve o verinin karşılığının bulunup bulunmadığını gösteren bir tablodur. Bunu tasarım başlamadan çıkarmak, projenin en yüksek getirili yarım günüdür.
| Ekran | İhtiyaç duyduğu veri | Karşılığı yoksa seçenek |
|---|---|---|
| Kategori ve liste | Kategori ağacı, ürün özeti, fiyat, stok durumu | Genelde doğrudan karşılığı olur; sıralama kuralları ara katmanda kurulur |
| Ürün detayı | Varyant, görsel, açıklama, özellikler | Özel içerik alanları panelde standart bir alana taşınabilir |
| Arama | Ürün adı, kod, özellik metinleri | Arama ara katmanda kurulur; panel aramasına bağlı kalınmaz |
| Sepet ve tutar | İndirim, kargo, vergi satırları | Hesap panelde kalmalı; uygulamada kopyalanmamalı |
| Üyelik ve adres | Üye kaydı, adres defteri | Panel kaydına bağlanır; uygulamada ayrı tablo açılmaz |
| Sipariş takibi | Sipariş durumu, kargo takip bilgisi | Karşılığı sınırlıysa durum eşlemesi ara katmanda yapılır |
| Kampanya ve kupon | Geçerlilik kuralları | Doğrulama panele bırakılır, uygulama sonucu gösterir |
| Sadakat / puan | Puan bakiyesi ve hareketleri | Karşılığı yoksa kapsam dışı bırakılır ya da ayrı bir sistemle kurulur |
Tablodaki üçüncü sütun asıl değerli kısım. Karşılığı olmayan bir veri için üç makul yol var: veriyi panelde mevcut bir alana taşıyıp oradan okumak, ara katmanda başka verilerden türetmek, ya da açıkça kapsam dışı bırakmak. Yanlış olan dördüncü yol, veriyi uygulama tarafında elle yönetmeye başlamaktır; o noktadan sonra iki ayrı doğru ortaya çıkar ve hangisinin geçerli olduğunu kimse bilemez.
İstek limitleri ve önbellek: uygulamanın hızı buradan gelir
Panel arayüzleri, mobil kullanımın ürettiği trafik düşünülerek tasarlanmaz. Kullanıcı bir kategoriye girer, iki ürüne bakar, geri döner, arama yapar; bu birkaç saniyede onlarca istek demektir. Uygulama bu isteklerin hepsini doğrudan panele yönlendirirse hem limitlere yaklaşırsınız hem de ekranlar bekleyerek açılır.
Kurulması gereken yapı şu: katalog, kategori ağacı ve arama dizini kendi sunucunuzdaki servis katmanında tutulur. Uygulama listeleri buradan alır, dolayısıyla ekran geçişleri anlık olur. Tam katalog taraması gecelik yapılır, gün içinde yalnızca değişen kayıtlar tazelenir. Stok ve fiyat gibi yanlış olması pahalıya patlayan alanlar ise sepete ekleme ve sipariş anında kaynaktan doğrulanır.
Bu ayrım, kullanıcı deneyimiyle doğruluk arasındaki dengeyi kuran şeydir: listelerde birkaç dakikalık gecikme kimseyi rahatsız etmez, ama tükenmiş bir ürünün satılması iptal ve iade maliyeti üretir.
Üyelik: panelde tek kayıt, uygulamada tek oturum
IdeaSoft'ta üye kaydı panelin kendi kaydıdır. Uygulama bu kaydın üzerine oturum açar; kendi kullanıcı listesini kurmaz. Sonuçları saymak gerekirse: sitede üye olan müşteri uygulamaya aynı bilgiyle girer, kayıtlı adresleri karşısına gelir, sipariş geçmişi tek listedir, müşteri temsilcisi tek ekrandan bakar.
Bu maddenin bir de uzun vadeli tarafı var. Müşteri kaydı panelde tekil kaldığında, ileride uygulama sağlayıcınızı değiştirmeye karar verseniz bile veri sizde kalır; taşınacak bir müşteri veritabanı, birleştirilecek iki liste olmaz. Uygulamanın kendi tarafında kullanıcı tutan çözümlerde bu, sözleşme sonunda konuşulması gereken ayrı bir başlık haline gelir ve genelde kimse baştan sormaz.
Hesap silme akışını da baştan planlayın. Uygulama içinden hesap açılabiliyorsa silinebilmesi de bekleniyor ve silme işleminin panel tarafındaki kayda işlemesi gerekiyor.
Ödeme ve sipariş: kurallar panelde kalır
Taksit tablosu, kapıda ödeme koşulları, havale indirimi, kargo ücret eşiği ve kupon kuralları IdeaSoft panelinde tanımlıdır. Bu kuralları uygulama içinde yeniden hesaplamak, her panel değişikliğinde uygulamanın da elden geçirilmesi anlamına gelir; ayrıca iki hesabın birbirinden ayrılması an meselesidir.
Bu yüzden sepet uygulama içinde native ekranlarla yönetilse bile siparişin oluşturulması ve ödeme adımı panel tarafında tamamlanır. Fiziksel ürün satan e-ticaret uygulamalarında mağazaların uygulama içi satın alma zorunluluğu geçerli olmadığı için tahsilat mevcut sanal POS altyapınızdan geçmeye devam eder ve komisyon yapınız değişmez.
Sipariş tarafında ikinci bir kuyruk oluşmaz. Uygulamadan gelen sipariş panelin sipariş listesine, kendi numarasıyla ve web siparişleriyle aynı durum akışına girer; hazırlama, kargolama ve faturalama adımları değişmez. Kanalı raporda ayırt etmek isterseniz siparişe bir etiket eklemek yeterlidir.
IdeaSoft mağaza uygulaması: yeniden kurgulanacak ekranlar
Bir IdeaSoft mağaza uygulaması, panelin ekran düzenini taşımaz. Uygulamada ayrıca düşünülmesi gereken başlıklar:
- Kategori derinliği. Panelde yönetim kolaylığı için derinleşen ağaç, mobilde her seviyede bir dokunuş maliyeti üretir. Uygulamada gezinmeyi sığ tutup gerisini aramaya ve filtreye bırakmak gerekir.
- Varyant seçimi. Renk görsel olarak, beden büyük dokunma hedefleriyle sunulur; tükenmiş kombinasyonlar seçilemez şekilde işaretlenir.
- Arama. Mobilde arama, gezinmenin kendisidir. Ara katmanda çalışan, yazım hatasını tolere eden ve öneri veren bir arama gerekir; katalog genişse anlam tabanlı arama uygulamada sitedekinden daha görünür bir fark yaratır.
- Sipariş ve kargo takibi. Uygulamanın en sık açılan ekranıdır, alt sekmelerden birinde durmalıdır. Kargo bilgisini uygulamayla sınırlamak istemiyorsanız kargo bildirimi gibi kanallar uygulaması olmayan müşteriyi de kapsar.
- Boş ve hatalı durumlar. Sonuçsuz arama, boş sepet, bağlantı koptuğunda gösterilecek ekran. Bu ekranlar tasarlanmadığında kullanıcı ilk sorunda uygulamayı siliyor.
IdeaSoft mobil uygulama yaptırmak: görüşmeye ne getirmeli?
IdeaSoft mobil uygulama yaptırmak isteyen mağazalarda ilk görüşmeyi verimli kılan bilgiler:
- Uygulamada olmasını istediğiniz ekranların listesi. Kapsam haritası bu listeden çıkar; ne kadar netse harita o kadar hızlı çıkar.
- Panelde kullandığınız özel alanlar. Ürün kartlarına eklenmiş özel bilgiler varsa bunların uygulamada nasıl gösterileceği ayrıca planlanır.
- Müşteri grubu ve özel fiyat yapısı. Bayi satışı yapıyorsanız fiyat gösterim mantığı buna göre kurgulanır.
- Kargo ve ödeme seçenekleri. Uygulamada hangi seçeneklerin görüneceği kapsamda yazılır.
- Katalog büyüklüğü. Ürün ve varyant sayısı senkron süresini ve önbellek stratejisini belirler.
Henüz altyapı kararını verirken uygulamayı da düşünüyorsanız, paket ve altyapı seçiminin uzun vadeli etkilerini e-ticaret paketi seçimi yazısında ele aldık; uygulama, altyapının dışarıya ne kadar açıldığına bağlı bir yatırım.
IdeaSoft mobil uygulama fiyatları hangi kalemlerden oluşur?
| Kalem | Bütçeye etkisi | Açıklama |
|---|---|---|
| Kapsam haritasında doğrudan karşılığı olan ekranlar | Öngörülebilir | Veri hazır; iş arayüz ve uygulama geliştirmede |
| Karşılığı olmayan ve türetilmesi gereken veriler | Yüksek | Ara katmanda ek mantık, ek test ve ek bakım demek |
| Servis katmanı ve önbellek | Taban | Hız ve istek limiti sorununu birlikte çözen yapı |
| Bayi / müşteri grubu fiyatlandırma | Orta | Oturuma göre fiyat gösterimi ve toplu sipariş ekranları |
| Çoklu dil ve para birimi | Orta | İçerik yönetimi ve biçimlendirme kuralları eklenir |
| Tasarım derinliği | Değişken | Şablon uyarlamak ile markaya özel kurgu arasında ciddi fark var |
| Bakım | Süreklilik | İşletim sistemi sürümleri ve mağaza politikaları düzenli iş üretir |
Teklifleri karşılaştırırken en ayırt edici soru şu: uygulama sipariş ve üye verisini nerede tutuyor? Kendi tarafında kopya tutan çözümlerin ileride çıkardığı maliyeti e-ticaret mobil uygulaması yazısında kalem kalem yazdık.
IdeaSoft'a bağlı uygulama mı, sıfırdan isteğe özel uygulama mı?
Bu yazının konusu birinci iş kolumuz: mevcut IdeaSoft mağazanızın üzerine kurulan, panelle ortak çalışan uygulama. Burada panel iş kurallarının sahibidir ve uygulama bir sunum kanalıdır; kapsamın sınırını da panelin dışarıya açtığı veri belirler.
İkinci iş kolumuz, panelin veri modeline hiç girmeyen işler: depo ve sayım araçları, bayi sipariş uygulamaları, servis ve bakım takibi, randevu ve üyelik sistemleri, cihazla konuşan uygulamalar. Burada uygulamanın kendi sunucu tarafı ve veri modeli sıfırdan yazılır; IdeaSoft varsa yalnızca bir veri kaynağı olur. Kapsam haritasında karşılığı olmayan başlıklar çok fazlaysa, konuşulması gereken şey aslında bu ikinci koldur. İki kolun nasıl planlandığı mobil uygulama hizmet sayfamızda anlatılıyor.
Sık karşılaşılan sorunlar
| Belirti | Gerçek sebep | Ne yapmalı |
|---|---|---|
| Proje ortasında kapsam daralıyor | Kapsam haritası çıkarılmamış | Tasarımdan önce ekran-veri eşleşmesini doğrulayın |
| Uygulama belirli saatlerde yavaşlıyor | Her ekran doğrudan panele gidiyor, limitlere yaklaşılıyor | Katalog verisini servis katmanında önbellekleyin |
| İstekler rastgele yetkisiz dönüyor | Jeton yenileme birden fazla yerden tetikleniyor | Yenilemeyi tek bileşene bağlayın, süresi dolmadan tazeleyin |
| Uygulamada fiyat panelden farklı | Sepet tutarı uygulamada hesaplanıyor | Tutarı panelde ürettirip satırları okuyun |
| Sipariş durumları uygulamada anlamsız görünüyor | Panel durum kodları doğrudan basılıyor | Durum eşlemesini ara katmanda yapın, kullanıcıya sade metin gösterin |
| Renk seçilince görsel değişmiyor | Görseller varyanta bağlanmamış | Ürün kartındaki varyant-görsel eşleşmesini düzeltin |
| Yeni özellik her seferinde uygulama güncellemesi gerektiriyor | İçerik uygulamanın içine gömülmüş | Ana sayfa ve kampanya içeriğini uzaktan yönetilebilir yapın |
Özet
IdeaSoft tarafında mobil uygulama projesinin kaderini kod değil kapsam belirliyor. Önce her ekranın hangi veriden besleneceğini doğrulayan bir harita çıkarılır; karşılığı olmayan başlıklar için panelde modelleme, ara katmanda türetme veya kapsam dışı bırakma kararı yazılı hale getirilir. Ardından erişim ve jeton yönetimi kendi sunucunuzda toplanır, katalog önbelleklenir, stok ve fiyat sipariş anında doğrulanır. Üye kaydı panelde tekil kalır, sipariş tek akışta ilerler, taksit ve kargo kuralları tek yerde tanımlanır. Bu sıra korunduğunda uygulama mağazanızın ikinci vitrini olur; korunmadığında yan yana duran ve birbirinden habersiz iki sistem ortaya çıkar. Bildirim tarafını kurgularken push bildirim yazısındaki izin zamanlaması ve frekans dengesine bakın. Kapsam haritası çalışması için destek@stools.digital adresinden ya da 0547 007 54 24 numarasından ulaşabilirsiniz.