Как разместить свой товар на Вайлдберриз, условия торговли · Анабар

Перейдите в Личный кабинет → раздел «Товары» → «Карточки товаров». Здесь можно создавать и редактировать карточки товаров на «Вайлдберриз».

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

Вкладка «Карточки товаров» в личном кабинете «Вайлдберриз»

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

Вручную. Если нужно оптимизировать карточку товара и попасть в большее количество категорий. Нажмите на кнопку «Добавить товар», откроется редактор карточки товара на сайте «Вайлдберриз».

Заполняем детали товара

Сначала выбираем основную категорию, в которой будет высвечиваться ваш товар. Её можно выбрать из списка товаров, например «Чехлы для телефонов». Затем указываем бренд и страну производства товара.

Создание карточки товара в личном кабинете «Вайлдберриз»

Артикул поставщика нужен, чтобы легко найти товар на своём складе. В карточке товара на сайте «Вайлдберриз» его не будет видно. Можно ввести любую комбинацию цифр или латинских букв, например «chehol1».

В комплектации указываем все предметы, которые получит покупатель при одном заказе. В нашем случае это «чехол 1 шт.». Если бы мы продавали другой товар — например, телефон — то в комплектации нужно было бы написать «телефон 1 шт., зарядное устройство 1 шт.».

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

Во вкладке «Добавление цвета» указываем основной и дополнительные цвета товара. Артикул цвета нужен для того же, что и артикул поставщика на «Вайлдберриз».

Генерируем штрихкод товара на «Вайлдберриз». Даже если на товаре уже есть штрихкод от производителя, нужно сгенерировать свой, чтобы в случае потери товар не присвоили другому поставщику на складе «Вайлдберриз». Перед поставкой его нужно будет добавить в маркировку товара.

Генерация штрихкода товара в личном кабинете «Вайлдберриз»

Теперь загружаем фото товара и выбираем, какое будет главным — обложкой. Нажимаем «Далее».

Минимальный размер фотографии товара в карточке «Вайлдберриз»: 450 × 450 пикселей

Устанавливаем цену

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

Установка цены в карточке товара на «Вайлдберриз»

Описание товара

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

В назначении подарка обычно указывают одну из категорий: женщинам, мужчинам, офис, спорт.

В поводе можно указать «день рождения» или календарные инфоповоды: Новый Год, 14 февраля, 8 марта.

Выбор повода для подарка в описании товара

В описании нужно собрать основные ключевые запросы, по которым покупатели ищут товар. Можно перечислить их через запятую, но лучше составить связный текст о товаре — он вызывает больше доверия у покупателей. Доступно 1000 символов, рекомендуем использовать все.

Нажимаем на кнопку «Создать карточку». Если всё заполнено правильно, она сразу появится в «Новых карточках», если нет, то сначала отобразится во вкладке «Карточки с ошибками». После модерации карточки появятся на сайте «Вайлдберриз», и товар станет доступен покупателям.

При работе по схеме FBW, после создания карточки нужно сформировать поставку с этим товаром.

Аналитики маркетплейсов помогут с управлением ассортиментом и продвижением товаров. Напишите или позвоните — расскажем условия.

Вотсап Телеграм+7 499 460-52-27

Рассказала Елизавета Кокорева, аналитик маркетплейсов. Написала Дарья Коченова.

Поделиться

Отправить

Твитнуть

[NEW] Как торговать на Wildberries со своего склада (FBS) – пошаговая инструкция для новичков на Вайлдберриз – Урок 4

1. Если вы хотите сэкономить на оборотке. Вместо того, чтобы отгружать товары на каждый из маркетплейсов, вы можете хранить всё на одном складе. При работе даже всего с двумя маркетплейсами это может снизить размер необходимых закупок почти вдвое
2. Если вы хотите лучше управлять остатками и ценами. Если маркетплейс устраивает акции, в которых вы не хотите участвовать, то можно просто обнулить остатки
3. Если вы хотите создавать несколько карточек товаров под один товар. Использование связки МойСклад + MPsklad позволит вам передавать остатки одного товара в несколько карточек. Узнать подробности можно по телефону в контактах на сайте.

