İkas kullanan mağazalarda uygulama konuşması genelde şu cümleyle başlıyor: "Panelde her şeyi kurdum, uygulamada aynısını baştan mı tanımlayacağım?" Bu soru yerinde bir soru, çünkü ikas'ta işin büyük kısmı panelde birikmiş oluyor: kampanya kuralları, kargo eşikleri, taksit tabloları, kapıda ödeme koşulları, fatura akışı ve müşteri grupları. Uygulamanın değeri de tam burada belirleniyor; bu birikimi kullanabilen bir uygulama ile bunu kendi tarafında yeniden kuran bir uygulama, aynı ekranları gösterse bile aynı şey değil.

Bu yazıda ikas'a özgü tarafı ele alıyoruz: uygulama veriyi hangi katmandan okur, ödeme adımı neden panelde bırakılır, yerli bir altyapıyla çalışmanın entegrasyonda somut karşılığı nedir, hangi hazırlıklar projeyi kısaltır ve fiyatı hangi kalemler belirler. Teknoloji seçimi ve mağaza yayın süreci gibi altyapıdan bağımsız başlıklar mobil uygulama yaptırma rehberinde duruyor.

İkas mobil uygulama nedir ve veriyi nereden alır?

İkas mobil uygulama, panelinizdeki ürün, kategori, stok, fiyat, müşteri ve sipariş verisini ikas'ın dışarıya açtığı arayüzler üzerinden okuyan, iOS ve Android'de cihaza kurulu çalışan bir uygulamadır. İki ayrı erişim katmanı vardır ve hangi işin hangisine düştüğünü ayırmak, projenin mimarisini belirler.

  • Vitrin tarafı: Müşterinin göreceği veri. Katalog listeleme, ürün detayı, arama, sepet işlemleri ve müşteri oturumu bu katmandan yürür. Bu katman müşteri adına, dar yetkiyle çalışır.
  • Yönetim tarafı: Mağaza sahibinin verisi. Sipariş listesi, müşteri kayıtları, stok yönetimi ve raporlama gibi işler buradan görülür. Uygulamanın kendisi değil, uygulamanın arkasındaki servis kullanır; bir kullanıcının telefonundaki uygulamaya yönetim yetkisi verilmez.

Bu ayrımın atlandığı kurgularda ciddi bir güvenlik hatası ortaya çıkar: uygulamanın içine yönetim yetkisi taşıyan bir anahtar gömülür. Uygulama paketi çözülebilir bir dosyadır; içine gömülen her anahtar er ya da geç okunabilir. Doğru kurulumda yönetim yetkisi gerektiren her iş sunucu tarafında kalır, uygulama yalnızca kendi kullanıcısının verisine erişir.

İkas storefront'u tek sayfa uygulama mantığıyla çalıştığı için web tarafında alışkın olduğunuz bazı davranışlar uygulamada yoktur; sayfa yenilenmesi, tarayıcı geri tuşu ve tema betikleri gibi konular ortadan kalkar. Uygulama tarafında ekran geçişleri cihazda yönetilir, ağdan yalnızca veri iner.

Yerli altyapı olmanın entegrasyonda pratik karşılığı

"Yerli altyapı" ifadesi pazarlama cümlesi gibi duruyor ama uygulama projesinde karşılığı somut. Türkiye'de satış yapan bir mağazanın uygulamasında şu başlıkların hepsi çıkar ve hepsinin ikas tarafında hazır bir karşılığı vardır:

BaşlıkUygulama tarafındaki karşılığı
Taksitli ödeme ve banka kampanyalarıÖdeme adımı panelde kaldığı için taksit tablosu uygulamada ayrıca kurulmaz
Kapıda ödemeKoşulları ve ek ücreti panelde tanımlıdır; uygulama seçeneği listeler, kuralı hesaplamaz
Yerli kargo firmaları ve gönderi takibiSipariş ekranındaki takip numarası ve durum bilgisi panelden gelir
Fatura süreçleriSipariş tek akışta ilerlediği için fatura tarafında ikinci bir kuyruk oluşmaz
İade ve cayma talebiUygulamadan açılan talep, web siparişleriyle aynı süreçten geçer
Destek ve dokümantasyonSorun çıktığında altyapı tarafıyla Türkçe ve aynı saat diliminde iletişim kurulur

