Az ajánló rendszerek értékelése: Válassza ki a legjobbat a vállalkozása számára

Az e-kereskedelem és az online média végtelen kibővítésével együtt az elmúlt években egyre több szoftver-szolgáltatásként (SaaS) ajánlórendszer (RS) válik elérhetővé. 5 évvel ezelőtt ellentétben, amikor az RS-ek használata nagyvállalatok kiváltsága volt, amikor saját RS-t építenek be, és óriási költségvetést költenek adattudósok csoportjára, a SaaS megoldások mai népszerűsége miatt megfizethető az ajánlás használata még kis- és középvállalkozások számára is. méretű vállalatok. Az a kérdés, amellyel szembesülnek az ilyen vállalatok műszaki szolgáltatói, amikor a megfelelő SaaS RS-t keresik: Melyik a legjobb megoldás? Feltételezve, hogy még mindig nincs RS, vagy nem elégedett a jelenlegi RS-szel, melyik megoldást kell választania?

Ebben a cikkben két megközelítést tárgyalok:

  • Offline értékelés az akadémiai világban (plusz a Netflix-díj), alacsony előrejelzési hibák keresése (RMSE / MAE) és magas Recall / Catalog lefedettség. TLDR; csak tudja, hogy ezek az intézkedések léteznek, és valószínűleg nem akarja őket használni. De mégis röviden összefoglalom azokat, ha érdekli.
  • Online értékelés az üzleti világban, magas ügyfél-élettartam-értékek (CLV) keresése, A / B-tesztelés, CTR, CR, ROI és QA. Olvassa el ezt a részt, ha komolyan fontolja meg a vállalkozását fellendítő ajánlásokat.

Offline világ = Hogyan csinálják az akadémikusok?

Az RS-ket évtizedek óta vizsgálják a tudományos kutatás során. Számos olyan kutatási cikk található, amelyek különféle algoritmusokat vezetnek be, és az algoritmusok összehasonlíthatóságának érdekében akadémiai méréseket használnak. Ezeket az intézkedéseket offline intézkedéseknek nevezzük. Nem tesz semmit a termelésbe, csak játszani kell a homokozóban lévő algoritmusokkal, és ezeket az intézkedéseket finomítani kell. Személyesen sokat kutattam ezeket az intézkedéseket, de a mai szempontból inkább őskori. De még a középkorban, a híres Netflix-díjjal, 2006-ban is, az RMSE nevű, tisztán akadémiai mércét használták (gyökér átlag négyzet hiba).

Annak érdekében, hogy röviden elmagyarázzuk annak működését, feltételezi, hogy a felhasználók kifejezetten értékelik az Ön termékeit, mondjuk csillagszámmal (1 = erős nem tetszik, 5 = erős, mint tetszik), és van egy csomó ilyen minősítésük (rekordok, amelyek szerint a felhasználó A Y csillagokkal) a múltból. A split validációnak nevezett technikát használják: ezeknek a besorolásoknak csak egy részhalmazát vesszük, mondjuk 80% -ot (vonatnevezésnek nevezzük), felépítjük az RS-t, majd felkértük az RS-t, hogy előre jelezze a 20% -on a rejtett (a tesztkészlet). És így előfordulhat, hogy egy tesztfelhasználó valamelyik elemet 4 csillaggal osztályozta, de az Ön modellje előrejelzi a 3,5-et, tehát 0,5-es hibával rendelkezik ezen besorolásnál, és pontosan ez az, ahonnan az RMSE származik. Ezután csak kiszámítja a teljes tesztkészlet hibáinak átlagát egy képlet segítségével, és a végső eredmény 0,71623. BINGÓ! Így jó (vagy pontosabban rossz) az RS. Vagy használhat különféle képletet is, és megkaphatja a MAE-t (átlagos abszolút hiba), amely nem sújtja a hatalmas hibákat (valódi 4 csillag, előrejelzett 1 csillag), így csak 0,6134-et kaphat.

Egy apró hátránya az, hogy ilyen adat szinte nem létezik a való világban, vagy legalábbis túl kevés ilyen.

