Intelligent Product Discovery: пошук, фільтри та конфігуратори для складних каталогів

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

КОРОТКО

Що таке product discovery в магазині

Product discovery в e-commerce це все, що допомагає покупцеві пройти шлях від «мені потрібно щось таке» до потрібного товару: пошук, фільтри, сортування, зв'язки між товарами, порівняння та підбір. У продуктовому менеджменті ті самі слова означають інше, рішення про те, що будувати, і про це значення ми писали у статті Product Discovery: що варто знати, перш ніж починати проєктувати? Тут мова про магазин.

Проблема поширена навіть у великих рітейлерів. У дослідженні пошуку e-commerce за 2026 рік Baymard Institute оцінив пошук 56% вивчених сайтів як посередній або гірший. У ранішому дослідженні 69% сайтів не пропонували доречних підказок автодоповнення для запитів з невеликою помилкою (Baymard Institute, 2021). У цих магазинів є бюджети й команди, а їхні покупці все одно вводять запит і не отримують нічого корисного.

У Peretz Agency ми розглядаємо пошук товарів як частину архітектури магазину, а не як віджет поверх неї. Дані про товари, структура каталогу, пошук, логіка фільтрів, зв'язки між товарами та інтерфейс проєктуються разом, бо кожен із цих шарів обмежує інші.

Покупцеві не треба вивчати ваш каталог, щоб у вас купити.

ТРИВОЖНІ ОЗНАКИ

Коли каталог переростає фільтри

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

Жодна з цих ознак сама по собі не причина міняти платформу. Більшість із них причина подивитися, як влаштовані дані каталогу і як система ними користується.

ЩО МИ БУДУЄМО

Чотири групи інструментів

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

Фільтри, що розуміють контекст. Динамічна фасетна навігація показує лише ті фільтри, які важливі для поточної категорії: покупцеві постільної білизни потрібні розмір і тканина, а не поле напруги, яке стосується світильників. Залежності між атрибутами відображають те, як товари влаштовані насправді, тож вибір матеріалу чи моделі обмежує наступні варіанти, і неможливі комбінації просто не з'являються. Лічильники в реальному часі показують, скільки товарів залишилося після кожного вибору, і покупець не потрапляє на порожню сторінку.

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

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

Персональні рекомендації, якщо для них є дані. Історія переглядів, попередні замовлення та вподобання допомагають запропонувати альтернативи й супутні товари. Ми додаємо це лише там, де в магазину достатньо даних, бо рекомендації на бідних даних виглядають випадковими і підривають довіру до всього каталогу.

ПОШУК

Пошук мовою покупця

У пошуку розрив між мовою каталогу і мовою покупця видно найкраще. У картці написано «підковдра 200x220, сатин, 100% бавовна». Покупець вводить «м'яка постільна білизна на двоспальне ліжко». Пошук, який порівнює лише слова, нічого не знаходить, і покупець іде з певністю, що такого товару в магазині немає. В Україні до цього додається мова: той самий товар шукають українською і російською, а назви брендів пишуть то латиницею, то кирилицею.

Такий пошук ми спершу зробили для власного сайту, і ті самі принципи переносяться на магазини. Пошук на peretz.agency працює англійською, російською та українською. Він розуміє групи синонімів трьома мовами. Якщо нічого не знайдено, він пробує запит в іншій розкладці клавіатури, і «ctj», набране на англійській розкладці, перетворюється на «сео». Якщо й це не допомогло, він пропонує найближче слово зі словника самого сайту («Можливо, ви мали на увазі»), і лише потім показує результати з інших мовних версій, з позначкою про те, що він зробив.

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

Журнал порожніх пошуків найкраще ТЗ для каталогу, яке у вас буде.

Ранжуванню потрібні свої рішення. Товари, яких немає в наявності, ідуть у кінець видачі чи зникають? Чи може магазин підняти категорію або нову колекцію на сезон? Де закінчується релевантність і починається просування? Це бізнес-правила, і їм місце в технічному завданні разом із технологією пошуку, а не після неї.

АРХІТЕКТУРА

Шари під інтерфейсом

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

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

ЧОТИРИ ШЛЯХИ

Побудувати, розширити, оновити або прискорити

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

Побудувати. Для нового магазину дані про товари, структура каталогу, пошук, фільтри і шлях покупця закладаються від самого початку, і пошук товарів стає частиною вихідної архітектури, а не набором функцій, доданих після запуску.

Розширити. Усталена платформа часто дає добру основу, але її стандартні функції покривають не всі вимоги. Ми додаємо власну фільтрацію, зв'язки між товарами, пошук і торговельну логіку та зберігаємо те, що в платформі вже працює.

Оновити. Буває, що з платформою все гаразд, а окремі її частини перестали пасувати бізнесу. Ми переробляємо окремі механізми, перебудовуємо дані про товари і покращуємо логіку фільтрів, не замінюючи систему повністю.

Прискорити. Коли каталог і трафік ростуть, пошук і фільтрація стають важчими. Ми дивимося на запити, індекси, кешування, структури даних і сам застосунок, щоб магазин залишався швидким і далі.

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

SHTAYER

Текстиль: товари, що поєднуються

SHTAYER це преміальний текстильний бренд, і його нова платформа будується на Laravel: сайт для B2B, магазин для B2C, власна ERP і CRM, що працюють як одне ціле. Нова айдентика SHTAYER, яку ми розробили, це візуальна система для цього нового сайту.

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

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

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

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

SCHOEFFEL

