E-ticaret mobil uygulaması konuşulan her görüşmede aynı iki soru geliyor: "Müşterilerim uygulamaya yeniden üye olmak zorunda kalacak mı?" ve "Siparişleri iki ayrı yerden mi takip edeceğim?" Bu sorular teknik merak değil; satıcının daha önce duyduğu ya da başına gelmiş bir sorunun izi. İkisi de tek bir başlığa çıkıyor: e-ticaret mobil uygulaması nasıl entegre edilir, yani uygulama mevcut mağazanın hangi parçasına bağlanır.

Cevap uygulamanın nasıl yapıldığına bağlı ve aradaki fark, uygulamanın görünüşünde değil arkasında. Bu yazıda tam entegre uygulama ile ayrı sistem kuran uygulama arasındaki farkı, bunun operasyonda neye mal olduğunu, uygulamanın siteden neden daha hızlı çalıştığını, hangi mağazanın uygulamaya ne zaman hazır olduğunu ve altyapı bazında (Shopify, İkas, Ticimax, T-Soft) tabloyu anlatıyoruz. Mağaza yayın süreci, red sebepleri ve teknoloji seçimi gibi genel mobil başlıkları ise mobil uygulama yaptırma rehberinde ayrıca yazdık.

E-ticaret mobil uygulaması nasıl entegre edilir: asıl mesele nereye bağlandığı

Entegrasyon sorusunun cevabı arayüzde değil, bağlantı katmanında saklı. İki uygulama ekranda birbirinin aynı görünebilir; biri mağazanızın devamıdır, diğeri mağazanızın yanında duran ikinci bir dükkândır. Farkı yaratan şey, uygulamanın veriyi nereden okuduğu ve nereye yazdığı.

Tam entegre uygulama: üyeler, sepet ve siparişler ortak

Tam entegre bir uygulamada uygulama kendi veri tabanını kurmaz; mevcut e-ticaret altyapınızın arayüzleri üzerinden çalışır. Bunun somut karşılığı şudur:

  • Üyelik ortaktır. Sitenizden üye olmuş müşteri, uygulamaya aynı e-posta ve parolayla girer. Yeniden kayıt yoktur, parola sıfırlama akışı ikiye bölünmez.
  • Sepet ortaktır. Telefonda sepete atılan ürün, akşam bilgisayardan girildiğinde sepette durur. Tersi de geçerlidir.
  • Siparişler tek yerdedir. Uygulamadan verilen sipariş, sitenin siparişleriyle aynı listeye düşer; aynı numaralandırma, aynı durum akışı, aynı fatura süreci.
  • Ürün ve stok tek kaynaktan gelir. Panelde fiyat değiştirdiğinizde uygulamada da değişir; ayrıca senkron kurmanız gerekmez.
  • Kampanya ve kupon aynı kurallarla işler. Sitede tanımlı indirim uygulamada da geçerlidir, ikinci bir kampanya tanımı yapılmaz.
  • Tek panel yönetirsiniz. Uygulama için ayrı bir yönetim ekranına girmezsiniz; uygulama sitenin bir görüntüleme kanalıdır.

Ayrı sistem kuran çözümler neden sorun çıkarıyor

Bazı uygulama çözümleri, mağaza verisini periyodik olarak kendi tarafına kopyalayıp uygulamayı kendi veri tabanı üzerinden çalıştırır. İlk bakışta fark edilmez; sorunlar operasyon başlayınca çıkar:

  • İkinci müşteri veritabanı. Aynı müşteri sitede bir, uygulamada başka bir kayıt olur. Sadakat puanı, sipariş geçmişi ve adres defteri bölünür.
  • Stok gecikmesi. Senkron aralığı ne olursa olsun bir gecikme vardır; kampanya günlerinde bu gecikme tükenen ürünün satılmasına ve iptal edilen siparişe dönüşür.
  • Fiyat tutarsızlığı. Sitede güncellenen fiyat uygulamaya geç yansırsa, müşteri iki farklı fiyat görür. Bunun operasyonel maliyeti müşteri hizmetleri tarafında ortaya çıkar.
  • İki ayrı sipariş akışı. Uygulama siparişleri farklı bir kuyruğa düşerse, kargo, fatura ve iade süreçleri ikiye ayrılır.
  • Çıkış maliyeti. Uygulamayı bıraktığınızda, orada birikmiş müşteri ve sipariş verisinin ne olacağı ayrı bir sorundur.

Bu yüzden teklif alırken sorulacak asıl soru "uygulama ne kadar" değil, "uygulama üyelik, sepet ve siparişte hangi veri tabanını kullanıyor" olmalı. Cevap "bizim tarafımızda kopya tutuluyor" ise yukarıdaki maddelerin hepsini kapsam görüşmesinde konuşmanız gerekir.

