Чому пошук у магазині не знаходить товар, який є на складі

Пошук по сайту інтернет-магазину не знаходить наявний товар тому, що покупець описав його не тими словами, якими менеджер заповнив картку. База в порядку, залишок на місці, ціна проставлена — просто рушій зіставляє рядки, а людина в рядку описала призначення, симптом, скорочення чи бренд латиницею. Товар лежить на складі, а видача порожня.

Далі він не пише вам у чат і не йде в каталог руками. Він відкриває сусідню вкладку, де той самий товар уже лежить у кошику. Причин, з яких видача порожніє на наявному товарі, вісім, і вони не перетинаються: тип запиту, на який рушій не розрахований; описка довша за дві операції; неперемкнута розкладка; розбіжність у транслітерації; розмовна назва товару; лічильник фільтра, якому не можна вірити; сторінка «нічого не знайдено» без виходу; повільна відповідь. Кожна лікується окремо і коштує різних грошей. Нижче — механіка кожної, з таблицею типів запитів, порядком діагностики за власними логами й межею, після якої дешевше поміняти рушій, ніж латати наявний.

Проблема не в пошуку, а в тому, що запити бувають різні

Baymard Institute роками ганяє юзабіліті-тести на е-комерс-пошуку і розклав запити за типами — не за тематикою, а за тим, ЩО людина описує в рядку. У таблиці частка сайтів, де тип ламається, за їхнім бенчмарком, і що з цим робити на своєму каталозі.

Закономірність видно згори вниз. Що далі від артикула — то гірше. Точний артикул віддає майже кожен рушій, бо це просте зіставлення рядків. А «щось для дачі, щоб не мерзнути» вимагає, щоб хтось колись зв'язав сценарій із категорією. Ніхто не зв'язував.

Третина запитів у рядку пошуку взагалі не про товар

Останній рядок таблиці коштує дорожче за решту, бо лікується найшвидше. За спостереженнями Baymard, приблизно третина учасників їхніх тестів шукала в рядку пошуку не товар, а сервісну інформацію — умови доставки, статус замовлення, гарантію. А ваш пошук індексує тільки каталог. Індекс — це той список, по якому рушій реально шукає; чого в ньому немає, того для пошуку не існує. Тому третина запитів приречена на нуль ще до старту. Лікується за годину: додайте в індекс сторінки доставки, оплати, повернення й контактів, а тоді подивіться, як просяде метрика нульових результатів. З чого почати аудит каталогу — розписали в розробці інтернет-магазинів.

Дві описки рушій пробачить, третю — ні

Толерантність до помилок звучить як «розумний пошук сам розбереться». Насправді це арифметика, і в неї жорсткі межі. Візьмімо документацію Algolia як приклад типової реалізації, інші рушії влаштовані схоже.

Помилку рушій міряє відстанню редагування (edit distance): скільки операцій — додати, видалити, замінити, переставити символи — треба, щоб перетворити одне слово на інше. Далі три обмеження, про які власник магазину зазвичай не знає.

Перше — не більше двох помилок у слові. «Хоолдильник» рушій виправить. «Халадильнек» — уже три операції, це нуль результатів.

Друге — короткі слова не отримують права на помилку взагалі. За замовчуванням слово має бути щонайменше з чотирьох символів, щоб рушій пробачив хоч одну помилку. Тобто «фен», «шини», «USB», «SSD» перевіряються буква в букву. Одна помилка в трилітерному запиті — і видача порожня, хоч ти скільки платив за «розумний пошук».

Третє — розрив і злиття слів це окремий клас збою, який толерантність до описок не покриває. «Мультиварка» і «мульти варка», «ноутбук» і «нот бук» — для рушія це не описка, а інша структура запиту. Її закриває окремий механізм, і його зазвичай не вмикають.

І ще один нюанс, який пояснює дивну видачу: кількість помилок — перший критерій ранжування. Точний збіг завжди стане вище за виправлений. Тому якщо у вас в каталозі є товар із помилкою в назві (а він є — перевірте вивантаження постачальника), він виграє в чесних карток на запиті з тією ж помилкою.

Що з цим робити на рівні інтерфейсу. За даними Baymard, 69% сайтів не пропонують виправлення описки прямо в автопідказці — людина дописує запит до кінця, отримує нуль і робить висновок не про пошук, а про ваш каталог: «у них цього немає». Виправлення в підказці коштує дешевше, ніж будь-яка сторінка «нічого не знайдено», бо гасить помилку до того, як вона стала нулем.

