Bu sayfada
Headless veya composable bir yapıya geçen mağaza sahipleri, dönüşümü artıran beden önerisi gibi özellikler için güvendikleri hazır kur-çalıştır uygulamaları çoğu zaman kaybediyor. Yerleşik bir uygulama mağazası olmadığında "bir widget ekle" seçenek olmaktan çıkıyor ve mühendislik ekipleri hep aynı soruyla karşılaşıyor: ödeme akışını baştan yazmadan, özel geliştirilmiş bir React, Vue veya MACH mağazasına doğru beden rehberliğini nasıl entegre ederiz?
İyi haber şu ki beden önerisi, platform bağımlılığından ayrıştırılması en kolay özelliklerden biri, çünkü mantık yalnızca üç girdiye ihtiyaç duyuyor: alışverişçinin ölçüleri, ürünün beden tablosu ve durum bilgisi taşımayan bir API'nin arkasında duran öneri motoru. Bu yazı, bunu kurmak için platform bağımsız bir kalıp sunuyor.
Headless mağazalar neden farklı bir beden yaklaşımına ihtiyaç duyar
Shopify veya Ticimax gibi monolitik platformlarda, beden uygulamaları genellikle tema enjeksiyon noktalarına ve uygulama bloklarına bağlanır. Headless bir mağazada tema olmadığı için bağlanacak bir enjeksiyon noktası da yoktur. Beden widget'ı dahil her arayüz öğesi, kendi frontend ekibiniz tarafından oluşturulup yerleştirilmelidir.
Bu yalnızca teknik bir zorluk değil — entegrasyon sözleşmesini de değiştiriyor. Bir uygulama kurmak yerine bir API'yi tüketip yanıtı kendiniz render ediyorsunuz. Bu size UX üzerinde daha fazla kontrol verir (önerinin tam olarak nerede ve nasıl görüneceğine siz karar verirsiniz) ama aynı zamanda beden sağlayıcısının bir tema parçacığı yerine temiz, iyi belgelenmiş bir REST veya GraphQL katmanı sunması gerektiği anlamına gelir.
Headless beden yığınının üç bileşeni
- Ürün beden verisi — PIM veya ticaret platformunuzdan beden sağlayıcısına senkronize edilen tablo değerleri (göğüs, bel, kalça, paça vb.).
- Bir öneri uç noktası (endpoint) — alışverişçinin ölçülerini veya profil verisini ve bir ürün/beden-tablosu kimliğini alır, önerilen bedeni ve güven skorunu döndürür.
- Bir frontend bileşeni — uç noktayı çağıran ve sonucu PDP'de satır içi gösteren bir React, Vue veya vanilla JS widget'ı.
API sözleşmesini tasarlamak
En temiz entegrasyon kalıbı, beden motorunu mağazanızın render sırasında veya alışverişçi widget'ı açtığında çağırdığı bir mikroservis olarak ele alır. Tipik bir istek/yanıt sözleşmesi şöyle görünür:
| Alan | Yön | Açıklama |
|---|---|---|
productId / sizeChartId | İstek | Hangi beden tablosuna göre değerlendirileceğini belirtir |
shopperProfile | İstek | Boy, kilo, kesim tercihi veya kayıtlı ölçü profili |
locale / region | İstek | Bedenlerin US, EU, UK veya yerel standarda göre gösterilip gösterilmeyeceğini belirler |
recommendedSize | Yanıt | En uygun beden etiketi |
confidenceScore | Yanıt | Eşleşmeye dair sayısal veya kategorik güven skoru |
alternateSizes | Yanıt | Alışverişçi daha bol veya daha dar bir kesim tercih ederse değerlendirilecek bedenler |
Bu durumsuz bir REST çağrısı olduğu için, frontend'iniz ister Next.js, ister Nuxt, ister SvelteKit, ister MACH sertifikalı bir yığın üzerindeki özel bir React uygulaması olsun aynı şekilde çalışır. Buradaki asıl mimari karar önbellekleme ile ilgili: öneri çağrıları PDP yüklenirken anlamlı bir gecikme eklemeden tetiklenecek kadar ucuz olmalı, bu yüzden çoğu uygulama beden-tablosu verisini uç (edge) noktada önbelleğe alır ve yalnızca alışverişçiye özel eşleşmeyi talep üzerine hesaplar.
Kimlik doğrulama ve hız limitleri
Beden API'sini composable yığınınızdaki diğer üçüncü taraf servisler gibi ele alın: her mağaza/kanal için kapsamlı bir API anahtarı kullanın, mümkün olduğunda anahtarı doğrudan tarayıcıya açmak yerine BFF (backend-for-frontend) katmanınızın arkasına koyun ve sağlayıcının hız limitlerinin ortalama trafiğinizi değil zirve PDP trafiğinizi kaldırabildiğinden emin olun. Flaş indirimler ve ücretli trafik artışları, saf istemci taraflı entegrasyonların ilk çöktüğü noktalardır.
Frontend uygulama kalıpları
API sözleşmesi belirlendikten sonra frontend işi büyük ölçüde standart bileşen mühendisliğidir:
- Widget'ı tembel yükleyin (lazy-load) ki PDP hidrasyonunu engellemesin — beden araçları sepete ekle'ye göre ikincil önceliktedir.
- Alışverişçi profil verisini kalıcı hale getirin (çerez, yerel depolama veya oturum açmış profil aracılığıyla) ki tekrar gelen ziyaretçiler ölçülerini yeniden girmesin.
- Durumlar için tasarlayın: yükleniyor, veri yok (tablo eksik), öneri ve hata durumlarının hepsi açık bir arayüze ihtiyaç duyar, çünkü headless bir yapı bir platformun varsayılan stillerinin hiçbirini devralmaz.
- Bileşen çerçevesini API katmanında platform bağımsız tutun — ilk mağazanız React olsa bile, gelecekteki bir marka yenilemesi veya Vue tabanlı bir mağaza aynı uç noktayı yeni bir backend işi olmadan çağırabilmeli.
Bu, Shopify Hydrogen'e beden önerici eklerken geçerli olan ilkenin aynısıdır: alttaki API değişmez, yalnızca bileşen sarmalayıcısı değişir. Farklı çerçevelerde birden fazla mağaza işleten ekipler — composable ticarette yaygın bir kalıp — tüm backend sözleşmesini yeniden kullanabilir ve yalnızca her yığın için ince arayüz katmanını yeniden inşa eder.
Çok kanallı ve çok mağazalı senaryolar
Composable ticaret kurulumları genellikle birden fazla mağaza demektir: bir web uygulaması, bir mobil uygulama ve bazen aynı ürün kataloğundan okuyan bir pazaryeri veya POS entegrasyonu. Beden mantığınız tek bir API'nin arkasındaysa, her kanal alttaki uyum modelini tekrar etmeden tutarlı öneriler alır. Bu göründüğünden daha önemli — beden önerilerini kanallar arasında senkronize etmek, monolitik bir platformdan geçiş yapan mağazaların en sık karşılaştığı boşluklardan biri, çünkü eski beden uygulamaları genellikle tek bir temaya bağlıydı ve ikinci bir kanala hizmet etmek için hiç tasarlanmamıştı.
Şunu da belirtmek gerekir: headless yalnızca modern JS çerçeveleriyle sınırlı değil — daha eski veya bölgesel platformlar işleten mağazalar da özel frontend'ler inşa ederken aynı entegrasyon sorularıyla karşılaşıyor. Burada anlatılan kalıp (durumsuz API, önbelleklenebilir beden-tablosu verisi, çerçeve bağımsız sözleşme) ister React'te çalışın ister T-Soft gibi bir platforma özel bir frontend katmanı üzerinden beden mantığı bağlarken geçerlidir.
Bunun dönüşüm açısından neden önemli olduğu, sadece mimari değil
Tüm bu API altyapısı, iade oranlarını ve dönüşümü etkilemiyorsa hiçbir şey ifade etmez. Kötü beden uyumu, hazır giyim iadelerinin en büyük sürücülerinden biri olmaya devam ediyor ve orta segment perakendede composable ticaret benimsenmesi hızlanıyor çünkü mağazalar, hepsi-bir-arada bir platformun yol haritasına sıkışmak yerine beden motorları gibi en iyisini seçebilecekleri araçları eklentileyebilecek esnekliği istiyor. MACH ve composable mimari benimsenmesini izleyen analistler, büyüyen perakendeciler için bu modüler, API-öncelikli ticaret yığınlarına yönelişi bir öncelik olarak not ediyor — daha geniş bağlam için McKinsey'in composable ticaret trendleri üzerine kapsamına bakabilirsiniz.
Mağazalar için API-öncelikli bir beden entegrasyonunun pratik faydası, beden araçlarının kalıcı, taşınabilir bir varlığa dönüşmesidir. İki yıl sonra tekrar platform değiştirirseniz, beden mantığı, geçmiş uyum verisi ve öneri doğruluğu sizinle birlikte taşınır — yalnızca frontend sarmalayıcısının yeniden inşa edilmesi gerekir.
Sıkça Sorulan Sorular
Headless mağazaya beden özelliği eklemek için bir backend ekibine ihtiyacım var mı?
Evet, en azından widget'ı oluşturacak ve API çağrısını entegre edecek bir frontend mühendisine ihtiyaç var, ancak öneri mantığının kendisi beden sağlayıcısı tarafından yönetildiği için çaba genelde haftalar değil günlerle ölçülür. Zaten headless bir mağaza inşa eden çoğu ekip, diğer bileşen işlerinin yanına tek bir API entegrasyonu ekleyecek mühendislik kapasitesine sahiptir.
Aynı beden API'si hem web hem mobil uygulama mağazasını besleyebilir mi?
Evet, ve bu API-öncelikli beden yaklaşımının en güçlü argümanlarından biri budur. Uç nokta durumsuz ve çerçeve bağımsız olduğu için, hem bir React web mağazası hem de yerel veya React Native bir mobil uygulama aynı backend'i çağırabilir ve aynı alışverişçi ile ürün için aynı önerileri döndürebilir.
Bu, Shopify veya Ticimax'e beden uygulaması kurmaktan nasıl farklı?
Monolitik bir platformda uygulama, tema enjeksiyonu üzerinden hem arayüzü hem mantığı yönetir, bu yüzden ekibinizin inşa etmesi gereken çok az şey vardır. Headless bir yığında sağlayıcı yalnızca API'yi ve veriyi sunar; frontend ekibiniz widget'ı inşa etmek ve stillendirmekten sorumludur, bu da daha fazla tasarım kontrolü ama önceden daha fazla mühendislik zamanı gerektirir.
Uç (edge) önbellekleme öneri doğruluğunu etkiler mi?
Hayır, uç noktada yalnızca beden tablosu ve ürün verisi önbelleğe alınırsa ve alışverişçiye özel öneri önbelleğe alınmazsa. Nihai eşleştirme hesaplaması doğruluğu korumak için her zaman alışverişçinin güncel profiline veya ölçülerine göre taze çalışmalıdır.