Uygulama siteden neden daha hızlı açılıyor

Uygulamanın hızlı hissettirmesinin sebebi daha güçlü sunucu değil, işin bölünme şekli. Tarayıcıda bir ürün sayfası açtığınızda sayfanın iskeleti, stil dosyaları, betikler ve içerik büyük ölçüde her seferinde yeniden çekilir. Önbellek bunun bir kısmını azaltır ama kurgunun kendisi değişmez.

Uygulamada ekranların kendisi zaten cihazda kuruludur. Kullanıcı bir kategoriye girdiğinde tasarımın inmesi gerekmez; yalnızca o kategorinin ürün verisi iner. Bunun üç somut sonucu var: aktarılan veri miktarı küçülür, ekran geçişleri beklemesiz olur ve zayıf bağlantıda deneyim daha az bozulur. Ayrıca görseller cihazda saklandığı için ikinci ziyaretlerde tekrar indirilmez.

Bu, sitenizin hızını önemsiz kılmıyor; ziyaretçilerin çoğu hâlâ siteden geliyor ve site hızı doğrudan dönüşüme etki ediyor. Uygulama, site hızının yerine geçen değil, sadık müşteride onun üstüne binen bir kanal.

Mağaza uygulaması ne zaman mantıklı, ne zaman erken

Mağaza uygulaması her mağaza için doğru yatırım değil. Ayrımı belirleyen şey ciro büyüklüğü değil, tekrar satın alma davranışı. Uygulamanın getirisi yeni müşteri kazanmaktan değil, mevcut müşteriyi geri getirmekten geliyor.

DurumUygulama kararıNeden
Müşteri yılda bir kez alıyor (beyaz eşya, mobilya)Genelde erkenUygulama telefonda unutulur; bildirim izni de zamanla kaybedilir.
Tekrar alım yüksek (kozmetik, gıda takviyesi, bakım ürünleri, moda)UygunSadık müşteri kitlesi uygulamada birikir, bildirim gerçekten okunur.
Sadakat programı veya puan sistemi varUygunKart ve puan görüntüleme uygulamanın en çok kullanılan ekranı olur.
Ciro büyük ama tamamı reklamdan gelen ilk alıcıÖnce başka yatırımlarUygulama yeni müşteri getirmez; önce site dönüşümü ve elde tutma çalışılmalı.
Kurumsal/bayi satışı, tekrar eden siparişUygunHızlı yeniden sipariş ekranı gerçek zaman kazandırır.
Ürün sayısı çok az ve katalog nadiren değişiyorGenelde erkenKullanıcının uygulamayı açması için tekrar eden bir sebep oluşmaz.

Kararsız kalanlara önerdiğimiz basit ölçüt şu: son bir yılda ikinci siparişini veren müşteri sayınıza bakın. Bu kitle anlamlı bir büyüklükteyse uygulama o kitleyi elde tutmak için doğru araçtır. Değilse, önce tekrar satın almayı artıran işleri yapmak daha yüksek getirili olur; sepet hatırlatma ve kargo bildirimi gibi otomasyonlar bu tarafta çalışır.

Altyapıya göre durum

Uygulamanın mağazanıza tam entegre olabilmesi, altyapınızın dışarıya sunduğu arayüzlere bağlı. Türkiye'de yaygın dört altyapıda tablo şöyle.

Shopify: entegrasyon hangi verilere dayanır

Shopify tarafında mağaza verisine erişim standarttır: ürün, koleksiyon, müşteri hesabı, sepet ve sipariş akışı uygulama tarafından doğrudan kullanılabilir. Ödeme adımında mağazanın kendi güvenli ödeme akışı kullanılır; böylece taksit, kargo kuralları, kupon ve vergi hesaplaması sitedekiyle birebir aynı işler. Bunun pratik anlamı şudur: uygulama için ayrı bir ödeme kurgusu, ayrı kampanya tanımı ya da ayrı sipariş sayacı gerekmez. Mağazanızın tema tarafındaki düzenlemeleri de uygulamayı etkilemez; uygulama temayı değil veriyi okur. Bu altyapıdaki ekran kurgusunu, tema ile uygulama arasındaki iş bölümünü ve yayın tarafını ayrıca Shopify tarafını anlattığımız yazıda ele aldık.

İkas: panel kuralları uygulamada nasıl korunur

