Доработка бонусной программы

7
Текущая система начисления бонусных требует доработки:

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

2) Округление бонусов как минимум до целого числа просто необходимо и совершенно непонятно, почему столь легкая опция через ceil(...) до сих пор не реализована по умолчанию. Кому нужны десятичные числа в бонусных баллах? Наверное, лучше 26 баллов, чем 25,94? Это полный аналог копеек, которыми в 2021-м году пользуется лишь тот магазин, который не уважает ни покупателей, ни свою бухгалтерию, добавляя им геморроя.

3) Поддержка разного курса начисления баллов в зависимости от типа/категории/списка товаров.

4) Нативная поддержка/хук отображения бонусных баллов в карточке товаров и в каталоге, которые покупатель получит за каждый из товаров, в т.ч. с учетом артикула и количества в поле quantity.

9 комментариев

  • +1

    2-4 решаются плагином «гибкие скидки и бонусы»

    • +1
      Worker Worker 28 сентября 2021 23:23 #
      Ожидал этот комментарий и даже хотел заранее написать отдельный комментарий про плагин в постскриптуме к первому сообщению...

      Одно дело, когда сторонний плагин вносит полностью новый функционал, совсем не реализованный в CMS. Другое дело, когда плагин предлагает альтернативу к имеющемуся в CMS функционалу. Если разработчики Webasyst внедрили нативную бонусную программу, то оставлять этот функционал сырым нельзя.

      Пункт 3: в упомянутом плагине нужно создавать отдельное правило на каждый отличающийся тип/категорию/список, т.к. бонусная ставка в правиле задается только одна. Если количество правил будет большим, то непонятно, как это скажется на отклике.

      Пункт 4: плагин действительно позволяет вывести количество баллов, начисляемых на товар, и даже отображает актуальную информацию для каждого артикула (при включенной опции "Динамически обновлять информационные блоки"), вот только отображение сделано заметным миганием, что не есть хорошо для юзабилити. Записал гифку ниже. Также не реализована зависимость от указанного количества в quantity, хотя строка с бонусами при изменении количества обновляется и показывает как за одну единицу товара.
      Сторонний плагин, даже без учета его стоимости (лично у меня он уже есть, поэтому некритично), - это дополнительные запросы к БД, возможная несовместимость с другими плагинами или обновлениями CMS на первых порах.

      Почему нельзя сделать это всё нативно?! Ведь реализация займет не больше суток. Пункты 2 и 4 лично мне удалось сделать за час, кроме зависимости от quantity в пункте 4 - потому как еще нужно и sku учитывать. Конечно же, не хочется проделывать эти операции при каждом обновлении - и так уже 30+ файлов модифицировано.

      Собственно говоря, именно этот момент и целиком пункт 1 - основная причина данной темы.
      • +1


        Если разработчики Webasyst внедрили нативную бонусную программу, то оставлять этот функционал сырым нельзя.

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


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

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

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

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

         

        Сторонний плагин, даже без учета его стоимости (лично у меня он уже есть, поэтому некритично), - это дополнительные запросы к БД,

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

        Ведь реализация займет не больше суток.

        Вы правда считаете что сделать на уровне Shop Script функционал повторяющий плагин "Гибкие скидки и бонусы" можно за сутки? Вы не Земле живете или на Венере?

         

        Собственно говоря, (...) пункт 1 - основная причина данной темы.

        Я думаю, что ваше пожелание по доработке функционала (начисление бонусов не в момент получения заказом признака "Оплачен" а либо в момент получения заказом статуса "Выполнен", либо через N дней после получения заказом статуса "Выполнен" с возможностью указать N) с бОльшей вероятностью может быть принято к рассмотрению сотрудником Webasyst и когда-либо реализовано, если вы создадите отдельную тему с данным пунктом. Это действительно дельное предложение.

        • +2
          Worker Worker 29 сентября 2021 19:24 #
          Фунционал не сырой. он удовлетворяет базовым потребностям. Большинству пользователей не нужна гибкая система начисления бонусов, многих устраивает фиксированный процент на все товары.

          Округление до целого числа для бонусов - это и есть база, которая нужна, я уверен, 99% пользователей. Или же Вы из тех, кто и копейки до сих пор использует в цене а-ля 132 руб 47 копеек?! 

          Навскидку, проблема решается одной строчкой кода в user.css (задать минимальную высоту элементу)

          height: Ypx позволяет устранить, однако мигание остается.

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

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

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

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

          Почему не процитировали "возможная несовместимость с другими плагинами или обновлениями CMS на первых порах" - быть в зависимости от разработчика плагина? А как же дополнительные подключаемые во фронтенде .css/.js? Забавно порой видеть некоторые плагины, в т.ч. платные, которые реализуют элементарный функционал, но засирающий сайт своими ненужными подгрузками.

          Вы правда считаете что сделать на уровне Shop Script функционал повторяющий плагин "Гибкие скидки и бонусы" можно за сутки? Вы не Земле живете или на Венере?

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

          • +1
            Приведите мне цитату, где я сообщил, что реализация функционала, повторяющего плагин "Гибкие скидки и бонусы", займет сутки. (...) Когда приведете эту цитату - поскорее возвращайтесь с Нептуна.

            =) прилетел. поискал пример цитаты, не нашел. действительно, не так вас понял и вырвал из контекста.



            Почему не процитировали "возможная несовместимость с другими плагинами или обновлениями CMS на первых порах" - быть в зависимости от разработчика плагина

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

            --

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

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

            - возможность округлять бонусы? - можно решить проблему плагином.

            - возможность начислять бонусы по каким-либо критериям? - можно решить проблему плагином.


            Зачем Вебасисту тратить время на то чтобы что-то сделать, если это уже сделано? Других проблем как будто не хватает? Ладно, я обратно на Нептун. Соус стынет.

            • +2
              Worker Worker 29 сентября 2021 22:13 #
              ваша очередь искать и приводить пример плагина/темы/приложения, которое серьезно конфликтует с плагином "Гибкие скидки и бонусы".

              никакой очереди, ведь я написал о возможной несовместимости - плагинов тысячи, где-нибудь да найдется, и опять же - сначала обновляется движок, потом плагин. Вот этот промежуток между обновлением движка и плагином порой занимает приличное количество времени. А новейшие версии php/mysql? Сам не раз сталкивался с тем, что движок оптимизирован под свежую версию, а вот плагины - нет.

              Главную мысль которую я хотел донести: не вижу смысла агитировать за добавление чего-либо в движок, если это что-то уже имеется в каком-либо плагине и нормально работает. Зачем Вебасисту тратить время на то чтобы что-то сделать, если это уже сделано? Других проблем как будто не хватает?

              Это несколько странно, учитывая Вашу тему https://support.webasyst.ru/fo... где Вы просите разработчиков Webasyst доработать функционал наклеек/стикеров и пишете "Текущий функционал наклеек в Shop Scriot сделан для галочки, не более.". В комментариях верно указали, что есть соответствующие плагины, в т.ч. "Наклейки" от... *барабанная дробь*... того же разработчика, что и плагин "Гибкие скидки и бонусы", на который Вы здесь акцентируете внимание. Иронично, не находите?

              Идеально лезет пословица "в чужом глазу соломину видеть, в своём — бревна не замечать"

              • +1

                Это несколько странно, учитывая Вашу тему https://support.webasyst.ru/fo... где Вы просите разработчиков Webasyst доработать функционал наклеек/стикеров и пишете "Текущий функционал наклеек в Shop Scriot сделан для галочки, не более.".

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

                - штатный функционал наклеек в шоп скрипт сделан на 2-ку с минусом. Он имеет большие недостатки.

                Не сравнивайте жопу с пальцем.

                Это несколько странно, учитывая Вашу тему https://support.webasyst.ru/fo... где Вы просите разработчиков Webasyst доработать функционал наклеек/стикеров и пишете "Текущий функционал наклеек в Shop Scriot сделан для галочки, не более.". В комментариях верно указали, что есть соответствующие плагины, в т.ч. "Наклейки" от... *барабанная дробь*... того же разработчика, что и плагин "Гибкие скидки и бонусы", на который Вы здесь акцентируете внимание. Иронично, не находите?

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

              • +4

                1 пункт действительно проблемный в контексте возвратов заказов. По-хорошему, начисление бонусов должно происходить не тогда, когда заказ получает признак "Оплачен", а тогда, когда захочет администратор сайта. Например: в момент перевода заказа в статус "Выполнен" или через 14 дней после перевода заказа в статус "Выполнен". Возможности кастомизации здесь немного не хватает.

                • +1
                  dez dez 29 сентября 2021 15:15 #

                  Разработчики наверное не ходят в магазины и ничего не заказывают онлайн или в доставке еды, тоже бонусы работают. Бо логично, что бонусы должны приходить после статуса выполнен и в идеале через 14 дней, так как можно вернуть товар. Это должно быть в коробке ШШ, ну ясень пень никто это вздумает делать

                  Добавить комментарий

                  Чтобы добавить комментарий, зарегистрируйтесь или войдите