Товары как база данных. Почему это основа любого интернет-магазина

Есть одна тема, о которую может споткнуться и профессионал, и начинающий, запускающий первый магазин. Эта тема контринтуитивна. Речь о товарах.
Лично я считаю, что товары — это первое, из чего состоит интернет-магазин. Возможно, это профдеформация. Но давайте посмотрим на них внимательнее.

Интуитивно товары кажутся очень простой вещью: название, цена, картинка и (не всегда) описание.

Этого достаточно, чтобы продажа была технически возможна.

На практике в информации о товарах могут быть:

  • товарные остатки из системы учёта;
  • вес и размер для автоматической оценки стоимости доставки;
  • варианты товара по объему (50/100/150 мл), расцветке и другим срезам;
  • данные о персонализации или конфигурации;
  • метки сквозной аналитики;
  • данные, используемые в рекламной системе через товарный фид;
  • налоговые и бухгалтерские правила.
    Почему важны варианты товара и как с ними разобраться

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

    Например, 10 размеров кроссовок по 3 цвета каждый.

    Это уже 30 коробок, чтобы иметь по 1 паре каждого варианта.


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


    Бывает товар и сложнее, когда хочется объединить в одну карточку выбор всех вариантов.


    Например, ремешок для часов:

    - размеры (2 мужских и 2 женских);

    - разная кожа (5 видов);

    - металл пряжки (4 варианта);

    - цвет пряжки (ещё 4 варианта);

    - узор пряжки (4 разных).


    Итого 4х5х4х4х4=1280 вариантов одного товара.

      Важно!

      У облачных систем управления магазинами есть ограничения на количество вариантов одного товара (не более 100 или 1000). Мы выработали способы их обхода.

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

      Давайте рассмотрим примеры.

      Сначала покажу антикейсы из своей практики, за которые до сих пор стыдно
      ДВА САМЫХ СТРАШНЫХ СЛУЧАЯ С БАЗОЙ ТОВАРОВ В ИНТЕРНЕТ-МАГАЗИНЕ

      Некоторые из этих кейсов произошли во время работы в компании ws24.pro.

      Пользуясь случаем, передаю привет коллегам)



      Магазин для сёрфингистов

      Классная тематика обернулась проблемами, когда выяснилось, что у клиента три склада с несовпадающими остатками. Вот как это было.

      Приходит клиент, приносит прайс товаров.

      Делаем магазин, загружаем прайс.

      Выясняется, что есть склад и оттуда надо брать информацию об остатках.

      Выставляем счёт за интеграцию склада и магазина.

      В процессе работ выясняется, что складов три, остатки не совпадают, артикулы не указаны.
      Несколько месяцев пытаемся связать магазин и склад по различным признакам, и всё время появляются нюансы, дубликаты и расхождения.
      В итоге вынуждены улаживать конфликт, закрывая сотни неоплаченных часов консультаций и работ.
      ДВА УСТРАШАЮЩИХ КЕЙСА, С КОТОРЫМИ МЫ УСПЕШНО СПРАВИЛИСЬ


      Магазин трусов

      Однажды к нам пришёл клиент с относительно типовой задачей — переездом интернет-магазина на InSales.

      Мы увидели несколько сотен товаров, оценили работы, согласовали и приступили. Инженер, который занимался переносом данных, задерживал работы. Когда попытались выяснить, в чём дело, он прислал скриншот со структурой базы данных клиента.

      В базе всего несколько сотен трусов. При этом только вариантов размеров больше 500, а есть ещё и цвета.

      А вот картинка со структурой базы данных трусов:
      Здесь вы видите визуализацию базы данных — сотни таблиц с данными о товарах (карточки с синими заголовками) и связи между этими таблицами (чёрные линии).
      В тот раз, чтобы создать файл для загрузки товаров, инженер обработал все связи во всех таблицах. Более 60 000 строк.

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


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


      Магазин обуви

      Клиент пришёл с просьбой подключить товарный фид от поставщика.
      Товарный фид — файл с информацией о товарах, наличием и ценами, который можно открыть по ссылке и который обновляется поставщиком по мере необходимости без изменения ссылки. Существует несколько форматов товарных фидов или можно создать свой.

      Проанализировали, нашли все логические неопределённости, урегулировали с клиентом, подключили, запустили. Отлично, теперь цены и наличие в БД обновляются каждое утро.



      Далее клиент принёс ещё три товарных фида.

      Движок не умеет работать более чем с одним фидом — создаём веб-приложение, которое собирает и объединяет данные из нескольких фидов.

      По дороге выясняем, что у разных поставщиков разные форматы записи цвета и размера; придумываем, как это объединить.
      Через год магазин использовал семь товарных фидов от разных поставщиков в разных форматах (CSV, XSL, XML, YML), объединяемых по изощрённой логике. Например, у некоторых поставщиков остатки передавались в количественном виде, у некоторых — в формате «есть/нет», у некоторых — в формате «много/мало». При этом надо было показывать, что товар недоступен, а в некоторых случаях скрывать эти товары.



      Теперь вы видите, что всё не так просто


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


      Разложим всё по полочкам. Для каждого товара вам понадобятся:

      1.Собственно описание товара, самое простое.
      Должно быть всегда. Источником может быть даже просто прайс.

      2. Параметры товара.
      Длина, ширина, вес, разъём, какие батарейки нужны

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

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

      3. Свойства товара.
      Тут мы имеем в виду такие параметры товара, по которым существуют варианты. Самые распространённые — цвет, размер, объём.

      С этого начинаются сложности. Например, кроссовки имеют 6 размеров и 4 цвета.Это значит, что в БД будет 24 строчки про этот товар, у каждой будет своя цена и наличие. 100 моделей дадут в итоге 2400 вариантов товара.

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

      4. Складской учёт.
      До тех пор пока вы работаете по дропшиппингу, или ваш поставщик передает вам товарный фид с наличием, или ваши товарные остатки условно бесконечные, у вас нет проблем с этим пунктом.

      Как только появляются товары в шоуруме, потом свой склад, потом склады в регионах — рекомендую как можно скорее внедрять полноценный складской учёт.

      С усложнением ситуации будут увеличиваться ваши проблемы: артикулы, остатки, ошибки персонала, дубли товаров. В базе на 300 товаров это может создать ад.

      Отдельно не рекомендую пытаться повесить внедрение складского учёта на IT-интегратора под видом настройки интеграции интернет-магазина с сервисом «Мой склад». Тот, кто возьмётся делать это за небольшие деньги, не понимает, во что ввязался.

      5. Склейка данных из нескольких источников.

      6. Влияние особенностей и ограничений движка на формат данных.
      Иногда надо разложить часть данных по разным полям, иногда невозможно это сделать.


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



      Что ещё важно

      Системы учёта

      Системы складского учёта (например «Мой склад») используют дополнительное поле в БД товаров, чтобы однозначно идентифицировать данный вариант товара. Плюс можно использовать ещё несколько полей для привязки к другим сущностям.


      Источники данных о товарах

      Иногда нет единого полноценного источника всей информации о вашем товаре.
      Часть информации вы берёте с сайта конкурента, часть даёт поставщик, часть создаёте вы сами.

      Роботы могут объединить данные, только если есть какой-то очевидный признак: SKU, barcode, ID. В остальных случаях это может сделать только человек.Наши сотрудники создают по 15–30 товаров в час (клиент — 2 товара в час). Поэтому создание 2000 товаров может занять месяц и будет хорошо стоить.


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

      Именно поэтому я призываю отнестись к товарам в ИМ как к проектированию БД.


      Итак, нужно:

      - определить источники данных: прайс, фид от поставщика, приложение для DropShipping, сайт конкурента, поставщик данных о товарах;

      - определить формат данных: короткое и длинное описания, фото, параметры, свойства;

      - выбрать способ работы с вариантами: отдельные товары, склеенные по всем свойствам, склеенные по отдельным свойствам, общий товар с конфигуратором;

      - определить одно (1) место, в которое вы будете складывать данные, — потом вы сможете распределить их по всем вашим ресурсам. Это позволит избежать путаницы в данных и снизит вероятность ошибок;

      - определить какие ограничения есть у движка: например, не более 100 вариантов;

      - учесть требования к фильтру в коллекциях;

      - требования к дизайну: картинки, длинное описание.


      Таким образом, данные о товарах могут проходить через все бизнес-инструменты компании: от поставщика, через складской учёт, движок ИМ (CMS), дизайн магазина, CRM, маркетинг и рекламу (товарные фиды), бухучёт.

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

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


      Думаю, дело в том, что они не решают задачу клиента до конца. Например, у сервиса может не быть одной из товарных категорий, не будет картинок в высоком качестве, описание не будет приведено к общему формату, они не будут клеить данные из нескольких источников и многие другие мелочи. Поэтому у нас уже много лет постоянно работает контент-менеджер, который продолжает решать задачу клиента ручным трудом. И только ручной труд пока позволяет решить задачу клиента на 100%. Надеемся, что однажды наши контент-менеджеры станут учителями нейросетей или подобных инструментов и им больше не будет сниться «CTRL+C, CTRL+V».


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

      Иногда мы делаем ручную обработку данных о товарах в таблице, чтобы потом быстро импортировать и сократить расходы на ручную работу.


      О некоторых кейсах по товарам мы кратко пишем на нашем сайте.