Viešbučio prieinamumas ir kambarių rekomendacijų algoritmas @ MMT

„MakeMyTrip“ aptarnauja įvairius viešbučių pirkėjus ir padeda jiems baigti rengti planus atsižvelgiant į įvairius jų kelionės tikslus, užimtumą ir informacijos reikalavimus. Atsižvelgiant į tai, du svarbiausi vartotojų poreikiai, kurie turi būti tenkinami visiems, yra vienodi - viešbučio užimtumas ir kambario kaina pagal kiekvieno biudžetą. Šiame tinklaraščio įraše dalijamės keletu įžvalgų, kaip padidinome bendrą viešbučių prieinamumą mūsų platformoje ir panaudojome dinaminį programavimą, kad išspręstume „pigiausio kambarių derinio“ problemą, kad pasiūlymas būtų galingesnis ir naudingesnis klientams.

Pirmiausia supraskime, kodėl viešbučių prieinamumas ir kambarių kainos, ypač pigiausios, yra tokie svarbūs.

Viešbučio prieinamumas: Svarbu parodyti klientui pakankamai viešbučių, kuriuos pasirinkti iš viešbučių sąrašo puslapio. Jei viešbučiai nėra prieinami arba jie yra žemi, daug klientų sumažėja pačiame aukciono puslapyje, todėl gali būti prarasta įmonė.

Kambario kaina: Daugelis keliautojų palygina viešbučio kambarių kainas visose internetinėse kelionių agentūrose (OTA) ir atlieka operaciją su OTA, siūlančia mažiausią kainą. Atsižvelgiant į tai, kad kambariuose su mažiausiomis kainomis užsakoma daug, tampa svarbu parodyti / paryškinti pigiausią kambario kainą viešbučio informacijos puslapyje, kad klientas galėtų greitai priimti sprendimą.

Žemas viešbučio prieinamumas

Problemos atradimas

„MakeMyTrip“ mes registruojame daug duomenų ir reguliariai juos analizuojame, kad gautume realių įžvalgų. Viena iš mūsų naujausių išvadų buvo tai, kad daug viešbučių paieškų viešbutyje nebuvo prieinama arba jo nebuvo viešbutyje. Pirmiausia tam buvo dvi priežastys:

  • Mažiau atsargų sezono metu / ilgus savaitgalius
  • Trūksta norimo užimtumo lygio „MakeMyTrip“ atsargų sistemoje (pvz., Viešbučio savininkas nesukonfigūravo kainų 3 suaugusiesiems)

Paimkime pavyzdį, kad tai suprastume geriau. Žemiau pateiktas apžvalgos vaizdas, kurį viešbučio „X“ sistemoje įkelia viešbučio savininkas (A žymi suaugusįjį, C - vaiką).

1 pav.: Inventoriaus momentinė nuotrauka

Vartotojo paieška 1 (2 kambariai: 1–1A kambarys, 2–1A kambarys) - šiuo atveju, nors turime 3 (nors ir skirtingų tipų) numerius, mes negavome viešbučio laisvų vietų, nes paieškos kriterijus suderinome su kiekvienu kambario tipo ir nė vieno kambario tipo atsargų nebuvo ≥2.

2 vartotojo paieška (1–3A kambarys) - šiuo atveju mes taip pat negavome viešbučių, nes viešbutis nepakonfigūravo aukščiau nurodytų paieškos kriterijų įkainių.

Abiem atvejais buvo būdas įvykdyti vartotojo paieškos kriterijus derinant skirtingos rūšies kambarius. Problema tampa daug sudėtingesnė, nes kiekvienas viešbutis turi savo vaikų amžiaus ribą ir atitinkamas kainas.

Trijų punktų sprendimas

  1. Pakeiskite paieškos kriterijus - nustojome atitikti tikslius vartotojo paieškos kriterijus kiekvienam kambario tipui ir pradėjome paiešką su pakeista paieškos užklausa. Tai ypač daroma ieškant didesnio užimtumo vietų, kur dažniausiai nėra galimybių.
  2. Sukurkite pigiausio kambario derinio algoritmą - mūsų klientams pigiausias pasiūlymas yra geriausias. Norint padėti išspręsti šią ir viešbučių užimtumo problemą, buvo prasminga sukurti algoritmą, kad vartotojams būtų pateiktas pigiausias kambarių (-ų) derinys.
  3. Paprašykite viešbučių savininkų sukonfigūruoti didesnio užimtumo kainas - kadangi 60% vartotojų keliauja vieni ar pora, viešbučių savininkai paprastai optimizuoja įkainius ir atsargas, kad galėtų apsistoti vienviečiai ir dviviečiai. Norėdami padėti klientams gauti geresnius paieškos rezultatus, kai užimtumas> 2, paprašėme viešbučių savininkų sukonfigūruoti visus galimus užimtumo derinius, kuriuos jie palaiko.