Какие есть варианты хранения

1. Вы можете хранить всё на своём складе. Данный вариант подходит для крупных компаний и для тех, у кого уже есть своя розничная сеть магазинов. Для автоматизации работы мы рекомендуем использовать связку софта МойСклад + MPsklad
2. Мы можете воспользоваться услугами стороннего склада, где все процессы работы с маркетплейсами уже автоматизированы

Схема торговли на Вайлдберриз со своего склада

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

Чтобы начать продажи со своего склада (FBS), нужно зарегистрировать ваш склад в личном кабинете.

Перейдите по ссылке (в Личном кабинете: «Продажа со склада Продавца» – «Настройки» – «Склад поставщика»).

Нажмите «Добавить склад».

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

Введите адрес вашего склада, укажите координаты долготы и широты – для этого можно использовать указатель на карте. И нажмите «Сохранить».

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

В вашем личном кабинете есть 2 окна для управления продажами со своего склада: «Остатки товара» и «Сборочные задания». Информация о наличии товаров на вашем складе также передается из личного кабинета или же по API.

Работа с остатками товара

В окне «Остатки товара» вы можете загружать/выгружать товары из таблицы Excel (.xls) или вручную вводить данные по остаткам товаров на вашем складе.

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

Ежедневно вам нужно проводить работу по обновлению остатков. Вы можете выгружать и загружать остатки «пакетно» с помощью файла Excel (как это делалось для загрузки ассортимента) в такой последовательности:

• Выгрузка файла с остатками.
• Корректировка остатков в файле.
• Загрузка файла с обновленными остатками.

Также эту работу можно делать вручную – для этого достаточно навести курсор мыши на остаток и отредактировать количество.

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

Например, система автоматизированного управления складскими остатками MPSklad на OZON и Wildberries по API позволяет не только выполнять все процессы по управлению остатками, но и отправлять ваши заказанные товары – а это самая сложная, ответственная и время затратная процедура в работе каждого продавца.

Работа с заказами

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

Когда вы готовы приступить к подготовке товаров для отправки на склад Вайлдберриз, вы устанавливаете статус «На сборке».

Проводите упаковку товара в соответствии с правилами Wildberries к поставке, наклеиваете на товар (упаковку) его штрих код (баркод).

С информацией о типе упаковок (Микс короб, Монокороб или Монопалета) можно ознакомиться по ссылке.

Чтобы распечатать штрихкод (баркод), используйте самоклеящуюся бумагу, лазерный принтер и программное обеспечение iBarcoder, Windows barcode generator – программа бесплатная и позволяет генерировать штрихкоды, которые вам нужны (указаны в спецификации товаров, которые вы отправляете). Или же можно воспользоваться онлайн-генератором Barcode-Generator.

«Собрано» – это окончательный статус вашего сборочного задания, который означает, что вы упаковали товар, промаркировали этикеткой со штрихкодом и передали на доставку на склад маркетплейса.

После доставки вашего заказа на склад Вайлдберриз вы можете отслеживать его статус: «Транзит на ПВЗ» (товар следует в пункт выдачи), «Доставлено» и «Отказ» (в случае, если клиент отказался принимать товар – именно поэтому для новичков мы советуем начинать с товаров, которые при надлежащем качестве не подлежат возврату).

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

Также не забывайте про раздел «Новости» — там регулярно будет появляться наиболее важная информация от маркетплейса.

Импортер продуктов Wildberries — WooCommerce

Импортер продуктов Wildberries позволяет импортировать любой продукт с wildberries.com в ваш магазин WooCommerce, включая данные о продукте, такие как название продукта, описание, категория, производитель, изображение, цена, варианты, атрибуты, покупатель обзоры и многое другое в один клик.