Son satır teknik görünmüyor ama proje süresine en çok etki eden maddelerden biri. Entegrasyon projelerinde zamanın önemli bir kısmı, beklenmedik bir davranışın altyapı kaynaklı mı yoksa kendi kodunuzdan mı geldiğini anlamaya gider. Bu döngünün kısa olması, takvimde doğrudan görünür.

İkas uygulama entegrasyonu: hangi iş nerede kalır?

Bir ikas uygulama entegrasyonunda sınır şudur: iş kurallarının sahibi paneldir, uygulama sunum katmanıdır. Bu cümlenin kalem kalem karşılığı:

  • Fiyat ve indirim hesabı panelde. Uygulama sepete ürün eklediğinde tutarı kendisi hesaplamaz, sepetin güncel hâlini panelden okur. Böylece bir kampanyayı değiştirdiğinizde uygulama sürümü yayınlamanız gerekmez.
  • Stok kontrolü panelde. Uygulama listede gördüğü stok bilgisini gösterir, ama satın alma anında kaynaktan doğrular. Kampanya günlerinde tükenen ürünün satılmasını engelleyen şey budur.
  • Müşteri grupları ve özel fiyat panelde. Bayi fiyatı veya müşteri grubuna özel indirim kullanıyorsanız, uygulama oturum açan kullanıcının grubunu panelden alır; uygulamada ayrı bir fiyat listesi tutulmaz.
  • Arayüz ve gezinme uygulamada. Ana sayfa kurgusu, kategori giriş yolları, arama davranışı, boş durum ekranları ve bildirim kurgusu uygulamanın kendi işidir; bunlar panelin sorumluluğunda değildir.

Bu sınırı korumanın bir bedeli var: uygulama, panelde olmayan bir davranışı tek başına üretemez. Örneğin panelde tanımlanamayan "yalnızca uygulamada geçerli" bir indirim istiyorsanız, bunu uygulamanın içine gömülü bir hesap olarak yazmak yerine kampanya yapınızda kanal ayrımı kurarak çözmek gerekir. Aksi hâlde iki ayrı kural setini elle senkron tutmaya başlarsınız ve bu, uygulamanın ilk yılında en çok hataya sebep olan şeydir.

Üyelik: müşteri uygulamada yeniden kayıt olmaz

İkas'ta müşteri kaydı panelin kendi kaydıdır; uygulama bu kaydın üzerine oturum açar. Görünen sonuçları sayalım: sitede üye olan müşteri uygulamaya aynı bilgiyle girer, adres defteri iki kanalda aynıdır, sipariş geçmişi tek listedir, pazarlama izinleri tek yerden yönetilir ve müşteri hizmetleri ekibi tek ekrana bakar.

Bir de görünmeyen tarafı var. Müşteri kaydı ortak olduğunda, uygulamayı bırakmaya karar verdiğinizde kaybettiğiniz şey yalnızca uygulamadır. Kendi tarafında müşteri tablosu tutan çözümlerde ise uygulamayı kapatmak, orada birikmiş adres, tercih ve sipariş verisinin ne olacağı sorusunu açar. Bu soruyu sözleşme aşamasında sormak, iki yıl sonra sormaktan çok daha ucuzdur.

Hesap silme akışına ayrıca dikkat edin. Uygulama içinden hesap oluşturulabiliyorsa, uygulama içinden silinebilmesi de bekleniyor ve bu silme işleminin panel tarafındaki kayda da işlemesi gerekiyor. Yalnızca oturumu kapatan bir "hesabımı sil" düğmesi, mağaza incelemesinde geri dönebilecek bir eksiktir.

İkas mağaza uygulaması: hangi ekranlar siteden ayrışır?

