drupal commerce с этим товаром покупают ?

Главные вкладки

Комментарии

Аватар пользователя neltharian neltharian 29 марта 2013 в 13:42

если честно там геморой еще тот.

http://drupal.org/project/recommender вот базовый модуль для подобного функционала от него надо плясать. но там надо уметь настраивать, а уменя за нехватковй времени разбираться с первого раза не получилось.

Может у вас выйдет... или ктото из местных гуру знает или читал.

Аватар пользователя Sun-fire Sun-fire 29 марта 2013 в 15:04

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

Плюсы:

  • не нужно почти ничего кодить;
  • конфигурируется в визуальном режиме.

Минусы:

  • для каждого типа товаров - своя вьюха и логика фильтров, иногда не простая;
  • не всегда работает производительно.
Аватар пользователя neltharian neltharian 29 марта 2013 в 15:28

"Sun-fire" wrote:
Самый простой вариант - для каждого типа товаров вьюха

ухх сильно геморно если типов много. как по мне

Аватар пользователя Sun-fire Sun-fire 29 марта 2013 в 15:56

"neltharian" wrote:
ухх сильно геморно если типов много. как по мне

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

Аватар пользователя Sun-fire Sun-fire 29 марта 2013 в 19:07

"Ламер v0.3" wrote:
я ручками вбиваю рекомендуемые товары.

Ню ню. А если (допустим) выводить предложения с учетом актуальности/наличия, и общим количеством товаров этак от 10-15К номенклатур? )))

Аватар пользователя Andruxa Andruxa 29 марта 2013 в 22:21

"Sun-fire" wrote:
для каждого типа товаров вьюха (блок)

а зачем для каждого типа своя вьюха?

для ноды-дисплея добавляем поле-нодрефренс на другие ноды-дисплеи со множественными значениями,
при редактировании добавляем ссылки на другие дисплеи

блоком на странице дисплея выводим представление с контекстным фильтром по id текущей ноды - делаем выборку всех нод-дисплеев, на которые ссылается текущая

одна вьюха, зачем больше?

Аватар пользователя qqqarmani qqqarmani 21 апреля 2013 в 23:16

Andruxa wrote:
"Sun-fire" wrote:
для каждого типа товаров вьюха (блок)

а зачем для каждого типа своя вьюха?

для ноды-дисплея добавляем поле-нодрефренс на другие ноды-дисплеи со множественными значениями,
при редактировании добавляем ссылки на другие дисплеи

блоком на странице дисплея выводим представление с контекстным фильтром по id текущей ноды - делаем выборку всех нод-дисплеев, на которые ссылается текущая

одна вьюха, зачем больше?

Тут будет больше всего конфликт с модулем commerce_price .
Вы делали так как написали ?

Аватар пользователя NikolayRR NikolayRR 30 марта 2013 в 17:05

Добрый день, коллеги!

Меня зовут Николай Хлебинский, я руковожу сервисом товарных рекомендаций для интернет-магазинов Retail Rocket. Приглашаю всех желающих протестировать наш сервис, он работает "из коробки", а установка не сложнее чем у Яндекс.Метрики или Google Analytics.

Мы сейчас в бете, поэтому бесплатны (и останемся таковыми ближайшие 2-3 месяца). Отдельного модуля для Drupal у нас пока нет, но внедрение очень простое: нужно поставить JS трекинг и разместить в шаблоне сайта html-код с нашим виджетом. Буду рад ответить на ваши вопросы здесь или по почте nh@retailrocket.ru

P.S.: если есть желающие разработать модуль для Drupal - тоже напишите мне, обсудим детали.

Аватар пользователя Andruxa Andruxa 30 марта 2013 в 19:18

Здравствуйте, Николай.

Расскажите, пожалуйста, поподробнее о своем сервисе.

Насколько я понял, он заключается в формировании ассортиментной матрицы - какие товары наиболее уместно предложить вместе с покупаемым/просматриваемым, чтобы вероятность их покупки была максимальной?

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

Спасибо.

Аватар пользователя Sun-fire Sun-fire 30 марта 2013 в 23:37

"Andruxa" wrote:
а зачем для каждого типа своя вьюха?

для ноды-дисплея добавляем поле-нодрефренс на другие ноды-дисплеи со множественными значениями,
при редактировании добавляем ссылки на другие дисплеи

блоком на странице дисплея выводим представление с контекстным фильтром по id текущей ноды - делаем выборку всех нод-дисплеев, на которые ссылается текущая

одна вьюха, зачем больше?

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

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

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

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

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

Аватар пользователя Andruxa Andruxa 31 марта 2013 в 2:05

"Sun-fire" wrote:
Но давайте смоделируем следующую ситуацию, близкую к реальной:
...
В каждой категории по две сотни товаров. Товары появляются в наличии, и исчезают по мере продажи в режиме, близкому к реальному времени.

"Sun-fire" wrote:
предлагать например к выбранному ноутбуку, одну (или несколько) из сумок, которая на текущий момент есть в наличии. Кроме того, используя настройки фильтров можно предлагать не один сопутствующий тип товара а несколько, например к ноутбуку предлагаем не только ноутбучные сумки, но и мышки.

сделать для словаря каталога рефренсы между терминами, например: ноутбук <-> сумки <-> мышки

на страницах товара выводить блоком представление, аргументами которого был бы id термина текущего раздела каталога, а результатом - список из N анонсов витрин, удовлетворяющих условиям:
- есть рефренс на раздел каталога, в котором она находится
- товар, продаваемый этой страницей, есть в наличии
отсортированный в соответствии с фантазиями отдела трейд-маркетинга

для зарегистрированных пользователей грузить ajax'ом это же представление, отсортированное, отфильтрованное и сгруппированное по id юзера, его роли и филдам
реализовав пользовательские фильтры с помощью Facet API

но, ~200 единиц товаров в одной категории - это, кмк, 5% интернет-гипермаркетов, и 15-20% к ним стремящихся, для остальных вполне подходит то, что я предложил

Аватар пользователя NikolayRR NikolayRR 31 марта 2013 в 11:18

"Andruxa" wrote:
Здравствуйте, Николай.
Расскажите, пожалуйста, поподробнее о своем сервисе.
Насколько я понял, он заключается в формировании ассортиментной матрицы - какие товары наиболее уместно предложить вместе с покупаемым/просматриваемым, чтобы вероятность их покупки была максимальной?
Как вы учитываете предпочтения магазина продавать тот или иной товар: его наличие, наценка на него, операционные расходы, связанные с продажей товара?
Спасибо.

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

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

Если вы сформулируете, как именно вы хотите учитывать маржинальность/расходы/габариты и т.п. - внесем план разработки!