1. Загрузите ZIP-файл из своей учетной записи WooCommerce.
2. Перейдите к :  Администратор WordPress > Плагины > Добавить новый  и  Загрузить плагин. Выберите файл для файла, который вы загрузили на шаге 1.
3. Установить сейчас и Активировать Плагин .

Чтобы начать импорт товаров с wildberries.com в ваш магазин WooCommerce, выполните следующие простые шаги.

Шаг 1: Загрузите и установите необходимое расширение Chrome Advanced Importer здесь.

Шаг 2: Затем вам нужно будет подключить установку WooCommerce Wildberries Product Importer к расширению Advanced Importer Chrome

• Перейдите в WP Admin > Products > Importer Configuration settings и вы найдете Import link и Secret key , которые необходимы для подключения Wildberries Product Importer с поддерживающим расширением Chrome.

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

Шаг 3: Используя тот же браузер Chrome, в котором вы установили поддерживающее расширение Chrome, перейдите на страницу продукта Wildberries, который вы хотите импортировать в свой магазин WooCommerce.

Шаг 4:  Откройте всплывающее окно расширения Chrome Advanced Importer, введите ссылку Import и секретный ключ (из настроек расширения Wildberries Product Importer ) и выберите Connect .

• Если ссылка импорта и секретный ключ действительны, вы получите сообщение об успешном выполнении, и во всплывающем окне расширения Chrome появится форма импорта.
• У вас также есть возможность использовать свой существующий идентификатор продукта WooCommerce для обновления информации о продуктах с продуктами на Wildberries.com.

• Если настроено, будут отображаться некоторые дополнительные параметры для назначения импортируемого продукта.

Шаг 5: Настройте информацию о продукте, который вы хотите импортировать, а затем Импортировать сейчас .

• Оставайтесь на той же вкладке браузера до завершения процесса импорта.

После успешного импорта товаров они будут опубликованы в вашем подключенном магазине WooCommerce.

Пример представления импортированного продукта на странице продукта WooCommerce.

Чтобы продолжить импорт продуктов, повторите шаг 5. Вы также можете импортировать продукты массово, перейдя на вкладку Массовый импорт во всплывающем окне расширения Chrome и введя соответствующие ссылки на продукты.

Как создать маркетплейс, который не будет уступать Wildberries? | by dev.family

Пока маркетплейсы захватывают мир, а Wildberries сообщает о росте оборота на 96% в 2020 году — до 437,2 млрд рублей, мы, разработчики, ищем способы заставить эти маркетплейсы обрабатывать запросы в дело миллисекунд и мгновенное масштабирование.

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

Одной из задач было сделать скорость работы сайта сопоставимой с общепризнанными тенденциями. Мы изучили опыт Ozon, Wildberries, Lamoda, чтобы найти оптимальное архитектурное решение и базы данных, создать универсальные конструкторы и выстроить общую логику с приложением.

В Озоне действительно все продумано, но скорость отклика не такая высокая. У Lamoda классный дизайн, но он не идеален в плане скорости, а Wildberries показывает лучшую производительность по сравнению с другими. Поэтому мы ставим перед собой цель достичь именно их уровня по скорости работы. Жаль, что разработчики Wildberries мало что рассказывают, так что если кто-то из них читает эту статью, поделитесь своим опытом. Думаю всем будет очень интересно.

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

Насколько хорош ваш проект, зависит от многих факторов. Например, насколько продвинутым и дальновидным является технический руководитель в команде. Насколько точно он продумает архитектуру сервера, чтобы она легко масштабировалась по мере роста проекта. Какие базы данных он выберет, чтобы сайт работал быстро и не надоедал пользователям. В основном используются Mysql и Postgresql. С последним мы работаем уже 2 года. Однако в данном случае этого было недостаточно. Потому что проект предполагал высокие нагрузки и использование фасетного поиска. Поэтому пришлось искать другое решение.

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

Итак, проблема №1 — это возможность удобно пользоваться фасетным поиском. Это такой поиск, где фильтры зависят друг от друга. То есть, если вы выбрали марку «босс», вам будут показаны цвета, доступные только для него. Тогда, если вы выбрали размер L, вы увидите все вещи указанной марки, цвета, размера. Так что все фильтры зависят друг от друга.

