E-Ticaret Altyapısında Veri Sahipliği: Taşınabilirlik Nasıl Kontrol Edilir?

Bir e-ticaret panelinde bütün ürünleri görebilmek, ihtiyaç olduğunda onları başka sisteme eksiksiz taşıyabileceğiniz anlamına gelmez. Altyapı seçerken tasarım ve aylık ücret kadar önemli bir soru daha vardır: işletmenin verisi hangi biçimde, hangi koşullarla ve kim tarafından alınabilir?

Veri sahipliği, erişim ve taşınabilirlik aynı soru değildir

Bu rehberde veri sahipliğini işletmenin verisine erişebilmesi, onu yönetebilmesi ve kullanılabilir biçimde taşıyabilmesi açısından ele alıyoruz. Hukuki hakların kapsamı ise sözleşme, lisans ve ilgili yükümlülüklerle ayrıca belirlenir. Bir yönetici hesabına sahip olmak bu konuların hepsini kendiliğinden çözmez.

Erişim, panelde bilgiyi görebilmek veya değiştirebilmektir. Dışa aktarım, bilgiyi bir dosya veya desteklenen arayüz üzerinden alabilmektir. Taşınabilirlik ise bu çıktının başka bir sistemde anlamlı şekilde kullanılabilmesidir. Ürün adı ve fiyatı alınırken varyant ilişkileri kayboluyorsa dosya vardır, fakat taşınabilirlik eksik kalmıştır.

Altyapı görüşmesinde bu üç soruyu ayrı sorun. “Veriler sizin” yanıtından sonra örnek dışa aktarım, alan listesi ve kullanım koşullarını isteyin. Böylece soyut bir güvence yerine test edilebilir bir durum elde edersiniz. Amaç yalnızca platform değiştirmek değil, işletmenin kendi kayıtları üzerinde sürdürülebilir kontrol kurmasıdır.

Veri sahipliği için önce varlık envanteri hazırlayın

Mağazadaki veri yalnızca ürün tablosundan oluşmaz. Müşteriler, adresler, siparişler, yorumlar, indirim kuralları, görseller, içerikler ve uygulama kayıtları farklı yerlerde tutulabilir. Alan adı, tema dosyaları ve analitik hesapları da işletmenin dijital varlıklarıdır. Her birinin hesabını ve sorumlusunu belirleyin.

Envanterde verinin nerede bulunduğu, kimlerin eriştiği, nasıl dışa aktarıldığı ve hangi iş için kullanıldığı yazsın. Örneğin ürün görselleri platformda, özgün çekim dosyaları bir ajans klasöründe ve ürün açıklamaları ayrı bir belgede olabilir. Bu dağınıklık görünür olmadığında devir sırasında eksikler ortaya çıkar.

Her varlığa bir iş sahibi atayın. Teknik erişim geliştiricide olsa bile işletme içinde sorumluluğu belli olmalıdır. Bir kişinin ayrılması veya hizmet sağlayıcının değişmesi durumunda hesabın nasıl yönetileceği bilinmelidir. Ortak şifreleri mesajlaşma gruplarında paylaşmak yerine yetkili hesap ve erişim düzeni kullanın.

Veri sahipliği ürün ve varyant dosyasında nasıl sınanır?

Ürün dışa aktarımında isim, açıklama ve fiyatın yanında varyant, ürün kodu, stok, ağırlık, kategori ve özel alanları kontrol edin. Dosyanın kaç satır olduğu kadar satırların birbirine nasıl bağlandığı da önemlidir. Aynı ürünün farklı renk ve ölçülerini doğru ilişkilendiremeyen çıktı, geçişte ek iş çıkarabilir.

Shopify’nin ürün dışa aktarma belgesi, CSV yapısını ve satır ilişkilerini dikkate almayı gerektirir. Görsel bağlantısının dosyada bulunması, özgün görsel dosyasının ayrıca elinizde olduğu anlamına gelmez. Medya dosyalarının erişimini ve arşivini ayrı planlayın.

Kontrol için kolay bir ürün yerine farklı özelliklere sahip küçük bir grup seçin. Çok varyantlı ürün, uzun açıklama, boş alan, özel karakter ve özel alan kullanan kayıtlar dahil olsun. Çıktıyı açıp alanları karşılaştırın. Sonraki adımda bu örnek grubun bir test ortamında doğru okunup okunmadığını deneyin.

Veri sahipliği müşteri ve sipariş kayıtlarında ne gerektirir?

