Hepsiburada Katalog Ürünlerini Zenginleştirme Projesi: Satıcı Deneyimini Nasıl Geliştirdik?
Öncelikle Hepsiburada’da nasıl bir hizmet veriyoruz, neye etki ediyoruz bunu anlatmaya çalışacağım.
Hepsiburada’da katalog yönetimi nasıl gerçekleştiriliyor?
Hepsiburada kataloğunda katlanarak artan ürünümüz mevcut. Katalog 2023 yılı itibariyle 160 milyon civarı ürün barındırıyor. Satıcılarımız ürünlerini yükledikten sonra çeşitli sebeplerden dolayı ürün ismi, görselleri, açıklaması gibi ürün özelliklerini güncelleme ihtiyacı duyabiliyor. Peki bunu istediği gibi yapabilmeli mi? Bu sorunun cevabı aslında ürün kataloğunu nasıl tutmayı tercih ettiğinize göre değişir. Genel olarak 2 farklı yöntem tercih ediliyor. Bunlar çoklu katalog ve tekli katalog yönetimidir. En kısa ifadesiyle çoklu katalog yönetiminde bir ürün bir satıcıya bağlı olurken, tekli katalog yönetiminde aynı ürünü satmak isteyen satıcılar, işlemlerini tek bir ürün üzerinden gerçekleştirir. Hepsiburada tekli katalog olarak çalışmayı tercih ediyor.
Zenginleştirme projesi öncesi ürün güncelleme sistemi nasıl çalışıyordu?
Satıcılar Salesforce üzerinden Excel ile ürün güncelleme taleplerini iletiyordu. Hepsiburada ürün güncelleme ekibi bu talepleri manuel olarak gözden geçiriyor, kendi ekranları üzerinden değişiklikleri yapıyor ve sonucu yine Excel ile satıcıya iletiyordu.
Projede amacımız ürün güncellemeyi satıcının kendisine yaptırarak, güncelleme sürelerini en kısa zamana indirmek, iş gücü kazanımı sağlamak, satıcı taleplerini doğru analiz etmek, geliştirilmeye açık ve yönetilebilir bir yapıya sahip olmaktı. Bu işe odaklanmak ve kısa sürede ürünü yayına almak için var olan ekiplerin içerisinden, uçtan uca işi geliştirebilecek yeni çevik bir ekip kurduk. Ekibimizi kurarken ismini tüm ekip arkadaşlarımızın oylaması ile seçtik, Platon. Sürekli öğrenmeye ve öğretmeye açık bir filozof ismi olması da misyonumuzu temsil ediyor.
Peki teknolojik kararları nasıl aldık?
Öncelikle veri kaynağını seçmek bizim için bir süreçti. Satıcılara son kullanıcının gördüğü veriyi göstermek istiyorduk. Bundan dolayı bizim “canlı” diye adlandırdığımız, üzerinde direkt olarak işlem yapılmayan veriyi satıcıya sunmak istiyorduk. Sonrasında sıra database kısmına karar vermeye gelmişti. Burada veri tabanı çözümleri içerisinden MongoDB ve PostgreSQL olmak üzere 2 seçenek arasında karar aşamasına girdik. İkisinde de katalog domaini olarak aktif kullandığımız yerler mevcut. Burada MongoDB’yi tercih etmemizi iki temel madde ile özetleyecek olursak;
Mikroservis mimarisine uyumluluğu, document base olarak çalışması, büyük veriler ile çalışma imkanı bizim tercih etme sebeplerimiz arasında.
MongoDB üzerinde tuttuğumuz verileri sorgulamak performans problemi üreteceğinden dolayı arama mekanizmaları kurmak için hangi teknolojiyi kullanacağımıza karar vermemiz gerekiyordu.
Burada search engine olarak Elasticsearch, Milvus ve Solr arasında inceleme yaptık ve Elasticsearch ile ilerlemeye karar verdik.
Tercih etmemizdeki etkili olan durumlar;
“Sharding” ve “cluster” desteği olması, “distributed search” özelliği ve “real-time allocation” yapılabilmesidir.
Önyüz geliştirmelerimizde ise mevcut sistemimizde “single page application” olarak çalıştığımız mevcutta kullandığımız ReactJS’yi kullanmaya devam ettik. Sezgisel kullanıma olanak vermek üzere UX ekibi ile çalıştık.
İki ana ekrandan oluşacak şekilde bir yapı tasarladık. Bunlardan biri satıcıların kullanacağı ekran diğeri ise hepsiburada çalışanlarının ekranıdır. Burada kendi içerisinde farklı iş akışları olacağı için isimlendirmede fayda gördük ve satıcı için Lysis, agent için ise Gorgias ismini aramızda oylama sonucu seçtik. Bu isimler de Platon’un yazdığı kitaplardan geliyor. Katalog ekibi olarak mono-repo olarak çalışıyoruz. Bundan dolayı, Platon’da ihtiyacımız olan; Excel operasyonları, Cloud tabanlı dosya tutma sistemleri vb. ortak operasyonları çok az maaliyet ile çözebildik. Yaptığımız her geliştirmede ölçeklendirilebilme ve performans konusunu dikkate aldık.
Şu an ürün güncelleme sistemi nasıl çalışıyor?
Satıcılar kendi listeledikleri ürün üzerinden mevcut bilgilerini görüntüleyerek, değiştirmek istedikleri veriler ile ticket oluşturuyorlar. Bu ticket’lar hepsiburada çalışanları tarafından incelenerek onaylayıp canlıya alınıyor.
Talep geliyor ürün güncelleme ekibi onaylıyor veya reddediyor vs.
Metriklere göz atalım
Beklediğimizden hızlı kullanılmaya başlayan sistemimiz 3 ayda 150 binden fazla güncelleme talebi aldı. Kolay kullanımı ile satıcılarımızdan tam not aldı. Mikroservis performanslarımızın en uzun süresi 1 saniyenin altında.
Satıcı ekranlarının yüklenme süresi ortalama 600 ms
Kontrol ekranlarının yüklenme süresi ortalama 1100 ms
Şu an ürüne video eklemeyi canlıya almak üzereyiz. Kısa sürede ürünlere eklenebilen tüm özelliklerin de bu ekranlarda satıcıların isteklerine cevap verebilir hale getirmeyi planlıyoruz. API aracılığı ile entegratör firmalardan ürün güncelleme taleplerini alacağız.
Sonrasında kontrol ekranlarında hiçbir manuel işleme gerek kalmadan yapay zeka destekli otomatik onaylama mekanizmaları kurmayı hedefliyoruz. Burada birden fazla satıcılı ürünlerde kimin güncelleme yetkisine sahip olması gerektiğine de karar vermek gerekecek.
Yeni ekleyeceğimiz özelliklerle birlikte uçtan uca çözümün fikri haklarına sahip olmak üzere bir patent başvurusu da planladık.
Bu blog yazısı Chat GPT tarafından desteklenerek yazılmıştır. Okuduğunuz için teşekkür ederim.