Štai kaip mes manėme, kad bendras sprendimas turėtų veikti.

2 pav. Srauto diagrama

(1) ir (2) yra paryškinti žalia spalva. Atsižvelgiant į kanalą, iš kurio vartojamas viešbutis, mes galime turėti arba neturime reikalingos informacijos, kad galėtume paleisti pigiausio kambarių derinio algoritmą. Tokiems atvejams tvarkyti mes sukūrėme keletą papildomų algoritmų reikalingiems duomenims generuoti / numatyti (atsargų skaičius yra vienas iš jų).

Poveikis verslui

Įgyvendinome ir 1, ir 2). Kaip ir buvo galima tikėtis, mūsų užimtumo puslapyje buvo daugiau laisvų viešbučių, kai ieškoma daugiau nei 2 suaugusiųjų. Mes taip pat pradėjome kasdien gauti 5% papildomų kambarių naktų. Apskritai užsakymų, kuriuose yra daugiau nei 2 suaugusieji, skaičius šoktelėjo daugiau nei 50%.

3 pav. Rezervavimo tendencija prieš ir po funkcijos išleidimo

Kompiuteriniai iššūkiai ir požiūris

Pigiausia kambario rekomendacijų problema yra derinio optimizavimo problema.

Atsižvelgiant į N viešbučio kambarius ir P (suaugusiųjų + vaikų) svečius, raskite pigiausią kambarių derinį, kad būtų galima apgyvendinti P svečius.

Norėdami paleisti bet kurį optimizavimo algoritmą, turėjome gauti duomenų atributus, reikalingus:

  • Sukurkite visas įmanomas kambario vietas
  • Apskaičiuokite kainą tokiems atvejams

Tam mes pradėjome vartoti viešbučių ir kambarių lygio atributus, tokius kaip vaiko amžiaus riba, maksimalus suaugusiųjų / vaikų skaičius kambaryje, kiekvieno kambario tipo laisvų vietų skaičius, papildoma kaina suaugusiesiems ir pan. Kiekvienas viešbučio savininkas gali savarankiškai konfigūruoti tarifų duomenis, pvz., Užimtumą. iki kurio jis nekainuos papildomai (bazinis užimtumas), iki kokio vaiko amžiaus jis laikys svečią vaiku, papildomą vaiko kainą, papildomą suaugusiojo kainą, maksimalų suaugusiųjų / vaikų skaičių, kurį galima apgyvendinti kiekviename kambaryje. Visais šiais būdais reikia pasirūpinti kuriant ir apskaičiuojant kiekvieno kambario kainą ir užimtumą. Tvarkydami šiuos atributus, kompiuterinis sudėtingumas tapo daugialypis. Papildomas iššūkis buvo nepažeisti paieškos latencijos. Šie skaičiavimai turi būti atlikti realiu laiku ir pagal užklausą, kuriame yra 200–250 viešbučių.

Nors mes visada galvojome apie dinamišką programavimą, kad išspręstume šią problemą, mes apsvarstėme brutalios jėgos sprendimą ir keletą gobšių metodų, norėdami išsiaiškinti, ar jų užtenka / veikia mūsų naudojimo atvejais.

Brutalios jėgos sprendimas: tai sudarė kiekvieno įmanomo inventoriaus ir visų tarifų planų derinio sukūrimą. Tuomet šie kambariai taip pat turės būti sujungti su skirtingais apgyvendinimo deriniais. Tai lėmė eksponentinį laiko sudėtingumą.

Pav. (4): Brutaliosios jėgos metodas lemia eksponentinį laiko sudėtingumą

Tai buvo įmanoma, tačiau jos negalima pakeisti. Tai taip pat padidins paieškos api vėlyvumą.

Negražūs požiūriai: ištyrėme keletą strategijų, bet kiekvienoje iš jų radome priešingą atvejį. Pagrindinė problema buvo ta, kad neturime kambarių, surūšiuotų pagal kainą ir svečių (svečių) užimtumą. Be to, bet kuris aukštesnio lygio kambarys / liukso kambarys gali priimti daugiau žmonių, palyginti su standartiniu kambariu.

Pigiausias kambarių derinio algoritmas