Перли: швидкий вибір і глибоке вивчення

Для Schoeffel, перлового дому, заснованого 1921 року, пошук товару влаштований інакше. Один покупець хоче погортати колекцію, обрати колір перлів або довжину намиста й ухвалити рішення. Інший хоче докладно вивчити конкретний виріб, перш ніж іти далі. Це два різні способи обирати, і магазин має підтримувати обидва, не сповільнюючи жоден.

Перший рівень це швидкий вибір. Просто в каталозі покупець може змінювати ключові параметри виробу, наприклад колір перлів (білий, золотистий, таїтянський), діаметр і довжину намиста, і бачити, як змінюються виріб і його ціна, без повного перезавантаження сторінки. Каталог залишається про прикраси, а не про технічні таблиці.

Другий рівень це картка товару для покупця, який хоче розібратися в якості. Перли оцінюють одразу за кількома факторами: Геммологічний інститут Америки (GIA) називає сім факторів цінності, від розміру й форми до блиску, якості поверхні, якості перламутру та підбору (GIA, жовтень 2026). Картка Schoeffel планується навколо шести критеріїв: тип і походження, розмір, колір і відтінок, блиск, поверхня та підбір. Архітектура також залишає місце для лабораторних документів, наприклад звітів GIA і SSEF, і для докладних візуальних матеріалів, макрозйомки та огляду на 360 градусів, якщо вони є у виробу.

Ця глибина не має нічого коштувати першому покупцеві. Докладна інформація запитується, коли покупець доходить до потрібного розділу, а не завантажується разом зі сторінкою. Каталог залишається швидким, а повна історія перлини чекає на того, хто про неї запитає.

Кожен покупець має змогу заглибитися настільки, наскільки хоче.

ТРИХОКОСМЕТИКА

OpenCart розширили, а не замінили

Trichocosmetics працює на OpenCart. Замість того щоб перебудовувати магазин, ми оновили його до OpenCart 3.0.5.1 і перевели на PHP 8.4. Тепер каталог і бізнес вимагають від фільтрації більше, ніж дає стандартний модуль, у трьох пов'язаних сферах.

Швидкість пошуку і фільтрації. Стандартна фільтрація стає дорогою, коли комбінується багато атрибутів і опцій, бо кожен вибір може перетворитися на запит, що об'єднує таблиці товарів, атрибутів і опцій. Ми оцінюємо для цього індексовану архітектуру: окремий пошуковий рушій на кшталт Elasticsearch або пласкі індексовані таблиці для фільтрації, залежно від того, що пасуватиме каталогу і хостингу. Мета в тому, щоб база даних робила менше зайвої роботи, відповіді приходили швидше, а поведінка системи залишалася передбачуваною, коли каталог росте.

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

Сторінки фільтрів для пошукових систем. Деякі комбінації фільтрів збігаються з реальними запитами, наприклад безсульфатні шампуні від випадіння волосся. Такі комбінації можуть стати посадковими сторінками з зрозумілою адресою та власними title, H1 і meta description. Решту комбінацій краще тримати поза обходом: настанови Google щодо фасетної навігації, оновлені у грудні 2025 року, радять закривати такі адреси в robots.txt, якщо вони не потрібні в пошуку, і віддавати 404 для комбінацій без товарів. Увесь метод ми розібрали у статті Фільтри та фасетна навігація: як інтернет-магазини створюють тисячі сторінок-дублів.

Покращення наявної платформи не вимагає її заміни. Тут правильна відповідь у тому, щоб розширити її архітектуру тим, що справді потрібно бізнесу.

ШІ-ПОКУПЦІ

Пошук товарів для агентів, а не лише для людей

Каталог тепер переглядають не лише покупці. ШІ-асистенти та агенти для покупок шукають товари від імені людей і спираються на ті самі структуровані дані, що потрібні добрим фільтрам.

У нашому власному тесті ШІ-агент у звичайному браузері поклав у кошик потрібний товар в 11 із 15 великих американських інтернет-магазинів. Агент, який читає сторінки без браузера, так, як багато асистентів відкривають посилання, отримав сторінку товару лише в 6 із 15. У даних про товари, які читають машини, умови доставки описав лише один магазин із 13. Подробиці у статті Ми відправили ШІ-агента по покупки в 15 американських інтернет-магазинів. Ось де він здався.

Каталог із чистими атрибутами, реальними зв'язками між товарами та узгодженими даними обслуговує обидва типи покупців одразу. Робота, яка робить фільтри надійними для людей, робить магазин зрозумілим і для машин. Що має бути в цих даних, ми описали у статті SEO картки товару: описи, відгуки та структуровані дані, які приносять клік.

З ЧОГО ПОЧАТИ

Як починається проєкт із пошуку товарів

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

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

• Журнал пошуку: що покупці шукали й не знайшли, якими фільтрами користувалися і які покинули.
• Аудит каталогу: атрибути, їхні значення, дублі та зв'язки, які існують лише в головах працівників.
• Правила: які комбінації фільтрів заслуговують на свою сторінку, як поводяться товари, яких немає в наявності, що можна просувати.
• Прототип на реальних даних, перевірений на найскладніших товарах каталогу, а не на найчистіших.

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

Завдання в тому, щоб не змушувати покупців розбиратися у вашому каталозі, а змусити каталог працювати на них.

FAQ

Джерела

• Baymard Institute: E-Commerce Search Usability, Report and Benchmark
• Google Search Central: Managing crawling of faceted navigation URLs
• GIA: Pearl quality factors