Shopify'da shipping uzun süredir büyüyen mağazaların en karmaşık configuration alanlarından biri.
Özellikle marka birden fazla ülkeye, farklı depolardan, farklı ürün gruplarıyla ve farklı taşıyıcılarla satış yapıyorsa shipping rule'ları kısa sürede karmaşık hale gelebiliyor.
Bugünkü problem ne?
Shipping configuration zamanla Products → Delivery Profiles → Locations → Zones → Rates yapısına dönüşebilir. Bunun üzerine market, currency, product restrictions, free shipping thresholds ve carrier rates eklendiğinde merchant'ın gerçek ticari kuralını anlamak zorlaşabilir.
Yeni model ne yapıyor?
Temel soru “Bu product hangi delivery profile'da?” yerine daha fazla “Bu market'te hangi shipping option geçerli?” haline geliyor.
Architecture nasıl değişiyor?
Eski zihinsel model:
Product → Delivery Profile → Zone → Rate
Yeni yaklaşım:
Market → Shipping Option → Product + Location Conditions → Rate
Örnek: Türkiye + Almanya
Türkiye
Standart: 99 TL
1.500 TL üzeri: ücretsiz
Almanya
Standart: €7,90
€100 üzeri: ücretsiz
Oversized ürün: €24,90
Buradaki ana business entity aslında market'tir.
Product condition neden önemli?
T-shirt, kahve makinesi ve mobilya aynı fulfillment maliyetine sahip değildir. Product-specific shipping rule doğal ihtiyaçtır.
App delivery profile'lar ne olacak?
Merchant shipping ile app-provided shipping farklı katmanlar olarak ele alınabilir. Custom shipping app geliştiriyorsanız hangi configuration modeline bağımlı olduğunuz audit edilmelidir.
Özel ERP/WMS entegrasyonu etkilenir mi?
Shipping configuration okuyan bir entegrasyon varsa potansiyel olarak evet.
Daha sağlam architecture:
Shopify Shipping Configuration → Internal Shipping Domain Model → ERP / WMS
şeklinde abstraction kullanır.
Shipping option ile fulfillment aynı şey değildir
Shipping option: müşteriye sunulan teslimat seçeneği.
Fulfillment: siparişin operasyonel olarak hangi location/warehouse tarafından gönderildiği.
İkisini aynı entity haline getirmemek gerekir.
Headless storefront etkilenir mi?
Özel storefront estimated shipping, free shipping progress, shipping eligibility veya delivery messaging gösteriyorsa configuration source değişikliğini hesaba katmalıdır.
Free shipping bar için kritik örnek
Cart drawer'da “Ücretsiz kargoya 250 TL kaldı” gösteren feature düşünelim.
Threshold component içine hard-code edilmemelidir.
Doğru resolver:
Current Market + Cart + Applicable Shipping Rule → Free Shipping Threshold
Market-driven shipping CRO açısından da önemli
Shipping yalnız operasyon problemi değildir. Checkout abandonment'ın önemli friction noktalarından biri teslimat maliyetinin geç ortaya çıkmasıdır.
PDP, cart ve checkout aynı shipping rule'dan beslenmelidir.
Migration öncesi audit
| Alan | Kontrol |
|---|---|
| Markets | Kaç market var? |
| Profiles | Kaç merchant delivery profile var? |
| Apps | Shipping profile oluşturan app var mı? |
| Rates | Static mi carrier-calculated mı? |
| Products | Product-specific rule var mı? |
| Locations | Multi-location fulfillment var mı? |
| ERP | Shipping mapping var mı? |
| Storefront | Shipping mesajları hard-coded mı? |
Test matrisi
- domestic market,
- international market,
- free shipping threshold altı/üstü,
- oversized product,
- mixed cart,
- multi-location inventory,
- unavailable location,
- app-provided rate,
- discount sonrası subtotal,
- subscription product,
- B2B customer.
Analytics'e shipping context eklenmeli mi?
Mümkünse market, shipping_option, shipping_cost ve free_shipping_eligible gibi context'ler checkout abandonment analizinde tutulmalıdır.
Market-Driven Shipping checklist
- Mevcut shipping profile envanteri çıkarıldı mı?
- Shipping app'leri belirlendi mi?
- Custom integration var mı?
- Product-specific rates test edildi mi?
- Location conditions test edildi mi?
- International markets test edildi mi?
- Free shipping threshold'ları doğrulandı mı?
- Cart messaging gerçek configuration ile uyumlu mu?
- ERP/WMS mapping kontrol edildi mi?
- Analytics shipping dimension içeriyor mu?
- Mixed cart test edildi mi?
- Failure/fallback davranışı tanımlı mı?
Shipping rule'u ürün değil market context'i belirler
Aynı SKU Türkiye'de yerel depodan, Almanya'da EU depodan, ABD'de 3PL'den gönderilebilir.
Daha doğru model:
Market
× Product
× Location
× Fulfillment capability
→ eligible methods/rates
Location priority
İki location'da stok varsa:
- proximity,
- cost,
- stock depth,
- SLA,
- split shipment
gibi faktörler devreye girebilir.
Free shipping message
Storefront “1000 TL üzeri ücretsiz” diyorsa checkout rate engine de aynı market/threshold'u uygulamalıdır.
Threshold:
- currency,
- tax inclusion,
- discount sonrası subtotal
gibi kurallarla açık tanımlanmalıdır.
ERP/WMS abstraction
commerce fulfillment request
→ internal fulfillment model
→ WMS adapter
kullanılabilir.
Migration test matrisi
- single product/single location,
- multi-product same location,
- split location,
- out-of-stock fallback,
- market change,
- currency change,
- free shipping boundary,
- remote postal code,
- pickup,
- app-managed delivery profile.
Observability
- no-rate checkout rate,
- shipping rate latency,
- split shipment rate,
- delivery method selection,
- checkout abandonment after shipping.
Rollout
Market bazında aşamalı migration, bütün global shipping logic'i tek seferde taşımaktan daha güvenlidir.
Shipping değişikliğinde finans etkisi
Shipping rule hatası yalnız checkout failure üretmez.
Yanlış location seçimi:
- fulfilment cost,
- teslimat süresi,
- split shipment,
- iade oranı
üzerinden margin'i de bozar.
Bu nedenle migration KPI'larına shipping cost/order ve SLA achievement eklenmelidir.
Sonuç
Shipping'i checkout'taki son seçenek olarak değil; market, katalog, fulfillment, storefront messaging ve analytics ile bağlantılı bir commerce domain'i olarak ele almak daha sağlıklı bir mimari oluşturur.
Reliefers olarak Shopify projelerinde shipping architecture'ı yalnız admin configuration değil, storefront ve operasyon sistemleriyle birlikte değerlendiriyoruz.