ÜRÜN VARYANT MODELİ KURGULAMAK

Ürün varyant modeli; renk, beden ve özellik kombinasyonlarını ana ürün, varyant ve SKU katmanlarıyla düzenleyerek stok karmaşasını, fiyat hatalarını ve filtre sorunlarını önleyen yapıdır; bu yazıda modelin temel kararlarını, sık yapılan hataları ve 50 üründen 50.000 ürüne büyürken işleyen sistemler kurmanın yolunu öğreneceksiniz.

1. Ana ürün ile varyant farkı

E-ticaret platformlarında bu ayrım sürekli karıştırılır. Net tanım:

• Ana ürün (parent product): Kullanıcının arama sonucunda gördüğü, ürün detay sayfasını açtığı birim. Marka + model + temel açıklama. Satılamaz; sadece kapsayıcıdır
• Varyant (variant/child): Kullanıcının "renk seç + beden seç" sonucunda gerçekten sepete attığı birim. Stok, fiyat, görsel bu seviyede tutulur
• SKU (Stock Keeping Unit): Her varyantın depo seviyesindeki tekil kodu. Operasyon bu kodla iletişim kurar

Pratik örnek

Ana ürün: "Casual T-Shirt"
├── Varyant 1: Beyaz / S    → SKU: CTS-WHT-S
├── Varyant 2: Beyaz / M    → SKU: CTS-WHT-M
├── Varyant 3: Beyaz / L    → SKU: CTS-WHT-L
├── Varyant 4: Siyah / S    → SKU: CTS-BLK-S
└── ...

Müşteri sayfaya gelir "Casual T-Shirt"ü görür; seçim yaptıktan sonra sepetine "CTS-WHT-M" eklenir. Operasyon ekibi siparişi gördüğünde CTS-WHT-M reyonundan ürünü alır. Bu üç katmanlı ayrım, elektronik ticaret altyapısının temel mantığına dayanır ve katalog büyüdükçe ölçeklenmeyi mümkün kılar.

2. Varyant özellik (attribute) tasarımı

Varyantı tanımlayan özellikler. Renk, beden, kapasite, malzeme gibi. İki ana karar:

Hangi özellik varyant, hangi özellik ürün-seviye?

• Varyant özelliği: Kullanıcının satın alırken seçim yaptığı, fiyat veya stoku etkileyen unsur. Renk, beden, kapasite
• Ürün-seviye özellik: Tüm varyantlar için ortak, sadece bilgi amaçlı. Marka, malzeme bileşimi, yıkama talimatı, ürün kodu

Yanlış kategoriden seçim sık yapılır. Örneğin "yıkama talimatı"nı varyant özelliği yapmak doğru değil; bu bilgi tüm varyantlarda aynı.

Sıralı vs sırasız özellikler

• Sıralı: Beden (XS, S, M, L, XL) — küçükten büyüğe sıralanmalı; kullanıcı kafa karışıklığı önlenir
• Sırasız: Renk — alfabetik veya popülariteye göre düzen; sıra fark etmez

Görsel özellikler için "swatch"

Renk seçimi text yerine renk örneği ile gösterilir (kare/yuvarlak swatch). Beden seçimi text olarak yeterli. Görsellik mantığı kullanıcı deneyimini ciddi şekilde iyileştirir.

3. SKU adlandırma sistemi

SKU'lar tutarlı ve okunabilir olmalı. İyi SKU sistemi şu özellikleri taşır:

• Anlamlı: Okurken neyin ne olduğu anlaşılır
• Tutarlı: Aynı sıralama mantığı tüm üründe geçerli
• Eşsiz: Hiçbir iki ürün aynı SKU paylaşmaz
• Sabit: Bir kez verilen SKU değişmez (varyant silinse bile yeniden kullanılmaz)
• Kısa: 8-16 karakter ideal; barkod basımı kolaylaşır

Örnek SKU şeması

[Kategori 3 harf]-[Marka 3 harf]-[Model 4 hane]-[Özellik]
TSH-CAS-0042-WHT-M     // T-shirt Casual model 42, Beyaz, M
JCK-DNM-0017-BLK-L     // Jacket Denim model 17, Siyah, L
SHO-NIK-0008-RED-42    // Shoe Nike model 8, Kırmızı, 42 num

Bu sistemde herhangi bir SKU'ya bakınca kategori, marka ve özellik bilgisini görebilirsiniz. Operasyon ekibi bu kodu raporlama, stok düzenleme ve iade işlerinde kolayca kullanır.

4. Stok ve fiyat seviyesi

Stok varyant seviyesinde tutulur

Yaygın hata: stoku ana üründe tutmak. "20 t-shirt var" yetmez; "10 beyaz S, 5 beyaz M, 3 siyah L, 2 siyah XL" detayı gerekir. Müşteri kendi kombinasyonunu seçtiğinde sistem doğru stokla yanıtlar.

Fiyat varyant seviyesinde olabilir veya olmayabilir

• Tüm bedenler aynı fiyatsa: ana ürün seviyesinde tek fiyat
• Bedene göre fiyat değişiyorsa (büyük bedenler daha pahalı): varyant seviyesinde
• Renk veya kapasiteye göre fiyat farkı varsa: varyant seviyesinde

Fiyat varyant seviyesinde tutuluyorsa "fiyattan başlangıç" gösterimi yapılır: kullanıcıya "175 TL'den başlayan fiyatlarla" gibi mesaj.

5. Görsel yönetimi

Görsel yönetimi varyant kararlarının en önemli parçasıdır.

Renk-spesifik görseller