Кирилиця, латиниця і людина, яка забула перемкнути розкладку

Ось механізм, який в українських магазинах майже ніколи не закритий. Відсотків ви тут не знайдете, бо їх ніхто не рахував. Зате їх видно неозброєним оком у логах пошуку, щойно ви туди зазирнете.

Людина набирає «ntktdsps», маючи на увазі «телевізор», бо не перемкнула клавіатуру. Або навпаки, «Барвшсру» замість «Panasonic». Для рушія це осмислений набір символів, який просто ні з чим не збігається. Лікує це зіставлення розкладок на етапі обробки запиту: якщо результатів нуль, прогнати запит через таблицю відповідності клавіш і спробувати ще раз. Десяток рядків коду, який ніхто не пише, бо про нього не думають.

Транслітерація ламає пошук, бо офіційна норма сама допускає два написання

Тут гірше, ніж здається, і причина — в самій нормі. Офіційна таблиця транслітерації українського алфавіту латиницею, затверджена Кабміном, влаштована так, що одна назва законно має кілька написань:

• «щ» передається чотирма літерами — Shch. Хтось напише саме так, хтось скоротить до Sch;
• «г» це h, «ґ» це g, «х» це kh. Звідси Kharkiv проти Harkov у назвах товарів і брендів;
• «ю» і «я» мають по два написання залежно від позиції в слові: Yurii, але Koriukivka; Yahotyn, але Kostiantyn. Один товар — два цілком легальні варіанти;
• м'який знак і апостроф латиницею не відтворюються взагалі. Тому «з'єднувач» і «зєднувач» мусять збігатися в індексі, інакше половина запитів провалюється на апострофі.

Практичний наслідок. Якщо у вас у каталозі назва «Житомирські ласощі» записана як Zhytomyr, а покупець набирає Zhitomir — це нуль результатів на товарі, який лежить на складі. Лікує це нормалізація на рівні індексу: обидва написання зводимо до однієї форми ще до пошуку. В Elasticsearch для цього є штатний фільтр аналізу тексту (icu_transform), у решти рушіїв свій еквівалент. Як це виглядає в архітектурі проєкту, розбираємо в матеріалі про семантичний пошук на сайті.

Той самий механізм закриває суржик і розмовні назви. «Мобілка», «телек», «пилосмок», «зарядка» — не помилки, а те, як люди називають товар уголос. Числа тут ніхто не публікував, зате масштаб видно з українського кейсу. Вендор пошуку Multisearch, описуючи роботу з мережею «Аврора», наводить 770 різних запитів на ОДИН товар і 15 варіантів написання його назви. Це дані самого вендора, не незалежний вимір, але порядок величини реалістичний для будь-якого каталогу від кількох тисяч позицій. П'ятнадцять написань означає, що чотирнадцять з них ви в картці не передбачили.

Чому лічильники біля фільтрів іноді брешуть

Це найменш очевидна частина, і саме через неї «пошук знайшов, а фільтр з'їв». Покупець бачить «Bosch (34)», ставить галочку — і отримує 11 товарів. Або порожню сторінку. Виглядає як баг фронтенду, а насправді це задокументована поведінка рушія.

Знову беремо документацію Algolia, бо там це описано чесно. Спершу термін: фасет — це характеристика, за якою ви даєте фільтрувати (бренд, колір, розмір), а число в дужках біля неї і є тим лічильником. Далі три речі.

Лічильники рахуються по-різному для AND і для OR. Коли ви комбінуєте фільтри кон'юнктивно (бренд І колір) чи диз'юнктивно (бренд АБО бренд), рушій навмисно рахує фасети за різними правилами, щоб інтерфейс залишався передбачуваним. Якщо фронтенд відмальовує числа з однієї відповіді, а фільтрує іншим режимом, числа перестають збігатися з видачею.

На великих каталогах лічильники взагалі наближені. Пряма цитата з документації Algolia про фасети: на масивних індексах рушій може апроксимувати підрахунок фасетів заради швидкості, і щоб дізнатися, чи точні числа, треба перевіряти окремий прапорець exhaustiveFacetsCount у JSON-відповіді. Тобто число біля фільтра — це не факт, це оцінка, і рушій сам про це попереджає. Ніхто не перевіряє прапорець.