A felhasználók túl lusták és nem értékelnek semmit. Csak nyitnak egy weboldalt, és ha tetszik az, amit látnak, vásárolhatják / fogyaszthatják; ha szar, elmennek olyan gyorsan, ahogy jöttek. Tehát a web-szerver naplójában vagy a vásárlások adatbázisában csak az úgynevezett implicit besorolások vannak, és nem tudja megmérni a csillagok számának hibáját egyszerűen azért, mert nincsenek csillagok. Csak +1 = a felhasználó megtekintett egy részletet vagy vásárolt egy terméket, és általában semmi mást. Ezeket néha egységes besorolásoknak hívják, amelyeket a Facebook „Tetszik” gombjából tudhat meg: az értékelés vagy pozitív, vagy ismeretlen (a felhasználó csak nem tudja, hogy a tartalom létezik).

Az ilyen adatokra még a split-érvényesítést is használhatja, még a SaaS-ajánlások saját offline összehasonlításához is. Tegyük fel, hogy példaként veszi be a vásárlási adatbázist, beküldi az RS-re a 80% -ot használó felhasználók előzményeit, majd minden tesztfelhasználó számára csak néhány vásárlást nyújt be, és kéri az RS-t, hogy előre jelezze a többit. Lehet, hogy 4 vásárolt tárgyat elrejtett, és 10 terméket kér az RS-től. 0%, 25%, 50%, 75% vagy 100% pontosságot kaphat a felhasználó számára, attól függően, hogy hány rejtett 4 jelenik meg az ajánlott 10-ben. És ezt a pontosságot hívjuk visszahívásnak. Átlagolhatja az egész tesztkészlet és a TADAAA között! Eredménye 31,4159%, tehát milyen jó az RS.

Most őszintén szólva: bár a visszahívás sokkal épesebb, mint az RMSE, még mindig sok fájdalmat okoz. Tegyük fel, hogy egy tesztfelhasználó ugyanazon TV-sorozat 20 epizódját nézte, és a visszaemlékezést mérjük rajta. Tehát elrejti a 18–20. Epizódot, és felkéri az RS-t, hogy jósolja meg őket az 1–17. Ez elég könnyű feladat, mivel az epizódok szorosan kapcsolódnak egymáshoz, tehát 100% -osan visszahívja őket. Most felfedezte a felhasználó valami újat? Egyáltalán szeretné ajánlani neki egy ilyen tartalmat? És mi hozza neked a legmagasabb üzleti értéket? Mondja el az online áruházban, hogy javasol alternatívákat vagy kiegészítőket? Úgy kell éreznie, hogy egy nagyon vékony jégre megy visszahívással.

És még egy titkot elmondok neked: Bizonyos esetekben (nem mindig az üzleti vállalkozástól függ!) Méltányos stratégia, ha csak a világszerte legnépszerűbb termékeket (például bestsellereket) ajánlja az ésszerű visszahívás elérése érdekében. Tehát itt jön a Katalógus lefedettség. Szeretné, ha a felhasználók továbbra is új és új tartalmakat fedezzenek fel, hogy hűek maradjanak? Akkor érdemes javasolni a lehető legtöbb különféle elemet. A legegyszerűbb esetben a katalógus lefedettségének kiszámításához vegye be a tesztfelhasználókat, kérjen ajánlást mindegyikükhöz, és tegye össze az összes ajánlott tételt. Nagyszámú különféle terméket kap. Ossza el a készlet méretét a teljes katalógusban szereplő cikkek számával, és így kapsz: 42,125%! Ez a cikk azon része, amelyet az RS bármikor tud ajánlani.

Most fontolja meg a bestseller modellt. Lehet, hogy elég jó visszahívást mutat, de szinte nulla lefedettség (5 állandó elem?). És vegyen egy véletlenszerű ajánlót. Szinte nulla visszahívással és 100% -os lefedettséggel rendelkezik. Lehet, hogy kompromisszumot szeretne.

A fenti kép az eredeti (ma nagyon elavult) eredeti kutatásomból származik. Körülbelül 1000 különféle RS modell látható a Recall-Coverage síkban. Geeky, nem igaz? :) szédülhet a legjobbakat választva, de remélem érzi, hogy jó választás lenne a jobb felső sarokból („Pareto-optimális front”).

Az offline becslés még robusztusabbá tétele érdekében a split-érvényesítés helyett kereszt-validációt (Xval) használhat. Csak ossza meg a felhasználókat 10 mappába, és lépjen be a hurokba: mindig készítsen 9 hajtást a modell felépítéséhez, és a fennmaradó 1 hajtást használja az érvényesítéshez. Átlagolja az eredményeket ezen 10 futtatás során.

