Більшість проектів пошуку по сайту починаються не з того місця: з демонстрації постачальника. Демонстрація завжди працює, оскільки вона запускається на індексі постачальника з його запитами. Тим часом, бенчмарк пошуку Інституту Баймарда за 2026 рік показує, що 56% сайтів електронної комерції мають посередній або гірший UX пошуку., і що невдачі групуються в певних, іменованих типах запитів, а не за "релевантністю" в цілому (Баймард, оновлено у квітні 2026 року). Новий двигун виправляє деякі з них, а інших — жодних.
Це рубрика оцінювання для вашого вже існуючого пошуку. Двадцять перевірок, по два бали за кожну, загалом сорок балів. Ви перевіряєте її у власному каталозі протягом дня, отримуєте число, і це число показує, чи є ваша проблема конфігурацією, контентом чи самим движком. Вона написана для UX-лідів електронної комерції, менеджерів з розвитку та власників продуктів, яких попросили обґрунтувати бюджет на пошук.
Що вимірює рубрика, а що вона навмисно ігнорує
Ця рубрика оцінює чотири речі: чи розуміє пошук типи запитів, які люди насправді вводять, чи витримує він невпорядковане введення, чи відновлюється він, коли нічого не знаходить, і чи можна щось із цього виміряти. Вона не оцінює якість ранжування результатів абстрактно. Ранжування – це останнє, що потрібно налаштовувати, і перше, про що всі сперечаються, і ви не можете налаштувати його, поки запити все ще не працюють на токенізації.
Оцінка становить 0, 1 або 2 бали за перевірку. Два означає, що перевірка проходить кожен запит у вашому тестовому списку. Один означає, що перевірка проходить для головних термінів, але не проходить для довгого хвоста. Нуль означає, що перевірка не проходить для головних термінів. Спочатку складіть тестовий список: візьміть 50 найпопулярніших запитів з аналітики, потім додайте п'ять запитів, які ви створите для кожного з восьми типів запитів Baymard, щоб був представлений довгий хвіст. Приблизно 90 запитів. Запустіть їх самостійно, на мобільному пристрої, без виходу з системи.
20 чеків
| # | перевірити | Оцінка 2, коли |
|---|---|---|
| Група A — Покриття запитів (кластери відмов Баймарда) | ||
| 1 | Точні запити та запити за номером моделі | Названий продукт є першим результатом, а не четвертим |
| 2 | Запити щодо типу продукту | Повертає доступний для перегляду фасетований список, а не плоский дамп релевантності |
| 3 | Запити щодо функцій ("червоне вовняне пальто") | Атрибути звужують набір, а не розбавляють його за допомогою зіставлення АБО |
| 4 | Запити щодо сумісності («зарядний пристрій для моделі X») | Повертає аксесуари для названої моделі, а не саму модель |
| 5 | Запити, що не стосуються товару («політика повернення») | Повертає сторінку змісту; 66% сайтів не проходять цей тест |
| Група B — Обробка вхідних даних | ||
| 6 | Допуск до друкарських помилок | Односимвольні та двосимвольні помилки в заголовних термінах все ще збігаються |
| 7 | Згинання регістру та діакритики | Правильно для кожної мови, яку обслуговує сайт (див. нижче) |
| 8 | Морфологія та множина | Флективні та суфіксальні форми утворюють ті ж самі продукти, що й основа |
| 9 | Синоніми та місцева говірка | Слова клієнта відповідають словам каталогу в обох напрямках |
| 10 | Автозаповнення для орфографічних помилок | З’являються пропозиції щодо неправильно написаних префіксів; 69% сайтів не відповідають цьому запиту. |
| Група C — Результати та відновлення | ||
| 11 | Відновлення з нульовим результатом | Принаймні два вихідні шляхи: пов'язані категорії та альтернативні запити |
| 12 | Збереження запитів | Запит залишається в полі після відправлення; 37% сайтів його відкидають. |
| 13 | Видно обсяг | Кількість результатів та будь-який автоматично застосований обсяг категорії вказані та можуть бути видалені |
| 14 | Парність граней | Результати пошуку пропонують ті ж аспекти, що й сторінка еквівалентної категорії |
| 15 | Релевантність можна пояснити | Хтось із команди може сказати, чому перший результат має рейтинг вище за другий |
| Група D — Вимірювання | ||
| 16 | Кожен шлях пошуку відстежується | view_search_results спрацьовує з пошуковим терміном, включаючи переходи автозаповнення |
| 17 | Запити з нульовими результатами можна ізолювати. | Ви можете переглянути список запитів, що не дали результатів за минулий місяць, за обсягом, без запиту |
| 18 | Пошук для покупки є звітним | Користувачів, які шукають, і тих, хто не шукає, можна порівнювати як сегменти |
| 19 | Запит на перегляд має власника | Названа особа переглядає топ-50 та нульовий результат у певний ритм |
| 20 | Зміни конфігурації мають версії | Зміни синонімів та підсилення реєструються, вони оборотні та тестові |
Порогові значення групи А випливають з опублікованих Baymard показників невдач за типом: пошук за нетоварними запитами не спрацьовує на 66% сайтів, пошук за скороченнями та символами – на 54%, пошук за сумісністю – на 44%, пошук за варіантами використання – на 43% (Беймард). Перевірка 11 існує тому, що майже половина сайтів не дають користувачам ефективного виходу з глухого кута (Баймард, лютий 2025 року). Перевірки 10 та 12 отримані з результатів автозаповнення та збереження запитів того ж самого бенчмарку (Пошуковий бенчмарк Baymard).
Детально перевірте 7: складна пастка, яка відображається лише за межами англійської мови
Перевірка 7 варта окремого розділу, оскільки саме вона непомітно обнуляє ринок. Більшість пошукових стеків перед збігом записують запит та індекс у нижньому регістрі. В англійській мові це нешкідливо. У турецькій – ні, і той самий клас проблем виникає в будь-якій мові з символами, відмінними від базової латиниці.
Юнікод визначає правило регістру для турецької та азербайджанської мов, специфічне для локалі: велика літера I (U+0049), малі літери, без крапки ı (U+0131), тоді як велика İ (U+0130) перетворюється на звичайну i (Unicode SpecialCasing.txt). Стек, який використовує малі літери з локалізацією за замовчуванням, перетворює "İPHONE" на "i̇phone" з випадковою крапкою в поєднанні або перетворює велику літеру "I" в назві продукту на неправильну. Потім запит та індекс розходяться щодо слова, яке вони обидва містять. Ніяких помилок. Ви просто отримуєте нульовий результат для бренду, який у вас є.
Два виправлення є незалежними, і вам потрібні обидва. По-перше, застосовуйте коректне використання нижнього регістру з урахуванням локалізації під час індексування та запиту — Elasticsearch постачає turkish аналізатор, що веде до ланцюгів apostrophe, turkish_lowercase, turkish_stop, turkish_keywords та turkish_stemmer саме з цієї причини (Еластичні, мовні аналізаториПо-друге, окремо вирішіть, що робити з діакритичними знаками, оскільки турецькі покупці зазвичай друкують кіліф та цінності обкладинка та сардж та цінності нараховувати на клавіатурах, які уповільнюють відтворення акцентованої форми. asciifolding фільтр перетворює символи, що не належать до Basic-Latin, на еквіваленти ASCII, а також його preserve_original опція видає як складений, так і оригінальний токен, тому точні збіги все одно виграють (Еластичний, асцискладальний). Зігніть для зручності, збережіть оригінал для точності.
За межами Туреччини та сама перевірка має місцеві форми: німецькі складні іменники, які потрібно розкласти на складові, перш ніж двослівний запит зможе збігатися, французькі та іспанські акценти, набрані нерівномірно, грецька кінцева сигма. Оцініть перевірку 7 як 2 лише за умови, що ви протестували її кожною мовою, якою фактично обслуговує ваш магазин, а не мовою, якою розмовляє ваша команда.
Спочатку фіксуємо виміри: перевірки з 16 по 20
Якщо група D набрала менше 6 балів, зупиніться та виправте це, перш ніж торкатися чогось іншого, оскільки ви не можете перевірити виправлення, яке не бачите. У GA4 спрацьовує розширене вимірювання. view_search_results з search_term параметр, коли сторінка результатів містить один із п’яти параметрів запиту за замовчуванням — q, s, search, query or keyword — і ви можете додати свої власні (Довідка Google Analytics). Поширені два режими помилок. Якщо на сторінці результатів використовується сегмент шляху, а не рядок запиту, відстеження за замовчуванням нічого не бачить. А якщо автозаповнення переводить безпосередньо до продукту, цей пошук взагалі ніколи не викликає подію, що непомітно зміщує ваш журнал запитів у бік пошуків, які не змогли нічого знайти з першої спроби.
Читання вашого рахунку
| Рахунок | Вердикт | Наступний хід |
|---|---|---|
| 32-40 | Налаштовувати, не замінювати | Витрати на синоніми, правила мерчандайзингу та сортування з нульовим результатом |
| 22-31 | Проблема конфігурації | Виправити групу B та спочатку перевірити 11; перерахувати через шість тижнів |
| 12-21 | Ймовірно, структурний | Переоцінити після виправлення групи D, а потім визначити обсяг заміни, використовуючи ці 20 перевірок як критерії прийнятності |
| 0-11 | Пошук ще не є функцією | Розглядати як збірку, а не як оптимізацію |
Головне правило: ніколи не підписуйте контракт на заміну за результатами, які ви отримали до того, як почала працювати група D. Постачальник, оцінений за результатами невиміряного пошуку, також оцінюється за результатами демоверсії.
Примітка щодо числа, яке всі цитують
Вам буде показано статистику, яка говорить, що користувачі, які здійснюють пошук по сайту, конверсії вдвічі або втричі вищі, ніж ті, хто не здійснює пошук, зазвичай для того, щоб виправдати бюджет. Ця цифра широко поширюється через огляди постачальників (приклад) і рідко простежується до контрольованого дослідження. Це також ефект відбору: люди, які здійснюють пошук, – це люди, які вже мають намір здійснити покупку. Використовуйте це як привід розглядати пошук, а не як прогнозоване зростання. Обґрунтоване бізнес-кейс будується на основі вашого власного обсягу нульових результатів та вашого власного коефіцієнта співвідношення пошуку до покупки – для отримання обох цих показників існують пункти 17 та 18. [НЕОБХІДНІ ВНУТРІШНІ ДАНІ: показники нульових результатів клієнтів Switas до/після корекції, якщо такі є доступними для спільного використання.]
Де ця рубрика розпадається
Він створений для роздрібної торгівлі за каталогом. Торговельним майданчикам з багатьма продавцями одного й того ж товару потрібен вимір дублікатів оголошень та якості продавця, для якого в цій рубриці немає стовпця. Сайти з великим вмістом контенту та сайти державного сектору потребують зважування за типом документа та новизною, а не за групою А. Сайти з кількістю товарів менше ніж 500 часто отримують хороші результати, але все одно втрачають гроші на пошуку, оскільки з невеликим каталогом справжнім рішенням є краща навігація за категоріями, а не кращий пошук. Рубрика також нічого не говорить про швидкість пошуку під навантаженням і нічого про персоналізацію — обидва варіанти навмисні, оскільки обидва дорого тестувати належним чином, і жодна з них не є вашою проблемою при оцінці нижче 30. Зрештою, оцінка — це знімок: імпорт каталогу, який змінює найменування атрибутів, може знизити Групу А на шість пунктів за одну ніч без розгортання коду.
FAQ
Скільки часу триває нарахування очок? Приблизно півдня для однієї людини на один магазин, після того, як буде створено тестовий список із 90 запитів. Створення списку — це повільна частина; виділіть ще дві години, щоб вибрати найпопулярніші запити та створити довгий хвіст набору.
Чи потрібна мені інженерія, щоб запустити це? Ні. Перевірки з 1 по 15 виконуються у браузері. Для перевірок з 16 по 20 потрібен доступ до аналітики, а для перевірки 20 – діалог із власником конфігурації пошуку.
Що робити, якщо у нас немає історії аналітики пошуку? Оцініть групу D як нуль, виправте відстеження та зберіть дані за чотири тижні, перш ніж оцінювати решту. Тестовий список, створений без справжнього журналу запитів, буде перебільшувати кількість запитів, які б ввела ваша команда.
Чи є оцінка 28 гарною? Це нормально, а нормально – це посередньо — бенчмарк показує, що більшість сайтів знаходяться на такому рівні. Корисним сигналом є не загальна кількість, а те, яка група тягне його вниз.
Чи варто нам купувати толерантність до друкарських помилок чи розвивати її? Купити. Зіставлення відстані редагування з розумними порогами вирішене та недороге. Зусилля на побудову належать синонімам та структурі атрибутів, які є специфічними для вашого каталогу та не можуть бути придбані.
Як це пов'язано з аудитом сторінки категорії? Вони мають спільні аспекти та фільтрацію. Якщо перевірка 14 не проходить, виправлення зазвичай знаходиться в шаблонах категорій, а не в пошуку, тому запускайте два аудити в одному спринті.
Чи стосується щось із цього до торгових агентів зі штучним інтелектом, які читають наш каталог? Частково. Агенти використовують структуровані атрибути, а не ваш інтерфейс пошуку, тому групи A та B важливі для них через якість ваших даних, тоді як групи C та D взагалі не застосовуються. Це окремий аудит.
Як часто нам слід перераховувати результати? Щоквартально та після будь-якої міграції каталогу, реплатформування або зміни конфігурації пошуку. Зберігайте той самий список із 90 запитів, щоб результати можна було порівнювати.
Якщо ви хочете отримати результат, не витрачаючи цілий день: доручіть нам провести цей аудит вашої вітрини і надамо вам оціночну рубрику, запити, що не пройшли, та список пріоритетних виправлень.
Джерела
- Інститут Баймарда — UX-інтерфейс пошуку електронної комерції: 8 типів запитів та коефіцієнти відмов для кожного типу (оновлено у квітні 2026 р.)
- Інститут Баймарда — Звіт та порівняльний аналіз зручності використання пошуку в електронній комерції
- Інститут Баймарда — 5 перевірених UX-стратегій для сторінок, які «не дають результатів» (лютий 2025 р.)
- Консорціум Unicode — SpecialCasing.txt, правила регістру літер для турецької та азербайджанської мов
- Elastic — аналізатори мови, включаючи ланцюжок аналізаторів турецької мови
- Elastic — фільтр токенів згортання ASCII та preserve_original
- Довідка Google Analytics — Розширене вимірювання, view_search_results та search_term
- Hello Retail — приклад множника конверсії пошуку за сайтом, що циркулює в мережі