T-shirt'ün siyah versiyonunun siyah fotoğrafı, beyaz versiyonunun beyaz fotoğrafı olmalı. Kullanıcı bir renk seçtiğinde tüm görsel galeri o renge göre değişmeli. Bu, dönüşüm oranını ciddi şekilde etkileyen bir UX detayı.

Bedene göre değişmeyen görsel

Bedenler için ayrı görsele genelde gerek yok; ana renkten yeterli. Sadece çok özel durumlarda (örneğin gömleğin XL'de dikim farklı görünüyorsa) bedenle görsel ilişkilendirilebilir.

Görsel kaynağı tek doğru

Görseller varyantla ilişkilendirilir ama tekil bir görsel havuzunda saklanır. Aynı görseli iki kez yüklemek depo israfıdır; bir varyanttaki güncelleme diğerlerini bozar.

6. URL ve SEO yapısı

Varyant sayfaları için iki ana yaklaşım:

1. Tek URL (önerilen)

Tüm varyantlar tek ana ürün URL'inde, varyant seçimi URL parametresi veya hash ile:

/casual-t-shirt
/casual-t-shirt?color=white&size=m
/casual-t-shirt#renk=beyaz

Avantajı: tek sayfa SEO otorite biriktirir, link inşası tek sayfa için yapılır, kanibalizasyon riski yok. Google önce ana sayfayı sıralar; kullanıcı geldiğinde varyant seçer.

2. Ayrı URL'ler

Her varyant ayrı URL'de:

/casual-t-shirt-beyaz-m
/casual-t-shirt-siyah-l

Çok özel durumlarda kullanılır (örneğin her renk için ayrı sayfa SEO'su istenirse). Çoğu durumda kanibalizasyon yaratır; ana ürün sayfasından otorite çalar.

7. Filtre yapısı

Kategori sayfasında "Renk: Beyaz" filtresi seçildiğinde:

• Sadece o renkte varyantı olan ana ürünler listelenir
• Ana ürün görseli o rengin görseliyle değişir
• URL filtre parametresi ile güncellenir

Filtre URL'leri varsayılan olarak indekslenmemeli (robots.txt veya canonical) çünkü binlerce kombinasyon sonsuz sayfa üretebilir; crawl bütçesi tüketir.

8. Klasik Hatalar modeller hatalar

1. Her varyantı ayrı ürün olarak listelemek. "Beyaz T-shirt", "Siyah T-shirt", "Mavi T-shirt" diye 3 ayrı ürün açmak. Kullanıcı yorulur, SEO bozulur
2. SKU sistemi yokken büyümek. İlk 50 ürünü manuel kodla, sonra 500 ürünle başa çıkamayıp panik yapmak
3. Stok ana ürün seviyesinde. Toplam stok 20 görünür ama hangi bedende kaç tane bilinmez
4. Görsel-renk eşleşmesi atlanması. Kullanıcı "siyah" seçer, görsel beyaz kalır; iade riski artar
5. Bedeni renk gibi davranmak. Beden sıralı, renk sırasız; kullanıcı arayüzü bu farkı yansıtmalı
6. Pasif varyantı silmek. Bir varyant artık satılmıyorsa pasif yapın, silmeyin. Tarih bazlı raporlama için varyant geçmişi korunmalı

9. Kanal-spesifik varyant farklılıkları

Pazaryeri-kendi site çoklu satış yapan markalar için ek karmaşıklık:

• Trendyol her bedeni ayrı "ürün" gibi listelemek isteyebilir; ana SKU ile haritalandırma gerekir
• Hepsiburada renk-beden kombinasyonunu farklı sıralayabilir
• Amazon ASIN sistemi kendi SKU'nuza ek bir katman ekler
• Kendi sitenizde özgün varyant yapısı kurar, pazaryerine entegrasyon eklentisi ile aktarırsınız

Bu durumlar için ERP veya PIM (Product Information Management) sistemi kullanılır; tek bir merkezde ürün-varyant-SKU haritası tutulur ve tüm kanallara dağıtılır.

10. Veri kalitesi kontrolleri

Büyüyen kataloglarda otomatik kontroller şart:

• Aynı SKU iki varyantta var mı? (eşsizlik ihlali)
• Negatif stok varyantı var mı? (operasyon hatası)
• Görselsiz varyant var mı? (yayın hatası)
• Fiyatsız varyant var mı? (satış engeli)
• Tanımlanmamış özellik değeri var mı? ("Renk: ", boş alan)

Bu kontroller cron job veya günlük rapor ile çalıştırılır; sorunlar oluştuğu gün yakalanır.

11. Pratiğin Üzerine

Varyant modeli e-ticaretin altyapı kararlarındandır; yanlış kurulan model ileride çok pahalıya düzeltilir. Sistemli e-ticaret yönetimi için e-ticaret eğitim programı ürün yönetimi, stok, fiyatlandırma ve operasyon konularını birlikte aktarır.

12. Yapının Özeti

Ürün varyant modeli; ana ürün, varyant ve SKU katmanlarının doğru ayrılmasıyla çalışır. Stok ve fiyat varyant seviyesinde, görsel renk-spesifik, SKU sistemi anlamlı ve eşsiz olmalı. URL yapısı tek ana ürün üzerinden gitmeli; filtre URL'leri indekslenmemeli. Veri kalitesi kontrolleri otomatik çalışmalı. Bu kararlar erken aşamada doğru verildiğinde katalog 50 üründen 50.000 ürüne kadar sorunsuz büyüyebilir; yanlış verildiğinde her ek ürün operasyonel yükü katlar.