imac
Вы делаете ошибку. Не как разработчик. На уровне продуктового маркетинга.
Ограничиваете сферу применения cs-cart
Сейчас сфера применения cs-cart как движка и-магазина ограничена малыми компаниями, в некоторых сферах - средними компаниями (которые не растут, или с большими оговорками), а сейчас окончательно ограничиваете применимость для средних компаний в сфере fashion
Чуть поясню.
1.
Малые компании работают как получится, как придется и как попало. И здесь никаких проблем. Временно подстроятся подо все. Средние ( а тем более крупные) компании работают с SKU. Им нужна однозначность. Во всех операциях, в которых участвует SKU.
Cs-cart и так неидеален с точки зрения работы с SKU (пытался говорить об этом в предыдущих постах) И увеличение этой неидеальности (добавление виртуальных SKU ) ухудшает эту ситуацию.
2.
У малых компании горизонт планирования 3-6 месяцев. У средних - 2-3 года. Выбирая движок-платформу - изучают перспективы платформы. И то, что cs-cart ограничивается одиночками или малыми компаниями (игнорируя, или не видя потребностей средних компаний), это исключает его из числа возможных претендентов на несколько лет вперед.
Моя печаль, как проектировщика систем, в том, что мне интересен рынок средних компаний, или малых, с хорошим потенциалом вырасти до средней. Как говорил, в некоторых сферах, с оговорками, можно использовать cs-cart как движок.
Хотелось, чтобы было с чем и на рынок fashion выходить.. Чтобы ограничения движка уменьшались, а не росли.. :-(
Вы поняли, о чем говорю и что имею в виду?
Вы поняли, о чем говорю и что имею в виду?
Я понял о чем вы говорите, но не понял каким именно действием или реализацией чего конкретно, по вашему мнению, я ограничу применимость CS-Cart для средних компаний? Если поясните что конкретно в посте о реализации привело вас к этом мысли буду благодарен.
imac
Про продуктовый маркетинг и позиционирование продукта - это длинно и точно не формате форума, и не публично...
Пробую дать ответ как можно короче.
в средних компаниях участвует в принятии решения много позиций и у каждой свои KPI и свои интересы.
Один из сценариев, где всего 2 позиции...
Руководство приходит к мысли о необходимости через 2 года в составе бизнеса иметь и-магазин. Ставится задача Директору по IT проработать вопрос.
Напомню - компания средняя, у нее своя история, в течении которой уже накопилось и используется туча оборудования, софта, взаимодействующего и обменивающегося данными между собой, ежедневно генерирующего десятки отчетов для разных служб, на основании которых и строится вся деятельность.
KPI директора по IT зависит от бесперебойности работы этой системы. Но директор по IT не дурак и понимает, что все что он делает, делает для продаж. Поэтому Директор по IT делает запрос Директору по маркетингу - какие функции и-магазина нужно обеспечить?
KPI директора по маркетингу зависит от количества чеков и среднего чека. Он живет в этом мире: https://dreamkas.ru/blog/srednii-check/, http://hobiz.ru/lib/fraud/9-sposobov-uvelichit-srednij-chek/ , https://delovoymir.biz/11-sposobov-uvelichit-sredniy-chek.html (ссылки для примера)
Весь софт существующей компании уже заточен на реализацию этой философии. И, не мудрствуя лукаво, Директор по маркетингу отписывает Директору по IT - и-магазин должен быть встроен во все наши системы учета и поддерживать все наши маркетинговые программы.
Директор по IT пишет список маркетинговых программ, которые зашиты в процессах компании и его софте - "на карточке товара должны быть:
- дополнительные услуги к товару,
- дополнительные товары
- обязательные товары
- сопутствующие (рекомендуемые) товары
- комплекты, в которых участвует товар
- аналогичные товары с другими, близкими характеристиками (список вариаций)
- похожие товары (другие товары с такими же характеристиками)
Далее он смотрит в интернете какой-нибудь авторитетный, с его точки зрения, рейтинг по надежности CMS (помним о его KPI), например: https://roem.ru/14-04-2015/192219/cms-highload/ ,
идет на сайты CMS, смотрит список партнеров-интеграторов и отправляет запросы-список требований указанных выше и добавляет, что существующая система учитывает товар по SKU и данные и связи между данными передаются в CMS из существующих систем через SKU и передавать в существующий софт из и-магазина тоже через SKU.
Собирает отклики, и для тех CMS, чьи партнеры откликнулись, начинает изучать логическую структуру данных (проверять честность и компетентность партнеров)
И даже если партнеры cs-cart отписали ему, что в cs-cart, как в Греции, все есть, он конечно проверит...пусть и поверхностно, на уровне логической структуры данных...
Логическая структура данных CMS связи с внешним миром отражена в файле экспорта-импорта.
в файле экспорта-импорта он видит
1) вау! здесь товары, оказывается, существуют разных типов, и изменить тип товара, без изменения его связей, невозможно. Он что, для всех товаров существующих и будущих должен организовать определение типа? навсегда? и следить за его соответствием будущим потребностям?
2) вау! тут связи между товарами формируются в зависимости от местоположения строки в файле.. То есть сбой софта, людей, приведет к краху данных и отследить это программно нельзя и как потом править? руками?
3) вау! тут присутствуют виртуальные SKU... и что делать, если эти чужеродные SKU попадут в его софт? сегодняшний и будущий? править руками? или каждый раз сверку SKU делать по всей базе?
4) вау! а тут связи типа доп.товары, обязательные, требуемые и т.п. отсутствуют вообще и с SKU не работают, да и назначаются только руками
Директор по IT (напомню, у него целый зоопарк разного софта и главное для него - однозначная устойчивая и бесперебойная связь данных внутри этого зверинца, во вторую очередь - подготовить инструмент для Директора по маркетингу) вычеркивает cs-cart из своего списка и переходит изучать предложения партнеров следующей CMS.
Описал один из сценариев, можете сказать, что все происходит совсем по другому. Спорить не буду...
Про потребности, приоритеты и специфику принятия решений у средних компаний примерно понятно? Про ограничения понятно?
Тут, на форуме, уже был пост (не помню кто писал), что ЗА ДЕНЬГИ спецы по 1С ОТКАЗАЛИСЬ (сказали-невозможно) сделать интеграцию с данными cs-cart. Ну понятно, что не в криворукости или знании commerceML дело, а либо в неполноте, либо в неоднозначности связи данных. Нехороший звоночек. 1С - это типовой софт, не экзотика. Жаль, не помню кто писал, любопытно на данные взглянуть.
Давайте еще короче.
На основе логической структуры данных - файла экспорта.
* Должна быть однозначность навсегда. Одна строка - один SKU-код. И все данные по SKU - в одной строке экспорта-импорта. Это исключает неоднозначность и уменьшает ошибки приема-передачи данных стороннему софту.
* Должен быть один тип товара, у которого могут быть разные типы связей (участие в вариациях, назначенные доп.товары, назначенные обязательные товары, назначенные рекомендуемые товары, участие в комплектах и т.п.) с другими товарами на основе SKU. Как это обеспечить на логическом уровне? Предложения выше были. Можно продолжить обсуждение. Как реализовать во внутренней архитектуре? Да, тут наверняка есть сложности, но зависит только от Вас и Вашего коллектива. Это - вызов: справитесь или не справитесь?
И еще момент. Маркетологи-продавцы - они же безбашенные. Маркетолог, не генерирующий и не проверяющий каждую неделю новую идею по повышению среднего чека - не продавец. И тут закладываться надо на будущее. Не стоит ограничивать возможность участия SKU в нескольких вариациях. Это несложно заложить сразу. Маркетологу нужны ВСЕ возможные связи товара ОДНОВРЕМЕННО (чтобы отразить их на карточке товара). Нужно заложить возможность покупателю самому конструировать свой комплект товаров. Реализовывать, конечно, поэтапно.
Ну это если совсем-совсем коротко, по верхушкам...
Я ответил на Ваш вопрос?
Ну это если совсем-совсем коротко, по верхушкам...
Я ответил на Ваш вопрос?
Нет.
Я написал план реализации, вы ушли в маркетинг и мотивацию при выборе CMS, но что конкретно вас подтолкнуло в моем посте на обсуждение этих вопросов вы не написали.
Я продублирую вопрос
>не понял каким именно действием или реализацией чего-то конкретного, по вашему мнению, я ограничу применимость CS-Cart для средних компаний?
imac
Предлагаю завершить углубление в продуктовый маркетинг.
Был неправ, необдуманно, не по адресу позволил себе высказать необоснованные претензии.
Извините. Извинения приняты?
Технический вопрос, как к разработчику.
Родительский продукт - это реальный SKU или виртуальный-фейковый?
Виртуальный, тот к которому привязаны все вариации
При импорте вариаций,
код родительского продукта должен быть уникальным или не обязательно?
код родительского продукта создается автоматически, или его нужно формировать заранее?
Если формировать - можно его формировать произвольно при каждом импорте?
Или он должен быть одним и тем же и его нужно сохранять где-то во внешних системах?
Что будет в базе при ежедневном импорте прайс-листов, если код родительской вариации формировать произвольно, при подготовке прайс-листа для импорта?
imac
Вопросы заданные в предыдущем посте - снимаются, проверил на http://dev.demo.cs-cart.ru/?url=admin.php
Структура файла экспорта импорта сейчас и то, о чем описывал словами в предыдущих сумбурных постах, представлено на скриншоте.
Отобразил то, что есть сейчас, и то, как можно, на мой взгляд, улучшить
[url=https://b.radikal.ru/b13/1802/53/8e4ed8621e91.jpg]
[/url]
а возможно как то всю базу товаров перевести на вариации с опций... не вводя товары заново?
imac
Предлагаю завершить углубление в продуктовый маркетинг.
Был неправ, необдуманно, не по адресу позволил себе высказать необоснованные претензии.Извините. Извинения приняты?
Вы уж через чур официально) Я все ваши сообщения воспринимаю как дискуссию и обратную связь. За что вам очень благодарен. То что ушли немного в сторону - бывает.
Что касается фильтров план пока такой, попробуем сделать синхронизацию опций с характеристиками, чтобы можно было удобно работать с фильтрами. А дальше будем смотреть.
imac
Не стоит благодарить :-) Спасибо.
Важнее иное- Вы посмотрели пример-структуру файла импорта-экспорта?
Все ли понятно?
Видите ли какие изъяны-ограничения в приведенной структуре? Для обработки-учета вариаций? Комплектов товаров? Дополнительных товаров? Обязательных(требуемых) товаров? Сопутствующих(рекомендуемых) товаров?
Или уже с вариациями обратной дороги нет? Так и будет требоваться отдельная строка с виртуальной родительской вариацией и тремя типами товаров?
Илья, еще один момент вообще по функционалу фильтров. Он уже несколько раз упоминался на форуме.
Точнее два момента:
- «Всплывание» выбранного фильтра
- Обновление страницы
У нас клиент может искать соседние роста, соседние размеры, соседние комбинации роста/размера. При выборе одного варианта, он «выпрыгивает» вверх. Некоторых просто нереально выбешивает. Ну с чего это вдруг размер 60 становится раньше 44-го? Это же совершенно нелогично?
Как я понимаю, на сегодня простого решения, как отключить эту функцию, нет. Были предложения закомментировать строку типа
scroll: '.ty-mainbox-title',
в файле js/tygh/product_filters.js
только это ни к чему не приводит. Во всяком случае, у меня ничего не вышло, кеш весь удалял.
Ну и обновление страницы каждый раз при наборе последовательности фильтров тоже может доставлять кучу отрицательных эмоций.
Нужна кнопка «Обновить» или «Применить». Просто представьте, вам нужен летний полукомбинезон из хлопка с карманами для наколенников, световозвращающими лентами, оранжевого цвета, размера 50 роста 182. Имеем 6 чекбоксов. Шесть раз страница обновится и пят раз придется скроллить с начала, чтоб найти нужные комбинации. Не каждому такое понравится.
Можно будет это прикрутить к новой версии?
Привет
В этой задаче я хотел бы поднять вопрос о том как должны работать фильтры по опциям.
Я прошел по некоторым популярным магазинам Lamoda, Wildberries, Next, Zappos и другие.
Могу сделать несколько выводов:
- некоторые магазины создают отдельный URL для каждой цветовой вариации, а вот у разных размеров URL один и тот же. Иными словами для каждого цвета создается отдельный товар, а размеры являются единственной опцией.
- В базе, каталоге и поиске отображаются всегда все вариации цветов как отдельные товары https://www.evernote.com/shard/s257/sh/7babf55d-7217-4935-97cc-9a62bdc40a1e/702491e8610d5b4c
- Фильтр по цветам обычно сводится к группировке цветов под существующие. Т.е. даже если цвет у футболки розовый, она будет отображаться в фильтре по красному цвету https://www.evernote.com/shard/s257/sh/8c316c12-b6cf-441a-8801-3646df12a4a6/8daf61fc050203c9
Мы запустили опрос по опциям и тому как вы ими пользуетейсь.
Что мне хочется выяснить в этой теме, это какие товары вы продаете с опциями и как вы видите удобную работу с ними на витрине и фильтрах?
Высказывайтесь, чем детальнее тем лучше - давайте сделаем этот функционал удобным!
Очень нужно все, что перечислили.
Для одежды и обуви каждая цветомодель товара (цветовая вариация) должна выводиться в списке товаров (в категории) отдельным товаров. Люди выбирают такие товары глазами и не заходят в карточку каждого товара посмотреть, есть ли такая модель в другом цвете. Цвет имеет один из наивысших приоритетов.
Есть категории товаров, где также присутствуют цветомодели. Но покупатели выбирают цвет уже в карточке товара, т.к. он менее важен. В данном случае выводить в каталог каждый цвет такого товара как отдельный товар не нужно. Это например стельки для обуви.
Фильтр по размерам в наличии - это просто MUST HAVE.
Теперь к примерам.
Я думаю что понять то что написано выше, довольно сложно, так что давайте я покажу на примере.
Берем Wildberries:
https://www.evernote.com/l/AQHIyVanM8lGRJuWuDa7hHUVC3HwbbU6IxE
теперь поясняю.
1. Для того чтобы отдельные цвета отображались как отдельные товары мы их создаем как полноценные товары.
2. Для того чтобы как то связать товары из пункта между собой, мы каким то образом группируем их в админке по принципу "Цвет"
3. У каждого товара из пункта 1. есть вариации, на картинке это только размеры.
Сейчас передо мной стоит только один вопрос, как правильно реализовать пункт 2, т.е. группировать товары по определенному признаку.
Пункт 2.
Мне кажется тут все довольно просто.
Каждому товару должна быть возможность задать настройку, например, с названием "Модель". Записываем товару значение этой настройки и таким образом группируем. Все товары, у которых будет одинаковое значение данной настройки будет сгруппированы. В карточке таких товаров можно будет переключаться другим между другом - т.е. между всеми товароми с одинаковым значением данный нстройки
Как правило, в качестве значений данной настройки будут использоваться названия моделей или артикулы (часть артикула) моделей.
В нашей 1Ске каждая цветомодель заведена как отдельная номенклатура, а размеры заведены через характеристики. Если группировка будет реализована вышеуказанным способом, то нужно предусмотреть возможность синхронизации настройки товара "Модель" с данными в 1С (в 1С скорее всего добавим доп. реквизит, куда пропишем значение модели)
Очень нужно все, что перечислили.
Для одежды и обуви каждая цветомодель товара (цветовая вариация) должна выводиться в списке товаров (в категории) отдельным товаров. Люди выбирают такие товары глазами и не заходят в карточку каждого товара посмотреть, есть ли такая модель в другом цвете. Цвет имеет один из наивысших приоритетов.
Есть категории товаров, где также присутствуют цветомодели. Но покупатели выбирают цвет уже в карточке товара, т.к. он менее важен. В данном случае выводить в каталог каждый цвет такого товара как отдельный товар не нужно. Это например стельки для обуви.
Фильтр по размерам в наличии - это просто MUST HAVE.
Тут есть один нюанс. Если каждая "цветомодель" в фильтрации отображается как отдельный товар то и в каталоге она будет отображаться так же как отдельный товар. Т.е. в категории у вас будет столько товаров сколько цветов.
Так сделано например в Next http://www.next.co.uk/shop/gender-men-category-shirts/use-casual#1_498- посмотрите первый и пятый товар - это один товар но в разном цвете.
Тут есть один нюанс. Если каждая "цветомодель" в фильтрации отображается как отдельный товар то и в каталоге она будет отображаться так же как отдельный товар. Т.е. в категории у вас будет столько товаров сколько цветов.
Так сделано например в Next http://www.next.co.uk/shop/gender-men-category-shirts/use-casual#1_498- посмотрите первый и пятый товар - это один товар но в разном цвете.
Да, так и нужно. Каждый цвет товара одежды и обуви нужно в каталоге показывать отдельным товаром. Люди не переходят в карточку товара, чтобы посмотреть, а какие там еще варианты цветов этой модели сапог.... Все привыкли цвета смотреть непосредственно со страницы категории. Но при этом в самой карточке товара должна быть возможность переключиться на другой цвет этой же модели - соответственно будет переход в другую карточку товара. Например, зашел посетитель в карточку босоножек модели ХХХ золотистого цвета. Но 37-го размера нет в наличии. Но в наличии 37-го размера есть эта же модель, но бежевого цвета. Так вот, если из карточки босоножек ХХХ золотистого цвета нельзя сразу перейти на модель ХХХ бежевого цвета, то маловероятно, что посетитель вернется в каталог и будет по нему "шерстить" в поисках такой же модели другого цвета с 37-го размера.
То, как делают крупные магазины (как в ваших примерах) для категорий одежды и обуви - это и есть правильно.
Да, так и нужно. Каждый цвет товара одежды и обуви нужно в каталоге показывать отдельным товаром. Люди не переходят в карточку товара, чтобы посмотреть, а какие там еще варианты цветов этой модели сапог.... Все привыкли цвета смотреть непосредственно со страницы категории. Но при этом в самой карточке товара должна быть возможность переключиться на другой цвет этой же модели - соответственно будет переход в другую карточку товара. Например, зашел посетитель в карточку босоножек модели ХХХ золотистого цвета. Но 37-го размера нет в наличии. Но в наличии 37-го размера есть эта же модель, но бежевого цвета. Так вот, если из карточки босоножек ХХХ золотистого цвета нельзя сразу перейти на модель ХХХ бежевого цвета, то маловероятно, что посетитель вернется в каталог и будет по нему "шерстить" в поисках такой же модели другого цвета с 37-го размера.
То, как делают крупные магазины (как в ваших примерах) для категорий одежды и обуви - это и есть правильно.
Да, мы говорим об одном и том же.
Так и планирую на текущий момент.
Хорошо бы для каждой вариации товара иметь свой SEO.
И если опции будут как то связаны с харрактеристиками. Возможен ли будет обратный процесс. Собрать из множества товаров один родительский с опциями. К примеру у нас ситуация такая. Никогда не пользовались опциями. Каждый тип, размер имеет отдельную карточку все отличия в харрактеристиках. С такой возможностью можно было бы такие товары собрать под одним Родительским товаром с опциями и перемещаться по ним сменяя опции. Собираться они бы могли по общим харрактеристикам и их значениям скажем товары имеющие 3-5 общих харрактиристик и значений и дополнительной ручной настройкой исключая ненужные.
И немножко не по теме. Почему то обделили вниманием разработчики возможность для мета данных и остальных полей, генерировать данные через переменные/шаблоны/плейсхолдеры. С падежами или сторонними сервисами, библиотеками склонения. Вроде в Битрикс генерация seo и мета по переменным в типовую конфу заложено, а тут целый зоопарк модулей сторонних.
1С : Дополнительные реквизиты = CS-CART: опции(по умолчанию)/характеристики(многие переименовывают)/они же фильтры
1C : Характеристики = CS-CART: вариации
При условии что вся номенклатура грузится из 1С. Пришел к выводу что вариации не каждому товару подойдут к сожалению.
В 1С есть возможность привязывать реквизиты только к родительскому товару. А все характеристики 1С (вариации) привязаны уже к этому родительскому товару и имеют реквизит этого товара например вес, фото, длину, ширину и тд. Таким образом эта история при выгрузке из 1С работать не будет. Потому как данные для вариаций из 1С брать неоткуда. Этого просто не заложено. Останется только ручками на сайте добавлять все недостающие данные.
Возможный выход для таких товаров это собирать их в вариации на сайте из отдельных карточек.
Пример товара радиатор отопления. Он имеет массу общих характеристик: давление материал, цвет и т.д. Для него необходимо создать вариации товара по размерам 27 ширин и 3 высоты. 81 позиция. Из 1С эти данные передать невозможно для вариаций, только общие характеристики родительского товара. Но можно создать 81 товар со своими габаритами весом (вес будет отличаться существенно для ширины радиатора 400 или 3000 мм, важный параметр для доставки) и остальными уникальными параметрами, выгрузить на сайт и там это превратить в вариации объединив по нескольким характеристикам.
Я не предлагаю отказываться от существующей схемы. Для одежды она видимо хорошо подходит, хотя из 1С грузить все параметры все равно невозможно. А это все таки основная программа учета в РФ. Предлагаю дополнить создание вариаций еще одной схемой. Собирать их из отдельных карточек.
А хотя бы приблизительно понятно уже, в какой версии будет реализовано что-то подобное?
Мне кажется однозначно нужно делать просто: один товар - одна карточка, а все вариации делать динамически через объединение карточек по определенному признаку (характеристике (кам)), задаваемой в админке. Встает вопрос о том, что при показе содержимого категории товаров будут вываливаться все подряд карточки. Решение опять таки в группировке при выводе - на одно объединение карточек (по заданной характеристике (кам)) один вывод в сетке витрины. При включенном фильтре показывать опять таки с группировкой, но чтоб из группы карточек показывалась именно та, которая соответствует текущему фильтру, а остальные связанные карточки будут видны при детальном просмотре товара.
Вот на мой взгляд ссылка на хорошую реализацию ссылка
Тут отдельные карточки объединены (сгруппированы) по определенным признакам (модель дивана, тип и цвет), а в рамках этой группировки уже показаны разные размеры по ширине. При этом в каталоге показываются опять таки не все подряд карточки, а сгруппированные. А при фильтрации по размеру например все равно показывается все в сгруппированном виде, только главной при группировке становится карточка с подходящим к фильтру размером.
Сумбурно наверное объяснил, но основной посыл в том, что все товары должны быть равнозначными отдельными карточками (не нужно городить разные типы товаров), а остальное уже дело второе как их группировать и выводить на витрину магазина, тут уже полет фантазии может быть разный под разный бизнес, при этом базовые данные (структура данных о товаре) будут у всех одинаковые - один товар (вариация) - одна карточка