Wildberries: как работает интернет-магазин и в чем его особенности
Крупнейший интернет-магазин одежды, обуви и галантереи в России Wildberries был создан обычными людьми — учителем английского языка и радиофизиком. На открытие такого бизнеса семейную пару подвигло сложное материальное положение. Спустя несколько лет магазин стал приносить большую прибыль. И вот сегодня Wildberries знает практически каждый житель страны. Как работает магазин Wildberries? Об этом будет подробно рассказано в статье.
Как работает «Вайлдберриз»
Wildberries — это непростая последовательная цепочка, в которой каждое звено — это менеджер, поставщик или покупатель. Любое нарушение целостности этой цепочки — это сбой программы, в которой страдают все, от продавца до покупателя.
Многих интересует, как работать с Wildberries поставщикам. Начинается работа магазина с выбора товара, который необходимо закупить для продажи. Ассортимент должен быть рациональным и востребованным. Поэтому над каталогом продукции трудится не один специалист.
Для удобства всех сотрудников компании на официальном сайте есть специальная форма регистрации для партнеров, заполнив которую, вы сможете увидеть все подробности сотрудничества с организацией.
Менеджер должен уточнить у поставщика все о товаре: качество, состав, размерный ряд и комплектацию, а также цену. После того как согласованы все нюансы, менеджер выдает разрешение на отгрузку товара.
Не думайте, что на этом все заканчивается. После того как продукция попала на склад компании Wildberries, ее необходимо проверить на наличие брака и дефектов. Товар распаковывается, осматривается и вновь помещается в стандартную упаковку. На него переклеивают бирки и вешают фирменный логотип. Модели одежды, обуви и аксессуаров фотографируются на манекенах и описываются. Собственно говоря, именно это описание видят все покупатели магазина. Бракованный товар отправляется обратно поставщику.
Следующий этап происходит непосредственно на сайте магазина. При введении любого запроса в поисковой строке он должен обрабатываться за несколько секунд. Такой скоростной режим и отличает Wildberries от других магазинов. В работе данного интернет-магазина используется несколько платформ и серверов, что помогает не только хранить и сервировать информацию, но и обрабатывать ее вдвое быстрее других магазинов. Таким образом, Wildberries — сложная система с простым и понятным интерфейсом, которым могут пользоваться даже пожилые люди и подростки.
Далее вещи со склада отправляют по местам формирования заказов. Каждая позиции занимает отведенную ей ячейку согласно штрих-коду. Затем товар доставляется покупателю.
Как работать с Wildberries поставщикам при наличии брака у товара? Если клиента не устроил товар в заказе или у него обнаружился брак, то продукция доставляется обратно на склад. Затем заполняется специальный акт о наличии дефектов и товар возвращается обратно поставщику. Это отлаженный годами алгоритм работы.
Несколько слов необходимо сказать об информационных центрах: склад, call-центр, магазин и ERP-система. Они управляются с помощью четырех блэйд-серверов. Они делают работу магазина удобной и комфортной как для клиентов, так и для самого персонала.
Секрет успеха
В 2016 году Wildberries стал лидером среди магазинов онлайн-торговли. Однако при этом он же является самым загадочным магазином для прессы. Создатели магазина не дают интервью и не посещают сетевые мероприятия.
Склад магазина до 2009 года находился на 20 километре МКАД. На сегодняшний день это место работы менеджеров. В этом трехэтажном здании вмещается более 400 человек рабочего персонала магазина. Все они стараются, чтобы покупатели были довольны.
Суть успешной работы Wildberries — решать текущие проблемы или жить одним днем. В компании нет совета директоров, а это значит, что каждый сотрудник может повлиять на ход событий в фирме. Именно поэтому каждый работник ощущает свою важность.
Отзывы о работе в Wildberries
В компании многие сотрудники работают более 5 лет. Есть определенный «костяк» работников со стажем в фирме более 9 лет. Новички в интернет-магазине задерживаются нечасто. Тяжелый график работы многих пугает. Однако начальство утверждает, что все это преодолимые трудности. Работники должны находится в офисе не менее 8 часов. При этом бывает, что необходимо работать и в выходные дни.
Официальной системы штрафов в Wildberries нет. Однако от качества работы зависит процветание компании и выручка, а, соответственно, это сказывается и на заработной плате. Поэтому каждый работник старается выполнить свою работу хорошо.
Доставка
40% от всех заказов клиенты забирают самостоятельно. На сегодняшний день у Wildberries более 600 пунктов самовывоза по России, Беларуси и Казахстану. В течении года планируется открытие еще 100-150 таких точек.
Чуть больше половины заказов развозит служба доставки, в которую входят около 2500 человек. В большинстве регионов доставка бесплатная. Исключение — районы дальнего Севера и Востока.
Тем, кому сложно разобраться, как работает доставка Wildberries, стоит ознакомиться с простыми и понятными правилами на официальном сайте. Здесь описаны способы доставки и оплаты, а также условия возврата товара.
Пункт самовывоза
При оформлении заказа на сайте необходимо выбрать способ доставки. При наличии пункта самовывоза в регионе клиент может сам забрать продукцию.
В точках Wildberries заказы хранятся 3 дня. Здесь есть удобные примерочные, в которых покупатели могут померить одежду и обувь, убедиться в отсутствии брака. Также в пунктах самовывоза товар необходимо проверять и осматривать. При обнаружении дефектов заполняется акт на наличие брака и товар возвращается на склад. Пункты самовывоза работают по будням и выходным.
О том, что заказ поступил в точку вывоза и его можно забрать, приходит смс-уведомление. Также на электронную почту покупателя поступает письмо, в котором указано, по какому адресу и когда можно забрать товар. Кроме того, в письме будет подробно описано, как работает пункт самовывоза Wildberries, и в течение какого срока товар будет оставаться в данной точке.
Ассортимент товаров
Сайт магазина разделен на удобные разделы, в которых можно легко найти нужную вещь или предмет. Также в самом верху главной страницы есть поисковая строка, которая поможет отыскать товар в считанные секунды. Кроме того, на официальной странице подробно описаны способы оплаты и доставки.
Многих интересует, как работает интернет — магазин Wildberries. Для начала работы с магазином необходимо зарегистрироваться на сайте. Для удобства клиентов им предлагается оставить свой номер телефона и адрес электронной почты. Менеджеры Wildberries связываются с покупателем, чтобы уточнить все нюансы заказа.
Женщинам, мужчинам
В данных разделах присутствуют все категории одежды, обуви и аксессуаров. Каталог товаров разделен на категории: платья, футболки и топы, рубашки, брюки и шорты, толстовки, лонгсливы, худи и др. Также есть отдельные категории товаров: «Большие размеры» и «Спецодежда». Можно ограничить поиск при помощи удобного разделения товаров по сезону, размеру, цене и цвету.
Детям
В данном разделе собраны все необходимые атрибуты для детей и младенцев. Одежда разделена на категории: мальчикам, девочкам и новорожденным. Также есть отдельные поисковые зоны «Школа» и «Любимые герои». Интерфейс сайта настолько удобен, что любую покупку можно совершить в несколько кликов.
Для игрушек отведен отдельный раздел. Они также распределены по возрасту и категориям. Удобным делается поиск, если воспользоваться фильтрами, которые выбирают игры по заданным параметрам.
Wildberries дает возможность покупать не только одежду и обувь для детей, но и различные средства передвижения. Здесь можно найти все — от коляски до роликовых коньков и санок.
Дом и дача
Если вы хотите приобрести мебель или атрибуты для дачи или дома, то просто и легко это можно сделать на официальном сайте Wildberries. Как работает система доставки мебели и аксессуаров до нужной точки, интересует всех клиентов. Все доставят непосредственно к месту пользования в указанный срок, так же как одежду, обувь и другие вещи из каталога. Здесь большой выбор различной мебели, аксессуаров для хранения вещей. Предлагается большой выбор украшений и статуэток.
Новый год
Этот раздел на сайте появился сравнительно недавно. Покупатели в отзывах отмечают, что он удобен и функционален. Ведь теперь найти необходимые атрибуты для праздника можно в считанные секунды.
Здесь есть вечерние платья, карнавальные костюмы и одежда для детишек. Также в разделе собраны украшения и статуэтки с символикой года. Все для новогоднего стола и праздника тоже можно отыскать в этом разделе.
Красота
Перечень товаров для женщин и мужчин в данном разделе огромен. Здесь можно найти практически все гигиенические средства различных фирм. Уход за лицом и телом, макияж, средства для волос и многое другое собрано на данной страничке сайта Wildberries. Как работает поисковая система на сайте относительно косметических средств, интересует всех покупателей-новичков. Вы можете выбрать товар по запросу в поисковой строке или непосредственно в разделе «Красота». Также можно найти нужное средство в разделе «Бренды». Все легко и просто, а разнообразие парфюмерии, косметики и подарочных наборов очень радует.
Бренды
Как уже отмечалось выше, Wildberries работает для удобства покупателей. Именно поэтому на официальном сайте есть отдельный раздел, в котором перечислены все торговые марки, с которыми работает данный интернет-магазин. Если кликнуть на названии бренда, компьютер выдает все позиции товаров, которые есть в магазине данной фирмы.
Как работают скидки на Wildberries
Скидки и акции — вот что любят в этом магазине. Иногда в течении дня на сайте магазина может одновременно проходить более пяти распродаж. Самые большие — сезонные скидки, проводятся в период смены коллекций. Также распродажи многих товаров можно встретить перед праздниками и в дни «черной пятницы».
Многих интересует, как работает Wildberries с несколькими акциями. Открывая раздел «Акции» на сайте, клиенты видят, сколько времени осталось до завершения данной распродажи. После того как товар отложен в корзину, покупатель видит его стоимость с учетом всех скидок и акций. Если акция закончилась, а товар остался в корзине, то его стоимость корректируется.
Кроме того, от процента выкупа (соотношение заказанного товара и купленного) и ежегодной суммы покупок зависит скидка на товар у данного покупателя. Таким образом, клиенты получают скидки на все товары в размере от 1 до 30%. Процент скидки можно уточнить в личном кабинете на сайте магазина в разделе «Моя скидка». Там же будет подробно описано, как можно увеличить этот процент.
Отзывы
Данным интернет-магазинов пользуются не только жители России, но и Беларуси, Казахстана. Многие довольны таким удобным способом покупки. В своих отзывах клиенты магазина рассказывают, что товары легко и удобно приобретать. Доставка осуществляется быстро. Практически любой товар можно найти на сайте магазина.
Для тех, кто не знает, как начать работать с Wildberries, на официальном сайте есть подробное руководство к регистрации. Все товары подробно описаны. Есть отзывы реальных покупателей о данной продукции, которые помогают определиться с выбором. При наличии брака или дефектов товар возвращается обратно. Взамен присылается такой же (по желанию клиента и при наличии товара на складе). Этот магазин — находка для занятых людей.
Как работает крупнейший маркетплейс: что у него под капотом
Сегодня Wildberries — самый большой маркетплейс в России и мы так часто заняты повседневным хайлоадом, что не всегда успеваем рассказать что за всем этим стоит: какие технологии и решения под капотом, как мы справляемся с адом черной пятницы и ужасами киберпонедельника.
Стоит начать с того, что основным генератором прогресса в WB с самого начала и по сей день является фактор роста. По бизнес-метрикам мы растем примерно х2 каждый год уже много лет, а по техническим (количестуву запросов / транзакций / трафику / объему данных и т. д.) — рост может быть даже быстрее, и это создает множество вызовов: технических, архитектурных и организационных.
В итоге, чтобы запустить любую программу или систему в прод на мало-мальски долгий срок нужно обязательно учитывать кратный рост нагрузки, иначе совсем скоро придется вносить серьезные изменения в архитектуру или вообще все переделывать. Речь, конечно, не только про код – надо иметь стратегию масштабирования на уровне железа, сети, данных, самого приложения, команды и т. д.
Сегодня я хочу рассказать немного про нашу инфраструктуру.
БД и микросервисы
Много лет назад рынок онлайн ритейла только набирал обороты и технически Wildberries походил на сотни компаний вокруг: у нас было несколько серверов в коммерческом датацентре, на которых крутились сайт, бэкенд мобильного приложения и реляционная БД, в которой лежали почти все наши данные, а на соседних серверах хостились корпоративные сервисы типа 1С.
Все это как-то работало до тех пор, пока количество клиентов и заказов не стало быстро расти – сразу после этого систему начало колбасить в разных местах (чаще всего узким местом становилась БД). Появились даунтаймы, которые вредили бизнесу, напрямую влияя на конверсию.
И если с ростом нагрузки на приложение мы просто добавляли больше серверов, то с БД все было несколько сложнее. Сначала мы пытались прокачать ее: добавляли реплики для чтения, подкладывали все более мощные серверы, приглашали специально обученных гуру для оптимизаций, но потом все же приняли очевидный факт – пытаться масштабировать сетап любой БД после определенного предела слишком дорого и бесполезно, и предел этот гораздо ниже, чем кажется на первый взгляд.
Через некоторое время мы разделили данные по функциональному признаку и разложили в разные БД, при этом появился интересный побочный эффект – оказалось, что с таким подходом можно очень просто и удобно разделить и само приложение. Так мы пришли к микросервисной архитектуре.
Тут стоит заметить, что в нашем случае дробление приложения на более мелкие сервисы потребовалось не по техническим причинам: stateless-программа довольно просто и дешево масштабируется даже если это какой-то жирный монолит (кроме совсем уж запущенных случаев) – только успевай ставить серверы. А вот масштабировать команду — такой подход очень помогает: небольшим сервисом может заниматься небольшая команда разработчиков, в которой гораздо ниже накладные расходы на коммуникации. Кроме того сервис с ограниченным функционалом, как правило, проще и имеет более низкий порог входа, что тоже снижает расходы.
разделяйте данные и раскладывайте в разные места при первой же возможности, иначе будете страдать
разбивайте функционал по разным программам, если хотите быстро масштабировать команду
Про K8S
Число небольших сервисов быстро росло и когда оно перевалило за сотню, мы уперлись в доставку приложений в прод: в то время приложения деплоились прямиком на baremetal-серверы с помощью полуавтоматических систем доставки, и поддерживать нужный темп деплоя (а каждый сервис может выкладываться много раз в день) стало дорого.
Поэтому мы сначала сделали самодельную оркестрацию LXC-контейнеров, а затем перешли на docker и попробовали набирающий популярность Kubernetes. В итоге нам понравилось.
Сейчас мы крутим множество кластеров K8S и используем его для запуска почти всех наших программ. Тем не менее не обошлось и без нюансов — подробно описывать не буду (эта тема потянет на отдельную статью), вкратце подведу итоги:
мы хостим K8S исключительно с L3 Networking — т.е используем L3 CNI-плагины (конкретно у нас — calico, но существуют и другие варианты) и BGP. Это позволяет легко и прозрачно приземлять входящий трафик, предназначенный конкретному сервису, именно на те ноды, на которых запущены поды этого сервиса, так как адрес сервиса анонсируется только с нужных нод.
Под сервисом здесь я понимаю именно service в терминах K8S. В случае с L2 сделать такое сильно сложнее. Кроме того L3 Networking гораздо лучше масштабируется и позволяет делать трюки типа анонса pod network, что дает возможность гонять трафик внутри кластера без оверлеев вроде VXLAN и даже без DNAT/SNAT — это очень актуально, когда нагрузка велика, а количество нод переваливает за несколько сотен.
мы почти не используем persistent storage в K8S. Гиперконвергенция хорошо звучит в рекламных проспектах, но в реальной жизни нужна какая-то очень серьезная причина, чтобы рисковать данными, а для экономии на железе существуют другие техники. Есть небольшие исключения, для которых мы используем local storage, но только там, где потеря данных некритична.
мы делаем много кластеров. Изначально у нас было по одному кластеру на каждый дата-центр, а растянутых между дата-центрами кластеров мы не делали вовсе. K8S отказоустойчив и отлично масштабируется, но накладные расходы после определенного количества нод становятся тяжелее, а failure domain все больше и больше. В итоге мы начали создавать больше кластеров, а сейчас вообще встаем на путь наливания кластера под каждый сервис или группу сервисов, благо у нас есть собственный инструмент для деплоя K8S — deadbeat.
Про железо
Вопрос железа — всегда вопрос денег. Wildberries — частная компания, и для нас очень важна операционная прибыль. Парадокс в том, что самый простой путь сэкономить на железе — использовать больше железа.
Поясню: стандартный путь энтерпрайза, который ценит свои данные — покупать большие и надежные СХД, с резервируемыми контроллерами, проприетарными технологиями репликации данных между дата-центрами, самым умным в мире тирингом и прочими изобретениями вендоров.
Это крутые девайсы, и чаще всего на них можно положиться, но проблема в том, что они очень дорогие. По цене такой СХД можно купить кучу обычных серверов, а вопрос резервирования и шардирования данных решить на уровне самих приложений — в этом случае вы больше инвестируете в собственное приложение, но зато всю добавочную стоимость вендора оставите себе.
В некоторых случаях игра может стоить свеч даже если речь идет об одной-двух СХД, а если у вас большие объемы, то это то, о чем стоит всерьез задуматься. Аналогичная история — с разного рода блейд-системами и прочим. Да, блейд-система выигрывает по плотности у обычных серверов, но зачем вам плотность в 2021 году? Power budget процессора не зависит от форм-фактора платформы и вы скорее всего упретесь в электричество, особенно в условиях когда в коммерческих дата-центрах аренда одного стойкоместа на 15 КВт чаще всего будет стоить дороже, чем двух по 8 Квт, что делает ценность высокой плотности блейд-систем по меньшей мере спорной.
Vendor lock-in — это зло. Вендоры хотят, чтобы их добавочная стоимость не доставалась другим вендорам. У нас был случай, что СХД одного вендора работала только через коммутаторы этого же вендора, не говоря уже про то, что вы не можете просто заменить диск на любой другой. С другой стороны в обычных серверах такого себе почти никто не позволяет.
Унификация позволяет сэкономить: наше серверное многообразие свелось в итоге к двум типам нод — compute-нодам с горячими процессорами и большим кол-вом памяти и storage нодам c вместительными корзинами для дисков. Когда вам надо купить очень много одинаковых серверов вы, во-первых, получите более низкие цены, а во-вторых, снизите косты на поддержание зипа и резерва.
Все пункты применимы не только к серверному оборудованию, но и к любому другому — к сетевому, десктопам и т. д.
Про сеть
Чтобы размещать в нескольких датацентрах много железа – нужно обеспечить соответствующее количество сетевых портов. Тут все работает так же как и для серверов – лучше всего использовать много простых, но производительных устройств, а стратегию масштабирования основать на общедоступных протоколах, не полагаясь на вендорские ноу-хау.
Еще очень важно построить логическую схему сети максимально устойчивой к отказам отдельных элементов, поэтому из классической энтерпрайз L2-сети, плохо масштабируемой, имеющей кучу ограничений и сильно связанных компонентов мы закономерно пришли к классической сети Клоза (или как ее еще называют — Leaf & Spine, архитектуре в случае двухуровневой фабрики).
Углубляться в рамках этой статьи не буду, но смысл в том, что такое решение по многим причинам гораздо лучше масштабируется и строится на стандартных протоколах и механизмах типа ECMP, которые хорошо поддерживаются устройствами всех вендоров, что опять же позволяет экономить на железе.
Кроме того мы используем следующие приемы оптимизации расходов на сеть:
почти во всех стойках только 1 ToR коммутатор, компенсируем риски распределенными приложениями (см. следующий раздел)
DAC-кабели вместо дорогих SFP-модулей
для максимальной унификации стараемся использовать взаимозаменяемые модели оборудования для разных уровней фабрики
разумная и контролируемая переподписка
Про программы
Для того, чтобы все перечисленные выше пункты работали, одной инфраструктуры недостаточно — нужно писать программы с учетом нашей специфики:
дата-центр может отвалиться — делайте приложение доступным в разных дата-центрах
стойка может отвалиться – делайте приложение доступным в разных стойках
все, что угодно может отвалиться или начать работать неустойчиво – делайте ретраи, curcuit breaker и т. д.
количество запросов будет расти намного быстрее, чем вы думаете – приложение должно легко масштабироваться добавлением инстансов
количество данных будет расти намного быстрее, чем вы думаете – разбивайте данные на куски любыми способами и раскладывайте в разные хранилища (см. раздел про БД и микросервисы)
там, где разбить не получается, предусмотрите шардирование, партиционирование, секционирование и другие подобные техники на этапе проектирования – потом будет слишком поздно
реплицируйте все, что можно. Если возможно и выбранное хранилище позволяет, то используйте разные реплики для разных целей – например, чтение с одних реплик, а запись в другие
Настоящая консистентность нужна гораздо реже, чем вы думаете, но за ее обеспечение платится высокая цена. Подумайте, может быть в вашем случае стоит вместо дополнительных гарантий купить дополнительную производительность
Не бойтесь велосипедов — часто вместо использования какой-то внешней системы/зависимости эффективней написать свою реализацию под конкретную задачу.
Например, в каких-то простых случаях вместо использования внешнего Redis можно закешировать что-то в памяти самостоятельно. Такое решение будет работать быстрее и обойдется дешевле в эксплуатации.
Сервис по банальному перекладыванию JSON-объектов, который кроме самого себя состоит еще из RabbitMQ для очередей, etcd для хранения конфигурации, Redis для кеша, sql-базы для хранения самих JSON-объектов, сайдкаров, Nginx для балансировки и еще пары-тройки других крайне нужных компонент, выглядит очень круто, но на этом его преимущества заканчиваются
Чаще всего принцип Time-to-Market очень важен — не пытайтесь написать самый лучший и самый красивый код в мире и избегайте лишних абстракций и оверинжиниринга. Лучшее — враг хорошего, а отсутствие каких-то абстракций почти всегда меньший грех, чем появление ненужных
Самое главное
Все пункты выше очень важны. Без этих решений мы бы не смогли обрабатывать миллионы заказов в сутки и быстро расти.
Однако самое важное условие – это крутая и динамичная команда. Об этом в следующей статье.
Как создать маркетплейс, который не будет уступать Wildberries
Пока маркетплейсы захватывают мир, а Wildberries отчитывается о росте оборота на 96% в 2020 году — до 437,2 млрд рублей, мы, разработчики, ищем пути как делать так, чтобы эти маркетплейсы отрабатывали запросы за считанные миллисекунды и могли масштабироваться по щелчку пальцев.
В статье расскажу о своем опыте работы с высоконагруженным проектом, с которым Веб Секрет сотрудничает уже почти 2 года. Я решил рассмотреть пока только несколько пунктов, которые считаю реально крутыми.
Одной из задач стояло сделать скорость работы сайта сопоставимой с общепризнанными трендами. Мы изучили опыт Ozon, Wildberries, Lamoda, чтобы подобрать наилучшее архитектурное решение и базы данных, создать универсальные конструкторы, построить общую логику с приложением.
У первых все нереально круто продумано, но скорость отклика не такая быстрая. У Lamoda классный дизайн, но с точки зрения скорости они не идеальны, а Wildberries показывают самые крутые цифры по сравнению с остальными. Поэтому поставили перед собой цель достичь в скорости работы именно их уровня. Жаль, что разработчики Wildberries мало что рассказывают, поэтому, если кто-то из них вдруг прочитает эту статью, поделитесь своим опытом. Думаю, всем будет очень интересно.
Ниже рассказываю, какие универсальные решения для разных задач мы находили с командой в процессе работы. Новый сайт проекта готовится к релизу, и совсем скоро вы сможете оценить, как все описанные ниже методы реально отработали и повлияли на скорость. А пока читайте и задавайте вопросы в комментариях.
То, насколько крутым выйдет ваш проект, зависит от многих составляющих. Например, насколько будет продвинутым и дальновидным техлид в команде. Как точно он продумает серверную архитектуру, чтобы она легко масштабировалась с ростом проекта. Какие базы данных подберет, чтобы сайт “летал” и не напрягал пользователей. Чаще всего используют Mysql и Postgresql. Мы работаем с последней уже 2 года. Однако в данном случае ее было недостаточно. Потому что проект подразумевал высокие нагрузки и использование фасетного поиска. Поэтому нам пришлось искать другое решение.
И, если с нагрузками все ясно (сложные запросы типа “покажи все товары красного цвета размера L для женщин” и “убери все остальные фильтры, которые не содержат такие товары” становятся в очередь, занимают все время, в итоге сайт нещадно тормозит), то на скорости работы хочу остановиться отдельно.
Итак, задача номер 1 – возможность удобного использования фасетного поиска. Это такой поиск, где фильтры зависят друг от друга. То есть, если вы выбрали бренд boss, то вам покажут цвета, доступные только для него. Потом выбрали размер L и увидели все вещи данного бренда, данного цвета, данного размера. Так все фильтры зависят от всех.
Одновременно с фасетным поиском заказчик хотел видеть довольно сложные выборки на странице товара. Например, подборка всех товаров такого же цвета. Или подборки товаров со скидкой в том магазине, где ты выбираешь себе аутфит. И это было задачей номер 2, которая подталкивала нас к тому, что нужна еще одна база данных, и одной Postgresql будет не достаточно.
Да, я понимаю, что запросы можно оптимизировать, но в любом случае БД будет требоваться перелопатить много данных и затратить большое количество времени на их обработку.
В общем мы стали искать БД, которая бы быстро читала данные и делала фасетный поиск удобным. Я не буду перечислять кучу вариантов, которые мы перепробовали. В итоге в финалистах у нас оставалась Mongodb и Elasticsearch.
По сути, между собой это одно и тоже, только Elasticsearch написан на java и писец как жрет ресурсы сервера. Если у вас каталог хотя бы от 100к товаров, то гигов 8 памяти смело придется выделить только на Elasticsearch. Да и в целом мы считаем, что java достаточно тормознутый. Поэтому Mongo стала победителем.
Решение второй задачи – снижение нагрузки на сайт и уменьшение количества запросов – привело нас к денормализации данных. Это способ, при котором мы заранее готовим данные для вывода. Например, собрали информацию о каком-то товаре сразу с наличием в магазине, связанными товарами, отзывами, ценой и сложили это в одно место. Таким образом, вывод страницы товара превращается в один запрос, а не несколько (в каких магазинах есть + по какой цене + какие похожие товары + какие размеры и т.п.).
Далее мы построили отдельную систему событий, чтобы при изменении статуса наличия или добавлении отзыва обновлялись денормализованные данные товара. Да, есть небольшая задержка в обновлении данных, но мы считаем, что можем этой задержкой пренебречь при выводе каталога. Такая модель называется read write model. В корзине же, например, при оформлении заказа, мы уже не используем денормализованные данные, но там и выборки проще и нагрузки меньше.
Конечно, мы могли бы хранить эти данные и в Postgresql, но это не логично, учитывая, что вся информация для фасетного поиска хранится в Mongo. Т.к. это сначала запрос в одну БД на фильтрацию данных, а потом в другую на их вывод.
В качестве основной БД использована Postgresql – здесь вся логика и данные, сюда все пишем и посылаем запросы. Дополнительно – Mongodb, куда денормализуются данные, она используется только для чтения . Mongo очень быстрая и легко реплицируется в случае роста объема данных или нагрузок.
Процесс записи данных в Mongodb мы построили на разных очередях, что тоже позволяет масштабировать проект в будущем, добавляя больше серверов, которые смогут быстрее разбирать очереди. Звучит вроде как просто, но процесс требует предельной внимательности, т.к. легко что-то упустить.
В результате мы получили очень быстрый рабочий каталог и высокую скорость генерации отдачи данных. Например, выбрать и подготовить страницу товара – порядка 7мс, каталог – около 30-40мс. И возможно это на сервере с 2 процессорами и 4Гб памяти. Так что перспективы для масштабирования и потенциал здесь огромные. Единственное что возможно – это упереться в скорость диска.
Отмечу еще, что вся наша серверная архитектура управляется с помощью Kubernetes. Для бизнеса это полезно по следующим причинам:
- автоматически разворачиваются разные ветки на тестовой площадке. То есть мы можем параллельно разрабатывать несколько новых фич и каждую тестируем на отдельном домене. Ключевой момент, что происходит это автоматически.
- Kubernetes – инструмент для серверной оркестрации. Понимайте это в прямом смысле слова. Штука, которая управляет оркестром контейнеров: БД1, БД2, front-end и php. И в случае падения он перезагрузит, в случае увеличения нагрузки – реплицируется на еще одну машину. Это наш дирижер. Однако не стоит думать, что он все сам умеет. Разработчики должны прописывать в Kubernetes всю логику. Вроде как составлять ему кучу инструкций, что делать в каждой ситуации. Кто-то может сказать, что он снижает немного время отклика из-за того, что строит свои сети, с помощью которых управляет контейнерами. Но послушайте, если этим будет заниматься человек, то времени потребуется еще больше, но помимо этого еще появится фактор ошибки. И, кстати, считая, за сколько выполнится код, мы всегда учитываем время на сеть. Вот ты, допустим, знаешь, что на это надо 30мс, а в консоли браузера показывается время обработки запроса — 100 мс. Как? 70мс — это скорость, с которой ходят данные. Хочешь, чтобы это время было меньше — храните сервера в непосредственной близости от клиента. Обычно в консоли видно, что тот же Wildberries передает данные о ближайшем сервере — откуда грузить данные, чтобы меньше тратить времени на их доставку до клиента.
- Деплой на продакшн происходит без простоя и нажатием одной кнопки.
Я топил, топлю и буду топить за кроссплатформенность , т.к. важно, чтобы клиент получал один и тот же функционал на любом устройстве и в любой операционной системе. Уже сейчас очень хочется сразу писать код, который подойдет и для веба, и для приложения, чтобы оптимизировать не только временные затраты, но и не получать расхождения в логике. Однако пока так нельзя.
Тем не менее, у нас, наконец, получилось частично переиспользовать код и логику между вебом и мобайлом, так как веб у нас на React, а мобайл – на React Native.
При этом внешний вид у каждой платформы свой. Если говорить техническим языком, у нас общий Redux Store , поэтому работа с данными ведется из одного места, но на визуальную составляющую это никак не влияет.
Конечно, можно было вспомнить еще про React Native Web, который предназначен для того, чтобы писать одно приложение, работающее одновременно и в браузере с использованием стандартных веб-технологий и на iOS или Android как настоящее нативное мобильное приложение. Год назад мы пытались там покопаться, но был еще совсем сырой. Поэтому мы сделали следующим образом.
Front-end разработчик, делая сайт, пишет store, а затем мобильный разработчик с небольшим отставанием приходит к разработке этого же раздела, берет store и делает собственную обработку , но в целом можно и наоборот. Так мы еще избегаем проблем с разной логикой. И я сейчас не только про то, что случается между Android и iOs, а еще про разницу между вебом и мобайлом. Плюс нам это дает колоссальный прирост в скорости разработки. По-моему офигенно.
Наверняка всех бесит, когда в браузере нажимаешь “назад”, и тебя выбрасывает не на ту строку магазина, где ты был, а в рандомное место страницы, и приходится снова скроллить до товара, на котором ты остановился. Обидно правда. А порой это еще и долго происходит. Поэтому в рамках сессии пользователя мы делаем браузерное кеширование. Как результат, если пользователь нажимает “назад”, мы просто отдаем страницу из браузерного кэша. Это происходит мгновенно, и пользователь возвращается в то место, где он закончил серфинг. Сообщество предлагает множество вариантов с костылями, но, как показала практика, кэширование ajax-запросов — самый действенный и простой способ, который позволит пользователям кайфовать от использования вашего сайта-каталога.
Теперь поговорим о том, как на проекте устроены сессии и мерж данных. Зачем мы разделяем get- и post- запросы и для чего кэшируем их? Откуда появилась идея генерировать токен на фронте? И что нам это дает?
Т.к. предполагается, что проект будет масштабироваться, мы решили учесть допнагрузки заранее и просчитали вариант с кэшированием. Чтобы прибавить скорости сайту, страница товара должна загружаться мгновенно, а профиль пользователя – потом подтягиваться асинхронно. Таким образом всю страницу товара можно класть в кэш, а профиль пользователя загружать отдельно. Быстрее? Очевидно же!
Мы пришли к тому, что нам достаточно получать данные только на клиенте (они не важны для ssr, но у нас есть возможность их кэширования на стороне Nginx). Это позволяет видеть мгновенную отдачу. Т.к. на ssr может кэшироваться страница целиком – все Get-запросы, и в случае высоких нагрузок мы себе оставляем такую опцию, а на стороне клиента будет подтягиваться информация по каждому конкретному пользователю (все его избранное, кол-во вещей в корзине и т.п.) – Post-запросы. Get-запрос кешируется отдельно даже для незарегистрированных посетителей и не ломается при апдейте. Пользовательские данные не должны изменять get-запросы. Таким образом, при необходимости весь сайт можно положить в кэш, не затрагивая сессионные данные (авторизационные).
Проиллюстрирую примером, почему это важно.
Допустим, я авторизовался и зашел на главную страницу, на мне она закешировалась. Если мы не будем разделять запросы, то, когда кто-то другой зайдет на сайт, он увидит главную с моими данными, полученными по post-запросам – с моим избранным, потому что Nginx посчитает кэшированную страницу актуальной и отдаст ее в том виде, в котором она попала туда. При разделении запросов же, получится, что главная достается из кэша, а пользовательские данные подтягиваются для каждого отдельно.
Он нужен, чтобы бэк понимал, кто конкретно к нему обращается и какие данные необходимо отдать. Это уникальный ключ, который раньше генерировался на стороне backend, но мы сделали иначе — на стороне клиента. Что это нам дало? Мы, во-первых, знаем источник, откуда пришел человек (web, ios, android), а во-вторых, теперь на фронте не надо ждать окончания одного запроса, как раньше, чтоб отправить другой (запрос на получение сессии + запрос на обновление истории просмотров). Соответственно мы снова сократили скорость.
Сделали так, чтобы не ждать постоянно бэкенд. А еще, чтобы сразу передавать на бэк информацию о клиенте, например, что он юзает – Android или iOs. Ведь иногда ценообразование в магазине напрямую зависит от устройства.
Отличие сессионного от авторизационного токена заключается в том, что, если бы у нас не было механизма регистрации пользователя, принцип работы сайта оставался бы таким же, как описано выше. Сессионные cookie — это уникальный идентификатор, к которому бэкенд может подвязать любые необходимые данные. Благодаря такому подходу мы начинаем различать такие сущности как user и сессия. В чем крутость?
user — Илья А
сессия 1 — web
сессия 2 — android
Илья в своем аккаунте с компьютера положил в корзину 2 товара. Потом с телефона зашел просто на сайт, не логинясь там и стал тоже наполнять корзину. Это пока “сессия 3”, т.к. мы не знаем кто это, и чья корзина. Но стоит Илье залогиниться с телефона в своем аккаунте, как все товары суммируются в личной корзине Ильи.
Как итог мы таким образом соединяем все устройства пользователя в один аккаунт и делаем мерж корзины с помощью сессионных cookie. Ну и мы объяснили почему мы так делаем с точки зрения перфоманса. Тут мелочь на перфомансе, а в итоге получается огонь. Ну и мы всегда знаем с каких устройств сидят наши пользователи. Конкретно в нашем случае это повлияло на ценообразование – пользователи с мобильного приложения получали скидку в 1%.
Изображениям на этом проекте мы тоже уделяли много внимания. Поэтому что это ключ к продажам клиента. Сейчас уже существует куча разрешений экранов, еще разная плотность пикселей, та же ретина, например. И все это надо учитывать, чтобы на каждом экране выдавать идеальную картинку пользователю с точки зрения и качества и пропорций.
Как этого добиться? Подскажу, грузить одну крутую картинку в большом разрешении, чтобы показать всем хорошее качество, – это лажа. Зачем тратить кучу трафика или сталкиваться с тем, когда грузишь картинку в баннер, на десктопе выходит красиво, а на телефоне голова у человека обрезана.
Поэтому мы грузим картинки через тэг и целым массивом: для телефонов, десктопа, разного разрешения, с разной плотностью точек. Кстати, сейчас хорошим тоном является формат webp (на момент написания текста Safari его не поддерживал, поэтому использовали оба формата), который весит меньше привычного jpg. В итоге каждое устройство получает свое изображение. Естественно, что это занимает очень много места (на 1 товар 14 картинок и это только для одной страницы, а есть же еще корзина, каталог и т.п в итоге под 50 штук набирается, чтобы каждый пользователь получил именно ту картинку, которую нужно), но место — самый дешевый ресурс сейчас. НО цель не экономить средства, а показать товар настолько круто, чтобы он его купил не ходя в магазин.
Все картинки на стороне сервера мы кэшируем, чтобы не генерировать каждый раз массив целиком. Клиент грузит одну, а мы уже нарезаем, сколько нам нужно.
Почему хорошая админка – это крутой инструмент, который требует сложной разработки, времени и денег?
Для нас мифы об админке – это боль. Например, что, если сайт сделан на CMS, админку можно будет редактировать самостоятельно без участия разработчиков. Но конкретно эту историю мы уже разбирали. Поэтому опустим.
Мы всегда все делаем с нуля, соответственно, админку тоже. У нас есть классный пакет, который мы в будущем заопенсорсим. Он позволяет быстро создавать управление простыми сущностями, вроде новостей, категорий имен и т.п. Но до сих пор приходится много внимания уделять сложным сущностям, вроде меню, конструкторов, поведения шахматной сетки в недвижимости или логики интерфейса в логистике, например. Это действительно большой кусок работы, и не стоит ее недооценивать. Потому мы закладываем часы, привлекаем front-end разработчика, придумываем и создаем удобные механизмы управления. Отсюда и возникают соответствующие суммы, но на выходе вы получаете кастомную удобную разработку индивидуально под ваш проект. Ниже 2 охеренных примера.
Его мы “придумали” для того, чтобы клиент как раз-таки мог самостоятельно без разработчиков что-то менять и добавлять. Например, разные новые категории меню (привет статье на vc.ru, где мы рассказываем, что это две разные вещи). Какими они могут быть благодаря текущем конструктору на примере нашего проекта?
Как вы поняли, прописать можно вообще что угодно. Но, если данные динамически выбирать по таким критериям, как я уже говорил, базе данных будет тяжко, и все будет грузиться медленно, поэтому вспоминаем денормализацию данных, которую мы внедрили. Теперь, чтобы в админке собрать новые пункты меню – запускается задача на формирование любого пункта по выбранным параметрам, и он готов, при этом открываться будет очень быстро благодаря пресловутой денормализации.
Но мы все же хотим рассказать про универсальность админки. Смотрите на видео, как мы создали крутой, удобный конструктор, который позволяет решать все задачи клиента.
Особенно хочу обратить ваше внимание на blocks. Это супер вещь, которая позволяет в каталоге помимо товаров создавать еще какие-то заранее отрисованные и сверстанные крутые блоки, чтобы, например, перед товарами добавить информацию о бренде или о каком-то промо.
Еще в нашем проекте есть понятие подборок. Понятно, что там есть машинное обучение, автоматические рекомендации и прочие технологии и сервисы, но иногда нужно формировать подборки вручную. Разберем следующий кейс.
Например, к майкам boss хотим рекомендовать джинсы boss. Или к майкам рекомендовать майки такого же цвета. Все бы ничего, но мы то строим универсальную архитектуру. А клиент сегодня продает майки, у которых разный цвет, завтра – ноутбуки с разной памятью и так далее. Поэтому опять сделали конструктор, зацените на видео.
Еще в процессе тестирования мы поняли, что сделали какой-то мощный конструктор, которым можно сформировать правила даже более сложного уровня. Например, к просматриваемому товару рекомендовать другие из этого же магазина, но на скидке. И для этого больше не нужны разработчики, а можно сделать руками маркетолога.
Есть несколько сценариев обмена со сторонними системами:
- сторонний поставщик вкидывает сайту какой-то стандартизированный файл, сайт его обрабатывает – так работают почти все CMS.
- сайт периодически сам запрашивает по URL стандартизированный файл и делает обновления, когда сайту удобно – так, например, работает Яндекс. Маркет.
- на стороне сайта есть полноценное API, и сторонний поставщик дергает методы, изменяет только то, что ему нужно – так, например, работает Ozon. Этот метод называется еще push based.
Описанные выше сценарии обмена данными под номерами 1 и 2 – начального уровня. Да, в некоторых случаях их достаточно, но на больших проектах нужен 3 вариант. Он, хоть и сложный, но зато гораздо более быстрый, гибкий и продвинутый с точки зрения функционала.
Вот по последнему принципу реализован обмен на нашем проекте. Выбор на него пал, потому что требовалось обновлять очень много данных и запрашивать их со стороны. Например, полный обмен товаров – это рядовая операция, поэтому все используют 1 или 2 вариант. А нам нужно было, чтобы, как только товар забрали из магазина в оффлайне, 1С уведомлял сайт, что такого товара больше нет, и мы сразу же убрали бы его со страницы. Или сменился импортер поставщика всех товаров Boss. Не переписывать же нам все товары — ты поменяешь название импортера, а эта информация подтянется во все товарах. Помимо этого есть очень много фоновых процессов, требующих полноценного API, например, обмен информацией о клиенте, push-уведомления и т.п., все это прописано в документации.
Тут важно отметить, что архитектурно мы готовимся, что множество поставщиков будут слать нам данные, и очевидно, что в один момент мы их не обработаем. Поэтому на все обращения по API мы отвечаем номером задачи, которая ставится в очередь. И поставщик в любой момент может проверить по отдельному методу, какой статус у его задачи: в очереди, выполнена, или есть какие-то ошибки. Либо, если настроить уведомления, можно получать результат по итогу отработки задачи.
Это позволяет балансировать нагрузку на своей стороне так, как нам удобно, не загружая весь сервер, если вдруг все поставщики в один миг начнут выполнять затратные операции. И это еще легко масштабируется. Чуть что, добавляется больше серверов, которые начинают параллельно разбирать задачи.
Я поделился в этой статье опытом, который мы получили за время работы с крутым клиентом, опытом, который можно использовать и совершенствовать в других проектах. И я рад буду, если кому-то он пригодится, потому как писал не хвастовства ради, а ради шэринга эксприенсом. Поэтому подключайтесь в комментах, кто еще какие классные решения знает.
И как? Теперь он не уступает диким ягодам? Вы уже вышли на топ-3 маркетплейсов?
Поздравляю, вы за 2 года сделали версию Битрикса на ларавеле для работы маркетплейса "без участия разработчиков".
Ни о какой конкуренции с озонами и дикими ягодами речи не может идти. Ваша поделка подойдёт для маркетплейса битрикса, чтобы каждый Вася Пупкин решил попробовать себя в роли владельца маркетплейса.
"И как? Теперь он не уступает диким ягодам? Вы уже вышли на топ-3 маркетплейсов?"
— статья как бы находится в разделе разработка, а не маркетинг или сео или торговля и вопрос больше был про создать, а не обогнать.
"Поздравляю, вы за 2 года сделали версию Битрикса на ларавеле для работы маркетплейса "без участия разработчиков"."
— вот некоторые прям любят топить за всякие битриксы, cms-ки и готовые решения. Во первых битрикс не панацея, во вторых стек в статье указан не только в рамках России, не думаю, что где-то за границей любят клепать сайты прям на битрикс, отсюда следует универсальность решения.
"Ни о какой конкуренции с озонами и дикими ягодами речи не может идти. Ваша поделка подойдёт для маркетплейса битрикса, чтобы каждый Вася Пупкин решил попробовать себя в роли владельца маркетплейса."
— и снова здравствуй битрикс=)) Мне иногда кажется, что некоторым нравится читать статьи из серии, а как мы использовали "коробочные решения" и заклепали сайт, или а как допили CMS, или как из "говна и палок" сделать сайт за 100$, нежели, чем когда студии делятся реально чем-то годным и достаточно подробно.
Я могу с уверенностью сказать, что до озона или ягоды им очень далеко в технологическом плане. Понимаете, озон или ягода — это не ИМ с админкой. Там сотни сервисов для очень разных вещей, в которые было вложено сотни или даже тысячи часов. Всё это делать с нуля ну очень и очень дорого и долго. А тут за 2 года конкурент? Реклама, не более.
— вот некоторые прям любят топить за всякие битриксы, cms-ки и готовые решения. Во первых битрикс не панацея, во вторых стек в статье указан не только в рамках России, не думаю, что где-то за границей любят клепать сайты прям на битрикс, отсюда следует универсальность решения.
Я не топлю за битрикс. Я тут немного поязвил. Битрикс тоже постоянно делает такие презентации, как у них машин лёрнинг теперь, фейсчекинг всякий, биг дейта и т.п. Все такие крутые, а по факту дальше маленького ИМ на нём не уедешь.
То же самое и тут — сделали законченное решение в сфере, где не бывает законченного продукта. В сфере, где надо нанимать штат из 50+ (на самом деле в озоне их намного больше, в вайлдбериз тоже) разработчиков, продактов, дизайнеров, тестировщиков на постоянном окладе, сжирающим по 5-30 миллионов в месяц, и постоянно улучшать продукт.
Где у убийцы маркетплейса хоть чуточку написано про разработку логистики? Или показ товаров на сайте и конструктор в админке по вашему мнению и есть маркетплейс?
По своему опыту скажу, что 90% фишек топовых маркетплейсов скрыто от пользовательских глаз. И это основная статья расходов, а не конструктор и меню.
И расписано типа круто, но где цифры, Билли? Когда эта поделка будет держать более 10к RPS, 25к заказов в день и всё это разруливать и доставлять, тогда и можно поговорить.
В целом суть мысли понял, частично согласен, но есть некоторые моменты:
"разработчиков, продактов, дизайнеров, тестировщиков на постоянном окладе, сжирающим по 5-30 миллионов в месяц"
— в том, то и дело, что у топ-компаний, условно "не ограниченные возможности" в плане финансирования, если сравнивать с небольшими конторками, предпринимателями, разработчиками и т.д.
Вариант, предложенный в статье, как отправная точка, вполне более чем, далее масштабирование и допиливание(по финансам и т.д). К тому-же озон маркетплейс тоже не сразу сделали, изначально там был интернет-магазин, на сколько мне память не изменяет.
"Где у убийцы маркетплейса хоть чуточку написано про разработку логистики? Или показ товаров на сайте и конструктор в админке по вашему мнению и есть маркетплейс?"
— как мне показалось, основная цель статьи в том том, что делать "высоконагруженные" проекты под большое количество товаров могут делать не только гиганты, если темы "стрельнет", ничто не мешает допиливать, как душе угодно.
"конструктор в админке по вашему мнению и есть маркетплейс?"
— Конструкторы в таких проектах вписываются в контекст" забавно конечно, но как мне кажется он был сделан для того, чтобы разработчика постоянно не дергали с типовыми доработками, под свои "хотелки", выборки, так как деньги на MVP может и найдут, а вот на штат программистов нет.
"По своему опыту скажу, что 90% фишек топовых маркетплейсов скрыто от пользовательских глаз. И это основная статья расходов, а не конструктор и меню."
— ну и конечно, запуская такие проекты следует помнить о том, что по мимо разработки здесь еще нужен постоянный мониторинг, на случай, если что-то начнет отваливаться и т. д, так как это не обычный сайт, отдал клиенту и забыл.
"Реклама, не более" — да реклама, но ребята не поленились и все достаточно подробно расписали, за что как минимум + в карму, потому что уже подташнивает от рекламы студий, в которой одна вода и ноль деталей, но зато рассказывают о том, какие они крутые, как из "говна и палок" делают супер продукты, с супер конверсией и без пруфов.
Цитата от автора
писал не хвастовства ради, а ради шэринга эксприенсом
В чем собственно экспиренс? Вроде бы в "Разработку" запостили, а написали как SEO-шники с маркетологами пишут. Смотрите, что мы выбрали. Решение №1 гуд, а решение №2 говно, но не потому что мы не осилили разобраться, а потому что мы так "щитаем". Если пишите про продукт, а не инструменты, то зачем вообще сравнивать эти самые инструменты. А коли решили так делать, то почему бы не добавить пруфов?
Отправная точка — это не конкурент. Это просто потенциальный новый маркетплейс, который возможно когда-нибудь дорастёт до старого озона до ребрендинга.
как мне показалось, основная цель статьи в том том, что делать "высоконагруженные" проекты под большое количество товаров могут делать не только гиганты, если темы "стрельнет", ничто не мешает допиливать, как душе угодно.
Витрина маркетплейса — это не полноценный маркетплейс уровня озона. Я в одиночку (ну дизайн будет кривой правда) смогу сделать витрину на условные 300к-1кк товаров в каталоге без особых проблем. Она реально будет работать и не особо тормозить. Да с этим даже биртикс справляется. В этом нет ничего уникального.
А вот когда попрут реальные продавцы, реальные клиенты, когда пойдёт логистика, саппорт и т.п., вот тогда и можно будет хоть попытаться сравнить с топами сегмента. И чуйка подсказывает, что в текущем виде убийца маркетплейсов не выдержит этого всего. Его ещё годик другой допиливать в бете, а потом оставшуюся жизнь проекта переписывать, т.к. в текущем виде он не справится с нагрузками уровня озона. А если он до них не дорастёт, то опять же, как можно их сравнивать?
К тому-же озон маркетплейс тоже не сразу сделали, изначально там был интернет-магазин, на сколько мне память не изменяет.
Да, примерно до 2018 он был обычным книжным магазином (но с огромной посещаемостью, своей логистикой и т.п.). А потом знаете что позволило ему выбиться в топ маркетплейсов? Десятки миллиардов рублей инвестиций и расширение ИТ-штата со 100 до 1000+ человек за лето. Т.е. представляете себе масштаб? Тысяча разработчиков, дизайнеров и т.п. пилили новый озон 2 года до текущего состояния (на самом деле часть озона, т.к. огромная часть так и осталась легаси и живёт как раньше в недрах озона). Они смогли в такие сроки сделать только по одной простой причине — совершенно не жалели денег и пылесосили всех хороших разрабов, до которых могли дотянуться. Их HR’ов даже на некоторых митапах забанили, т.к. они тупо приходили хантить.
Не хвастались бы, всё было бы нормально. А так какой-то пафос идёт от них и послание потенциальным неразбирающимся клиентам — мы делаем сервисы круче топовых ИТ компаний со штатом в 10-100 раз меньше.
Выбираем схему сотрудничества с «Вайлдберриз»: FBO, FBS или DBS
Маркетплейс Wildberries предлагает три схемы сотрудничества.
FBO/FBW (Fulfilment By Operator/Fulfilment By Wildberries) — хранение и продажа товаров со склада Wildberries. Продавец отправляет на склады маркетплейса крупные партии товаров, и они появляются в каталоге. Когда покупатель заказывает, Wildberries организует доставку.
FBS (Fulfillment By Seller) — реализация через маркетплейс с собственного склада продавца. Продавец хранит товары у себя, когда появляется заказ — наносит маркировку и отправляет товары на Wildberries, и маркетплейс организует доставку до клиента.
FBO (хранение и доставка со склада маркетплейса): преимущества и недостатки
Продавец отправляет товары на склады маркетплейса и ждет заказов. Когда появляется заинтересованный покупатель, Wildberries организует доставку.
Схема удобна: не нужно обрабатывать каждый заказ, содержать собственный склад. Но важна готовность заморозить партию товара.
Поэтому считается, что FBO рискованнее, чем FBS. Продавец может отправить маркетплейсу много продукции и не реализовать её, но продолжать оплачивать хранение. Можно перейти к этой схеме после успешной работы по FBS, если товар популярен и вы легко можете предсказать спрос покупателей
Кроме того, у «Вайлдберриз» несколько складов в разных точках России: Москве, Краснодаре, Казани, Новосибирске и т. д. Можно распределить товар по ним. Это благоприятно для ранжирования: чем ближе потенциальная дата доставки до конкретного пользователя, тем выше товар в его личной выдаче.
Выбрать схему размещения товаров поможет платформа WeCheck. Изучите, с каких складов продают конкуренты, и определите, что под ходит вам лучше.
Плюсы
Быстрая доставка (быстрее, чем при FBS).
Не нужен собственный склад — экономия на аренде складских площадей, оплате работы сотрудников.
Не нужно контролировать каждое отправление.
Лучшие позиции в выдаче при наличии товара на ближайшем к покупателю складе.
Нет риска пропустить заказ покупателя.
Нет риска просрочить доставку при форс-мажоре, как при работе по схеме FBS, и получить за это штраф.
Минусы
Более высокая комиссия, чем при работе по FBS.
Риск порчи и потери товара на складе маркетплейса.
Невозможно контролировать качество упаковки.
“Заморозка” товара на складе маркетплейса, невозможность его реализации через другие каналы.
Долгий и затратный возврат товара, если вы передумали продавать его на Wildberries.
FBS и DBS (фулфилмент от продавца и доставка от продавца): преимущества и недостатки
FBS и DBS оптимальны, если нужно протестировать спрос на новые товары, не “замораживая” их на складе маркетплейса, есть другие выгодные каналы реализации продукции.
Плюсы
Комиссия ниже, чем при FBO.
Можно свободно распоряжаться товаром, продавать его через другие маркетплейсы или торговые точки, контролировать остатки и срок годности.
Можно контролировать условия на складе, исключить потери и порчу товара.
Нет расходов на хранение товаров на складе маркетплейса.
Можно упаковывать товар самостоятельно и не сомневаться в качестве тары и аккуратности сотрудников.
Минусы
Доставка медленнее, чем при работе по FBO.
Необходим собственный склад и сотрудники (либо привлечение фулфилмент-оператора на аутсорс).
Необходимо контролировать отправление в пути на склад маркетплейса, зависимость от добросовестности транспортной компании.
Штраф Wildberries за нарушение сроков доставки.
DBS — доставка продавцом
DBS — частный случай FBS. Продавец берет на себя практически весь фулфилмент и доставляет заказ покупателю напрямую, без посредников в виде складов и ПВЗ Wildberries. Схема позволяет продавать цветы, скоропортящиеся продукты.
Основные плюсы и минусы — те же, что у FBS, но есть два исключения:
быстрая доставка и возврат товара при отказе клиента при получении — нет посредника в виде маркетплейса;
цена перевозки может возрасти — для маркетплейсов, как крупнейших заказчиков, условия выгоднее, чем для маленьких компаний с редкими отправлениями.
В данный момент услуга доступна в Москве и Санкт-Петербурге.
FBS с привлечением фулфилмент-оператора
Если FBO не подходит, а ресурсов на обработку каждого заказа не хватает, можно передать задачу на аутсорс, выбрав фулфилмент-оператора. Компания хранит товары, обрабатывает заказы, доставляет товар на склад Wildberries, выполняет все рутинные задачи. Фактически, с маркетплейсом вы работаете по FBS, но пользуетесь комфортом FBO. Все задачи решает подрядчик, остается только передать ему товары.
Плюсы
Не нужен собственный склад и персонал.
Можно работать с разными маркетплейсами, офлайн-точками и т. д., не “замораживая” товар.
Не нужно взаимодействовать с транспортной компанией.
Быстрая обработка заказов (при больших объемах вложения меньше, чем на наем штатных сотрудников для этой задачи).
Фулфилмент-оператор отвечает за сохранность товара.
Можно выбрать оператора с оптимальными условиями оплаты (процент с оборота, оплата за каждую операцию, абонемент и т. д.).
Многие операторы обеспечивают интеграцию с маркетплейсами: проще следить за продажами и остатками.
Минусы
Запутанная тарифная сетка у некоторых операторов, скрытые платежи.
Ограниченный доступ к складу.
Незнание специфики бизнеса клиента.
Риск задержек выплат и выдачи документации (сотрудники не могут выдавать их каждый день по первому требованию).
Зависимость от внутренних правил оператора.
Риск выбрать недобросовестного фулфилмент-оператора.
Эта универсальная схема объединяет плюсы FBO и FBS: минимизацию нагрузки и свободное распоряжение собственным товаром. Главное — выбрать фулфилмент-оператора с наиболее выгодным тарифом, который не потребует больше вложений, чем FBO.
Какая схема фулфилмента лучшая?
Все зависит от специфики и особенностей бизнеса. Итак:
FBO — для тех, кто хорошо прогнозирует и ценит удобство, не хочет тратить ресурсы на логистику и обработку каждого заказа, готов заморозить часть товаров и платить более высокую комиссию;
FBS — для тех, кому важно свободно распоряжаться товаром, не “замораживая” его на складе, для тестирующих новые продукты;
DBS — для поставщиков скоропортящихся товаров и цветов, для тех, кто хочет доставлять быстрее маркетплейса.
FBS с фулфилмент-оператором
Кроме того, один продавец может сочетать разные схемы: например, поставлять популярные товары по FBO, а редкие — по FBS.
На платформе WeCheck можно отслеживать продажи конкурентов по каждой из этих схем. Посмотрите, в каких категориях продавцы предпочитают FBO, а в каких FBS. Оцените объемы продаж и выручку по каждому типу склада и подберите для себя оптимальную схему сотрудничества
Следите за нами в соц сетях
Бесплатный демо-доступ
Если ранее вы не работали с нашим сервисом аналитики, то вы можете оформить бесплатный доступ на 24 часа и провести аналитику
- Полный доступ на 24 часа
- Без привязки карты
Бесплатная консультация
Если вы хотите посмотреть, как работает этот или другой функционал WeCheck на конкретном примере, вы можете заказать бесплатную консультацию нашего специалиста
Какой склад «Вайлдберриз» выбрать именно вам: изучаем конкурентов с WeCheck и планируем логистику
В этой статье мы рассмотрим зоны покрытия складов маркетплейса и расскажем, почему это важно для успешной торговли.
Как WeCheck собирает данные? Точность аналитики продаж на маркетплейсах по FBO и FBS
В этой статье мы расскажем о различиях и объясним, какая информация будет более точной.
Как организовать поставку FBS на «Вайлдберриз»
В этой статье мы дадим пошаговую инструкцию для поставки на «Вайлдебрриз» по схеме FBS (также иногда называется «поставка «Маркетплейс»»).
Что такое обезличка? Что делать, если «Вайлдберриз» потерял товар?
В статье мы рассмотрим две проблемы — обезличку (ситуацию, когда товар нашли, но идентифицировать не могут) и собственно потерю (вы сдали товар, но на складе его нет).
Как вернуть товар с «Вайлдберриз»
Иногда селлеры решают перенести товары с «Вайлдберриз» на другой маркетплейс или нарастить офлайн-продажи. При работе по FBS это сделать просто: все хранится у продавца, и нужно лишь обнулить остатки. При FBO необходимо забрать свои товары со склада маркетплейса. Здесь мы расскажем, как это сделать.
Требования «Вайлдберриз» к коробам и палетам
«Вайлдберриз» принимает товары только в коробах либо в коробах на палетах. Это относится даже к предметам, которые изначально продаются в коробках (например, обуви и инструментам). Следует различать коробки как вид индивидуальной упаковки и короба, о которых пойдет речь ниже.