İkas tarafında da mağaza verisine programatik erişim mevcut; ürün, kategori, müşteri ve sipariş akışları uygulamaya taşınabilir. İkas kullanan mağazalarda en sık kurduğumuz yapı, uygulamanın panelde tanımlı kampanya ve kargo kurallarını aynen kullanması. Böylece pazarlama ekibi tek yerden çalışmaya devam ediyor. Bu altyapıdaki ayrıntıları İkas tarafına ayırdığımız yazıda genişlettik. İkas ile Shopify arasında karar aşamasındaysanız, iki altyapının maliyet ve yerel özellik farklarını ikas mı Shopify mı yazısında karşılaştırdık.

Ticimax ve T-Soft: servis tarafında nelere dikkat edilir

Ticimax ve T-Soft tarafında da servisler üzerinden erişim mümkün; bu altyapılarda dikkat edilmesi gereken nokta, servislerin alan ve filtre davranışlarının beklenenden katı olabilmesi. Entegrasyon kurulurken bu ayrıntıların baştan test edilmesi, projenin ortasında sürpriz çıkmasını engelliyor. Her iki altyapıda da uygulamanın siteyle ortak çalışması mümkün; kapsamı belirleyen şey mağazanın hangi özellikleri kullandığı oluyor. Bu iki altyapının kendine özgü başlıklarını Ticimax yazımızda ve T-Soft yazımızda ayrı ayrı topladık.

Kendi altyapımız RapiSoft üzerinde ise uygulama zaten aynı çekirdeğe bağlanıyor; üyelik, sepet, sipariş ve kampanya kuralları tek yerde durduğu için ek entegrasyon katmanı gerekmiyor.

E-ticaret mobil uygulaması nasıl entegre edilir: kapsamda olması gereken başlıklar

Entegrasyonun tamam sayılabilmesi için aşağıdaki başlıkların kapsamda olup olmadığını tek tek sorun. Bunlar "olsa iyi olur" değil, uygulamanın mağazayla gerçekten aynı sistemi paylaştığını gösteren asgari liste.

  • Ortak üyelik ve parola akışı. Site ile aynı hesap; parola sıfırlama, e-posta doğrulama ve hesap silme akışlarının uygulamada da çalışması.
  • Ortak sepet. Cihazlar arasında taşınan, üyeliğe bağlı sepet.
  • Arama ve filtreleme. Mobilde arama, sitedekinden daha yoğun kullanılır; sonuç kalitesi doğrudan satışa etki eder. Yazım hatalarını tolere eden ve eş anlamlıları bilen bir arama, mobilde sitedekinden daha çok fark yaratır.
  • Sipariş takibi ve iade talebi. Müşterinin uygulamayı açmak için en sık kullandığı sebep sipariş durumu bakmaktır.
  • Bildirim altyapısı ve segment yönetimi. Yalnızca toplu duyuru değil, davranışa göre gönderim.
  • Ürün yorumlarının uygulamada da görünmesi. Karar anı mobilde geçiyorsa, sosyal kanıt orada olmalı.
  • Derin bağlantı. Bildirime ya da paylaşılan bağlantıya tıklayan kullanıcının uygulamada doğrudan ilgili ürüne düşmesi.
  • Ölçümleme. Uygulama içi olayların analitiğe akması; aksi hâlde uygulamanın katkısını göremezsiniz.

Uygulamanın tasarımı siteden nerede ayrılmalı

Tam entegre olmak, uygulamanın sitenin birebir kopyası olması demek değil. Veri ortak kalır ama arayüz mobildeki davranışa göre yeniden kurgulanır. Mağaza uygulamalarında siteden ayrışması gereken başlıklar şunlar:

  • Ana sayfa kısa olmalı. Sitede ana sayfa bir vitrindir; uygulamada ise çoğu kullanıcı zaten ne aradığını bilerek girer. Uzun kampanya şeritleri yerine arama, son bakılanlar ve devam eden sipariş öne alınmalı.
  • Arama, filtrenin önüne geçer. Mobilde filtre panelleri zahmetlidir; kullanıcı yazmayı tercih eder. Bu yüzden arama kutusunun her ekrandan erişilebilir olması ve yazarken öneri vermesi gerekir.
  • Ürün sayfası tek elle kullanılabilmeli. Sepete ekle butonu kaydırma ile kaybolmamalı, varyant seçimi alt panelden açılmalı, görseller yatay kaydırmayla gezilebilmeli.
  • Ödeme adımı kısaltılmalı. Kayıtlı adres ve kayıtlı kart varsa akış tek ekrana inebilir; uygulamada bunu yapmak sitedekinden kolaydır çünkü kullanıcı zaten giriş yapmıştır.
  • Sipariş takibi ilk sekmelerden birinde olmalı. Kullanıcının uygulamayı açma sebeplerinin başında sipariş durumu bakmak geliyor; bunu menünün içine gömmek, uygulamanın açılma sıklığını doğrudan düşürür.
  • Boş durumlar tasarlanmalı. Boş sepet, sonuç bulunamayan arama, siparişi olmayan yeni kullanıcı. Bu ekranlar sitede genelde ihmal edilir; uygulamada ilk deneyimin büyük kısmını oluşturur.

