İade Portalı Analitiğinde Neyi Takip Etmelisiniz

Çoğu mağaza sahibi iade portalını katlanılması gereken bir maliyet merkezi olarak görür, incelenmesi gereken bir veri seti olarak değil. Bu bir hatadır. Müşterinin self-servis iade portalında yaptığı her tıklama — seçtiği neden, yüklediği fotoğraf, neredeyse aldığı ama vazgeçtiği değişim — ürün kalitesi, beden doğruluğu ve yukarı akış merchandising kararları hakkında bir sinyaldir. Eğer iade oranınızı sadece tek bir yüzde olarak ölçüyorsanız, o oranı yarıya indirmenizi sağlayacak asıl veriyi çöpe atıyorsunuz demektir.

Sorun şu ki çoğu portal analitik kurulumu 'iade gönderildi' ve 'iade işlendi' noktasında durur. Bu, aralarında düzinelerce anlamlı adım olan bir sürecin sadece iki ucudur. Aradaki adımlar olmadan, iadelerdeki bir artışın beden sorunu mu, kalite sorunu mu, yoksa müşterileri sessizce değişim yerine iadeye iten bir portal UX sorunu mu olduğunu anlayamazsınız. Bu yazı, bir iade portalının kaydetmesi gereken tam olay şemasını ve bu olayların iade sayıları yerine kâr sızıntısını gösteren bir panoya nasıl dönüştüğünü tanımlıyor.

İade oranı tek başına neden bir gösteriş metriği

Tek bir iade oranı rakamı size neredeyse hiçbir eyleme dönüştürülebilir bilgi vermez. İki mağaza aynı %22 iade oranına sahip olabilir — biri bir beden çizelgesi düzeltmesiyle bir haftada çözülecek kötü kesimli bir ürün hattı yüzünden, diğeri ise o kadar hantal bir değişim akışı yüzünden ki müşteriler pes edip iade almayı tercih ediyor. Panolar birebir aynı görünür. Çözümler tamamen farklıdır. Bu yüzden başka bir yazımızda gerçekten önemli olan metriklerin başlık orandan çok daha derine indiğini savunmuştuk ve bu derinlik portal seviyesindeki olay verisinden gelir.

Sadece hacmi takip ettiğinizde tamamen kaçırılan bir kârlılık boyutu da var. Recommerce sektör araştırmaları, elden çıkarılan ürünlerin yaklaşık %48'inin tam fiyattan yeniden satılabildiğini gösteriyor — geri kalanı indirimli satılıyor, tasfiye ediliyor ya da tamamen zarar yazılıyor; recommerce pazar raporlamasına göre. Bu, bir iadenin finansal sonucunun büyük ölçüde ürün başlatıldıktan sonra olanlarla belirlendiği anlamına gelir: ne kadar hızlı işlendiği, hangi durumda geri geldiği ve yeniden satış penceresi kapanmadan satılabilir envantere geri yönlendirilip yönlendirilmediği. Bunların hiçbiri ham bir iade oranı rakamında görünmez.

Olay şeması: gerçekte ne kaydedilmeli

İade portalını tek bir form gönderimi değil, kontrol noktalarından oluşan bir huni olarak düşünün. Her kontrol noktası, en azından bir zaman damgası, sipariş kimliği, SKU ve müşteri kimliğiyle yakalamanız gereken ayrı bir olaydır. Temel set:

• portal_session_started — müşteri sipariş onayından, e-postadan veya doğrudan bağlantıdan portala ulaşır
• order_lookup_completed — sipariş başarıyla bulunur ve uygun ürünler görüntülenir
• item_selected — siparişteki kaç üründen hangi SKU'nun(ların) iade edildiği
• reason_selected — iade neden kodu (beden çok küçük, beden çok büyük, açıklamaya uymuyor, hasarlı, kalite sorunu, fikir değiştirdi, diğer)
• photo_uploaded — fotoğraf kanıtı eklenip eklenmediği ve hangi neden kodları için
• resolution_offered — portalın sunduğu seçenekler (iade, değişim, mağaza kredisi, tamir)
• resolution_selected — müşterinin gerçekte ne seçtiği
• exchange_item_browsed — değişim akışlarında hangi alternatif beden/renk/ürünün görüntülendiği
• label_generated — kargo etiketinin oluşturulması, taşıyıcı ve maliyet
• portal_session_abandoned — oturumun bir çözüme ulaşmadan sona ermesi, ulaşılan son adımla birlikte
• item_received_at_warehouse — fiziksel teslim alma zaman damgası
• item_disposition_set — yeniden satılabilir, tasfiye, imha, tedarikçiye iade
• refund_or_credit_issued — nihai finansal sonuç ve tutar

Çoğu portalın tamamen atladığı adım, elden çıkarma (disposition) takibidir. Bu olmadan, bir iade nedenini gerçek finansal sonucuyla ilişkilendiremezsiniz ki bu, günümüzde çoğu mağaza analitik yığınındaki en büyük kör noktadır.