Most azt mondhatnád: Mi van a vállalkozással? A visszahívás és a lefedettség mérése rendben lehet, de hogyan kapcsolódnak a KPI-khoz?

És igazad van. Ahhoz, hogy a SaaS RS-t az X-tengelyre, a $ $ $ -ot az Y-tengelyre tegyük, el kell hagynunk az offline világot és bele kell lépnünk a produkcióba!

Online világ: kövesse az intelligens CTO-k példáit

A fenti szakasz az RS minőségének méréséről szólott, még mielőtt a gyártásba kerülne, itt az ideje, hogy beszéljünk az üzleti KPI-kről.

Míg az offline értékelésben általában a split-validációt használjuk, az online értékelés során az A / B-tesztelés (vagy többváltozós tesztelés) a mai legjelentősebb megközelítés. Integrálhat néhány különféle RS-t, megoszthatja felhasználóit csoportokba és harcolhat az RS-kkel. Kicsit költséges, mert elhasználja a fejlesztési erőforrásokat, így az integráció becsült nehézségeit és a jövőbeni testreszabási / kiigazítási költségeket használhatja az egyik intézkedésként, amely a priori csökkentheti a jelöltek körét.

Tegyük fel most, hogy készen áll az integrációra, és meg tudja osztani online felhasználóit A / B-teszt csoportokra. Használhatja saját UID-cookie-jaik kiosztását, vagy használhat ehhez valamilyen eszközt (például a VWO, az Optimizely vagy akár a GA, bár az utolsó lehetőség kissé fájdalmas). A kísérlet elvégzéséhez meg kell határoznia a webhelyén / alkalmazásában egy jó helyet, ahol tesztelheti az ajánlásokat, mivel biztosan nem akarja a kísérleti szakasz elején teljes mértékben integrálni az összes jelölt RS-t, ugye? Ha kis forgalom van, ne feledje, hogy a kiválasztott helynek elég láthatónak kell lennie a jelentős eredmények gyűjtéséhez. Ellenkező esetben, ha hatalmas forgalommal rendelkezik, akkor választhat egy konzervatív stratégiát, amely például a forgalomnak csak 20% -át engedi a teszteléshez, miközben biztonságban tartja magát és a többi 80% -ot abban az esetben, ha az RS jelölt valamelyikének lenne teljesen megtört, és furcsa dolgokat ajánlhat.

Tegyük fel, hogy az egész működik és működik. Mit kell mérni? A legegyszerűbb intézkedések az ajánlások átkattintási aránya (CTR) és az átváltási arány (CR).

Megjelenített N-ajánlás-sorozat 20-szor, ebből 3-szor a felhasználó kattintott legalább az egyik ajánlott elemre? Akkor a CTR 15%. Valójában a kattintás jó, de valószínűleg ez a felhasználót egy részletes oldalra vezette, és érdemes tudni, mi történt ezután. Valóban érdekesnek találta a felhasználót a tartalom? Nézte az egész videót, hallgatta az egész dalt, olvasta az egész cikket, válaszolt a munka ajánlatára, betette a terméket a kosárba, és megrendelte? Ez az átváltási arány = azoknak az ajánlásoknak a száma, amelyek mind az Ön, mind a felhasználó számára boldoggá tették.

Példa: Adja meg a KPI konzolt

A CTR és a CR jó becslést adhat az ajánló teljesítményére, ám legyen óvatos, és mindig gondolkodjon a termékén. Lehet, hogy egy hírportált üzemeltet, és a legfrissebb híreket helyezte a honlapra. Lehet, hogy ez nem biztosítja a lehető legmagasabb CTR-t, de fenntartja a minõséget és az érzést, hogy Ön és a felhasználók a szolgáltatásod iránt. Most elhelyezhet egy RS-t, és előfordulhat, hogy más tartalmat jelenít meg, például sárga újságírási cikkeket vagy vicces cikkeket a “nagyon gyors kutyákról, amelyek hihetetlen hihg sebességgel futnak”. Ez ötszörösére növelheti az Ön közvetlen CTR-jét, de rontja a képet, és hosszú távon elveszítheti felhasználóit.

