На чем лучше реализовать фасетный поиск. В поисках верного пути: как фасетная навигация влияет на SEO (перевод). Почему все, что выше описано про фасеты, фасетный поиск и про фасетные блоки может не работать

Мы кратко рассмотрели установку и базовый синтаксис PINQ, портированную на PHP версию LINQ. В этой статье мы рассмотрим, как использовать PINQ для имитации возможности фасеточного (аспектного) поиска в MySQL.

В этой статье мы не будем рассматривать все аспекты фасеточного поиска. Интересующиеся люди могут поискать подходящую информацию в интернете.

Типичный фасеточный поиск работает следующим образом:

• Пользователь вводит ключевое слово, или несколько ключевых слов для поиска. Например, “маршрутизатор” для поиска продуктов, у которых в слово “маршрутизатор” встречается в описании, ключевых словах, названии категории, тегах и проч.
• Сайт возвращает список продуктов, подходящих под эти критерии.
• Сайт предоставляет несколько ссылок для подстройки условий поиска. Например, может позволить указать конкретных производителей маршрутизаторов, либо задать диапазон цен, или другие особенности.
• Пользователь может продолжать указывать дополнительные критерии поиска для того, чтобы получить интересующий его набор данных.

Фасеточный поиск весьма популярен, и является мощным инструментом, его можно наблюдать почти на любом сайте, связанном с электронной коммерцией.

К сожалению, фасеточный поиск не встроен в MySQL. Так что же нам делать, если мы всё-таки используем MySQL, но хотим дать пользователю такую возможность?

С помощью PINQ, в котором реализован аналогичный, мощный и простой подход, мы можем добиться такого поведения, как если бы мы использовали другие движки баз данных.

Расширяем демонстрационный пример из первой части

Замечание : весь код из этой части, и из первой части, можно найти в репозитории .

В этой статье мы расширим демонстрационный пример из первой части, добавив к нему существенное улучшение в виде фасеточного поиска.

Начнём с index.php , добавив в него следующие строки:

$app->get("demo2", function () use ($app) { global $demo; $test2 = new pinqDemo\Demo($app); return $test2->test2($app, $demo->test1($app)); }); $app->get("demo2/facet/{key}/{value}", function ($key, $value) use ($app) { global $demo; $test3 = new pinqDemo\Demo($app); return $test3->test3($app, $demo->test1($app), $key, $value); });

Первый маршрут переносит нас на страницу для просмотра всех записей, подходящих под поиск по ключевому слову. Чтоб не усложнять пример, мы выбираем все книги из таблицы book_book . На ней также будут отображён результирующий набор данных и набор ссылок для конкретизации критериев поиска.

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

Но в этом примере мы не будем реализовывать такое поведение - все фильтры будут отражать граничные значения оригинального набора данных. Это первое ограничение и первый кандидат на улучшение в нашем демонстрационном примере.

Как видно в вышеприведённом коде, реальные функции располагаются в другом файле, под названием pinqDemo.php . Давайте взглянем на соответствующий код, который предоставляет возможность фасеточного поиска.

Класс аспекта

Первым делом создадим класс, представляющий аспект. В целом, аспект должен содержать несколько свойств:

• Данные, которыми он оперирует ($data )
• Ключ, по которому производится группировка ($key )
• Тип ключа ($type). Может быть одним из следующих:
  • указывать полную строку, для точного совпадения
  • указывать часть строки (обычно - начальную), для поиска по шаблону
  • указывать диапазон значений, для группировки по диапазону
• если тип ключа - диапазон значений, необходимо определить шаг значения для определения нижней и верхней границы диапазона; или же если тип - часть строки, необходимо указать, сколько первых букв будет использоваться для группировки ($range)

Группировка - наиболее критичная часть аспекта. Вся агрегированная информация, которую, возможно, сможет вернуть аспект, зависит от критериев группировки. Обычно наиболее используемыми критериями поиска являются “Полная строка”, “Часть строки”, или “Диапазон значений”.