Одновременно с фасетным поиском покупатель хотел видеть на странице товара довольно сложные подборки. Например, подборка всех товаров одного цвета. Или выбор товаров со скидкой в ​​магазине, где вы выбираете одежду. Еще была задача №2, которая подтолкнула нас к тому, что нам нужна еще одна БД, и одного Postgresql будет недостаточно.

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

В общем, мы начали искать базу, которая бы быстро считывала данные и делала фасетный поиск удобным. Не буду перечислять кучу вариантов, которые мы перепробовали. Наконец, остались MongoDB и Elasticsearch.

По сути они одинаковые, но Elasticsearch написан на java и потребляет кучу ресурсов сервера. Если у вас в каталоге хотя бы 100 тысяч товаров, то 8 гигов памяти придется выделить только под Elasticsearch. И мы обычно думаем, что java довольно медленная. Вот почему Монго стал победителем.

Решение второй задачи — снижение нагрузки на сайт и уменьшение количества запросов — привело нас к денормализации данных. Это способ, которым мы заранее подготавливаем данные для вывода. Например, мы собрали информацию о товаре с наличием в магазине, сопутствующими товарами, отзывами, ценой и разместили в одном месте. Таким образом, вывод товарной страницы превращается в один запрос, а не в несколько (в каких магазинах есть в наличии + по какой цене + похожие товары + какие размеры и т.д.).

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

Конечно, мы могли бы хранить эти данные и в Postgresql, но это не логично, учитывая, что вся информация для фасетного поиска хранится в Mongo. Потому что, во-первых, это запрос к одной базе данных для фильтрации данных, а во-вторых, к другой для их вывода.

В качестве основной базы используется Postgresql, вся логика и данные здесь, пишем все сюда и отправляем запросы. Дополнительно используется MongoDB, данные здесь денормализованы, он доступен только для чтения. Mongo очень быстр и легко реплицируется в случае роста данных или рабочих нагрузок.

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

В результате мы получили очень быструю рабочую директорию и высокую скорость генерации передачи данных. Например, на выбор и подготовку страницы товара нужно около 7 мс, на каталог — около 30–40 мс. А можно на сервере с 2 процессорами и 4гб памяти. Так что перспективы масштабирования и потенциал огромны. Единственное, что возможно, это нарваться на скорость диска.

Также отмечу, что вся наша серверная архитектура управляется Kubernetes. Это хорошо для бизнеса по следующим причинам:

• различные ветки автоматически развертываются на тестовой площадке. То есть мы можем параллельно разрабатывать несколько новых фич и тестировать каждую на отдельном домене. Главное, что это происходит автоматически.
• Kubernetes — это инструмент оркестрации на стороне сервера. Воспринимайте это буквально. То, что управляет оркестром контейнеров: DB1, DB2, интерфейс и PHP. И если выйдет из строя, то перезагрузится, если увеличится нагрузка, то реплицируется на другую машину. Это наш дирижер. Однако не стоит думать, что он может все сделать сам. Разработчики должны писать всю логику в Kubernetes. Составить кучу инструкций на все случаи жизни. Кто-то может сказать, что он немного снижает время отклика за счет того, что строит свои сети, с помощью которых управляет контейнерами. Но смотрите, если человек это сделает, это займет еще больше времени, но кроме того, возникнет фактор ошибки. И, кстати, мы всегда учитываем сетевое время, подсчитывая, сколько времени требуется для выполнения кода. Например, вы знаете, что это занимает 30 мс, а в консоли браузера отображается время обработки запроса — 100 мс. Как так? 70 мс — это скорость, с которой передаются данные. Хотите сократить это время — храните серверы в непосредственной близости от клиента. Обычно в консоли видно, что Wildberries, например, передает данные о ближайшем сервере, откуда загружать данные, чтобы тратить меньше времени на их доставку клиенту.
• Развертывание в рабочей среде происходит без простоев и нажатием одной кнопки.

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

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

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