Віддається лише 100 значень фасета за замовчуванням. Максимум за запит — тисяча. Якщо у вас у каталозі кількасот брендів, фільтр покаже перші сто за частотою. Решта для покупця не існує. Не тому, що товару немає, а тому, що ліміт відповіді не піднімали з дефолту.

Додайте сюди те, що Baymard прямо називає антипатерном: дозволити людині вибрати комбінацію фільтрів, яка гарантовано дає нуль, і показати їй порожню сторінку. Правильно — гасити або підсвічувати такі комбінації заздалегідь. Плюс дрібниці, які коштують продажів: 20% магазинів не показують застосовані фільтри під час перегляду, 14% не дають вибрати кілька значень одного фільтра, а незрозумілі підписи на мобільному зустрічаються в 40% магазинів проти 25% на десктопі.

Висновок для власника простий. Якщо ваш фільтр і ваш пошук — це дві різні підсистеми, які по-різному розуміють каталог, покупець побачить розбіжність раніше за вас.

Сторінка «нічого не знайдено» — це остання точка, де ви ще можете продати

Нуль результатів неминучий. Питання не в тому, як звести його до нуля, а в тому, що покупець бачить у цю секунду. За оцінкою Baymard, приблизно половина магазинів робить сторінку «нічого не знайдено» так, що вона підвищує відмови, і майже половина взагалі не дає людині шляху виходу.

Що не працює: список порад «перевірте орфографію, спробуйте інший запит, скористайтеся каталогом». Baymard фіксує, що поради самі по собі не рятують, їх рідко читають і ще рідше застосовують. Текст для галочки.

Що працює: показати хоч щось релевантне. Результати за частиною запиту (відкинути найрідше слово й пошукати рештою). Найближчі за написанням товари. Категорію, до якої запит схожий. Товари з того ж цінового діапазону. Форму «повідомити, коли з'явиться» — вона перетворює нуль на лід замість виходу.

І ще одна деталь, яку ламають 37% сайтів: запит має залишатися в полі пошуку після переходу на видачу. Якщо поле порожнє, людина не може відредагувати запит — вона мусить набирати заново. На мобільному це майже гарантована втрата, бо там складніше не лише набирати, а й правити набране.

Скільки часу є у вашого пошуку

Окремих досліджень саме про затримку внутрішнього пошуку ми не знайшли. Але є класичні межі інтерфейсу від Nielsen Norman Group. Це загальні пороги сприйняття, а не бенчмарк пошуку, і саме в цій ролі вони працюють як розумний орієнтир. Три межі часу відгуку такі:

До 0,1 с реакція відчувається миттєвою. Це бюджет автопідказки: вона мусить встигати за набором тексту, інакше людина допише запит швидше, ніж ви їй допоможете. До 1 с хід думки не переривається — це бюджет видачі результатів, і в цю секунду людина ще думає про товар, а не про сайт. Після 10 с уваги немає: потрібен індикатор прогресу, і покупець усе одно перемикається на інше.

Прикладіть це до свого каталогу. Якщо пошук ходить у базу з LIKE '%запит%' по таблиці на 50 тисяч позицій із JOIN на характеристики, ви не в першій категорії й не в другій. Ви в третій — а там покупця вже немає.

Як діагностувати свій пошук за один тиждень

Без інструментів це вгадування. З інструментами — п'ять кроків, які може зробити ваш маркетолог, не чекаючи розробників.

1. Увімкніть логування запитів у понеділок. Не аналітику подій, а сирі рядки: що людина набрала, скільки результатів отримала, чи клікнула. Мінімум — таблиця з чотирьох колонок: запит, кількість результатів, час відповіді, клік. Метрика нульових результатів рахується просто: частка пошуків, які повернули нуль. Вендори пошуку називають орієнтир у 12–20%, але це оцінка вендора, публічного дослідження за нею немає. Тому спирайтеся на власну динаміку, а не на чужу цифру.
2. У пʼятницю вивантажте всі запити з нульовим результатом і згрупуйте однакові. Верхні двадцять рядків за частотою закриють більшу частину болю. Далі розкладіть верхівку за трьома ознаками — латиниця й неперемкнута розкладка, розмовні назви товару, сервісні запити. Кожна група лікується інакше, тому спершу подивіться, чого у вас більше, а не «додайте синоніми».
3. Розкладіть нульові запити за вісьмома типами з таблиці вище. Проставте кожному рядку тип — точний, тип товару, характеристика, симптом, сценарій, сумісність, скорочення, непродуктовий. Порахуйте частку кожного типу від усіх нульових. Це і є ваш власний зріз замість чужого бенчмарку: у когось половина нулів упаде на сервісні запити, і тоді робота на годину — індексація сторінок доставки й гарантії; у когось на сумісність, і це вже поле в каталозі.
4. Перевірте нуль на трилітерних запитах з однією помилкою. Візьміть десять коротких назв із каталогу, зробіть у кожній одну описку, прогоніть. Якщо порожньо — у вас дефолтний поріг довжини слова, і його треба знижувати.
5. Порівняйте число на фільтрі з реальною видачею. Десять фільтрів, десять кліків, два стовпці в тій же таблиці: що обіцяв лічильник і скільки товарів прийшло. Розбіжність хоч в одному означає, що фасети або наближені, або обрізані лімітом.