Namespace classFacet { use Pinq\ITraversable, Pinq\Traversable; class Facet { public $data; // Оригинальный набор данных public $key; // поле, по которому производится группировка public $type; // F: вся строка; S: начало строки; R: диапазон; public $range; // играет роль, только если $type != F ... public function getFacet() { $filter = ""; if ($this->type == "F") // вся строка { ... } elseif ($this->type == "S") // начало строки { ... } elseif ($this->type == "R") // диапазон значений { $filter = $this->data ->groupBy(function($row) { return floor($row[$this->key] / $this->range) * $this->range; }) ->select(function (ITraversable $data) { return ["key" => $data->last()[$this->key], "count" => $data->count()]; }); } return $filter; } } }

Главная функция этого класса - вернуть отфильтрованный набор данных, основываясь на исходном наборе данных, и свойствах аспекта. Из кода видно, что для различных типов счетов используются различные способы группировки данных. В вышеприведённом коде мы показали, как может выглядеть код, если мы группируем данные по диапазону значений с шагом, указанным в $range .

Задаём аспекты и отображаем исходные данные

Public function test2($app, $data) { $facet = $this->getFacet($data); return $app["twig"]->render("demo2.html.twig", array("facet" => $facet, "data" => $data)); } private function getFacet($originalData) { $facet = array(); $data = \Pinq\Traversable::from($originalData); // 3 примера создания различных объектов аспектов, и возврат аспектов $filter1 = new \classFacet\Facet($data, "author", "F"); $filter2 = new \classFacet\Facet($data, "title", "S", 6); $filter3 = new \classFacet\Facet($data, "price", "R", 10); $facet[$filter1->key] = $filter1->getFacet(); $facet[$filter2->key] = $filter2->getFacet(); $facet[$filter3->key] = $filter3->getFacet(); return $facet; }

В методе getFacet() мы делаем следующее:

• Конвертируем оригинальные данные в объект Pinq\Traversable для последующей обработки
• Создаём три аспекта. Аспект ‘author’ будет группировать по полю author , и реализует группировку по всей строке; аспект ‘title’ - по полю title с группировкой по части строки (по первым 6 символам); аспект ‘price’ - по полю price с группировкой по диапазону (с шагом 10)
• Наконец, извлекаем аспекты и возвращаем их функции test2 , чтобы их можно было вывести в шаблон для отображения

Вывод аспектов и отфильтрованных данных

В большинстве случаев фильтры будут отображены в виде строки, и будут вести к просмотру отфильтрованного результата.

Мы уже создали маршрут ("demo2/facet/{key}/{value}") для вывода результатов фасеточного поиска и ссылок фильтров.

Маршрут принимает два параметра, в зависимости от ключа, по которому производится фильтрация, и от значения для этого ключа. Функция test3 , которая привязана к этому маршруту, представлена ниже:

Public function test3($app, $originalData, $key, $value) { $data = \Pinq\Traversable::from($originalData); $facet = $this->getFacet($data); $filter = null; if ($key == "author") { $filter = $data ->where(function($row) use ($value) { return $row["author"] == $value; }) ->orderByAscending(function($row) use ($key) { return $row["price"]; }) ; } elseif ($key == "price") { ... } else //$key==title { ... } return $app["twig"]->render("demo2.html.twig", array("facet" => $facet, "data" => $filter)); }

В основном, в зависимости от ключа, мы применяем фильтрацию (анонимную функцию в выражении where), согласно переданному значению, и получаем следующий набор отфильтрованных данных. Также мы можем задать порядок фильтрации данных.

Наконец, мы отображаем исходные данные (вместе с фильтрами) в шаблоне. Этот маршрут использует тот же шаблон, который мы использовали в " demo2 ".

Нужно помнить, что аспекты, генерируемые нашим приложением, являются вложенными массивами. На первом уровне это массив всех аспектов, и, в нашем случае их три (соответственно, для author , title , price).

У каждого аспекта есть массив “ключ-значение”, так что мы можем итерировать его обычными методами.

Заметьте, как мы строим URL для наших ссылок. Мы используем и ключ внешнего цикла (k), и ключи внутренних циклов (vv.key) в качестве параметров для маршрута ("demo2/facet/{key}/{value}"). Размер массивов (vv.count) используется для отображения в шаблоне.

На первом изображении представлен изначальный набор данных, а на второй - отфильтрованный по диапазону цен от 0$ до 10$, и отсортированный по автору.

Здорово, у нас получилось имитировать фасеточный поиск в нашем приложении!

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

Возможные улучшения

В общем, это очень элементарный пример. Мы всего лишь прошлись по базовому синтаксису и концепциям, и реализовали их в виде рабочего примера. Как ранее было сказано, у нас есть несколько областей, которые можно улучшить для большей гибкости.

Нам необходимо реализовать “наложение” критерий поиска, так как текущий пример ограничивает нас возможностью применить фильтрацию поиска только к оригинальному набору данных, применить фасеточный поиск к уже отфильтрованному результату нельзя. Это самое большое улучшение, которое я могу представить.

Ограничения

Фасеточный поиск, реализованный в этой статье, имеет серьёзные ограничения (что, возможно, относится и к другим реализациям фасеточного поиска):

Мы каждый раз выбираем данные из MySQL

Это приложение использует фреймворк Silex. Как и в любом фреймворке с единой точкой входа, вроде Silex, Symfony, Laravel, его файл index.php (или app.php) вызывается каждый раз, когда происходит анализ маршрута, и выполняются функции контроллера.

Если посмотреть в код в нашем index.php , можно обратить внимание, что следующая строчка кода:

$demo = new pinqDemo\Demo($app);

вызывается каждый раз, когда отображается страница приложения, что значит, что каждый раз выполняются следующие строки кода:

Class Demo { private $books = ""; public function __construct($app) { $sql = "select * from book_book order by id"; $this->books = $app["db"]->fetchAll($sql); }

Будет ли лучше, если мы не будем использовать фреймворк? Что ж, несмотря на факт того, что разрабатывать приложения без фреймворков, является не очень хорошей идеей, могу сказать, что мы встретимся с теми же проблемами: данные (и состояние) не сохраняются между разными HTTP запросами. Это фундаментальная характеристика HTTP. Этого можно избежать, используя механизмы кеширования.

Мы сэкономили несколько SQL запросов, используя аспекты. Вместо того, чтобы передать один select запрос на выборку данных, и три запроса group by с соответствующими условиями where , мы выполнили только один запрос where , и использовали PINQ для получения агрегированной информации.

Заключение

В этой части мы реализовали возможность фасеточного поиска по коллекции книг. Как я и сказал, это всего лишь маленький пример, который есть куда ещё улучшать, и у которого есть ряд ограничений.

Facet API Bonus для Drupal 7 - это коллекция дополнительных Facet API плагинов и функциональных возможностей, прежде всего фильтра и плагинов зависимостей - и место для хранения большинства дополнительных расширений Facet API.

В настоящее время Facet API Bonus включает в себя:

Facet Dependency (Facet-ные Зависимости) : плагин зависимостей, чтобы сделать один фасет (например "категория продукта"), чтобы показать в зависимости от других фасетов или специфических фасетных активных пунктов (item-ов) (например, "тип содержимого" - это "продукт" или "сервис"). Очень гибкий, поддерживает мультифасеты, для зависимостей, а также регулярное выражение для определения зависимостей фасетного пункта (item-а) , так же как и параметр, как себя вести, если зависимость теряется.

"Exclude Items (Исключить позиции/айтемы)": Плагин для фильтра, для исключения определенных фасетных айтемов по их разметке / названию или внутреннему значению (например, за исключением "page-ей" с "типов содержимого»). Также возможны регулярные выражения.

(Продолжение следует...)

Как показать фасетный поиск на нефасетных страницах

Бывают случаи, когда на сайте при разработке необходимо вывести поисковые фасеты на нефасетных страницах. Например, Вы хотите, чтобы самые популярные категории отображались на главной странице, вместе с соответствующими счетчиками. Когда посетитель сайта нажимает на какую-либо категорию, его должно перенаправить на поиск по сайту, с нажатой категорией, выбранной в фасетах.

Чтобы все это сделать, есть блочный дисплей Views Facets, предусмотренный подмодулем search_api_facetapi

С его помощью можно легко использовать фасетные ссылки для любого поиска на любой желаемой Вами странице. С этой целью есть две опции:

Показать фасеты непосредственно в блоке вьюса

Необходимо или создать новый вьюс на основе поискового индекса, который вы хотите использовать, или изменить старый вьюс. Добавьте тип отображения "Facets block" (Фасетный блок) для просмотра и настройки "Facet field" (фасетного поля) и "Search page path" (Пути страницы поиска) в "Настройке блока".

Фасеты не будут выведены в предварительном просмотре, поэтому, чтобы проверить ваш вьюс, включите Ваш новый вьюсовый фасетный блок, зайдя Администрирование> Структура> Блоки, как вы обычно делаете для всех других блоков. Настройте блок, чтобы он отображался на тех страницах, на которых Вам необходимо его вывести.

Настройте любые (контекстные) фильтры, которые нужно применить к результату, который используется для фасетных ссылок (например, учитывать только категории для опубликованных нод определенного типа контента). Exposed фильтры игнорируются. Настройки формата и полей игнорируются, но вы также можете изменить настройки нажав на "Прочее".

Список фасетных ссылок будет выведен на страницах, которые были указаны.

Однако существуют некоторые ограничения в этом варианте:

Фасетные ссылки всегда будет оформлены в виде списка, невозможно будет переписать или отформатировать выбранное.
В частности, также невозможно использовать обычные Facet API виджеты для этих фасетов. Это потому, что достаточно сложно добиться повторного использования Facet API компонентов снаружи Facet API .
Если вы хотите отобразить фасеты для более чем одного поля, вы должны добавить дополнительные _вюсовые диспели для фасетного блока и каждый будет выполнять отдельный поисковый запрос при отображении.

Чтобы разрешить эти недостатки, существует второй вариант:

Вы также можете просто использовать дисплей фасетного блока, чтобы выполнить поиск, а затем использовать обычное Facet API для фасетных блоков чтобы вывести в них фасеты. Чтобы сделать это, создайте дисплей фасетного блока, как и раньше, но установите настройку "Скрыть блок" в настройках блока. Таким образом, на страницах, на которых появится блок, поисковый запрос выполняется, но блок будет скрыт.

Теперь вы можете создать фасетные блоки для этого поиска как обычно, на индексной станице на вкладке "Фасеты". Вы просто должны убедиться в том, что фасет активен для дисплея фасетного блока (обычно ID будет равен search_api_views: -facets_block) в "Display for searches" / "Search IDs . Затем, все обычные опции Facet API могут быть использованы для определения вида и поведения отображаемых фасетных блоков. Фасеты в этих блоках будут автоматически использовать путь, выданный во вьюсовых фасетных блоках в настройках "Путей поисковой страницы".

Тем не менее, есть также некоторые проблемы с этим подходом: Во-первых, в настоящее время не представляется возможным вывести тот же фасет в двух разных местах (# 1411160: Разрешить фасетуотображаться несколько раз в той же сфере). Таким образом, список фасетов на главной странице должен быть в той же области и месте, для поиска и быть отстилизирован так же. Обход этого по любому (или путем клонирования фасетного блока, или путем альтера (изменения) дисплея для перемещения блока) в настоящее время по-прежнему требуется кодинг (если вы не используете панели (или что-то аналогичное) для отображения блоков).

Вторая проблема - это то же самое, что описано в Часто задаваемых вопросах (Search API FAQs) - для того, чтобы фасетные блоки работали, вы должны убедиться, что вьюс выполняется перед тем, как блоками рендерятся. Однако, поскольку вы можете положить вьюсовый блок в любом регионе, (поскольку он любом случае не будет отображаться), это не должно быть слишком большой проблемой, чтобы найти положение, при котором это требование считается выполненным.

Добавление фасетного блока в панель

Почему все, что выше описано про фасеты, фасетный поиск и про фасетные блоки может не работать?

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

Показать последний уровень иерархической таксономии в мультифасетах

Полезная функция автоматически разделит иерархический словарь, после чего каждый уровень получит свой собственный фасетный блок и пользовательскую метку. Кажется, этот модуль уже имеет опцию для переписывания одиночного фасета. Поэтому, мы уже на полпути. Как трудно было бы сгенерировать фасетный блок для каждого уровня?

Эта опция будет особенно удобна для товарных категориях, где термины могут иметь несколько родителей, например, "размер" или "цвет". Если они отображаются в отдельных блоках, для пользователя гораздо более ясно, как перемещаться по фасетам вместо навигации по огромному фасетному дереву, где термины отображаются несколько раз...

Xитать полезную информацию про все это вот тут

Переводы сделаны на основе следубщих страниц.

Фасетная навигация - это тип структурирования сайта, при котором пользователи имеют возможность указывать разные фасеты (желаемые параметры), для того чтобы найти искомый товар или услугу.

Это дает возможность посетителям интернет-магазина без труда ориентироваться во множестве предложенных товаров или услуг, быстро приходя к искомому. Только при этом каждый пользователь осуществляет поиск по своему пути.

Лучше всего продемонстрировать принцип фасетной навигации на конкретном примере.

Например, вы собираетесь купить мобильный телефон в интернет-магазине. Вы хотите найти телефон определенной модели, цвета, цены, марки. Было бы удобнее и быстрее найти то, что вам нужно, сузив поиск, используя несколько или все параметры (фасеты).

Подобная подвижность структуры сайта позволяет без труда создавать целевые страницы для отдельных ключевых слов. Это может показаться достаточно простым на бумаге. На практике же все гораздо сложнее.

Рассмотрим основные затруднительные вопросы.

1. Как много фасетов необходимо, чтобы ваш сайт был качественно проиндексирован?

В идеале, «глубина» фасета не должна превышать 100 наименований. Это позволит поисковым роботам проиндексировать все страницы ресурса. Большинство специалистов по продвижению сайтов склонны полагать, что поисковые роботы могут распознать более 100 ссылок на одной странице.

Лучше всего придерживаться следующего мнения: так как большинство сайтов в любом случае имеют навигационные ссылки на каждой странице, количество ссылок на товары на отдельной странице не должно превышать 100.

2. Фасеты и поисковые фильтры

Возможно, на вашем сайте будут опции, которые вы захотите предложить посетителям, но которые не будут так важны с точки зрения поискового продвижения . Например, для посетителей очень удобно отбирать товар по нужному размеру, а вы на самом деле можете и не быть заинтересованы в индексации именно этой страницы ресурса. В таком случае воспользуйтесь фильтрами с применением Java Script и закройте определенные внутренние страницы от индексации .

3. Сортировка

Возможно, вы захотите включить дополнительные параметры выбора (например, цена товара, его популярность и т. д.). Конечно, для клиентов это очень удобно, но при этом существует риск возникновения дублированного контента. Если вы не хотите, чтобы одна и та же страница была индексирована поисковым роботом несколько раз из-за наличия различных навигационных путей ее нахождения, воспользуйтесь JavaScript или Ajax.

4. Проблема дублированного контента

При фасетной структуре сайта, проблема дублированного контента возникает из-за наличия различных навигационных путей к одной и той же странице. И если вы невнимательно отнесетесь к данному вопросу, то вы получите одинаковый контент на нескольких страницах.

Не важен навигационный путь, которым пользуется посетитель, чтобы найти конкретный товар. Важно, чтобы индексировался только один из путей. Для этого воспользуйтесь CMS. В противном случае одна и та же страница будет проиндексирована неоднократно.

И еще раз об уникальности контента…

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

Итак, вот что следует запомнить:

1. создавайте так много фасетов, сколько необходимо для размещения на одной странице не более 100 товаров;
2. убедитесь, что для каждой ключевой фразы, по которой вы хотите ранжироваться в поисковых системах, существует своя целевая страница;
3. неправильная сортировка может приводить к появлению дублированного контента, чтобы этого избежать используйте Ajax и Java Script для закрытия некоторых внутренних страниц от индексации;
4. не важно, каким навигационным путем пользователь находит ту или иную страницу, индексироваться должна только одна страница;
5. не забывайте: информационное наполнение должно быть интереснее и привлекательнее.

Организует на сайте так называемый фасетный поиск (фасетную навигацию). Смысл его в том, что результаты поиска можно уточнять с помощью различных характеристик материала - автор, тип, термин, дата создания и т.п.

Например если у вас интернет магазин по продаже электронной технике, и пользователь вводит в поиск фразу аудио плеер . На странице с результатами, помимо самих результатов, будут присутствовать фасеты:

- Раздел : аудиотехника (54), компьютерная техника (85)
- Брэнд : Apple (25), Samsung (68), iRiver (78)
- Наличие на складе : есть (456), нет (12)
- Цена : 100-1000$ (45), 1000-10000$ (12)

и т.д. В скобках будет указано число товаров (нод), которые соответствуют этим характеристикам. Кликая по ссылкам, пользователь будет сужать результаты поиска.

С одной стороны это альтернатива раскрытым фильтрам в Views, с другой альтернатива стандартному расширенному поиску.

Установка

Раздел Facets

В этом разделе можно указать, какие фасеты использовать при поиске. Например разрешить отбирать материалы по таксономии, дате добавления или автору. Число фасетов зависит от включённых модулей.

Раздел Results page

Display style - стиль вывода результатов поиска: Extracts значит выводить как при обычном поиске (подсвеченный текст, автор, дата); Teasers значит выводить тизеры материалов с помощью соответствующего node.tpl.php.

Use the Extracts display style selectively - Если опция отмечена, то стиль Extracts будет применяться всегда, если введено ключевое слово. Если не отмечать эту опцию то можно использовать модуль в качестве замены навигации по терминам таксономии.

Раздел Current search

Позволяет включить блок Текущий поиск , в котором отображаются условия поиска:

Популярное в рубрике:

Самсунг Галакси перезагружается сам по себе — Решения Galaxy note...

читать

Основные возможности Kaspersky Rescue Disk

читать

Макбук не подключается к wifi Макбук не видит вай фай

читать

Как заработать на WebMoney

читать

Последние Статьи

"Супра", планшет: отзывы покупателей

читать

Местонахождения судов в реальном времени

читать

Лучшие программы для Android Запись звонков от...

читать

Удаляем не читателей в Твиттере

читать

Подключаем интернет на ноутбуке: все возможные...

читать

Samsung Galaxy S IV – новый флагман...

читать

Как происходит управление скоростью вращения...

читать

Магнитный кабель USB TYPE-C с круглым...

читать

innovakon.ru
Мобильные телефоны и связь

• Редакция проекта
• Реклама на сайте

• Контакты
• Карта сайта

© 2024 Мобильные телефоны и связь