Метка: интернет-магазин

Скидки в скриптах интернет-магазина

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

Часто возможность раздачи скидок выпадает из факторов, которые рассматриваются при выборе платформы. И зря. Трудно себе представить, какие фантазии могут придти в голову владельцам, маркетологам или рекламщикам магазина. Поэтому при выборе скриптов для интернет-магазина этот параметр никак нельзя упускать из виду. Во многих случаях я натыкался на жестко фиксированный набор различных скидочных программ, который причинял изрядные неудобства уже спустя несколько месяцев после запуска сайта. Зачем далеко ходить? Например, после установки модулей приема платежей с кредитных карт владельцу пришло в голову дать скидку за платежи наличными — те самые 3-4%, которые забирает себе эквайрер. А автор скрипта этого не предусмотрел. В таких случаях часто требуется вмешательство в основной код скрипта, что, конечно, расстраивает. И не просто расстраивает! Многие скрипты сейчас имеют возможность автоматического обновления, при котором либо все внесенные изменения, конечно, теряются, либо просто блокируют саму возможность обновления.

Модульность этого компонента скрипта интернет-магазина даст возможность комбинировать и видоизменять, гибко настраивать скидочную систему. Это очень важная составляющая, от которой, во многом, зависит успешность проекта. Читать далее Скидки в скриптах интернет-магазина

Почтовые адреса

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

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

Здесь также пользователь должен с минимумом усилий указать максимум полезной информации. Во всех скриптах обычно заполняются такие поля:

  1. Почтовый индекс
  2. Страна
  3. Регион, штат или другая территориальная единица (если есть)
  4. Город
  5. улица, дом, квартира и т.д.

Для крупных городов, например, для Москвы или Санкт-Петербурга можно дополнительно спросить ближайшую станцию метро. В Webasyst Shop-Script это реализуется дополнительным полем.

Применительно к России возникает вопрос к 3-му пункту, у нас весьма пестрое административное деление. Самое простое — воспользоваться списком кодов субъектов РФ из Википедии. Но тут надо иметь в виду, что некоторые субъекты могут входить в состав других — автономные округа могут входить в состав краев и областей. Большинство реализаций скриптов этого не предусматривают, а зря. Деление на регионы должно быть не плоским списком а древовидным!. Стоп, не надо бежать срочно добавлять поле «parent_id» в существующую базу. Надо сначала погуглить на тему nested sets и проникнуться.

При этом регион «Москва» не идентичен городу Москва. При заполнении списка регионов об этом тоже надо помнить, Зеленоград также входит в состав Москвы, а доставка туда, как правило, отличается ценой.

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

Update. Раз уж речь зашла о древовидном хранении, то список страны-регионы_(области, края и т.д.) можно хранить в единой таблице. В ней корневыми элементами или элементами первого уровня (корень тогда будет «World» :) ) будут страны. Для классификации можно воспользоваться стандартом ISO 3166 и его подразделами относительно административных единиц.