Ölçeklenen Bir İade Veri Modeli Tasarlamak

Çoğu mağaza iade veri modelini kaza eseri kurar. Destek ekibi bir müşterinin ürünü neden geri gönderdiğini kaydetmek için bir alana ihtiyaç duyar, biri serbest metin bir sütun ekler. Finans ekibi iade tutarlarını takip etmek ister, bir Excel dosyası devreye girer. On sekiz ay sonra, kimse 'kadın elbiselerde 80 doların üzerindeki ürünlerde beden kaynaklı iade oranımız nedir' gibi basit bir soruyu bir hafta süren manuel veri temizliği yapmadan cevaplayamaz. Sorun asla raporlama aracı değildir — sorun, altta yatan returns-api-integration-guide'ın hiçbir zaman gerçek bir varlık modeli olarak tasarlanmamış olmasıdır. RMA (İade Yetkilendirme) seviyesinde şemayı yanlış kurarsanız, sonraki her panel, tahmin ve tedarikçi geri ödeme talebi bu zayıflığı miras alır.

Bu, eskisinden daha önemli hale geldi. Online alışverişlerde iade oranları giyimde düzenli olarak %20-30 bandında seyrediyor ve her iadeyi işlemenin operasyonel maliyeti gerçek bir para — National Retail Federation analistleri, iadelerin tek başına ABD perakendesinde yüzlerce milyar dolarlık bir yük olduğunu defalarca vurguladı. Ayda on binlerce iade işleyen bir perakendeci, her iadeyi izole bir talep gibi ele alan bir veri modeline sahip olmayı göze alamaz. İhtiyaç duyduğu şey, tek bir RMA kaydının 'müşteri iade başlattı'dan 'geri ödeme yapıldı' ve 'ürün yeniden satıldı veya zarar yazıldı'ya kadar sorgulanabilir bir iz üretmesini sağlayan bileşik bir modeldir.

Temel varlıklar: RMA, satır kalemi, sebep, disposition

Ölçeklenebilir bir iade veri modeli, çoğu ev yapımı sistemin tek bir tabloda birleştirdiği dört ayrı kaygıyı birbirinden ayırır. Bunları ayrı tutmak, analitik ve finansın nullable sütunlardan oluşan bir karmaşayı birleştirmeden bağımsız sorgu yapabilmesini sağlar.

• RMA (başlık): her iade yetkilendirmesi için bir kayıt — sipariş referansı, müşteri, kanal, durum, oluşturulma/kapanma zaman damgaları, toplam iade tutarı.
• Satır kalemi: iade edilen her SKU/adet için bir kayıt, sadece siparişe değil orijinal sipariş satırına bağlı — ürün bazında iade oranını hesaplamayı sağlayan şey budur.
• Sebep: satır kalemi seviyesinde uygulanan standartlaştırılmış bir taksonomi (RMA seviyesinde değil), çünkü tek bir iade aynı kutuda hem yanlış beden hem fikir değişikliği içeren ürünleri barındırabilir.
• Disposition: incelemeden sonra fiziksel ünitenin başına gelen — yeniden stoklama, elden çıkarma, imha, tedarikçiye iade, yenileme — geri ödeme kararından ayrı, kendi başına bir olay olarak kaydedilir.

Satır kalemi ile RMA arasındaki bu ayrım, çoğu sistemin ilk çöktüğü noktadır. Sebep kodları RMA başlığında yaşıyorsa, hangi belirli ürünün iadeyi tetiklediğini söyleme yeteneğini kaybedersiniz, bu da ürün bazlı analitiği imkansız hale getirir. Bu, arayüz müşteriye tek bir sebep seçici gösterse bile, mağazaları ilk günden itibaren satır seviyesinde uygulanan katı bir return-reason-taxonomy-in-practice'ye yönlendirmemizin en büyük nedenidir.

Disposition neden bir durum alanı değil, ayrı bir tablo olmalı

Disposition sıklıkla RMA'nın durum enum'unda başka bir değer olarak modellenir — 'yeniden stoklandı', 'iade edildi', 'kapandı' hepsi birbirine karışmış halde. Bu, tek bir RMA üç ünite içerdiği anda bozulur: biri yeniden stoklandı, biri hasar nedeniyle elden çıkarıldı, biri kusurlu ürün anlaşması kapsamında tedarikçiye geri gönderildi. Disposition, satır kalemine (hatta seri numaralı veya yüksek değerli ürünler için tek tek üniteye) bağlı, kendi zaman damgası, aktörü ve depo konumu olan bir alt olay olmalıdır. Bu ayrım aynı zamanda tedarikçi geri ödeme tahsilatını ve fire analizini de mümkün kılan şeydir — veri modeliniz hangi belirli ünitelerin gerçekten kusurlu olduğunu, hangilerinin sadece istenmediğini hiç kaydetmediyse, bir tedarikçiden üretim kusuru geri ödemesi talep edemezsiniz.