Müşteri e-posta listesi ile tam müşteri kaydı aynı şey değildir. Adresler, iletişim tercihleri ve sipariş ilişkileri ayrı alanlar olabilir. Hangi bilgilerin hangi amaçla tutulduğunu anlayın. Dışa aktarılan dosyada alanların bulunması kadar, anlamlarının ve kaynaklarının korunması da önemlidir.

Siparişlerde satır ürünleri, indirimler, kargo, vergi, ödeme ve işlem durumları kontrol edilmelidir. Yalnızca toplam tutarı içeren bir rapor, müşteri hizmetleri veya yeni sistemde geçmiş sipariş takibi için yeterli olmayabilir. Hangi ayrıntının gerçekten gerektiğini işletme ekibiyle birlikte belirleyin.

Müşteri verisini deneme dosyalarında gereksiz yere çoğaltmayın. Mümkün olduğunda temsili kayıtlarla yöntem kontrolü yapın; gerçek kayıt gerekiyorsa erişimi görevle sınırlayın. Taşıma kolaylığı adına pazarlama tercihlerini değiştirmeyin veya kişisel bilgiyi herkesin erişebildiği bağlantılarda saklamayın. Taşınabilirlik, düzenli erişim ve doğru kullanım sorumluluğuyla birlikte düşünülmelidir.

Veri sahipliği ile uygulama bağımlılığını birlikte değerlendirin

Yorumlar, sadakat puanları, kişiselleştirme dosyaları veya abonelik kayıtları ana platform yerine bir uygulamada tutulabilir. Ana ürün dosyasını almak bu verileri kapsamayabilir. Her uygulama için dışa aktarım biçimini, saklanan alanları ve hesabı kapatınca erişimin ne olacağını kontrol edin.

Bir araç yalnızca kendi içinde kullanılabilen bir dosya veriyorsa bu çıktının başka sistemde nasıl okunacağını sorun. Gerekli alan sözlüğü ve kayıt kimlikleri var mı? Veriyi topluca almak mümkün mü? Ek ücret veya destek talebi gerekiyor mu? Bu soruların cevabı, hizmetten ayrılma gününe bırakılmamalıdır.

Uygulamaların birbirine bağımlılığını da belgeleyin. Örneğin yorumların ürün koduyla eşleşmesi, ürün kodlarının geçişte korunmasına bağlı olabilir. Sadakat kayıtları müşteri kimliğine dayanıyorsa yeni sistemde eşleştirme gerekir. Bu ilişkileri tek tek görmek, “CSV aldık, hazırız” varsayımından daha gerçekçi bir taşıma planı oluşturur.

Veri sahipliği kontrolünde yedek ile dışa aktarımı ayırın

Bir rapor indirmek, bütün mağazayı eski haline döndürebilen bir yedek almakla aynı değildir. Shopify’nin yedekleme ve mağaza çoğaltma belgesi, farklı verilerin ayrı yöntemlerle alınabildiğini ve bütün bilgilerin aynı şekilde geri yüklenmediğini açıklar. Her çıktı için hangi geri dönüş işini desteklediğini belirleyin.

Yedek planında kapsam, sıklık, saklama yeri ve geri yükleme denemesi olsun. Ürünler düzenli alınıyor ama tema veya önemli uygulama ayarları hiç kaydedilmiyorsa planın sınırı açıkça yazılmalıdır. Son başarılı dosyanın tarihi bilinmeden “yedek var” demek yeterli güvence sağlamaz.

Bir geri yükleme denemesi, dosyanın gerçekten kullanılabilir olduğunu gösteren güçlü kontroldür. Test ortamında birkaç kayıt seçin ve ilişkileriyle birlikte okunabildiğini doğrulayın. Denemeyi canlı mağazadaki verilerin üzerine yazacak biçimde yapmayın. Başarısız olan alanları kaydedip yedek veya aktarım yöntemini buna göre geliştirin.

Tedarikçiye sorulacak sorular ve istenecek kanıtlar

Altyapı sağlayıcısından yalnızca “destekliyoruz” yanıtı almak yerine örnek dosya, alan listesi ve işlem adımı isteyin. Aşağıdaki tablo, teklif görüşmesine götürülebilecek bir kontrol çerçevesidir. Her sorunun cevabını tarihli kaydedin; hizmet veya plan değiştiğinde yeniden doğrulayın.

Teknik yöntemle sözleşme koşulunu birbirinin yerine koymayın. Bir özellik teknik olarak mümkün olsa da hizmet planınızda ücretli olabilir. Bir sözleşme veri teslimini öngörse de kullanılabilir biçim belirsiz kalabilir. İki tarafı birlikte açıklığa kavuşturmak, altyapı karşılaştırmasını daha gerçekçi hale getirir.

