http://drupal.org/project/recommender вот базовый модуль для подобного функционала от него надо плясать. но там надо уметь настраивать, а уменя за нехватковй времени разбираться с первого раза не получилось.
Может у вас выйдет... или ктото из местных гуру знает или читал.
Самый простой вариант - для каждого типа товаров вьюха (блок), которая по заданым фильтрам выводит определенные товары, которые мы рекомендуем. Например к ноутбукам рекомендуем сумки, мышки, и т. д.
Плюсы:
не нужно почти ничего кодить;
конфигурируется в визуальном режиме.
Минусы:
для каждого типа товаров - своя вьюха и логика фильтров, иногда не простая;
для ноды-дисплея добавляем поле-нодрефренс на другие ноды-дисплеи со множественными значениями,
при редактировании добавляем ссылки на другие дисплеи
блоком на странице дисплея выводим представление с контекстным фильтром по id текущей ноды - делаем выборку всех нод-дисплеев, на которые ссылается текущая
для ноды-дисплея добавляем поле-нодрефренс на другие ноды-дисплеи со множественными значениями,
при редактировании добавляем ссылки на другие дисплеи
блоком на странице дисплея выводим представление с контекстным фильтром по id текущей ноды - делаем выборку всех нод-дисплеев, на которые ссылается текущая
одна вьюха, зачем больше?
Тут будет больше всего конфликт с модулем commerce_price .
Вы делали так как написали ?
Меня зовут Николай Хлебинский, я руковожу сервисом товарных рекомендаций для интернет-магазинов Retail Rocket. Приглашаю всех желающих протестировать наш сервис, он работает "из коробки", а установка не сложнее чем у Яндекс.Метрики или Google Analytics.
Мы сейчас в бете, поэтому бесплатны (и останемся таковыми ближайшие 2-3 месяца). Отдельного модуля для Drupal у нас пока нет, но внедрение очень простое: нужно поставить JS трекинг и разместить в шаблоне сайта html-код с нашим виджетом. Буду рад ответить на ваши вопросы здесь или по почте nh@retailrocket.ru
P.S.: если есть желающие разработать модуль для Drupal - тоже напишите мне, обсудим детали.
Расскажите, пожалуйста, поподробнее о своем сервисе.
Насколько я понял, он заключается в формировании ассортиментной матрицы - какие товары наиболее уместно предложить вместе с покупаемым/просматриваемым, чтобы вероятность их покупки была максимальной?
Как вы учитываете предпочтения магазина продавать тот или иной товар: его наличие, наценка на него, операционные расходы, связанные с продажей товара?
для ноды-дисплея добавляем поле-нодрефренс на другие ноды-дисплеи со множественными значениями,
при редактировании добавляем ссылки на другие дисплеи
блоком на странице дисплея выводим представление с контекстным фильтром по id текущей ноды - делаем выборку всех нод-дисплеев, на которые ссылается текущая
одна вьюха, зачем больше?
Ну, Ваш способ это безусловно неплохой вариант, если нужно задать явственную связь что вместе с товаром А мы предлагаем именно товар В. Ваш вариант хорош именно для таких ситуаций, и будет в таком случае наиболее производительным.
Но давайте смоделируем следующую ситуацию, близкую к реальной:
Имеем например два типа товаров: ноутбуки и ноутбучные сумки. В каждой категории по две сотни товаров. Товары появляются в наличии, и исчезают по мере продажи в режиме, близкому к реальному времени.
Если использовать Ваш способ, то есть очень большая вероятность, что сопутствующий товар будет не доступным по причине отсутствия (еще не завезли или уже продали), или просто банально конент-менеджер не проставил привязку.
Поэтому исходя из личного опыта, я предложил именно универсальное решение, которое может предлагать например к выбранному ноутбуку, одну (или несколько) из сумок, которая на текущий момент есть в наличии. Кроме того, используя настройки фильтров можно предлагать не один сопутствующий тип товара а несколько, например к ноутбуку предлагаем не только ноутбучные сумки, но и мышки.
По поводу отдельной вьюхи для каждого типа товара - это я немного погорячился. Вьюха может быть одна, а вот разграничивать можно отдельными дисплеями, или например входящим аргументом - тут все зависит от архитектуры каждого отдельного проекта.
Но давайте смоделируем следующую ситуацию, близкую к реальной:
...
В каждой категории по две сотни товаров. Товары появляются в наличии, и исчезают по мере продажи в режиме, близкому к реальному времени.
"Sun-fire" wrote:
предлагать например к выбранному ноутбуку, одну (или несколько) из сумок, которая на текущий момент есть в наличии. Кроме того, используя настройки фильтров можно предлагать не один сопутствующий тип товара а несколько, например к ноутбуку предлагаем не только ноутбучные сумки, но и мышки.
сделать для словаря каталога рефренсы между терминами, например: ноутбук <-> сумки <-> мышки
на страницах товара выводить блоком представление, аргументами которого был бы id термина текущего раздела каталога, а результатом - список из N анонсов витрин, удовлетворяющих условиям:
- есть рефренс на раздел каталога, в котором она находится
- товар, продаваемый этой страницей, есть в наличии
отсортированный в соответствии с фантазиями отдела трейд-маркетинга
для зарегистрированных пользователей грузить ajax'ом это же представление, отсортированное, отфильтрованное и сгруппированное по id юзера, его роли и филдам
реализовав пользовательские фильтры с помощью Facet API
но, ~200 единиц товаров в одной категории - это, кмк, 5% интернет-гипермаркетов, и 15-20% к ним стремящихся, для остальных вполне подходит то, что я предложил
Здравствуйте, Николай.
Расскажите, пожалуйста, поподробнее о своем сервисе.
Насколько я понял, он заключается в формировании ассортиментной матрицы - какие товары наиболее уместно предложить вместе с покупаемым/просматриваемым, чтобы вероятность их покупки была максимальной?
Как вы учитываете предпочтения магазина продавать тот или иной товар: его наличие, наценка на него, операционные расходы, связанные с продажей товара?
Спасибо.
Именно так. Мы оперируем вероятностями исходя из того, как пользователи проявляют интерес к товарам. По сути, мы автоматизируем формирование upsell и cross-sell контента на основе анализа огромного количества данных. Сегодня сервис предлагает блок рекомендаций для главной страницы сайта, страниц товарных категорий, карточки товара и корзины.
Наличие товаров учитывается с помощью YML-файла, который наш сервис забирает от магазина раз в несколько часов, товары, которых нет в наличии, не рекомендуются. Маржинальность, потенциальные расходы и т.п. в данные момент не учитываются, однако, у нас есть API, которое в ответ на ID товара отдаст вам набор из рекомендованных ID, которые можно сортировать по вашему усмотрению.
Если вы сформулируете, как именно вы хотите учитывать маржинальность/расходы/габариты и т.п. - внесем план разработки!
Комментарии
если честно там геморой еще тот.
http://drupal.org/project/recommender вот базовый модуль для подобного функционала от него надо плясать. но там надо уметь настраивать, а уменя за нехватковй времени разбираться с первого раза не получилось.
Может у вас выйдет... или ктото из местных гуру знает или читал.
Самый простой вариант - для каждого типа товаров вьюха (блок), которая по заданым фильтрам выводит определенные товары, которые мы рекомендуем. Например к ноутбукам рекомендуем сумки, мышки, и т. д.
Плюсы:
Минусы:
ухх сильно геморно если типов много. как по мне
хе хе ) Ну то что геморно, это я согласен. Но для не больших магазинов может быть вполне приемлимо.
можно еще так http://drupal.org/node/1465920
я ручками вбиваю рекомендуемые товары.
Ню ню. А если (допустим) выводить предложения с учетом актуальности/наличия, и общим количеством товаров этак от 10-15К номенклатур? )))
Sun-fire neltharian Вам большое Спасибо.
Ламер v0.3 Ужас зачем писать такой бред !
а зачем для каждого типа своя вьюха?
для ноды-дисплея добавляем поле-нодрефренс на другие ноды-дисплеи со множественными значениями,
при редактировании добавляем ссылки на другие дисплеи
блоком на странице дисплея выводим представление с контекстным фильтром по id текущей ноды - делаем выборку всех нод-дисплеев, на которые ссылается текущая
одна вьюха, зачем больше?
Тут будет больше всего конфликт с модулем commerce_price .
Вы делали так как написали ?
модуль так работает.
Добрый день, коллеги!
Меня зовут Николай Хлебинский, я руковожу сервисом товарных рекомендаций для интернет-магазинов Retail Rocket. Приглашаю всех желающих протестировать наш сервис, он работает "из коробки", а установка не сложнее чем у Яндекс.Метрики или Google Analytics.
Мы сейчас в бете, поэтому бесплатны (и останемся таковыми ближайшие 2-3 месяца). Отдельного модуля для Drupal у нас пока нет, но внедрение очень простое: нужно поставить JS трекинг и разместить в шаблоне сайта html-код с нашим виджетом. Буду рад ответить на ваши вопросы здесь или по почте nh@retailrocket.ru
P.S.: если есть желающие разработать модуль для Drupal - тоже напишите мне, обсудим детали.
Здравствуйте, Николай.
Расскажите, пожалуйста, поподробнее о своем сервисе.
Насколько я понял, он заключается в формировании ассортиментной матрицы - какие товары наиболее уместно предложить вместе с покупаемым/просматриваемым, чтобы вероятность их покупки была максимальной?
Как вы учитываете предпочтения магазина продавать тот или иной товар: его наличие, наценка на него, операционные расходы, связанные с продажей товара?
Спасибо.
Ну, Ваш способ это безусловно неплохой вариант, если нужно задать явственную связь что вместе с товаром А мы предлагаем именно товар В. Ваш вариант хорош именно для таких ситуаций, и будет в таком случае наиболее производительным.
Но давайте смоделируем следующую ситуацию, близкую к реальной:
Имеем например два типа товаров: ноутбуки и ноутбучные сумки. В каждой категории по две сотни товаров. Товары появляются в наличии, и исчезают по мере продажи в режиме, близкому к реальному времени.
Если использовать Ваш способ, то есть очень большая вероятность, что сопутствующий товар будет не доступным по причине отсутствия (еще не завезли или уже продали), или просто банально конент-менеджер не проставил привязку.
Поэтому исходя из личного опыта, я предложил именно универсальное решение, которое может предлагать например к выбранному ноутбуку, одну (или несколько) из сумок, которая на текущий момент есть в наличии. Кроме того, используя настройки фильтров можно предлагать не один сопутствующий тип товара а несколько, например к ноутбуку предлагаем не только ноутбучные сумки, но и мышки.
По поводу отдельной вьюхи для каждого типа товара - это я немного погорячился. Вьюха может быть одна, а вот разграничивать можно отдельными дисплеями, или например входящим аргументом - тут все зависит от архитектуры каждого отдельного проекта.
сделать для словаря каталога рефренсы между терминами, например: ноутбук <-> сумки <-> мышки
на страницах товара выводить блоком представление, аргументами которого был бы id термина текущего раздела каталога, а результатом - список из N анонсов витрин, удовлетворяющих условиям:
- есть рефренс на раздел каталога, в котором она находится
- товар, продаваемый этой страницей, есть в наличии
отсортированный в соответствии с фантазиями отдела трейд-маркетинга
для зарегистрированных пользователей грузить ajax'ом это же представление, отсортированное, отфильтрованное и сгруппированное по id юзера, его роли и филдам
реализовав пользовательские фильтры с помощью Facet API
но, ~200 единиц товаров в одной категории - это, кмк, 5% интернет-гипермаркетов, и 15-20% к ним стремящихся, для остальных вполне подходит то, что я предложил
Именно так. Мы оперируем вероятностями исходя из того, как пользователи проявляют интерес к товарам. По сути, мы автоматизируем формирование upsell и cross-sell контента на основе анализа огромного количества данных. Сегодня сервис предлагает блок рекомендаций для главной страницы сайта, страниц товарных категорий, карточки товара и корзины.
Наличие товаров учитывается с помощью YML-файла, который наш сервис забирает от магазина раз в несколько часов, товары, которых нет в наличии, не рекомендуются. Маржинальность, потенциальные расходы и т.п. в данные момент не учитываются, однако, у нас есть API, которое в ответ на ID товара отдаст вам набор из рекомендованных ID, которые можно сортировать по вашему усмотрению.
Если вы сформулируете, как именно вы хотите учитывать маржинальность/расходы/габариты и т.п. - внесем план разработки!