Paieškos funkcionalumas svetainėje – tai viena iš tų dalykų, kuriuos visi naudoja, bet niekas nepastebi, kol ji neveikia. O kai neveikia ar veikia prastai, vartotojai paprasčiausiai išeina ieškoti informacijos kitur. Statistika rodo, kad apie 30% lankytojų naudojasi vidinės paieškos funkcija, o tie, kurie ja naudojasi, yra 2-3 kartus labiau linkę atlikti norimus veiksmus – pirkti, užsiregistruoti ar kitaip įsitraukti.
Problema ta, kad daugelis projektų į site search žiūri kaip į paprastą „pridėk paieškos laukelį ir viskas” funkcionalumą. Realybė kur kas sudėtingesnė. Gera paieška – tai ir technologijų pasirinkimas, ir UX dizainas, ir nuolatinis optimizavimas pagal realius vartotojų poreikius.
Kodėl standartinės CMS paieškos paprastai nepakanka
Daugelis content management sistemų ateina su integruota paieškos funkcija. WordPress turi savo, Drupal – savo, ir taip toliau. Problema ta, kad šios paieškos dažniausiai remiasi paprastomis SQL LIKE užklausomis, kurios veikia tik su labai paprastais scenarijais.
Įsivaizduokite situaciją: vartotojas ieško „nešiojamo kompiuterio”, bet jūsų produkto aprašyme parašyta „laptop”. Arba atvirkščiai. Arba jis padaro rašybos klaidą ir parašo „nešiojamo komputerio”. Standartinė SQL paieška tiesiog nieko nerastų. O juk tai visiškai natūralūs scenarijai, kurie vyksta kiekvieną dieną.
Be to, tokios paieškos paprastai neturi jokio relevance scoring – rezultatai grąžinami tiesiog chronologine tvarka arba pagal ID. Tai reiškia, kad dokumentas, kuriame ieškomas žodis paminėtas vieną kartą kažkur pabaigoje, gali būti rodomas aukščiau nei tas, kuriame šis žodis yra pavadinime ir paminėtas dešimt kartų.
Elasticsearch ir kitos dedicated paieškos sistemos
Kai projektas pradeda augti ir paieška tampa kritine funkcija, laikas žiūrėti į specializuotas paieškos sistemas. Elasticsearch čia yra beveik industrijos standartas, nors yra ir alternatyvų – Solr, Algolia, Meilisearch ir kitos.
Elasticsearch privalumai akivaizdūs: full-text paieška su relevance scoring, faceted search (filtravimas pagal kategorijas), typo tolerance, synonym support, multi-language support. Bet svarbiausia – greitis. Net su milijonais dokumentų, paieška vyksta per milisekundes.
Praktinis implementavimo pavyzdys su Elasticsearch būtų maždaug toks: pirmiausia reikia sukurti indeksą su tinkamu mapping’u. Čia svarbu gerai apgalvoti, kokius laukus indeksuosite ir kaip:
PUT /products
{
"mappings": {
"properties": {
"title": {
"type": "text",
"analyzer": "standard",
"fields": {
"keyword": {
"type": "keyword"
}
}
},
"description": {
"type": "text",
"analyzer": "standard"
},
"category": {
"type": "keyword"
},
"price": {
"type": "float"
}
}
}
}Pastebėkite, kad title laukas turi ir text, ir keyword tipus. Text naudojamas full-text paieškai, o keyword – tiksliam atitikimui ir rūšiavimui. Tai labai dažnas pattern’as.
Bet Elasticsearch turi ir minusų. Tai resource-intensive sistema – reikia nemažai RAM ir CPU. Taip pat reikia papildomos infrastruktūros – dar vieno serverio ar bent konteinerio. O jei norite high availability, reikės cluster’io su keliomis node’ais. Tai didina ir kompleksiškumą, ir kaštus.
Modernios cloud-based alternatyvos
Jei nenorite tvarkytis su infrastruktūra, yra keletas puikių cloud-based sprendimų. Algolia yra vienas populiariausių – jie specializuojasi būtent į greitą, relevantišką paiešką su puikiu developer experience.
Algolia didžiausias privalumas – tai instant search. Rezultatai atsinaujina kiekvienu klavišo paspaudimu, be jokio lėtėjimo. Jie turi puikias klientines bibliotekas React, Vue, vanilla JS. InstantSearch.js biblioteka leidžia sukurti pilnai funkcionalią paieškos sąsają per kelias valandas.
Štai kaip atrodo bazinė Algolia integracija:
const searchClient = algoliasearch(
'YOUR_APP_ID',
'YOUR_SEARCH_API_KEY'
);
const search = instantsearch({
indexName: 'products',
searchClient,
});
search.addWidgets([
instantsearch.widgets.searchBox({
container: '#searchbox',
}),
instantsearch.widgets.hits({
container: '#hits',
templates: {
item: `
<h3>{{title}}</h3>
<p>{{description}}</p>
`
}
})
]);
search.start();Problema su Algolia – kaina. Jie skaičiuoja pagal search operations skaičių, ir kai projektas auga, sąskaitos gali tapti gana didelės. Bet jei turite e-commerce projektą, kur konversija tiesiogiai priklauso nuo paieškos kokybės, investicija dažnai atsipirksta.
Typesense – tai open-source alternatyva, kuri pozicionuojasi kaip lengvesnė ir pigesnė Algolia alternatyva. Galite ją self-host’inti arba naudoti jų cloud. Performance panašus į Algolia, bet funkcionalumo kiek mažiau. Tačiau daugumai projektų to pakanka.
Relevance tuning – svarbiausias, bet dažniausiai ignoruojamas aspektas
Galite turėti geriausią paieškos technologiją pasaulyje, bet jei rezultatai nerelevantūs, vartotojai vis tiek bus nepatenkinti. Relevance tuning – tai procesas, kai derinsite, kaip paieška vertina ir rūšiuoja rezultatus.
Pirmiausia reikia suprasti, kad ne visi laukai yra vienodai svarbūs. Jei ieškomas žodis randamas produkto pavadinime, tai kur kas svarbiau nei jei jis randamas aprašymo pabaigoje. Elasticsearch tai galite pasiekti su boosting:
{
"query": {
"multi_match": {
"query": "laptop",
"fields": [
"title^3",
"description^1",
"category^2"
]
}
}
}Čia title laukas turi 3x boost’ą, category – 2x, o description – 1x (default). Tai reiškia, kad atitikimas title lauke bus vertinamas tris kartus svarbesniu nei aprašyme.
Bet kaip žinoti, kokius boost’us naudoti? Čia reikia analytics. Stebėkite, ką žmonės ieško, į kokius rezultatus spaudžia, o kurių ignoruoja. Jei matote, kad žmonės ieško „laptop”, gauna 10 rezultatų, bet spaudžia tik į 7-ą, tai signalas, kad kažkas ne taip su relevance.
Google Analytics arba bet kokia kita analytics platforma gali padėti, bet dar geriau – naudokite specialized search analytics. Algolia turi integruotą, Elasticsearch galite naudoti su Kibana, arba yra atskiri įrankiai kaip SearchIQ.
Typo tolerance ir synonymai – būtinybė, ne prabanga
Žmonės daro klaidų. Daug klaidų. Ypač mobiliuose įrenginiuose. Jei jūsų paieška negali susidoroti su „nešiojamas kompiuteris” -> „nešiojamas komputeris”, prarandate potencialių konversijų.
Elasticsearch turi fuzzy search, kuris leidžia tam tikrą kiekį klaidų. Galite jį įjungti taip:
{
"query": {
"match": {
"title": {
"query": "nešiojamas komputeris",
"fuzziness": "AUTO"
}
}
}
}Fuzziness „AUTO” automatiškai parenka tolerancijos lygį pagal žodžio ilgį. Trumpiems žodžiams leidžia mažiau klaidų, ilgiems – daugiau. Tai veikia gerai daugeliu atvejų.
Bet fuzzy search nepadės su sinonimais. Jei vartotojas ieško „laptop”, o jūs naudojate „nešiojamas kompiuteris”, tai ne rašybos klaida – tai tiesiog skirtingi žodžiai tam pačiam daiktui. Čia reikia synonym dictionary.
Elasticsearch galite sukurti custom analyzer su synonym filter:
PUT /products
{
"settings": {
"analysis": {
"filter": {
"synonym_filter": {
"type": "synonym",
"synonyms": [
"laptop, nešiojamas kompiuteris, nešiojamasis",
"smartphone, išmanusis telefonas, mobilus"
]
}
},
"analyzer": {
"synonym_analyzer": {
"tokenizer": "standard",
"filter": ["lowercase", "synonym_filter"]
}
}
}
}
}Sinonimų sąrašas turėtų būti kuriamas remiantis realiomis paieškos užklausomis. Pradėkite su akivaizdžiais sinonimais, paskui papildykite pagal tai, ką matote analytics.
UX aspektai – paieška yra ne tik backend
Techniškai puiki paieška gali būti visiškai nenaudojama, jei UX prastas. Paieškos laukelis turi būti lengvai pastebimas – dažniausiai viršutiniame dešiniajame kampe arba centre, header’yje. Mobiliuose įrenginiuose dažnai naudojama paieškos ikona, kuri išskleidžia pilną laukelį.
Autocomplete arba instant search yra beveik būtinybė šiuolaikinėje paieškoje. Vartotojai tikisi matyti rezultatus jau rašydami, ne tik paspaudę „Search”. Tai ne tik patogiau – tai dar ir padeda vartotojams suformuluoti užklausas, matant, kokie rezultatai atsiranda.
Bet autocomplete reikia implementuoti protingai. Nereikia rodyti rezultatų po kiekvieno simbolio – tai ir per daug request’ų, ir per daug vizualinio triukšmo. Dažniausiai naudojamas debouncing – laukiama 200-300ms po paskutinio klavišo paspaudimo prieš siunčiant užklausą.
Štai paprastas debouncing pavyzdys su JavaScript:
let debounceTimer;
const searchInput = document.getElementById('search');
searchInput.addEventListener('input', (e) => {
clearTimeout(debounceTimer);
debounceTimer = setTimeout(() => {
performSearch(e.target.value);
}, 300);
});Rezultatų puslapyje svarbu rodyti ne tik rezultatus, bet ir kontekstą. Highlight’inkite ieškotus žodžius rezultatuose. Rodykite, kiek iš viso rezultatų rasta. Jei rezultatų nėra, pasiūlykite alternatyvų – gal panašių produktų, gal pataisytą užklausą.
Faceted search (filtravimas) yra kritinis e-commerce projektams. Vartotojas ieško „laptop”, gauna 500 rezultatų – per daug. Bet jei gali filtruoti pagal kainą, gamintojų, ekrano dydį, tuomet greitai susiaurins iki kelių tinkamų variantų.
Performance optimizavimas ir caching strategijos
Net su greitu paieškos engine, reikia pagalvoti apie performance. Jei kiekvienas klavišo paspaudimas instant search metu siunčia užklausą į serverį, tai gali tapti problema su dideliu traffic’u.
Pirmasis lygis – client-side caching. Jei vartotojas ieško „laptop”, paskui ištrina raidę ir vėl parašo, nereikia siųsti naujos užklausos – rezultatai jau yra cache. Galite naudoti paprastą JavaScript object kaip cache arba kažką sudėtingesnio kaip IndexedDB ilgalaikiam cache.
Server-side taip pat galima cache’inti populiarias užklausas. Redis čia puikiai tinka. Bet būkite atsargūs – jei cache per ilgai, vartotojai gali nematyti naujų produktų ar atnaujinimų. Dažniausiai 5-15 minučių TTL yra geras balansas.
Elasticsearch turi savo query cache, bet jis veikia tik su filter context, ne su query context. Tai reiškia, kad jei naudojate tuos pačius filtrus (pvz., category:laptops), jie bus cache’inti, bet pilnos text užklausos – ne.
Dar vienas svarbus aspektas – pagination vs infinite scroll. Pagination yra lengvesnis backend’ui – tiesiog LIMIT ir OFFSET. Bet infinite scroll dažnai geresnis UX, ypač mobiliuose įrenginiuose. Tik reikia implementuoti protingai – naudoti cursor-based pagination vietoj offset-based, nes offset tampa lėtas su dideliais datasets.
Kai paieška tampa strateginiu įrankiu
Gera paieška – tai ne tik techninis funkcionalumas, bet ir verslo įrankis. Analytics iš paieškos gali atskleisti daug įdomių dalykų apie jūsų vartotojus. Ką jie ieško? Ko nerandate? Kokie terminai populiariausi?
Jei matote, kad daug žmonių ieško kažko, ko neturite, tai signalas produkto ar content komandai. Gal reikia naujo produkto? Gal reikia straipsnio ta tema?
Personalizacija – kitas lygis. Jei žinote vartotojo istoriją, galite pritaikyti paieškos rezultatus. Jei jis dažniausiai perka elektronikos prekes, galite boost’inti elektronikos kategorijos rezultatus. Bet čia reikia būti atsargiems su privacy – būtinai informuokite vartotojus ir leiskite opt-out.
A/B testavimas su paieška gali duoti įdomių insights. Testuokite skirtingus boost’us, skirtingas synonymų strategijas, skirtingus UI variantus. Matuokite ne tik click-through rate, bet ir conversion rate – galiausiai tai ir yra svarbiausias metricas.
Paieška taip pat gali būti monetizuojama – sponsored results arba promoted products. Bet čia reikia balanso – jei per daug komercializuosite paiešką, vartotojai praras pasitikėjimą. Amazon tai daro gerai – aiškiai pažymi sponsored rezultatus, bet jie vis tiek relevantūs užklausai.
Galiausiai, site search nėra „set and forget” funkcionalumas. Tai gyvas organizmas, kurį reikia nuolat prižiūrėti, optimizuoti, tobulinti. Stebėkite metricas, klausykite vartotojų feedback, testuokite naujus dalykus. Gera paieška gali būti jūsų konkurencinis pranašumas – ypač jei konkurentai vis dar naudoja tą default WordPress paiešką, kuri nieko nerastų, net jei ieškotumėte tikslaus produkto pavadinimo.