NovСинонимы проекта должны вести к одной сущности, а не склеивать разные фазы
Почему варианты названия проекта должны помогать найти одну сущность, не стирая различия между фазами, башнями и другими самостоятельными частями.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
Одно и то же название проекта легко встретить в нескольких вариантах: полное коммерческое имя, сокращение, прежнее написание, вариант без номера корпуса. Для человека это обычно одна и та же вещь — пока речь действительно идёт об одном проекте. Техническая проблема начинается там, где система делает следующий, слишком смелый шаг и решает, что похожие названия означают одинаковую сущность вообще во всех случаях. У недвижимости есть фазы, башни, корпуса и очереди, которые могут быть связаны общим брендом, но отличаться сроками, составом, документами и состоянием предложения.
Мне здесь важен простой результат: покупатель должен иметь возможность найти один проект по разным привычным названиям и при этом не потерять различия между его самостоятельными частями. Синоним нужен как вход к правильной сущности, а не как клей для всего, что звучит похоже.
Когда объединение помогает, а когда начинает искажать выбор
Представим условный проект «Резиденция у гавани». В старых материалах его называли «Гавань», в новых — «Резиденция у гавани — Пномпень». Если обе подписи относятся к одному и тому же объекту, разумно привести поиск, сохранённые ссылки и упоминания к одной карточке. Человеку не нужна искусственная конкуренция двух записей, которые описывают одно и то же.
Теперь добавим «Резиденция у гавани — вторая очередь». Название почти то же, бренд тот же, часть фотографий территории может совпадать. Но покупателю уже может быть важно другое: какая очередь построена, какая ещё строится, где находится конкретная квартира, к какому набору общих зон она относится, какой документ описывает именно эту часть. Если система автоматически решит, что «Гавань», «Резиденция у гавани» и «Резиденция у гавани — вторая очередь» — одна сущность без внутренних границ, удобство поиска превратится в потерю смысла.
Такой дефект редко выглядит как громкая техническая авария. Страница открывается, изображения показываются, поиск что-то находит. Ошибка проявляется в мелочах: отзыв от первой очереди оказывается рядом со второй; дата обновления одной части меняет впечатление о другой; квартира попадает в сравнение под общим названием без указания фазы; сохранённая карточка после обновления ведёт уже не к тому набору данных, который человек видел раньше. Внешне всё работает, но покупатель сравнивает смешанную сущность.
Поэтому я разделяю две задачи. Первая — распознать разные написания одного объекта. Вторая — сохранить самостоятельность связанных объектов внутри бренда. Эти задачи похожи только на уровне строки текста. Для продукта они противоположны: первая уменьшает дубли, вторая не даёт полезным различиям исчезнуть.
Сильная система должна уметь сказать: эти названия относятся к одной сущности; эти две сущности принадлежат одному проекту; эта запись — отдельная фаза; а вот здесь связь пока не подтверждена и автоматическое объединение преждевременно. Последняя ситуация особенно важна. «Не уверен» безопаснее, чем уверенно соединить записи только потому, что совпали несколько слов.
Покупателю нужна непрерывность, а не знание внутренней схемы
Человеку не нужно видеть технический справочник идентификаторов. Ему важно, чтобы знакомое название приводило к нужному объекту, а различия были видны там, где они меняют решение. Если человек сохранил квартиру в первой фазе, позднее переименование проекта не должно стирать эту связь. Если он ищет по старому названию, система может привести его к актуальной странице и объяснить современную подпись. Но если существует отдельная вторая фаза, интерфейс не должен делать вид, что история, готовность и условия автоматически общие.
Я проверял бы такую систему не вопросом «удалили ли мы дубли», а несколькими пользовательскими ситуациями. Находит ли старое название актуальный проект? Может ли покупатель отличить две очереди с похожими именами? Сохраняется ли выбранная квартира в той же фазе после изменения подписи? Не переносятся ли фотографии, статусы и даты между родственными, но разными сущностями? Можно ли увидеть, что две записи связаны, не выдавая их за одну?
Есть и обратный риск — раздробить один объект на множество технических копий. Тогда у проекта появляются разные страницы по языку, источнику или историческому написанию, каждая со своей частью данных. Один вариант показывает цену, другой — статус, третий попадает в поиск. Покупатель вынужден угадывать, какая запись настоящая. Поэтому отказ от склейки не означает любовь к дублям. Нужна одна устойчивая идентичность там, где реальность одна, и отдельные идентичности там, где реальность действительно различается.
Для меня хороший результат выглядит скучно — и это комплимент. Человек вводит привычное название, получает нужный проект, видит отдельные фазы и не замечает, сколько работы понадобилось, чтобы данные не смешались. Техническая система в таком случае не решает за покупателя, какая фаза «главная». Она сохраняет отношения между сущностями и даёт интерфейсу показать их без потери истории.
Синонимы полезны, когда помогают найти то же самое. Они опасны, когда начинают доказывать, что похожее — одинаковое. В каталоге недвижимости эта граница стоит внимания именно потому, что ошибка может долго оставаться незаметной: карточки выглядят правдоподобно, но факты уже принадлежат разным объектам.