Sebep kodlarınız ve disposition sonuçlarınız satır kalemine bağlı değilse, iade oranınız bir manşet rakamdır — operasyonel bir kaldıraç değil.

Referans şema

Aşağıdaki tablo, ResReturn'ün Shopify, Ticimax ve ikas gibi platformlar için uyarladığı, kurum içinde kullandığı şemanın sadeleştirilmiş bir versiyonudur. Bilinçli olarak normalize edilmiştir — daha sonra bir raporlama veri ambarına denormalize edebilirsiniz, ama işlemsel model katı kalmalıdır.

Gerçekten çalıştıracağınız sorgular için tasarlamak

Önerilen herhangi bir şema için faydalı bir test: CFO'nuzun, ürün yöneticinizin ve operasyon liderinizin ilk çeyrekte isteyeceği beş raporu yazın ve her birinin tek bir join uzaklıkta olup olmadığını kontrol edin. Pratikte bunlar neredeyse her zaman aynı beş rapordur:

1. 1Hareketli bir pencerede SKU ve kategoriye göre iade oranı
2. 2Erken bir beden veya kalite sorununu yakalamak için ürün bazında sebep dağılımı
3. 3RMA oluşturulmasından paranın serbest bırakılmasına kadar geri ödeme döngü süresi
4. 4Geri ödeme tahsilatı için tedarikçiye göre disposition sonuçları (yeniden stoklama vs. zarar yazma)
5. 5Dolandırıcılık ve politika ayarı için müşteri seviyesinde tekrarlayan iade davranışı

Bu raporların her biri, sebep ve disposition'ın RMA başlığının değil, satır kalemi seviyesinin altında olmasını gerektirir. Veri mühendisliği ekipleri genellikle, McKinsey'nin dijital pratiği gibi ekiplerin analitiğe hazır operasyonel veri konusundaki en iyi uygulama rehberlerinde de yankılanan bir noktada, ayrıntı seviyesini erkenden en küçük anlamlı birime indirmenin, bunu sonradan eklemekten daha ucuz olduğu konusunda hemfikirdir. Sadece RMA seviyesindeki geçmişe granüler bir model uydurmak, ya pahalı bir geriye dönük doldurma projesi ya da kalıcı olarak bozulmuş bir geçmiş raporlama anlamına gelir.

Yaygın modelleme hataları

Excel tablolarından veya bir help-desk alanına eklenen geçici bir çözümden gerçek bir sisteme geçen mağazalarda aynı birkaç hatayı sürekli görüyoruz.

• Sebebi sadece serbest metin olarak saklamak, standart bir kod olmadan, bu da NLP temizliği yapmadan ürünler arası karşılaştırmayı imkansız kılar.
• Geri ödeme ile disposition'ı aynı olay olarak ele almak, bu da ürün fiziksel olarak ulaşmadan önce iade yapıldığı anda bozulur ('anında iade' politikalarında yaygındır).
• Orijinal sipariş satırına geri bağlantı olmaması — sadece siparişe bağlantı — bu yüzden bir siparişteki beş görsel olarak aynı SKU'dan hangisinin gerçekten iade edildiğini söyleyemezsiniz.
• Ekleme-yalnızca bir olay günlüğü yerine değişebilir durum alanları, bu SLA zamanlamasını ölçme veya tartışmalı geri ödemeleri denetleme yeteneğinizi yok eder.
• Disposition'da depo/konum boyutu olmaması, bu yüzden yeniden stoklama-vs-zarar yazma kararları belirli bir tesisin performansına bağlanamaz.

Sadece sebep kodu sorununu düzeltmenin bile orantısız bir getirisi olma eğilimindedir — ResReturn'de ilk 30 gün içinde mağazalarla birlikte yürüttüğümüz spesifik temizlik adımları için rma-data-quality yazımıza bakın. Sebep ve disposition'ı erkenden doğru yapmak, güvenilir iade oranı tahminlemesinin de anahtarıdır, çünkü tahmin modelleri ancak besledikleri geçmiş verinin kategorik ayrıntısı kadar iyidir.

Kesintisiz şekilde mevcut sistemi geçirmek

Çoğu mağaza bunu sıfırdan tasarlama şansı bulamaz — platform yerleşik bir iade akışından veya bir destek masası hack'inden geçiş yapıyorlardır. En güvenli yol katmalı olanıdır: yeni satır kalemi, sebep ve disposition tablolarını mevcut RMA başlığının yanına ekleyin, geçmiş sipariş ve geri ödeme verisinden mümkün olduğunca geriye dönük doldurun, raporlamayı devretmeden önce bir geçiş penceresi boyunca çift yazın. Canlı bir iade kuyruğunda tek seferlik büyük bir geçiş yapmaya çalışmak, mağazaların tam da en çok ihtiyaç duydukları anda — yoğun iade sezonunda — haftalarca güvenilmez SLA raporlamasıyla kalmasına yol açar.