Her panonun göstermesi gereken dört metrik

Ham olay kayıtları bir pano değildir. Merchandising veya operasyon ekibinin haftalık olarak harekete geçebileceği az sayıda türetilmiş metriğe ihtiyacınız var. Gerçekten işe yarayan iade panolarını kurarken önce oluşturmanızı önerdiğimiz dört metrik şunlar:

Değişim dönüşümü özel dikkat gerektirir çünkü elde tutulan gelirle en doğrudan bağlantılı metriktir. Değişim satışı korur; iade ise siler. Portalınız değişim seçeneği sunuyor ama dönüşüm oranı %20'nin altındaysa, bu genellikle müşteri tercihi sorunu değil, UX ya da envanter görünürlüğü sorunudur — alışverişçiler en az dirençli yolu tercih eder ve değişim akışı daha fazla tıklama gerektiriyorsa ya da canlı stok göstermiyorsa, iadeyi seçerler.

İade maliyetlerini en hızlı düşüren ekipler en düşük iade oranına sahip olanlar değil — hangi iadenin önlenebilir olduğunu ve ne kadarının önlenebilir olduğunu SKU bazında size söyleyebilenlerdir.

Neden kodlarını kâr sızıntısı görünümüne dönüştürmek

Neden kodları ancak harekete geçilebilecek kadar spesifik olduğunda işe yarar. 'Fikir değiştirdi' ve 'diğer' gibi genel-geçer kovalar, faydalı sinyalin öldüğü yerdir — iadelerinizin %25'inden fazlası belirsiz bir kovaya düşüyorsa, taksonomiyi sıkılaştırın. İyi bir beden-özel taksonomi (dar geliyor, bol geliyor, yanlış beden sipariş edildi, beden tablosuyla uyuşmuyor), gerçek bir beden aracı sorununu sıradan alışverişçi hatasından ayırt etmenizi sağlar; bu çok farklı bir çözüm gerektirir.

Neden kodları temizlendiğinde, bunları elden çıkarma verisiyle birleştirin. Kâr sızıntısının görünür hale geldiği yer burasıdır: sürekli olarak 'imha' sonucuna varan bir 'taşımada hasar gördü' nedeni, her birimde tam marjınıza mal olan bir paketleme veya kargo sorunudur. Belirli bir tedarikçi partisine bağlı bir 'kalite sorunu' nedeni, yapılmayı bekleyen bir tedarikçi görüşmesidir. Bu kalıpların hiçbiri iade oranından tek başına görünmez — yalnızca neden, elden çıkarma ve finansal sonucu SKU seviyesinde birleştirdiğinizde ortaya çıkarlar.

Basit bir haftalık inceleme yapısı

1. 1İade hacmine ve iade oranına göre en yüksek 10 SKU'yu çekin (bunlar genellikle farklı listelerdir)
2. 2Her biri için neden kodu yoğunlaşmasını inceleyin — tek bir neden mi baskın?
3. 3Elden çıkarma sonuçlarını kontrol edin — yüzde kaçı satılabilir envantere geri döndü?
4. 4O SKU'nun kategorisi için değişim dönüşümünü gözden geçirin — değişim akışı işe yarıyor mu?
5. 5Artan terk oranı olan her şeyi bir portal UX incelemesi için işaretleyin

Bu ritim, portalı pasif bir iade işleme aracından erken uyarı sistemine dönüştürür. Bu döngüyü tutarlı biçimde çalıştıran perakendeciler, beden ve kalite sorunlarını bir ürün lansmanından bir-iki hafta içinde yakalama eğilimindedir — iade oranının kendisi manuel bir araştırmayı tetikleyecek kadar alarme geçmeden çok önce. McKinsey'in perakende uygulamasındaki analistler bu gecikmeyi hazır giyim operasyonlarındaki en maliyetli kör noktalardan biri olarak işaret ediyor.

Mühendislik ekipleri için enstrümantasyon notları

Kuruluş aşamasında doğru yapılması gereken birkaç pratik nokta var, çünkü olay şemalarını sonradan yeniden kurmak pahalıdır:

• Finansal sonucu olan her çözümü (iade, etiket oluşturma, elden çıkarma) sunucu tarafında kaydedin — yalnızca istemci tarafı takip, reklam engelleyiciler ve terk edilen oturumlar yüzünden veri kaybeder
• portal_session_started'dan refund_or_credit_issued'a kadar süren bir oturum kimliği ekleyin, böylece tam huni sadece toplanmış değil müşteri bazında yeniden inşa edilebilir
• Her şeyi UTC olarak, mağazanın yerel saat dilimini ayrı bir alan olarak damgalayın — çok bölgeli mağazaların doğru kohort analizi için ikisine de ihtiyacı var
• Neden kodu taksonomisini sürümleyin — kodları değiştirdiğinizde, geçmiş trend çizgilerinin bozulmaması için bir eşleme tablosu tutun