Küçük bir taşınabilirlik denemesi nasıl yapılır?

Önce bir örnek veri seti seçin: birkaç farklı ürün, bunların görselleri ve temsili müşteri ile sipariş kayıtları. Her kaydın kaynak görünümünü ve gerekli alanlarını listeleyin. Ardından desteklenen yöntemle dışa aktarın. Dosyada özel karakter, tarih, para birimi ve kayıt ilişkilerini kontrol edin.

WooCommerce’un ürün CSV aracı gibi araçlar kendi desteklediği veri yapısıyla çalışır. Bir sistemin dosyasının diğerine doğrudan uyacağını varsaymayın. Gerekli dönüşümleri ayrı çalışma kopyasında yapın ve her dönüşümün nedenini kaydedin. Ham çıktıyı değiştirmeden koruyun.

Denemenin sonunda yalnızca kaç kaydın yüklendiğine bakmayın. Ürün kodu, varyant, görsel ve sipariş ilişkileri doğru mu? Eksik alanlar için elle tamamlama gerekiyor mu? Bu işin tahmini kapsamı ne? Küçük deneme, gelecekteki geçişin gerçek maliyetini ve zorluğunu anlamak için kullanılabilir.

Ajans veya ekip değişiminde devir paketini hazırlayın

Platform değiştirmeseniz bile hizmet sağlayıcı değişimi sırasında aynı kontrol ihtiyacı doğar. Alan adı hesabı, yönetici yetkileri, tema değişiklikleri, uygulama listesi, analitik hesapları ve görsel dosyaları devir paketinde yer alsın. Hesapların işletme adına yönetilebilmesi ile görev için verilen erişimleri ayırın.

Devir belgesinde neyin teslim edildiği ve neyin kapsam dışında olduğu yazılı olsun. Özel geliştirme kodu, tasarım dosyaları, lisanslı görseller veya fontlar farklı kullanım koşullarına sahip olabilir. Kullanım ve devir haklarını ilgili sözleşme ve lisans kayıtlarıyla doğrulayın; dosyanın elinizde olması bütün hakların devredildiği anlamına gelmez.

Yeni ekip devraldıktan sonra erişimleri gözden geçirin ve kritik görevleri deneyin. Yedek alabiliyor, ürün güncelleyebiliyor ve önemli entegrasyonları yönetebiliyor mu? Eski ekibin erişiminin kaldırılmasıyla çalışan bağlantılar duruyor mu? Devir, yalnızca parola gönderimi değil, işletme sürekliliğinin kontrolüdür.

Altyapı kararını çıkış planıyla birlikte verin

Bir platformu seçerken ondan ayrılma ihtimalini konuşmak olumsuz bir yaklaşım değildir. İş modeli, ürün sayısı veya entegrasyon ihtiyacı değişebilir. Çıkışın nasıl yapılacağını bilmek, bugünkü kararı daha bilinçli verir. İlk görüşmede alınan yanıtları küçük bir denemeyle desteklemek bu nedenle değerlidir.

Karar belgenize dışa aktarılabilen veri türlerini, eksikleri, ek ücretleri, erişim sürelerini ve sorumluları ekleyin. Yalnızca aylık abonelik tutarı üzerinden yapılan karşılaştırmanın yanına bu operasyon bilgisini koyun. Veri taşıma için gereken insan emeği ve özel dönüşümler de gelecekteki kapsamı etkiler.

Mevcut mağazanızda envanter hazır değilse ürün, müşteri ve siparişten başlayın. Ardından görsel, içerik, uygulama ve hesapları ekleyin. Altyapı değiştirme rehberini bu listeyle birlikte kullanarak eksikleri sıralayabilirsiniz. Hedef, bütün sistemleri aynılaştırmak değil, kendi verinizin nerede ve ne durumda olduğunu bilmektir.

Kaynaklar ve editoryal not

• Shopify: Yedekleme ve mağaza çoğaltma sınırları
• Shopify: Ürünleri dışa aktarma
• WooCommerce: Ürün CSV araçları

Kaynak kontrolü: 4 Kasım 2026. Platforma ilişkin bilgiler birincil kaynaklarla kontrol edilmiştir. Karar tabloları, kontrol listeleri ve mesaj taslakları Timurial’in editoryal önerileridir. Temsili senaryolar gerçek müşteri sonuçları olarak sunulmamıştır.