Leiskite mums suprasti keletą terminų ir žymėjimų, prieš pereidami prie algoritmo.

5 pav. Pigiausio kambario derinio algoritmo terminija

Modeliavome problemą, kaip rasti pigiausią kambarių derinį, aplink labai garsiąją 0–1 kuprinių problemą. Daiktai (N) ir svoriai (W) kuprinių problemoje laisvai atspindi fizinių viešbučio kambarių komplektą ir įvairius galimus užimtumo derinius (pradedant nuo 0 ir vedant iki reikalaujamo užimtumo). Tačiau mūsų atveju buvo keletas unikalių suvaržymų, kuriuos reikėjo specialiai tvarkyti.

  1. Daliniai elementai / virtualūs kambariai: kiekvienas daiktas yra unikalus, turint omenyje 0–1 rankinės problemą, tačiau tai nėra tiesa mūsų atveju. Fizinis kambarys (daiktas) turi būti apsvarstytas atsižvelgiant į visas įmanomas vietas ir tarifus, kad būtų užtikrintas daiktų komplekto unikalumas. Dėl to sukuriami virtualūs kambariai kiekvienam fiziniam kambariui. N, esant problemai 0–1, mūsų atveju iš tikrųjų atitinka virtualių kambarių rinkinį.
  2. Užtikrinti, kad fizinis kambarys būtų naudojamas vieną kartą: Tai yra tiesioginė reikšmė (1). Nors algoritme visiems skaičiavimams ir sprendimams naudojame virtualius kambarius, reikia įsitikinti, kad fizinis kambarys yra naudojamas tik vieną kartą kiekvienam kambarių deriniui, ir kilus konfliktui reikia rasti geriausią alternatyvą.
  3. Krašto atvejai užpildydami likusį užimtumą: Turėjome tvarkyti kelis kraštinius atvejus, remdamiesi jau išspręstomis papildomomis problemomis. pvz. daugelyje viešbučių neleidžiama užsisakyti kambarių su tik vaikais. Taip pat turime tvarkyti atvejus, kai suaugusiųjų užimtumą įvykdėme per virtualų kambarį ir liko tik vaikų užimtumas.

Pagrindiniai algoritmo kūrimo žingsniai

  1. Gaukite transformuotos paieškos užklausos rezultatą.
  2. Sukurkite 2 matmenų matricą T su visais įmanomais kambarių užimtumais stulpeliais (W) ir virtualiais kambariais kaip eilutėmis (N).
  3. Kiekvienoje 2 matmenų matricos ląstelėje mes svarstome dvi galimybes - pasirinkti atitinkamą virtualų kambarį kaip optimaliausio sprendimo dalį arba jį atsisakyti. Mes apskaičiuojame išlaidas, susijusias su tuo virtualiu kambariu ir be jo, ir pasirenkame pigiausią. Kiekvienoje matricos ląstelėje saugomi pagrindiniai kambarių, naudojamų tos ląstelės užimtumui, atributai.

Matrica užpildoma iš apačios į viršų, naudojant žemiau pateiktą pasikartojimo santykį:

Pav. (6): Skaičiavimo formulė

4. Grąžinkite rezultatą, pravažiavę matricą.

Pavyzdys:

7 pav. Informacija apie kambario / tarifo lygį

Aukščiau pateiktiems įvesties parametrams bus sukurta ši 2 dimensijų matrica. Oranžinė stulpelis užfiksuoja kainą, atitinkančią kiekvieną virtualų kambarį pagal viešbučio nustatymus.

Pav. (8): 2D matrica, rodanti įrašus 3 suaugusiems ir 2 vaikams. Null įrašai buvo pažymėti kaip „X“.

Žalia spalva paryškinti langeliai rodo pigiausią kambarių derinį pagal nurodytus paieškos kriterijus. Kambario identifikatoriai, nurodyti ląstelėje, apibūdina, į kuriuos kambarius reikia atsižvelgti, ir jų indeksai nusako kiekvieno kambario užimtumą. Mėlynai paryškinti langeliai naudojami skaičiuojant žalią langelį rekursyviai (naudojant aukščiau minėtą pasikartojimo santykį).

Šis algoritmas gana gerai veikė gaminant, nepaveikdamas mūsų paieškos API 99-ojo procentilio vėlavimo. Net išsaugoję šių rekomendacijų rezultatus, mes vis dar apdorojame maždaug 15 000 unikalių viešbučių derinių kiekvieną minutę.

Ypatinga padėka Ajay Singh ir Abhijeet Sharad už pagalbą rengiant šį tinklaraštį.