> Webshop-keresés mérése: egységes eseményséma, öt mutató célértékekkel, pozícióhatás-korrekció, heti null találatos átnézés és GDPR-korlátok.
>
> Web page: https://balazscsorba.com/hu/blog/shop-search-analytics · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/shop-search-analytics.md) · [Deutsch](https://balazscsorba.com/de/blog/shop-search-analytics.md)
> Author: Balázs Csorba · Published: 2026-10-06 · Keywords: shop search analytics, zero result rate, zero result search queries, site search metrics, search click-through rate position bias, query intent classification LLM, search abandonment rate, synonyms from zero-result queries, interleaving vs A/B testing search, search log retention GDPR

[Blog](https://balazscsorba.com/hu/blog)/Webfejlesztés

# Webshop-keresésanalitika: mit naplózzon, és mely javításokat vezesse be elsőként

Webshop-keresés mérése: egységes eseményséma, öt mutató célértékekkel, pozícióhatás-korrekció, heti null találatos átnézés és GDPR-korlátok.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 6.·10 perc olvasás

-   Search analytics
-   Zero-result search
-   Position bias
-   Search logs
-   GDPR

![Nagyító egy oszlopdiagram mellett, az egyik oszlop üres.](https://balazscsorba.com/images/blog/shop-search-analytics/cover.webp?v=99a845a050)

## A lényeg röviden

-   Minden interakcióhoz naplózzon egy keresési és egy követő eseményt, query\_id-val összekötve, mielőtt bármelyik irányítópultot megnézi.
-   A heti kört a null találatos lekérdezésekkel kezdje: ezek a legolcsóbban megtalálható hibák, és sokuk ismert megoldású szókincsbeli rés.
-   A pozíció szerinti átkattintási arányt úgy olvassa, mint azt, hogy hol landolnak a kattintások, nem mint a relevancia mérőszámát, és a rangsorolási változtatásokat interleave-vel vagy A/B-teszttel próbálja ki.
-   A javítás előtt sorolja be az egyes hibákat katalógus-, szókincs- vagy szándékrésbe, hogy a katalógushibákat ne szinonimákkal foltozza.
-   A munkamenet-azonosítók legyenek álnevesítettek, a megőrzési idő rövid; a keresési naplók személyes adatok, és az elnevezett munkavállalókhoz eljutó naplók Ausztriában az ArbVG 96. §-a alá esnek.

Ezen az oldalon

1.  [Mit javítson először?](https://balazscsorba.com/#what-to-fix-first)
2.  [Mikor téveszt meg a keresésanalitika?](https://balazscsorba.com/#where-search-analytics-usually-fails)
3.  [Mit kell tartalmaznia egy keresési eseménynek?](https://balazscsorba.com/#search-log-schema)
4.  [Melyik öt mutatót kövesse?](https://balazscsorba.com/#core-metrics-and-targets)
5.  [Miért téveszt meg a nyers pozíció szerinti CTR?](https://balazscsorba.com/#position-bias-and-why-raw-ctr-misleads)
6.  [Hogyan csoportosítja a null találatos lekérdezéseket?](https://balazscsorba.com/#classifying-zero-result-queries)
7.  [Hogy néz ki a heti átnézés?](https://balazscsorba.com/#weekly-review-loop)
8.  [Meddig érdemes megőrizni a keresési naplókat?](https://balazscsorba.com/#privacy-and-retention)
9.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A legtöbb webshop azt naplózza, hogy volt keresés. Sokkal kevesebb azt, hogy működött-e. Az a mérés, amely ezt megteszi, egy kör: minden keresés egy eseményt ír a lekérdezéssel, a szűrőkkel, a találatok számával és egy összekötő kulccsal; minden kattintás egy követő eseményt ír, amely erre a kulcsra mutat; és hetente egyszer valaki átnézi azokat a lekérdezéseket, amelyek nem adtak találatot vagy nem kaptak kattintást, és ebből javítást csinál. Ez a cikk ezt a kört írja le: az eseményséma, öt mutató a definíciókkal és az első lépésekkel, a pozícióhatás korrekciója, a hibák csoportosításának módja, és az a korlát, amit érdemes gyűjteni.

A kör nem helyettesíti a lekérdező munkát. Az illesztés, a lekérdezés átírása és a tiszta katalógus határozza meg, mit tud megtalálni a keresés; ezt az oldalt a [B2B szemantikus termékkeresés](https://balazscsorba.com/hu/blog/semantic-product-search-b2b) cikk tárgyalja. Az analitika mutatja meg, melyik problémába ütköznek ténylegesen a vásárlók. Az alábbi mutatódefiníciók az Algolia analitikai termékének dokumentációját követik, az eseményalak pedig a nyílt User Behavior Insights (UBI) specifikációt, így a tervezés nem függ egyetlen szolgáltatótól.

## Mit javítson először?

Először a naplózási hiányosságokat zárja le, utána a null találatos lekérdezéseket, majd a kattintás nélküli kereséseket, és csak ezután a rangsorolást. Minden más szám csak annyit ér, amennyit a mögöttes események, ezért a naplózás az első. A null találatos lekérdezések következnek, mert ezek a legolcsóbban megtalálható hibák, és sokuk ismert megoldású szókincsbeli rés. Egy utólagos bevezetés első két hetében a cél nem egy irányítópult. Az a cél, hogy legyen egy teljes hét eseménye, amelyet exportálni, átnézni és amely alapján cselekedni lehet.

Egy kereséselemzés nélküli webshopnál a következő sorrend működik. Vegyen fel egy keresési és egy kattintási eseményt, amelyek közös query\_id-t használnak. Exportáljon egy hét null találatos lekérdezést, és olvassa át kézzel. Vezessen be három-öt szinonima- vagy átirányítási javítást. Adja hozzá a kattintás nélküli nézetet. Kísérletet csak akkor indítson, ha az alapvonal már néhány hete stabil. Minden lépés önmagában is hasznos, ezért nem kell a teljes műszerezésnek készen lennie ahhoz, hogy valamit megtanuljon.

## Mikor téveszt meg a keresésanalitika?

A keresésanalitika félrevezet, ha a forgalom túl kevés egy különbség megmutatásához, ha egyetlen arányt ítéletként olvasunk, ha figyelmen kívül hagyjuk a szezonalitást, és ha néhány visszatérő szakmai vevőt az összes többivel átlagolunk. Ezek mindegyike gyakori B2B webshopokban, ahol egy kis vevőcsoport gyakran a keresések nagy részét futtatja, cikkszámokkal és mentett kosarakkal.

-   **Túl kevés forgalom.** Az a változtatás, amely egy arányt néhány ponttal mozdít el, variánsonként elég keresést igényel, mielőtt az eredménynek jelentése van. Ha egy kategóriában heti néhány száz keresés van, hetekben számoljon, nem napokban, és fogadja el, hogy egyes kérdések nyitva maradnak.
-   **Az átkattintási arány mint ítélet.** A kattintás érdeklődést jelez, nem sikert. Aki az első találatra kattint, rossz alkatrészt lát, és távozik, az egy kattintást és egy sikertelen keresést hozott létre.
-   **Szezonalitás.** A szezonális áruk vagy a pótalkatrészek null találati aránya a naptárral mozog, ezért az azonos heteket hasonlítsa össze évről évre, vagy a hasonlót a hasonlóval, ne az utolsó hetet egy csendes héttel.
-   **B2B-forgalmi torzítás.** Az ismétlődő vevők, akik cikkszám szerint keresnek, uralhatják az átlagokat. Ahol az adatai engedik, szegmentáljon vevőtípus szerint, mielőtt egy arányt egész webshopra érvényes eredményként olvasna.
-   **Naplók, amelyeket nem érdemes tárolni.** Egyes mezők nem segítik a kört, és jogi kockázatot jelentenek. Az adatvédelmi rész elmagyarázza, melyeket hagyjon ki.

## Mit kell tartalmaznia egy keresési eseménynek?

Egy keresési esemény rögzíti a lekérdezést és azt a kontextust, amelyben futott. Külön események rögzítik, mit csinált a vásárló ezután, a kettőt pedig a query\_id köti össze, amelyet a keresőszolgáltatás minden válaszban visszaad. Az UBI specifikáció nevezi meg azokat a mezőket, amelyek a keresési naplót összekapcsolhatóvá teszik: query\_id, a lekérdezés szövege, a szűrők, az oldal, egy client\_id, amely stabil marad, amikor a látogató névtelenről bejelentkezettre vált, a pozíció a kattintási eseményeken, és az objektumazonosító, például a cikkszám. [Az UBI specifikáció](https://github.com/o19s/ubi) példájában egy cikkszámon történt termékkattintás szerepel. Egy webshop két eseményének vázlata így néz ki:

```
// search event
{
  "query_id": "3f9c0b7e-6d2a-4c1e-9a55-2b8f1d7e4a10",
  "client_id": "c-7b1e44",
  "user_query": { "query": "m8x25 hex bolt a2" },
  "filter": ["in_stock:true"],
  "page": 1,
  "result_count": 0
}

// click event, same query_id
{
  "query_id": "3f9c0b7e-6d2a-4c1e-9a55-2b8f1d7e4a10",
  "client_id": "c-7b1e44",
  "event_attributes": { "position": 3 },
  "object": { "object_id": "SKU-100234", "object_id_field": "sku" }
}
```

A query\_id és a client\_id teherhordó elemek. Nélkülük nem tudja a kattintást ahhoz a kereséshez kötni, amely előidézte, és nem látja, pontosított-e a vásárló ugyanazt a kérdést. A szűrő- és oldalmezők megmutatják, hogy egy null találatos keresés túlszűrt volt-e, ami gyakran a valódi probléma. A pozíció teszi használhatóvá a kattintási adatokat az írás későbbi részében tárgyalt torzításkorrekcióhoz. A két eseménytípust külön táblában tárolja, a nyers lekérdezési szöveget pedig külön oszlopban, hogy az ütemezett törlés az összesítéseket ne veszítse el.

![Műszerezett keresési útvonal Négy lépés balról jobbra: a keresési kérés keresési eseményt ír a lekérdezéssel és a szűrőkkel; a vásárló rákattint egy találatra, a kattintás pedig kattintási eseményt ír ugyanazzal a query_id-val és a pozícióval; a heti export csoportosítja azokat a keresést, amelyek nem adtak találatot vagy nem kaptak kattintást.](https://balazscsorba.com/images/blog/shop-search-analytics/diagram-12.webp?v=010a03f5b5)

Minden keresés és kattintás eseményt ír; a heti export a közös query\_id-val összekötött hibákat csoportosítja.

## Melyik öt mutatót kövesse?

Öt mutató fedi le a kör nagy részét. A definíciók a gyártók megfogalmazását követik, hogy a számai összevethetők legyenek a dokumentációval, és minden sor megnevezi mögötte az eseménymezőt, hogy egy mozgó szám visszavezethető legyen az eseményeire. Az Algolia analitikai fogalmai ugyanezt a nézetcsaládot sorolják fel, köztük az eredmény nélküli és a kattintás nélküli kereséseket, és a heti átnézés ezeknél kezdődik.

Mutató

Definíció (a gyártó megfogalmazásában)

Forrásmező

Viszonyítási pont vagy cél

Első lépés, ha rossz irányba mozdul

Null találatos arány

Az eredmény nélküli keresések aránya (az Algolia no-results rate néven említi)

a `result_count` a keresési eseményen

10–15% átlag, 5% alatti cél ([Hello Retail](https://helloretail.com/en/blog/2026-02-24-ecommerce-search-statistics/))

A hét legnagyobb null találatos csoportjainak átnézése

Átkattintási arány

A követett keresések aránya, legalább egy kattintással; egy keresésen belüli több kattintás egynek számít

a `query_id`, összekötve a kattintási eseményekkel

Nincs nyilvános átlag; saját alapvonal kell

a relevancia hibáztatása előtt nézze meg a kattintási pozíciót

Kattintás nélküli arány

Kattintás nélküli egyedi keresések, osztva az egyedi keresések számával; a CTR-rel együtt nem ad 100%-ot

query\_id, amelyhez nincs kattintás

Nincs nyilvános átlag; saját alapvonal kell

A legnagyobb forgalmú kattintás nélküli lekérdezések átnézése

Pontosítási arány

Azon keresések aránya, amelyeket ugyanabban a munkamenetben ugyanazon kliens újabb lekérdezése követ (saját definíció)

a `client_id` és a `user_query`

Saját alapvonal kell

A pontosított lekérdezéseknél a szinonimákat és az alapszűrőket ellenőrizze

Kattintási pozíció

Az érintett találatok átlagos pozíciója; nyers, nincs torzításkorrekció (az 1, 1, 3 és 10. helyre kattintások átlaga 3,75)

az `event_attributes.position` a kattintási eseményen

Nincs nyilvános átlag

csak az itt leírt torzításellenőrzés után olvassa pozíció szerint

A célértékeknél gyenge a nyilvános bizonyíték. Az egyetlen viszonyítási pont a Hello Retail gyártói tájékoztatása, 2026 februárjából, amely szerint a null találati arány átlagosan a keresések 10–15%-a, a cél pedig 5% alatt van. Ez egy gyártói blogbejegyzés, nem tanulmány, ezért mérési vonalként használja, ne célként. A kattintási és a kattintás nélküli arányokra nincs megbízható nyilvános átlag. Állítsa be a saját alapvonalát négy-hat hét naplóiból, és csak akkor módosítsa, ha egy változtatást már teszteltek.

## Miért téveszt meg a nyers pozíció szerinti CTR?

A nyers kattintási pozíció főként azt írja le, hol álltak a találatok, nem azt, mennyire voltak jók. A vásárlók gyakrabban kattintanak a legfelső találatra, mert az a tetején van. A Google WSDM 2018-as, pozícióhatásról szóló cikke szerint ezeknek a hajlamoknak a találatok véletlenszerűsítésével történő becslése „nem kívánatos, mert a találatok randomizálása negatívan befolyásolhatja a felhasználók keresési élményét”, és ehelyett a szokásos kattintási naplókból javasolja a becslést ([Google Research](https://research.google/pubs/position-bias-estimation-for-unbiased-learning-to-rank-in-personal-search/)).

Az eBay SPIRE 2019-es munkája tovább megy: a kattintási hajlamokat közvetlenül becsli az e-kereskedelmi lekérdezés–dokumentum párokból, amelyek különböző rangokon jelennek meg, élő beavatkozás és relevanciamodell nélkül, az 500. helyig ([arXiv](https://arxiv.org/abs/1812.09338)). A legtöbb webshop nem fogja ezt megépíteni. A gyakorlati szabály egyszerűbb: ne olvasson egy pozíció szerinti CTR-diagramot relevanciadiagramként. Azt lássa belőle, hol koncentrálódnak a kattintások, a rangsorolási változtatásokat pedig olyan módszerrel ítélje meg, amely nem függ a pozíciógörbétől.

Az interleave ez a módszer. Két rangsoroló találatait egy listába keveri, és minden kattintást annak a rangsorolónak ír jóvá, amelyik a kattintott találatot adta. Chapelle, Joachims, Radlinski és Yue beszámolt arról, hogy az interleave több mint egy nagyságrenddel csökkentette a szükséges lekérdezések számát a kattintás-alapú jelekhez képest, és hogy egy megítélt lekérdezés–dokumentum pár nagyjából annyi érzékenységet adott, mint egy-két kattintással járó lekérdezés ([Chapelle et al., TOIS 2012](https://www.cs.cornell.edu/people/tj/publications/chapelle_etal_12a.pdf)). A sima A/B-teszt továbbra is megválaszolja az olyan üzleti kérdéseket, mint a konverzió és a bevétel, és nagy változtatásokhoz ez a megfelelő eszköz. Rangsorolási változtatásoknál az interleave jóval kevesebb forgalommal ad választ.

## Hogyan csoportosítja a null találatos lekérdezéseket?

Csoportosítsa őket szakaszokban, a legolcsóbbal kezdve. A szabályok elkapják a nyilvánvaló eseteket, például egy elírt márkanevet vagy egy cikkszámrészletet. A normalizálás kezeli a kis- és nagybetűt, az elválasztójeleket, a mértékegység-írásmódot és a többes számot. A maradék egy beágyazó modellen és egy csoportosító lépésen megy keresztül. A BERTopic leírja a szokásos receptet: a dokumentumokat egy előtanított transzformerrel beágyazza, a beágyazásokat csoportosítja, a témákat pedig osztályalapú TF-IDF-fel nevezi el ([arXiv](https://arxiv.org/abs/2203.05794)). Ezután egy nyelvi modell nevezi el az egyes csoportokat, és címkét rendel hozzájuk.

A címkeszókincs fontosabb, mint az eszközök. Az Amazon Shopping Queries Datasetje a lekérdezés–termék párokat Exact, Substitute, Complement vagy Irrelevant besorolással értékeli. Angol, japán és spanyol nyelven mintegy 130 000 egyedi lekérdezést és 2,6 millió kézi értékelést tartalmaz, és a KDD Cup 2022-re adták ki ([arXiv](https://arxiv.org/abs/2206.06588)). A szókincs átvételéhez nincs szüksége az adatokra. A sorba állításhoz egy null találatos csoport általában három rés egyikeként olvasható: katalógusrés, ha a termék nincs a webshopban; szókincsrés, ha a termék más szavakkal létezik; vagy szándékrés, ha a vásárló olyasmit kér, amit a webshop nem termékként kezel, például egy kompatibilitási kérdést.

A címkézési lépés szándékosan olcsó. Nem minden keresést lát, hanem a csoportneveket és néhány példalekérdezést, ezért költsége a csoportösszefoglaló méretét követi, nem a webshop forgalmát. Ha a heti export csak néhány tucat különböző null találatos lekérdezést tartalmaz, olvassa át őket kézzel. A csoportosítás akkor térül meg, ha a lista hosszú.

## Hogy néz ki a heti átnézés?

A kör hetente egyszer fut, és egy változtatással zárul. Exportálja a hét null találatos és kattintás nélküli lekérdezéseit. Csoportosítsa és nevezze el őket. Döntse el, melyik rés melyik csoport. Vezessen be egy javítást, rögzítse egy változásnaplóban, és mérje a következő hetet, vagy teszteljen, ha a javítás kockázatos. Ha egyszerre csak egy változtatással zárja a kört, a hozzárendelés tiszta marad.

A javítások négy csoportba sorolhatók, és a rés dönti el, melyiket válassza.

-   **Szinonima** szókincsbeli résre. Az Algolia dokumentált munkafolyamata a keresésanalitikából indul, és többféle szinonimát ad hozzá: szokásos, egyirányú, alternatív javításokat és helyőrzőket. A szinonimák nem láncolódnak tovább, a dokumentáció pedig figyelmeztet a túlzott használatra ([Algolia](https://www.algolia.com/doc/guides/managing-results/optimize-search-results/adding-synonyms/)).
-   **Átirányítás** olyan lekérdezésre, amelynek egyértelmű célja van, például kategóriaoldal vagy kampányoldal.
-   **Emelés vagy rögzítés** olyan termékre, amely már illeszkedik a lekérdezésre, de gyengébb találatok alatt szerepel.
-   **Adatjavítás** katalógusrésre. Ha a termék létezik, de a neve vagy attribútumai nem tartalmazzák azt a szót, amelyet a vevő használt, a javítás a katalógusért felelőé. [A katalógus adatminősége](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data) bemutatja, hogyan kell ezt a munkát továbbítani.

A csoportok, amelyek valójában navigációs problémák, például egy hiányzó kategóriahivatkozás, nem keresési problémák. Vegye ki őket a körből, és rögzítse elvetettként, hogy ugyanaz a csoport ne térjen vissza minden héten.

![Heti keresésátnézés zárt körként Hat doboz. Felül balról jobbra: export, csoportosítás és elnevezés, egy javítás bevezetése, kísérlet. A kísérlet jobb alul az irányítópultba táplál, az irányítópultból visszafelé mutató nyíl pedig az exportdobozhoz ér, és ezzel zárul a kör. A csoportosító dobozból szaggatott ág vezet az „elvetve” dobozba azokhoz a csoportokhoz, amelyek navigációs vagy katalógushibák, nem keresési problémák.](https://balazscsorba.com/images/blog/shop-search-analytics/diagram-30.webp?v=bde93694a1)

A heti kör zárt körforgásként: hetente egy javítás, datált alapvonalhoz mérve, kilépéssel a nem keresési problémákhoz.

A kísérleti lépés zárja a kört. Egyszerre csak egy változtatást vezessen be, rögzítse a dátumát és a célzott csoportot, és a következő hét számait ehhez a dátumhoz képest olvassa. Nagy változtatásnál, elegendő forgalom mellett használjon A/B-tesztet. Rangsorolási változtatásnál, ha gyorsabb választ kell kapnia, használjon interleave-et. A sok javítás mögötti átírási mechanikát a [beszélgetős keresés lekérdezés-átírása](https://balazscsorba.com/hu/blog/conversational-search-query-rewriting) cikk tárgyalja; a heti átnézés mutatja meg, melyik átírás érdemes.

## Meddig érdemes megőrizni a keresési naplókat?

Csak azokat a mezőket tartsa meg, amelyeket a kör használ, és csak addig, ameddig a körnek szüksége van rájuk. A GDPR szerint az adattakarékosság (5. cikk (1) bekezdés c) pont) és a tárolás korlátozása (5. cikk (1) bekezdés e) pont) a keresési naplókra is vonatkozik, mint bármely személyes adatra, a 32. cikk pedig az álnevesítést és a titkosítást sorolja a biztonsági intézkedések közé ([EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj)).

A gyakorlatban ez azt jelenti: álnevesített munkamenet-azonosítók a fióksszámok helyett, a nyers lekérdezési szöveg külön táblában saját megőrzési idővel, és nincs IP-cím a betöltés után. Itt az alapértelmezés számít. Az Algolia az IP-címekkel különbözteti meg a felhasználókat, hacsak nem ad át userToken-t, és figyelmeztet, hogy a háttérszolgáltatásból indított keresések másképp az összes felhasználót a szerver IP-je alá csoportosítják ([Algolia](https://www.algolia.com/doc/guides/search-analytics/concepts/query-aggregation/)). Az IP-cím személyes adat, amelyet inkább álnevesített azonosítóra cserélne, mielőtt az a naplóba kerül.

**A nyers lekérdezési szöveg ne kerüljön az összesítésekbe**

A null találati arányhoz és a pozíció szerinti CTR-hez nem kell a nyers lekérdezési szöveg, miután a heti átnézés megtörtént. A nyers szöveget a megőrzési ütemterv szerint törölje vagy hashelje, a számokat pedig tartsa meg.

Ha a naplók eljuthatnak név szerint azonosított munkavállalókig, a kérdés megváltozik. Ausztriában az Arbeitsverfassungsgesetz 96. § (1) bekezdés 3. pontja a munkavállalók megfigyelésére szolgáló ellenőrzési intézkedések és technikai rendszerek bevezetését az üzemi tanács hozzájárulásához köti, ha az emberi méltóságot érinti ([RIS](https://www.ris.bka.gv.at/NormDokument.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10008329&Paragraf=96)). Az a belső keresési napló, amely egy név szerint azonosított munkavállalóig visszavezethető, az első ellenőrzendő eset, a biztonságosabb tervezés pedig álnevesítve tartja az összekötő kulcsot, és összesítve készíti a jelentéseket.

A megőrzési idő az Ön vállalkozásának szabályzati döntése, nem a gyártó alapértéke. Írja le az időtartamot a sémadokumentációban, és ütemezett törléssel érvényesítse, hogy a heti export tovább működjön anélkül, hogy a nyers előzmények örökké nőjenek. Ha ezt B2B webshopnak építi, a [B2B e-kereskedelmi munkám](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer) a keresés mellett a katalógus oldalát is lefedi.

## Források

1.  [Algolia: search analytics concepts (metrics and definitions)](https://www.algolia.com/doc/guides/search-analytics/concepts/)
2.  [Algolia: query aggregation and userToken](https://www.algolia.com/doc/guides/search-analytics/concepts/query-aggregation/)
3.  [User Behavior Insights (UBI) specification 1.3.0](https://github.com/o19s/ubi)
4.  [Google Research: position bias estimation for unbiased learning to rank in personal search (WSDM 2018)](https://research.google/pubs/position-bias-estimation-for-unbiased-learning-to-rank-in-personal-search/)
5.  [eBay: click propensity estimation for e-commerce search (SPIRE 2019)](https://arxiv.org/abs/1812.09338)
6.  [Chapelle, Joachims, Radlinski, Yue: interleaved search evaluation (TOIS 2012)](https://www.cs.cornell.edu/people/tj/publications/chapelle_etal_12a.pdf)
7.  [Shopping Queries Dataset (ESCI), KDD Cup 2022](https://arxiv.org/abs/2206.06588)
8.  [BERTopic: neural topic modeling with class-based TF-IDF](https://arxiv.org/abs/2203.05794)
9.  [Hello Retail: ecommerce search statistics (24 Feb 2026)](https://helloretail.com/en/blog/2026-02-24-ecommerce-search-statistics/)
10.  [Algolia: adding synonyms](https://www.algolia.com/doc/guides/managing-results/optimize-search-results/adding-synonyms/)
11.  [Regulation (EU) 2016/679 (GDPR), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
12.  [Arbeitsverfassungsgesetz § 96, RIS (consolidated text)](https://www.ris.bka.gv.at/NormDokument.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10008329&Paragraf=96)

## Gyakori kérdések

Mi egy jó null találati arány egy webshopban?

Az egyetlen nyilvános viszonyítási pont ebben a cikkben a Hello Retail gyártói tájékoztatása, 2026 februárjából: a keresések átlagosan 10–15%-a nem ad találatot, a cél 5% alatt van. Ezt durva mércének tekintse. Állítsa be a saját alapvonalát a naplók alapján, és ahhoz mérje a változtatásokat.

Mely keresési eseményeket érdemes először naplózni?

A keresési eseményt a lekérdezési szöveggel, a szűrőkkel, az oldalszámmal és a találatok számával, a kattintási eseményt pedig a query\_id-val, az objektumazonosítóval és a pozícióval. Közös query\_id nélkül nem tudja a kattintást ahhoz a kereséshez kötni, amely előidézte.

Miért nem elég önmagában az átkattintási arány?

A kattintás érdeklődést jelez, nem sikert, és a kattintások a relevanciától függetlenül a magasabb pozíciókra koncentrálódnak. A pozíció szerinti átkattintási arányt ezzel a torzítással együtt olvassa, a rangsorolási változtatásokat pedig olyan módszerrel értékelje, amely nem függ a pozíciógörbétől.

Jobb-e az interleave, mint az A/B-teszt keresésnél?

Rangsorolási változtatásoknál az interleave jóval kevesebb lekérdezéssel jut döntésre. Chapelle és munkatársai több mint egy nagyságrenddel kevesebb lekérdezésről számoltak be a kattintás-alapú jelekhez képest. Nagy változtatásokhoz és az üzleti mutatókhoz, mint a konverzió vagy a bevétel, az A/B-teszt továbbra is a megfelelő eszköz.

A keresési naplók személyes adatnak számítanak a GDPR szerint?

Lehetnek azok. Egy fiókhoz, munkamenethez vagy IP-címhez kötött lekérdezés személy azonosítására alkalmas, ezért a GDPR érvényes rá. Csökkentse a gyűjtött mezőket, álnevesítse az azonosítókat, és a célnak megfelelő megőrzési időt állítson be.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[B2B e-kereskedelem és PIM →](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Schema.org strukturált adatok B2B webshopokhoz: bejelentkezés mögötti árak, egységek és változatok](https://balazscsorba.com/hu/blog/schema-org-structured-data-b2b-shop)
-   [AI-asszisztens a B2B webshop ügyfélszolgálatához: eszközök, jogosultságok és átadás embernek](https://balazscsorba.com/hu/blog/ai-assistant-b2b-shop-customer-support)
-   [AI-csevegő UI Vue-ban és Nuxtban: akadálymentes streaming](https://balazscsorba.com/hu/blog/vue-ai-chat-ui-streaming-accessibility)
-   [LLM-fordítási pipeline i18n-hez: glosszárium, helyőrzők és review](https://balazscsorba.com/hu/blog/llm-translation-pipeline-i18n)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)