План, как настроить поиск с автодополнением и исправлением опечаток для индийских названий товаров: синонимы, транслитерации и улучшения по аналитике.
Товар может быть в каталоге, но пользователь его не находит по простой причине: он вводит название не так, как оно записано в карточке. Поиск сравнивает строки слишком буквально, поэтому в ответ получает пустую или нерелевантную выдачу.
В Индии это заметнее, чем на многих рынках. Одно и то же слово встречается в разных языках и в разных привычных написаниях. Люди легко смешивают алфавиты: сегодня печатают латиницей, завтра тем же смыслом, но на местной письменности, а иногда пишут просто «как слышится».
Обычно поиск ломают такие ситуации:
Когда поиск ошибается, это сразу бьет по продажам. Пустая выдача заставляет уйти и купить в другом месте. Неверная выдача подталкивает к случайным товарам, повышает возвраты и снижает доверие. Параллельно растет нагрузка на поддержку: люди спрашивают «почему у вас нет X», хотя он есть.
Цель здесь не «умная математика», а понятный процесс: настроить автодополнение и исправление опечаток, собрать словарь синонимов и транслитераций, а затем улучшать его по аналитике реальных запросов.
Чтобы автодополнение и опечаткоустойчивость работали в Индии, заранее решите, какие варианты одного и того же товара вы считаете «одинаковыми». Люди ищут так, как говорят дома, а карточка товара чаще оформлена «официально» и по-английски.
Начните с самых частых типов расхождений. Обычно нескольких групп хватает, чтобы закрыть большую часть пропусков:
Дальше разделите то, что лучше нормализовать, и то, что лучше хранить как синоним.
Нормализация обычно подходит для единиц измерения и форматов записи (пробелы, точки, регистр). А бытовые названия и транслитерации удобнее держать в словаре, чтобы они участвовали и в автодополнении.
Пример: пользователь вводит “aata 5kg”, а в каталоге товар называется “Wheat Flour (Atta) 5 kg”. Поиск должен понять, что aata = atta, а “5kg”, “5 kg” и “5 kilo” - одна и та же фасовка. Отдельно учтите запросы вроде “Aashirvaad 5kg” или “atta Aashirvad”: бренд и категория меняются местами, но намерение одно.
Синонимы лучше брать не «из головы», а из данных. Хороший словарь растет из того, как люди реально пишут, и как ваш каталог реально описан.
Первый источник - сам каталог. Помимо названия товара, полезны подзаголовки, характеристики, теги и атрибуты. Часто именно там лежат «вторые имена»: тип (масала, дал), форма (whole, powder), бренд, размер упаковки.
Второй источник - поведенческие сигналы. Смотрите поисковые логи: что вводят, что кликают после поиска, где сразу уходят. Особенно важны два класса проблем:
«Почти ноль» часто означает плохие подсказки, неудачные синонимы или то, что нужный товар в выдаче слишком низко.
Что стоит собирать и регулярно проверять:
Практика: если в поддержку пишут «atta for roti», а в каталоге стоит «wheat flour», добавьте связку не только «atta = wheat flour», но и контекстные варианты («roti flour», «chapati flour»). Затем проверьте по логам, что люди кликают и покупают.
Синонимы лучше хранить отдельно от карточек товаров. Если править названия прямо в каталоге, вы ломаете витрину (брендовые требования, единый стиль, выгрузки) и все равно не закрываете «народные» варианты. Отдельный словарь можно подключать к поиску, автодополнению и обработке опечаток, не трогая контент.
Основа словаря - группы, где один смысл объединяет разные написания. Внутри группы держите «каноническую» форму (что показывать в выдаче и подсказках) и варианты (как люди вводят).
Чтобы словарь не превратился в свалку, заранее разделите уровни совпадения:
Дальше ограничивайте синонимы контекстом. Один термин может означать разное в специях и в косметике, поэтому у группы должен быть «контекст применения» (категория, бренд, тип товара). Тогда слово вроде «масала» не потянет случайные результаты там, где это не нужно.
Полезно добавить служебные поля, чтобы управлять качеством и откатами:
В Индии один и тот же товар пишут латиницей, на хинди, на языках штатов и часто вперемешку (Hinglish). Без транслитерации вы потеряете часть спроса даже на простых вещах вроде специй и муки.
Транслитерация нужна в двух случаях: когда в каталоге название на английском, а пользователь вводит на хинди (или наоборот), и когда слово живет в разговорной латинице (jeera, haldi, atta), но люди пишут «как слышат» (jira, huldi, aata). Отдельно поддержите смешанный ввод: запрос может начинаться латиницей и заканчиваться местным словом.
Сначала сделайте нормализацию ввода, чтобы не плодить «синонимы из мусора»:
Дальше задайте правила «похожести по звучанию», но с ограничителями. Фонетические варианты полезны для коротких товарных слов (jeera/jira), но агрессивное исправление быстро превращается в шум.
Где лучше отключать жесткую коррекцию или требовать больше контекста:
Практика: транслитерации и «разговорные» варианты храните как синонимы к базовому термину. Исправление опечаток включайте только после нормализации и с лимитами для коротких запросов.
Автодополнение работает, когда оно помогает выбрать правильный путь за 1-2 клика, а не показывает «все подряд». Для индийских названий это особенно важно: пользователь может писать латиницей, с пробелами или без, и ждать подсказку еще до того, как он вспомнит «правильное написание».
Подсказки удобнее смешивать по типам:
Сортировку лучше строить не только по популярности. Рабочее правило: выше то, что с большей вероятностью можно купить прямо сейчас и что соответствует намерению.
Практичный порядок факторов: (1) точность совпадения, (2) наличие, (3) популярность за последние 7-14 дней, (4) актуальность по сезону или промо, (5) бизнес-приоритет (например, маржинальность), но не выше наличия. Если товар закончился, его можно показывать ниже или помечать, а не скрывать полностью.
Фасовку добавляйте в подсказки по ситуации. «atta 1kg» и «atta 5kg» - разные решения. Подсказки по весу и объему лучше показывать, когда пользователь уже ввел число или единицу, или когда запрос явно про продукт, который обычно выбирают «по размеру».
Не меняйте смысл запроса молча. Безопаснее показывать «Вы имели в виду ...» отдельной строкой и оставлять исходный ввод как вариант. Автоисправление без выбора подходит только для очевидных опечаток (1-2 символа) и только если результат совпадает по категории.
Полезный подход - два режима: мягкий (подсказка с выбором) по умолчанию и жесткий (сразу исправлять) только для узкого списка «железных» случаев.
План ниже помогает запустить поиск без лишней «магии». Логика простая: сначала собираем данные, затем улучшаем то, что реально влияет на покупки.
Начните с логирования. Нужно видеть сам запрос, что человек кликнул в выдаче и купил ли он после поиска (хотя бы в окне 24 часов). Без этого любые правки будут спором «на ощущениях».
Параллельно сделайте нормализацию: нижний регистр, удаление лишних пробелов, одинаковая обработка точек и дефисов, простая замена «ё» на «е». Добавьте короткий список стоп-слов (например, «купить», «цена», «доставка»), но только если они мешают ранжированию.
Запустите autocomplete на популярных реальных запросах и названиях категорий. Сначала сортируйте подсказки по частоте и конверсии, а не по «умности». Если запрос “besan” часто приводит к покупке, он должен быть выше редких вариантов.
Добавляйте толерантность к опечаткам постепенно. Введите ограничения: не включать fuzzy-поиск для очень коротких запросов (1-2 символа), ограничить расстояние правки, отключить исправление для брендов с похожими названиями. Иначе пользователь набрал “atta” и внезапно увидел специи.
Подключайте словарь синонимов и правила транслитерации точечно, начиная с топ-50 запросов. Добавляйте пары только когда видите в логах нулевую выдачу или низкие клики.
После запуска держите ритм: раз в неделю смотрите метрики (доля запросов без результатов, клики по подсказкам, конверсия после поиска) и делайте 5-10 правок. Гораздо полезнее небольшие изменения, чем редкие «переписывания всего».
Понять, что поиск полезен, можно только по цифрам. При большом количестве вариантов написания «кажется, что стало лучше» почти всегда обманывает.
Первое, что стоит смотреть, - нулевые результаты. В отчете держите долю запросов с нулем и список топ-запросов, где люди ничего не находят.
Дальше смотрите на клики. Отдельно полезны CTR по выдаче и CTR по подсказкам. Если подсказки кликают хорошо, но после клика люди быстро уходят, значит подсказка обещает не то: например, подсовывает бренд вместо категории или ведет на нерелевантные товары.
Самая честная метрика - конверсия после поиска. Считайте хотя бы добавления в корзину после поиска и покупки после поиска. Хороший поиск обычно поднимает эти показатели, даже если общий трафик не растет.
Не забывайте про скорость. Замеряйте p95 времени ответа поиска и отдельно скорость подсказок, особенно на мобильных. Если подсказки тормозят, ими перестают пользоваться.
Минимальный набор событий:
Поиску нужен простой ритм улучшений: смотрим данные, правим по одной причине за раз, проверяем результат. Иначе вы будете добавлять синонимы и подсказки «на глаз», а конверсия не сдвинется.
Хорошая практика - раз в неделю разбирать топ-50 проблемных запросов. «Проблемный» не значит редкий. Это запросы, где много показов и кликов, но мало покупок, или где люди часто переформулируют запрос (например: atta -> aata -> wheat flour).
Еженедельный ритуал:
Изменения проверяйте на одинаковой выборке запросов, сравнивая «до/после» на одинаковом периоде.
Даже если поиск уже работает, он может начать вредить продажам. Обычно дело не в одной крупной ошибке, а в нескольких мелких настройках.
Слишком широкие синонимы. Если склеить разные товары одним словом, выдача становится шумной. Пользователь видит «не то» и уходит.
Опечатки без ограничений. Если разрешить слишком большую «похожесть» для коротких слов, запросы начинают прыгать по смыслу.
Подсказки только по популярности. Верх автодополнения забивают общие слова вроде rice или oil, и подсказки не помогают уточнить выбор.
Игнорирование наличия. Подсказки, которые уверенно ведут в товары вне наличия, выглядят как обман.
Смешивание брендов и категорий без правил. Если бренд совпадает со словом категории, он перетягивает выдачу на себя.
Перед правками полезно быстро проверить:
Поиск чаще ломается не из-за алгоритма, а из-за отсутствия опор: данных, правил нормализации и понятного процесса обновлений.
Сначала убедитесь, что сможете измерять эффект. Без связки запрос -> клик -> корзина -> покупка легко спорить «на вкус».
После этого сделайте короткий прогон на 20-30 реальных запросах: с опечатками, со смешанными алфавитами, с измерениями.
Рутина должна занимать 30-60 минут и давать конкретные правки.
Представьте каталог индийских продуктов, где одна и та же мука встречается по-разному: “atta”, “aata”, “chakki atta”, “wheat flour”. Пользователь набирает “aata” или “atta”, а вы хотите, чтобы он попадал в одну и ту же группу товаров, а не в пустую выдачу.
Здесь хорошо работает связка: синонимы + транслитерация + аккуратная обработка опечаток. В словаре вы задаете, что “aata”, “atta”, “आटा”, “wheat flour”, “chakki atta” ведут к одному нормализованному ключу, например “atta flour”. Дальше этот ключ связывается с карточками: бренды, помол, фасовка (1 кг, 5 кг), подкатегории вроде «цельнозерновая» или «для чапати».
Автодополнение помогает не только «угадать слово», но и подсказать правильный выбор. Когда пользователь вводит “att…”, подсказки можно показать так: сначала категория (“Мука Atta”), затем частые уточнения (“Chakki Atta 5 кг”), потом бренды.
С опечатками важно не переусердствовать. Если пользователь набрал “atat”, исправление должно быть мягким: предложить “atta” как вариант, но не подменять запрос на другой продукт.
Понять, что поиск стал полезнее, помогают сигналы из аналитики:
Не пытайтесь покрыть все варианты сразу. За 2-4 недели реально собрать MVP, который снимет основные потери, а дальше улучшать его по данным.
Начните с минимума: выгрузите топ запросов, топ запросов с нулевым результатом и составьте стартовый словарь на 100-300 синонимов. В индийских названиях это обычно локальные варианты, простые сокращения, популярные бренды, транслитерации и смешанные написания.
Дальше договоритесь о правилах, чтобы поиск не стал непредсказуемым: где вы автоматически исправляете опечатку (когда уверены), а где только показываете альтернативу (когда есть риск подменить смысл).
Назначьте владельца словаря (часто контент-менеджер или категория) и человека, который подтверждает изменения (поиск/продукт). Введите короткий регламент: что добавляем сразу, что только после проверки, как быстро откатываем ошибку.
Если нужен быстрый старт разработки и тестирования, такие изменения удобно прогонять в TakProsto (takprosto.ai): в planning mode разбить работу на шаги, проверять правила на реальных данных и при необходимости быстро откатываться через snapshots и rollback, а затем экспортировать код и развернуть в своем окружении.
Потому что поиск часто сравнивает строки слишком буквально. Один и тот же товар люди пишут по-разному: транслитерацией (khakhra/khakra), местным словом (besan) вместо «официального» (gram flour), со слитным написанием (garammasala) и с опечатками. Если не нормализовать ввод и не подключить синонимы, запросы будут давать ноль или нерелевантную выдачу.
Начните с того, что чаще всего ломает выдачу:
Эти группы обычно дают максимальный эффект при минимуме работы.
Базово делайте два слоя:
Нормализация убирает «мусор», а словарь расширяет смысловые совпадения.
Опирайтесь на данные, а не на догадки:
Дальше добавляйте синонимы точечно под конкретные проблемные запросы.
Держите словарь отдельным от карточек и группируйте варианты вокруг «канонической» формы.
Практичная схема внутри группы:
Так проще контролировать качество и быстро откатывать неудачные изменения.
Сделайте три правила безопасности:
Отдельно поддержите смешанные запросы (часть латиницей, часть местной письменностью): их лучше обрабатывать тем же пайплайном нормализации и словаря.
Показывайте подсказки так, чтобы пользователь за 1–2 клика попадал в нужный смысл:
Сортируйте не только по популярности: выше ставьте точное совпадение и наличие, затем свежую популярность и только потом бизнес-приоритеты.
Безопасный дефолт — не подменять запрос молча. Лучше:
Также задайте лимиты: отключайте fuzzy для 1–2 символов, осторожно с числами/моделями и с похожими брендами.
Минимальный рабочий план:
Дальше поддерживайте ритм: раз в неделю 5–10 правок по данным, а не «большая переделка раз в квартал».
Смотрите на метрики, которые напрямую связаны с тем, «нашли ли и купили»:
Чтобы правки были управляемыми, фиксируйте для каждого изменения причину и возможность отката. Для быстрой проверки гипотез удобно работать через режим планирования и снапшоты (например, в TakProsto), чтобы тестировать правила на реальных данных и быстро возвращаться назад при шуме в выдаче.