На виході за тиждень — таблиця нульових запитів із часткою кожного типу поломки, а не відчуття «пошук у нас якийсь не такий». З цим списком уже можна рахувати гроші: скільки запитів на тиждень, який середній чек, скільки з цього ви віддаєте маркетплейсу. Якщо хочете, щоб цей аудит зробили ми — це впровадження AI-пошуку, і починається воно саме з логів, а не з вибору рушія.

Коли пора не лагодити, а міняти рушій

Пошук за ключовими словами, класичний повнотекстовий індекс, синоніми — усе це зіставляє рядки. Чудово працює на артикулах і ламається на сенсі. Запит «щоб не мерзнути на балконі взимку» не містить жодного слова з картки обігрівача. Ніяка кількість синонімів це не закриє, бо синонім — це пара слів, а тут потрібне розуміння наміру.

Векторний, або семантичний, пошук працює інакше: він зіставляє не рядки, а близькість сенсів, тому «не тримає заряд» приводить до акумуляторів, а «для дачі» — до відповідної добірки. Це рішення для запитів типу «симптом» і «сценарій використання», тих самих 37% і 43% провалів. Механіку розкладаємо в семантичному пошуку на сайті, а споріднений підхід до неструктурованих даних розбираємо в матеріалі про RAG у документах.

Тверезо: семантика не замінює ключовий пошук, вона його доповнює. Артикул мусить далі знаходитися точно й миттєво. Гібридна схема — точний збіг плюс векторний резерв на нульових результатах — дає обидва режими без переписування каталогу.

Скільки людей це зачепить. Algolia оцінює, що близько 30% покупців в е-комерсі користуються внутрішнім пошуком. Це оцінка вендора, не незалежне дослідження. Український зріз від Multisearch по мережі «Аврора» дає 31% користувачів і 49% доходу від пошукової аудиторії, знову ж таки за даними самого вендора. Цифри різних вендорів сходяться в одному: аудиторія пошуку менша за загальну, але конвертує краще, бо це люди з уже сформованим наміром купити. Ваш власний відсоток дадуть логи за тиждень, і він єдиний, на який варто спиратися.

Що врешті ламається і що з цим робити

Пошук по сайту інтернет-магазину не знаходить наявний товар не з однієї причини, а з восьми, і вони не перетинаються. Запит не того типу, який рушій вміє обробляти. Дві помилки — межа, а коротке слово не отримує права навіть на одну. Розкладка не перемкнута. Транслітерація розійшлася на «щ» і «ю», бо офіційна норма сама допускає варіанти. Товар називається в народі не так, як у картці постачальника. Фільтр показав число, якому рушій сам не довіряє. Сторінка «нічого не знайдено» не запропонувала виходу. Відповідь прийшла на четвертій секунді.

У кожного пункту своя ціна впровадження і свій ефект. Нормалізація розкладки й транслітерації — кілька днів роботи, найбільший приріст на українському каталозі. Індексація сервісних сторінок — година, знімає до третини нульових запитів. Синоніми з реальних логів — постійна робота маркетолога, не разова задача. Семантичний шар — це вже проєкт, і братися за нього варто, коли перші три кроки зроблено й видно, що залишилося.

Порядок дій завжди однаковий — спершу логи, потім типологія, потім рушій. Не навпаки. AI-пошук для інтернет-магазинів ми будуємо саме в такій послідовності, і часто після аудиту логів виявляється, що новий рушій купувати не треба: досить полагодити нормалізацію в наявному. Надішліть вивантаження нульових запитів за місяць. За 30 хвилин у Zoom розберемо його при вас і покажемо, які поломки закриваються нормалізацією, а які тягнуть на окремий проєкт.

Часті питання