Bagaimana kami membangun pengalaman belanja baru yang sangat personal
Blog ini merupakan kelanjutan dari blog produk sebelumnya di Fynd App 2.0.
Di Fynd, kami terus mengembangkan produk yang memungkinkan pelanggan kami menemukan pilihan fesyen mereka dengan mudah. Untuk mencapai hal ini, baru-baru ini kami merilis Fynd App 2.0 dengan Hyper-Personalization.
Dengan belajar secara cermat dari perilaku pengguna, kami menyempurnakan komponen front-end dan back-end kami, membimbing mereka untuk memilih mode yang mereka sukai daripada menelusuri opsi tanpa akhir. Kami sekarang memperkirakan pilihan pengguna kami yang pada gilirannya memberikan pengalaman aplikasi yang sangat personal.
Tugas membangun Fynd 2.0 diberikan kepada tim #Reco yang direkayasa berdasarkan pilar skala, integrasi berkelanjutan, otomatisasi, adaptasi.
Mari kita jelaskan desain sistem dan aliran data antar komponen yang melayani personalisasi dalam skala besar.
Desain Sistem & Aliran Data
Pemeta Aliran
Mesin penilaian untuk mempelajari memori jangka pendek dari perilaku pengguna
Input dasar yang diperlukan untuk algoritme rekomendasi adalah peringkat pengguna untuk produk yang berinteraksi dengan mereka (produk dilihat, ditambahkan ke daftar keinginan, ditambahkan ke keranjang, dilihat merek, dilihat kategori, dilihat koleksi). Mengambil setiap peringkat produk adalah proses yang sangat rumit. Bahkan peringkat ini tidak akan cukup untuk kami gunakan, jadi daripada merusak pengalaman pengguna kami, kami mengandalkan peringkat implisit data clickstream. Dengan memanfaatkan integrasi webhook Segmen, Stream Mapper menangkap peristiwa clickstream dan membuat memori pengguna untuk permintaan pengguna berikutnya.
Scoring Engine melakukan pembelajaran berbobot dari semua peristiwa berbeda yang memberikan skor lebih tinggi untuk interaksi lebih dalam.
Peringkat implisit adalah fungsi dari jenis peristiwa, total kejadian, properti peristiwa, dan peluruhan waktu dari kunjungan terakhir ke aplikasi.
Untuk menilai properti peristiwa di dalam memori pengguna, kami menambah atau mengurangi besaran variabel fitur merek, kategori, koleksi, kisaran harga dengan kriteria tertentu.
Which has these variables, del_behavior = change in user preference while y = matching flag, 1 if event attrb. matched with user memory else 0 del_t = time day since last visit max_t = maximum time duration for score w_i = weight of event i score = previous calculated score for event property - brand, category or collection
Untuk menilai atribut properti ini, kami telah menggunakan algoritma FyndRank yang dibuat oleh #Reco-team (terinspirasi dari EdgeRank dari Facebook). Penilaian memastikan nilai fitur tetap dalam rentang yang telah ditentukan jika tidak, kami akan menormalkan skor dengan metode min-maks.
Selain menghasilkan memori pengguna, Stream Mapper juga menghitung kesamaan antara merek dan koleksi yang juga dapat direkomendasikan kepada pengguna. Untuk menghitung skor kesamaan antar merek, pengumpulannya mengambil informasi meta dari Reactive Grid dan menyiapkan vektor fitur untuk diproses.
Feature vectors for brand and collection Brand = [category, price_range ,gender ,discounts,...] Collection = [brand, category, price_range, gender ,discounts, ...] Calculate similarity scores with cosine measure between [0,1] sim(BH, DZ) = 0.9 (similar brands) sim(BH, FS) = 0.1 (dis-similar brands)
Saluran
ML Pipeline untuk menghasilkan preferensi pengguna berdasarkan memori pengguna.
Pipeline mengandalkan pemfilteran kolaboratif dan pemfilteran konten untuk menghasilkan konten umpan dinamis yang dikurasi sesuai preferensi pengguna. Dengan bantuan skor afinitas yang dihitung di Stream Mapper, Pipeline memprediksi pengaruh antara merek, kategori, dan koleksi bagi pengguna serta peringkat untuk menghasilkan konten halaman dinamis.
Perlu diperhatikan bahwa pengguna akan melihat produk fesyen yang mereka minati sesuai dengan urutan skor relevansi yang menurun.
Dengan bantuan algoritme FyndRank, kami secara dinamis menghasilkan konten rekomendasi berbasis gender untuk berbagai bagian aplikasi — Untuk Anda, Merek, dan Koleksi. Bagian Untuk Anda dibuat dengan berbagai jenis rekomendasi produk.
Untuk Anda = Pilihan + Rekomendasi + Trending + Unggulan
Untuk menjaga keterlibatan pengguna dan lebih mendorong mereka untuk menjelajahi lebih banyak produk yang mereka minati dalam Merek, Kategori, dan Koleksi, kami telah mulai menggunakan sumber konten umpan baru. Pilihan berisi konten umpan berdasarkan preferensi peringkat pengguna. Rekomendasi adalah Kemiripan Item berdasarkan konten untuk Merek, Kategori, dan Koleksi.Trending adalah konten yang populer di kalangan pengguna. Unggulan adalah ruang untuk produk dari konten bersponsor.
Dengan menentukan parameter yang disesuaikan, kami menjaga keseimbangan ideal antara keragaman, kebaruan, kedalaman, dan cakupan objek inventaris (yaitu Merek, Kategori produk) dengan perkiraan urutan kartu feed baru di halaman Feed, Merek, dan Koleksi. Pipeline mencakup beberapa model ML dengan variasi logika peringkat. Dari semua model tersebut, model penayangan akan dipilih berdasarkan eksperimen yang sedang berjalan di panel eksperimen kami.
Vortex: Mesin Eksperimen
Setelah membangun platform yang sangat dipersonalisasi, kita masih perlu mencari tahu model mana yang berhasil dan mana yang tidak dalam hal penayangan dan konversi saluran. Oleh karena itu, kami membuat Vortex— mesin eksperimen berskala besar untuk melakukan pengujian A/B di seluruh grup pengguna yang ditentukan pengguna. Kami mengontrol berbagai pengaturan aplikasi dan menyajikannya di antara kelompok pengguna yang berbeda.
Pengaturan Aplikasi = Model AI + Urutan Kartu + Teks Kartu + Konten Unggulan
Model AI adalah model yang sangat dapat disesuaikan untuk menilai dan menyensor merek, koleksi, dan kategori. Semakin besar skornya, semakin besar peluang untuk melihat konten teratas di feed produk. Ia memiliki fasilitas untuk menyesuaikan visibilitas merek, koleksi, dan kategori tertentu pada tingkat gender.
Teks Kartu membantu kami mengonfigurasi judul dan subjudul untuk setiap kartu khusus dengan dukungan lanjutan dari template Jinja.
Konten Unggulan memudahkan tim pertumbuhan untuk mempromosikan merek tertentu, koleksi, dan lainnya!
Filosofi inti di balik Vortex adalah menyajikan berbagai model, kartu dalam urutan berbeda untuk segmen pengguna yang berbeda (berdasarkan prakondisi atau persentase yang berbeda), belajar darinya, lalu skalakan untuk melayani semua pengguna.
Jaringan Reaktif
Reactive Grid adalah grafik untuk konten inventaris yang disimpan di dalam Redis.
Konten inventaris disimpan di MongoDB. Di sisi infra, tantangan utama kami adalah menyajikan konten yang dipersonalisasi kepada setiap pengguna dengan sangat cepat (‹40 md) pada lalu lintas yang sangat tinggi. Sesuai preferensi pengguna (dihasilkan oleh Pipeline), semua kueri db menjadi lebih dinamis dan kompleks sehingga membutuhkan waktu lebih lama untuk merespons. Untuk mendapatkan keluaran yang konsisten pada beban tinggi, kami menemukan Redis sebagai solusi terbaik. Kami membuat pola grafik id inventaris di Redis yang memungkinkan pengambilan lebih cepat daripada MongoDB. Redis tetap sinkron dengan inventaris dari MongoDB secara real-time sehingga dinamakan Reactive Grid.
# Graph storage format inside Redis Index map r:v1:rgp:AND:b#: ["r:v1:g#women:b#AND:c#143:p#low", …] r:v1:rgp:143:c#: ["r:v1:g#women:b#AND:c#143:p#low", …] r:v1:rgp:low:p#: ["r:v1:g#women:b#AND:c#143:p#low", …] r:v1:rgp:women:g#: ["r:v1:g#women:b#AND:c#143:p#low", …] Redis graph map r:v1:g#women:b#AND:c#143:p#low: [123, 1243, 3214, 654 …] (item ids) r:v1:g#women:b#AND:c#178:p#low: [989, 465, 216, 852 …]
Dari preferensi pengguna, pertama-tama kami memilih id konten yang disajikan dari Reactive Grid dan kemudian kami mengambil informasi meta untuk id yang dipilih dari MongoDB. Awalnya untuk memilih id kami menggunakan panggilan perintah KEYS pada pola Redis. Karena Redis adalah thread tunggal dan perintah KEYS memblokir thread tersebut, perintah berikutnya dimasukkan dalam antrean. Ini menurunkan kinerja server secara signifikan. Untuk mengatasi hal ini, kami membuat keranjang indeks pola grafik untuk setiap properti di Redis. Dengan menggunakan indeks ini, kami memotong beberapa keranjang properti untuk mengetahui kunci mana yang akan diakses dari Reactive Grid.
Sebelum beralih ke produksi, kami melakukan beberapa uji beban di server untuk menemukan waktu respons API sekitar 100 md, sangat tinggi dari tolok ukur kami yang 40 md. Pembuatan profil kode menunjukkan hambatan di MongoDB karena permintaan pencarian yang kompleks dengan banyak koleksi MongoDB. Kami memutuskan untuk membuat lapisan caching untuk menyajikan konten langsung dari Redis, bukan Mongodb. Kami juga membuat mekanisme untuk menyinkronkan cache dengan setiap pembaruan inventaris di MongoDB. Dengan lapisan cache ini,kami dapat menyajikan API rekomendasi dalam waktu kurang dari 40 mdtkbahkan pada lalu lintas puncak.
Poin pengoptimalan utama dari Reactive Grid —
- Gunakan "transaksi" Redis untuk mengurangi koneksi yang dibuat, waktu pemutusan sambungan, dan mengambil data secara massal dari Redis.
- Jangan gunakan perintah KEYS di Redis, mereka memblokir. Gunakan solusi seperti kasus kami, kami menggunakan Pengindeksan menggunakan SET di dalam Redis.
- Alih-alih kueri db langsung, kami menggunakan grafik atau peta untuk menanyakan id dari Redis. Jaga agar lapisan kisi ini tetap sinkron dengan db dengan beberapa waktu tunggu cache.
- Gunakan msgpack untuk operasi decode/encode json, ini lebih cepat dari perpustakaan json biasa.
Dengan upaya teknis yang dilakukan oleh Jigar Dafda, pratik patel, Fahim Sakri dan Amboj Goyal, kami dapat mencapai kontrol menyeluruh atas apa yang disajikan kepada pengguna kami dalam skala besar.
Hasil percobaan awal menunjukkan bahwa kami telah meningkatkan rata-rata tampilan halaman produk per sesi lebih dari 50%. Kami juga berharap dapat meningkatkan metrik lainnya di corong dengan eksperimen di masa mendatang.
Kami akan sangat senang mendengar tanggapan dan saran Anda — silakan kirimkan pesan kepada kami di app[at]gofynd.com atau tinggalkan komentar di bawah.
#HappyFynding #R"tim ramah lingkungan"