Itt jön az RS empirikus értékelése. Csak kezdjen el egy új munkamenetet üres sütikkel, szimulálja a felhasználó viselkedését és ellenőrizze, hogy az ajánlások ésszerűek-e. Ha van QA csapata, hívja meg őket a munkára! Az empirikus értékelés egyszerre bonyolult és egyszerű. Bonyolult, mert nem hoz létre olyan számot, amelyet a terméktáblán megjeleníthet. De ez is könnyű, mert emberi intuíciójának köszönhetően egyszerűen felismeri, mely ajánlások jók és melyek rosszok. Ha furcsán működő ajánlót választ, akkor sok jövőbeli bajba kerül, még akkor is, ha a CTR / CR jelenleg magas.

Természetesen a minőség mellett a befektetés megtérülését is érdekelnie kell.

Egyszerűen fogalmazva megállapíthatta, hogy az 1. / A / B-tesztelési hajtás az átváltási arány X% -ának növekedését eredményezi a 0. alaphajláshoz képest (a jelenlegi megoldás), hogy az átlaga Y $ volt az átlagos sikeresen ajánlott tételnél, és hogy ennek eléréséhez Z ajánlási kérelmekre volt szükség. Hajtsa végre a matematikát, tervezze meg a költségeket / jövedelmeket arra az esetre, ha a forgalom 100% -át az adott RS-re állítja, integrálva a webhely / alkalmazás egyéb szakaszaiba is.

Egy figyelmeztetés a ROI kiszámításáról: Nagyon homályos és nagyszámú ismeretleptől függ: Vajon a CR ugyanaz lesz-e a webhelyem / alkalmazás más helyein? (Egyszerű válasz = nem, nem fog, a különböző helyek eltérő CTR / CR értékkel rendelkeznek). Hogyan változik a CR, ha az ajánlásokat többé-kevésbé vonzó helyzetbe helyezi? (Egyszerű válasz = nagyon sok). Hogyan alakul a CR idővel? Megtanulják-e a felhasználók használni és megbízni az ajánlást, vagy a CR visszautasul?

Ez a végső, de legnehezebb mértékhez vezet: az ügyfelek élettartamának értékéhez (CLV). A win-win helyzetet keresi. Azt szeretné, ha a felhasználók szeretik a szolgáltatást, kényelmesek, boldogok és visszatérőek. Ezzel együtt azt szeretné, hogy az RS javítsa az UX-t, segítse a felhasználókat érdekes tartalmak / termékek megtalálásában, amit szeretnek. Hogyan lehet elérni a magas CLV-t RS segítségével?

Nos, itt nincs egyszerű tanács. Kedves ajánlásokat kell keresnie, magas empirikus minõséggel és ésszerûen pozitív ROI-val. Tapasztalataim szerint az ajánlások finomsága általában megfelel az üzleti értéknek, így megakadályozzuk, hogy a QA csapata / vezérigazgatója panaszt küldjön. És ha megfigyeli, hogy az üzleti helyzet pozitív, akkor megtalálta azt, amit keresett :)

Következtetés

Megpróbáltam lefedni az RS-k értékelésének legfontosabb aspektusait. Láthatta, hogy ez nem könnyű feladat, és még sokat kell fontolóra venni, de remélem, hogy legalább adtak neked néhány nyomot, hogy megtalálják az utat a környéken. Kipróbálhatja az RS-k offline elérését még a termelés megkezdése előtt, vagy elvégezheti a termelés A / B tesztelését CTR / CR és ROI becslésekkel. Mindig tartalmazzon QA-t, mert önmagában a CTR / CR / ROI megtévesztő lehet, és nem garantálja a termék látomásával való kompatibilitást.

Sokat elhagytak, hogy a szöveget hosszú ideig megőrizzék. A CTR / CR / ROI / az ajánlások minőségén túl gyorsan át kell tekintenie a figyelembe vett RS általános képességeit. A jövőben érdemes lehet javaslatokat felvenni az e-mail kampányaiba. Működni fog? Van-e képessége az ajánlások elforgatására, hogy egy adott felhasználó ne kapja meg ugyanazt az ajánlást az egyes e-mailekben? Meg tudja felelni az összes üzleti igényének, befolyásolhatja az ajánlásokat, javíthat bizonyos típusú tartalmakat, szűrheti azokat különféle kritériumok alapján? Ezek olyan témák, amelyekre nem terjed ki, de úgy érzi, hogy meg akarja fontolni őket.

A szerző a COMFE, a kifinomult SaaS ajánlásmotor egyik alapítója.