Конечно, можно было бы еще вспомнить React Native Web, который предназначен для написания одного приложения, работающего одновременно в браузере с использованием стандартных веб-технологий и на iOS или Android как настоящее нативное мобильное приложение. Год назад мы пытались с ним бороться, но он был еще совсем сырым. Итак, мы сделали следующее.

Фронтенд разработчик делающий сайт написал магазин, а потом мобильный разработчик с небольшим отставанием пришел в разработку этого же раздела, взял магазин, сделал свою обработку, но в целом можно было сделай наоборот. Таким образом мы также избегаем проблем с другой логикой. И сейчас я говорю не только о том, что происходит между Android и iOS, но и о разнице между веб-приложением и мобильным приложением. Кроме того, это дает нам огромное увеличение скорости разработки. На мой взгляд, это здорово.

Наверняка всех бесит, когда в браузере нажимают «назад», и их перебрасывает не на строчку магазина, где вы были, а в рандомное место на странице, и приходится снова листать до нужного товара остановился на. Какой позор! А иногда это тоже занимает много времени. Вот почему мы делаем кэширование браузера в сеансе пользователя. В результате, если пользователь нажмет назад, мы просто покажем страницу из кеша браузера. Это происходит мгновенно и пользователь возвращается на то место, где он остановился. Сообщество предлагает множество вариантов с временными решениями, но, как показала практика, кэширование ajax-запросов — самый мощный и простой способ, позволяющий пользователям получать удовольствие от использования каталога вашего сайта.

Теперь поговорим о том, как организованы сессии и слияние данных на проекте. Почему мы разделяем запросы на получение и публикацию и зачем их кешируем? Откуда появилась идея генерации токенов на фронте? И что это нам дает?

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

Мы пришли к выводу, что нам достаточно получать данные только на стороне клиента (для SSR это не важно, но у нас есть возможность кешировать их на стороне Nginx). Это позволяет нам видеть мгновенный ответ, потому что вся страница может кэшироваться на SSR — все получают запросы, а в случае высоких нагрузок мы оставляем эту возможность себе, а на стороне клиента будет информация по каждому конкретному пользователю. принес (все его любимые вещи, количество вещей в корзине и т. д.). Get-запрос кешируется отдельно даже для незарегистрированных посетителей и не дает сбоев при обновлении. Пользовательские данные не должны изменяться путем получения запросов. Таким образом, при необходимости весь сайт можно положить в кеш, не затрагивая данные сессии (авторизацию).

Позвольте мне проиллюстрировать на примере, почему это важно.

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

Нужен для того, чтобы бэкенд понимал, кто конкретно к нему обращается и какие данные нужно отдавать. Это уникальный ключ, который ранее был сгенерирован на стороне бэкенда, но мы сделали это по-другому — на стороне клиента. Что это дало нам? Во-первых, мы знаем источник, откуда пришел человек (веб, ios, android), а во-вторых, теперь не нужно ждать на стороне фронтенда окончания одного запроса, как это было раньше, чтобы отправить другой (запрос на получение сеанса + запрос на обновление истории просмотров). Соответственно, мы снова увеличили скорость.

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

Отличие сессионного токена от авторизационного токена в том, что если бы у нас не было механизма регистрации пользователя, принцип работы сайта оставался бы таким же, как описано выше. Файл cookie сеанса — это уникальный идентификатор, к которому серверная часть может привязать любые необходимые данные. Благодаря такому подходу мы начинаем различать такие сущности, как пользователь и сеанс. Что в этом крутого?

Например:

Пользователь — Илья A

Сессия 1 — Web

Сессия 2 — Android

ILYA в его учетной записи из компьютера. Поместите 2 продукта в корзину. Потом зашел на сайт с телефона не авторизовавшись там и тоже начал наполнять корзину. Это пока «сессия 3», потому что мы не знаем, кто это и чья это тележка. Но как только Илья заходит с телефона в свой аккаунт, все товары группируются в личной корзине Ильи.