Bir de tersten bir kural var: kampanya kurgusu, fiyatlandırma ve kargo kuralları uygulamada değişmemeli. Arayüz farklılaşır, iş kuralları farklılaşmaz. Uygulamaya özel indirim vermek isterseniz bunu ayrı bir kampanya mantığı kurarak değil, mevcut kampanya sisteminizde kanal ayrımı yaparak çözmek gerekir; aksi hâlde iki ayrı kural setini elle senkron tutmaya başlarsınız.

Ödeme ve mağaza komisyonu meselesi

Sık sorulan bir endişe var: "Apple ve Google satışlarımdan komisyon alacak mı?" Fiziksel ürün satan e-ticaret uygulamalarında mağazaların uygulama içi satın alma kuralı uygulanmaz; ödeme kendi sanal POS altyapınızdan geçer ve komisyon yapınız değişmez. Mağaza ödeme sistemi zorunluluğu, uygulama içinde tüketilen dijital içerik ve abonelikler için geçerlidir.

Bunun pratik sonucu şu: taksit seçenekleriniz, kapıda ödeme kurgunuz, kupon ve hediye çeki kurallarınız uygulamada da aynen çalışır. Ancak bir şart var; ödeme akışının mağazanın kendi ödeme altyapısı üzerinden yürümesi gerekir. Ödeme adımını kendi içinde yeniden kuran çözümlerde taksit tablosu, kargo kuralı ve vergi hesabı gibi ayrıntılar siteden ayrışmaya başlar.

Uygulamanın asıl getirisi: doğrudan erişim

Uygulamanın e-ticaret tarafındaki en somut kazancı, müşteriye reklam bütçesi harcamadan ulaşabilmek. Bildirim, ekranın kilit ekranında görünür ve tıklandığında doğrudan ürüne gider. Ancak bu kanalın ömrü kullanım şekline bağlı: gereğinden sık gönderilen bildirimler önce sessize alınır, sonra tamamen kapatılır ve geri kazanılamaz. İzin yönetimi, segmentleme ve frekans dengesini push bildirim yazısında ayrıntılı ele aldık.

Bildirim tek kanal değil. WhatsApp tarafındaki otomasyonlar, uygulaması olmayan müşteriye de ulaşır ve farklı bir kullanım alanına oturur; ikisini birbirinin alternatifi değil, aynı müşteri yolculuğunun farklı noktaları olarak kurgulamak gerekir.

Sık yapılan hatalar

  1. Siteyi olduğu gibi uygulamaya sarmak. Uygulama içinde web sitesini gösteren kurgular, mağaza incelemesinde asgari işlevsellik gerekçesiyle reddedilebilir; geçse bile kullanıcı bunu hisseder.
  2. Uygulamayı sitenin birebir kopyası olarak tasarlamak. Mobilde kullanıcı listeleri kaydırarak gezer, filtreleri az kullanır, aramaya daha çok başvurur. Aynı düzen mobilde iyi çalışmaz.
  3. Bildirim iznini ilk açılışta istemek. Uygulamayı yeni açan kullanıcı neye izin verdiğini bilmez ve reddeder; reddedilen izni geri almak sistem ayarlarından geçtiği için çok zordur.
  4. Uygulamayı sadece indirilme sayısıyla ölçmek. Bakılması gereken şey ilk açılıştan sonra geri dönen kullanıcı ve uygulama üzerinden gelen tekrar sipariş oranıdır.
  5. Lansmanı duyurmamak. Uygulamanın mağazada olması indirileceği anlamına gelmez; sitede, e-postada ve sipariş sonrası akışta duyurulması gerekir.

Biz nasıl yapıyoruz

Mağazanız Shopify, İkas, Ticimax ya da T-Soft üzerinde olsun, uygulamayı mevcut altyapınızın üzerine kuruyoruz: üyeler, sepet ve siparişler siteyle ortak kalıyor, ikinci bir panel yönetmiyorsunuz. Arayüzü hazır şablona logo koyarak değil, ana sayfa kurgusundan ödeme akışına kadar markanıza göre çizerek yapıyoruz; uygulama sitenizin devamı gibi durmalı, ayrı bir ürün gibi değil.

Geliştirici hesapları sizin adınıza açılıyor, mağaza gönderimlerini biz yürütüyoruz. Kapsam ve süreç için mobil uygulama hizmet sayfamıza bakabilir, mağazanızın uygulamaya hazır olup olmadığını konuşmak için bize yazabilirsiniz.