Veri ortak kalır, arayüz ayrışır. İkas mağaza uygulaması kurgularken siteden farklılaşması gereken başlıklar:

  1. Ana sayfa kısalır. Sitede ana sayfa vitrindir; uygulamada kullanıcı çoğu zaman ne aradığını bilerek girer. Uzun kampanya şeritleri yerine arama, son bakılanlar ve devam eden sipariş üste alınır.
  2. Kategori derinliği azalır. Panelde altı kırılımlı bir kategori ağacı web'de sorun çıkarmayabilir; mobilde her kırılım bir dokunuş demektir. Uygulamada genelde iki seviyeyle sınırlı bir gezinme kurup gerisini filtre ve aramaya bırakmak gerekir.
  3. Varyant seçimi alt panele taşınır. Renk görsel, beden dokunmatik hedefi büyük düğmeler olarak sunulur; tükenmiş kombinasyonlar seçilemez şekilde işaretlenir.
  4. Sipariş takibi alt sekmede durur. Uygulamanın açılma sebeplerinin başında sipariş durumu gelir; bunu menü içine gömmek uygulamanın açılma sıklığını doğrudan düşürür.
  5. Boş durumlar tasarlanır. Boş sepet, sonuçsuz arama, hiç siparişi olmayan yeni kullanıcı. Bu ekranlar sitede ihmal edilebilir, uygulamada ilk deneyimin büyük kısmıdır.

Arama konusunda ek bir not: mobilde kullanıcı filtre panelleriyle uğraşmak yerine yazmayı tercih ediyor. Katalog büyükse aramanın yazım hatasını tolere etmesi ve eş anlamlıları bilmesi gerekiyor. Anlam tabanlı site içi arama tarafındaki iyileştirmeler, uygulamada sitedekinden daha fazla iş görür çünkü mobilde arama kutusu ana gezinme aracıdır.

İkas mobil uygulama yaptırmak: projeyi kısaltan hazırlıklar

İkas mobil uygulama yaptırmak isteyen mağazalarda takvimi uzatan şey genelde geliştirme değil, veri tarafındaki eksikler oluyor. Görüşme öncesi şu dört başlığı kontrol etmek projenin ilk iki haftasını kazandırır:

KontrolEksikse ne olur
Varyant barkod ve stok kodları dolu muSipariş, iade ve stok eşleşmelerinde tekil kimlik kalmaz; hata ayıklama zorlaşır
Varyant görselleri doğru varyanta bağlı mıRenk seçiminde görsel değişmez, uygulama hatalı görünür
Ürün özellik adları tutarlı mıFiltreler bölünür; aynı özellik iki farklı isimle listelenir
Kategori ağacı ne kadar derinMobil gezinme yorucu olur, uygulama içi arama zorunlu hale gelir

Mağazanız yeni kuruluyorsa bu kontrolleri kurulum sırasında yapmak en ucuz yoldur; ikas mağaza kurulumu yazısındaki katalog düzeni maddeleri doğrudan uygulama tarafına da hizmet eder.

İkas mobil uygulama fiyatları neye bağlı?

Uygulama fiyatını tek bir rakamla vermek doğru olmaz; belirleyici olan mağazanın çalışma şeklidir. Bütçeyi hareket ettiren kalemler:

  • Kapsam genişliği. Katalog, sepet, ödeme, sipariş takibi ve bildirim standart tabanı oluşturur. Sadakat programı, hediye çeki, bayi fiyatlandırması ve kupon havuzu gibi başlıklar bunun üzerine eklenir.
  • Tasarım derinliği. Hazır bir şablona logo yerleştirmek ile ana sayfa kurgusundan boş sepet ekranına kadar markaya göre çizmek arasında ciddi bir emek farkı var.
  • Dil sayısı. İkinci dil yalnızca metin çevirisi değil; biçimlendirme, ürün içeriğinin çift dilli yönetimi ve mağaza sayfalarının ayrı hazırlanması demek.
  • Bildirim kurgusunun derinliği. Toplu duyuru göndermek kolaydır; sepette ürün bırakana, siparişi kargoya verilene ya da otuz gündür girmeyene ayrı mesaj göndermek ayrı bir kurgudur.
  • Üçüncü taraf sistemler. Ayrı bir sadakat, canlı destek veya analitik aracı kullanıyorsanız her biri ek entegrasyon kalemidir.
  • Bakım. Yeni işletim sistemi sürümleri, mağaza politikası değişiklikleri ve sertifika yenilemeleri hiç yeni özellik istemeseniz bile düzenli iş üretir.