В результате мы соединяем все устройства пользователя в одну учетную запись и объединяем корзины с помощью сеансовых файлов cookie. Ну, мы только что объяснили, почему мы делаем это с точки зрения производительности. Это небольшая вещь для производительности, которая имеет большое значение. Кроме того, мы всегда знаем, с каких устройств наши пользователи заходят на сайт. В нашем конкретном случае это повлияло на ценообразование — пользователи из мобильного приложения получили скидку 1%.

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

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

Поэтому загружаем изображения через тег и целым массивом: для телефонов, десктопов, разного разрешения, с разной плотностью точек. Кстати, сейчас хорошим решением является формат webp (на момент написания статьи Safari его не поддерживал, поэтому использовались оба формата), который весит меньше обычного jpg. В результате каждое устройство получает свой образ. Места конечно занимает много (на 1 товар 14 изображений и это только на одну страницу, но есть еще и корзина, каталог и т.д., в итоге надо штук 50 чтобы каждый пользователь получил именно ту картинку, которая ему нужна) но пространство сейчас является самым дешевым ресурсом. НО цель не в том, чтобы сэкономить, а в том, чтобы показать товар так, чтобы пользователь купил его, не заходя в магазин.

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

Почему хорошая админка — крутой инструмент, требующий сложной разработки, времени и денег?

Для нас мифы об админке — настоящая проблема. Например, если сайт сделан на CMS, админку можно редактировать самостоятельно без участия разработчиков. Но мы уже разбирали эту конкретную историю. Итак, мы его опустим.

Всегда все делаем с нуля, админка соответственно тоже. У нас есть классный пакет, который мы сделаем открытым в будущем. Это позволяет нам быстро создавать элементы управления для простых объектов, таких как новости, категории имен и т. д., но нам все равно приходится уделять много внимания сложным объектам, таким как меню, конструкторы, поведение шахматной сетки в недвижимости или интерфейс. логика в логистике, например. Это действительно большая работа, и ее нельзя недооценивать. Именно поэтому мы заводим часы, привлекаем фронтенд-разработчика, проектируем и создаем удобные механизмы управления. Отсюда возникают соответствующие суммы, а в итоге вы получаете нестандартную удобную разработку индивидуально под ваш проект. Ниже приведены 2 отличных примера.

Мы «придумали» это для того, чтобы клиент мог что-то изменить и добавить самостоятельно без разработчиков. Например, различные новые категории меню. Какими они могут быть благодаря текущему конструктору на примере нашего проекта?

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

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

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

Сборщик коллекций

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

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

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

Отображение коллекции Web Secret

Обмен с 1С

Существует несколько сценариев обмена со сторонними системами:

• сторонний провайдер доставляет на сайт стандартизированный файл, сайт его обрабатывает — так работают почти все CMS.
• сайт периодически запрашивает стандартизированный файл по URL и делает обновления, когда это удобно сайту — так Яндекс. Рынок. работает, например.
• есть полноценный API на стороне сайта, а сторонний провайдер выбирает методы, меняет только то, что ему нужно — так работает, например, Ozon. Этот метод также называется push-based.

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

По последнему принципу реализован обмен в нашем проекте. Выбор пал именно на него, так как требовалось обновлять много данных и запрашивать их извне. Например, полный обмен товара — обычная операция, поэтому все используют вариант 1 или 2. Но нам нужно было, чтобы как только товар был взят из офлайн-магазина, 1С оповестила сайт о том, что такого товара нет в запаса больше нет, и мы бы немедленно удалили его со страницы. Либо сменился импортер поставщика всех товаров Boss. Мы не можем переписать все товары — вы меняете имя импортера, и эта информация будет извлечена во всех товарах. Кроме того, есть много фоновых процессов, требующих полноценного API, например, обмен клиентской информацией, push-уведомления и т. д., обо всем этом написано в документации.

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

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

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

This entry was posted in Популярное