Teklifleri kıyaslarken tek bir teknik soru çoğu farkı ortaya çıkarır: sepet tutarını kim hesaplıyor? Cevap "uygulama kendi hesaplıyor" ise ucuz görünen teklif, ilk kampanya gününde fiyat tutarsızlığı olarak geri döner. İki modelin operasyonel karşılaştırmasını e-ticaret mobil uygulaması yazısında yaptık.

İkas'a bağlı uygulama mı, sıfırdan isteğe özel uygulama mı?

Mobil tarafta iki ayrı iş yapıyoruz. Birincisi bu yazının konusu: mevcut ikas mağazanızın üzerine kurulan, panelle ortak çalışan uygulama. Burada ikas iş kurallarının sahibidir ve uygulama o kuralları gösterir.

İkincisi, ikas'ın veri modeliyle ilgisi olmayan işler: saha ekibi uygulamaları, bayi sipariş sistemleri, randevu ve üyelik yönetimi, cihaz veya sensörle konuşan uygulamalar. Burada uygulamanın kendi sunucu tarafı ve kendi veri modeli sıfırdan yazılır. Bu iki işin planlaması, süresi ve bakım şekli farklıdır. Bazı mağazalarda ikisi birden gerekir: müşteriye dönük ikas'a bağlı bir uygulama, depo veya bayi tarafına ise ayrı bir uygulama. Hangi kolun size uyduğunu mobil uygulama hizmet sayfamızdaki kapsam başlıklarına bakarak ayırt edebilirsiniz.

Kurulumda karşımıza çıkan tipik sorunlar

BelirtiSebepÇözüm
Uygulamada fiyat panelden farklıSepet tutarı uygulama içinde hesaplanıyorSepeti panelde oluşturup güncel tutarı okuyun
Renk seçilince görsel değişmiyorGörseller varyanta değil ürüne bağlanmışVaryant-görsel eşleşmesini panelde düzeltin
Filtrelerde aynı özellik iki kez çıkıyorÖzellik adları ürünler arasında tutarsızÖzellik sözlüğünü tekilleştirin
Bildirim izni oranı çok düşükİzin ilk açılışta, kullanıcı hiçbir şey görmeden isteniyorİzni bağlama oturan bir anda isteyin
Uygulama listesi yavaş açılıyorListe sorgusunda gereksiz alanlar ve tam boyutlu görsellerSorguyu ekranın ihtiyacına indirin, görselleri boyutlandırılmış çekin
Kapıda ödeme uygulamada görünmüyorÖdeme adımı uygulama içinde yeniden kurulmuşÖdemeyi panelin ödeme akışına devredin

Özet

İkas tarafında iyi bir mobil uygulamanın ölçütü tek cümleyle şudur: panelde tanımlı olan hiçbir kural uygulamada ikinci kez tanımlanmaz. Katalog panelden okunur, sepet tutarı panelde hesaplanır, ödeme panelin ödeme akışında tamamlanır, oturum panelin müşteri kaydına bağlanır. Bu tuttuğunda uygulama mağazanızın yeni bir vitrini olur; tutmadığında yan yana duran ve zamanla birbirinden uzaklaşan iki sistem elinizde kalır. Uygulamanın en değerli kanalı olan bildirimi kurgularken push bildirim yazısındaki izin ve frekans dengesine bakmakta fayda var. Mağazanızın hangi kapsamla uygulamaya geçebileceğini konuşmak isterseniz destek@stools.digital adresinden ya da 0547 007 54 24 numarasından ulaşabilirsiniz.