Последние сообщения

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

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

Классическое решение: 

таблица товаров, таблица опций, таблица связей товар-опция
NoSQL не нужен

Ответ на вопрос «как хранить» зависит от того, какие данные вы будете запрашивать. То есть — от представлений данных, с которыми работает ваша программа (программы). Именно на основе этих представлений синтезируется полная модель данных, хранящаяся в БД.

В свое время, лет 25 назад, был (может, и сейчас есть) стандартизированный подход, называвшийся IDEF1 (это имя из стандарта) или Entity-RelationShip (это название процедуры), позволявший формальным образом синтезировать из этих, частных, представлений полную модель данных. И были программы, которые позволяли это делать. Я одной такой пользовался, ERwin называлась (AFAIK она жива и сейчас), но, в принципе, нужные процедуры можно выполнять и вручную. Описание процедуры на русском есть, как минимум одно, которое я знаю — в старой книге «Мартин Дж. Организация баз данных в вычислительных...»

Короче, синтез модели ваших данных — это ваша задача, связанная со специфическими вашими задачами.

Судя по информации из вашего вопроса, я могу только сказать, что:

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

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

3. NoSQL — это название больше коммерческое, а не техническое: оно включает много разных технологий хранения в БД, единственным общим признаком которых является, что они — не реляционные. Под эту задачу мне видится годным вариант навигационной БД (это где каждая запись содержит физические ссылки на связанные с ней записи): сетевая, например. В настоящее время такие БД иногда ещё проходят под псевдонимом «графовая». Но, опять же, смотрите на нужные вам представления, в данном случае — обращайте внимание на пути доступа к данным (эти самые ссылки): навигационные БД в этом плане не так гибки, как реляционные, и отсутствие нужных ссылок может заставить ходить по кривым путям и убить тем самым производительность.

Но это все теория, а что там сейчас на практике творится — я с уверенностью сказать не могу. Насколько я понимаю, там надо смотреь возможности конкретной СУБД — тем более, что производители часто называют их словом «гибридная», и надо понимать, что в этот гибрид попадает. 

В стародавние времена это действительно было проблемой.

И обычно использовался п.2, который называется EAV, и который в нормальном виде (таблица всех атрибутов, таблица всех значений, и таблица-связка товар-атрибут-значение), хотя и является истинно реляционным решением, служил причиной кровавых слез не одного поколения программистов.

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

Но сами по себе «документо-ориентированные базы данных» в качестве основного хранилища — это ад и проклятие, хуже EAV. Если EAV делает адом только работу с атрибутами товаров, то Монга делает проклятием работу со всей БД целиком. Забудьте об этой идее.

Тем более что в последние годы появилось вполне достойное решение: во всех классических СУБД появилась поддержка JSON полей.

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

На начальном этапе вы даже сможете делать поиск по атрибутам, используя нативные JSON функции. Но в дальнейшем поиск товаров, а так же фильтрацию по атрибутам на странице категории (так называемый «фасетный поиск») надо будет возложить на специальный поисковый движок (который тоже входит в широкую категорию «NoSQL», хотя ничего общего с документными БД не имеет, и БД, собственно, не является), такой как Эластик или Мантикора.

Главное при этом хранить (либо в коде, либо в таблице категорий) эталонные структуры таких json полей, которые, во-первых, использовать как справочники для заполнения товаров (тупо чтобы помнить, что частота процессора называется freq, а не frequency), и чтобы собственно делать фасетные фильтры. 

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

Если говорить «за вообще» — то лично я стою за агентскую схему: «в там» регается компания-агент, которая за незначительный процент собирает деньги, основную сумму по договору отправляя материнской компании (например — в РФ). Конечно, ИП в России — удобная штука, но сумма оборотов уж очень ограничена, для международного-то маркетплейса :-)

В США налоги платить придется в любом случае, вне зависимости от направления получения доходов, только размер и количество будут разными. В Делавере, кстати, помимо федеральных налогов будут еще и местные, налоги штата. Другое дело, что с агентского вознаграждения можно и заплатить — это немного. Но вот если клиент попадется из США, да еще и местный — то возникает налог с продаж (как минимум — в большинстве штатов), и тут уже агентский договор не рулит, платить придется с полной суммы. Жульнические схемы типа «клиента из США отправляем на европу, и наоборот» ловятся, читал такие сообщения краем глаза пару раз.

В целом — поддержу предыдущих ораторов: на каждом рынке придется строить свою схему отдельно, и она будет очень сильно зависеть от частностей, например — от доли самого маркетплейса в сумме транзакции. Без юристов и спецов по International Taxation эту проблему не расколоть.
Если бы я сам захотел принимать максимально широкий спектр платежей со всего мира в одной точке подешевле, я бы регнул контору в Вайоминге, США, и принимал деньги на пейпал.

Если взять Китай — там совсем специфические платежные системы. Карты Visa, как в Европе — не приветствуются.

Если взять Европу и США — напротив, будет через VISA.
И т.д.
На весь мир не получится — придется подстраиваться под каждую крупную страну.
Можно взять интегрированное решение, типа XSola, но за свой сервис они закономерно хотят денежку. Которая ну намного-намного больше ваших вожделенных 6%

У эквайрингов в РФ есть один недостаток: они не любят карты дальше РФ/СНГ

за Альфу не скажу, может, любит, но, думаю, не любит

второе — не знаю, какие планируются обрроты, но прямой мерчант дают далеко не нулевым, хз насколько верна цифра в $100к/mo для минимума (для Кипра до кризиса было и 10к), но, думаю, около того

PayPal с нуля, если пролет с мерчантом, приемлем. Лучше не в России.

Эстонские компании с 25% налогом и возможным НДС — для лохов. Если вы клюнули на e-residency, поздравляю.
NL, CY получше, но НДС везде в Европе давит тяжелой лапой.

«Всего мира» не существует. От слова «совсем» или «вообще»
Есть США с кредитками в пупке, от рождения. И все. Чуток AU и CA.
Остальные платят кредитками много хуже, европа — много населения, потому много транзакций, но до США конверсии далеко.
Поэтому на «все виды платежей» можно забить. Их всего три: кредитки, Пейпал и крипто. Крипто для нелегала (казиношки там, зверушки, ..)

Ирландия и Нидерлады да. Ведут. 50к в год если готовы выложить, можно что-то рекомендовать.

Sripe хорош, но проблема США в их завязанности на US Citizen, это значит — наличие SSN.
Да, можно зарегить компанию, необязательно Делавер (там скрытый реестр, в отличие от многих, но это последнее преимущество). И США не оффшор, номинала с SSN нанять за 500 в год не получится.

В целом схема строится от оборотов, если продавать услуги аутсорса для небольшой конторы — это одно, 8-15% потерь + налоги, если обороты большие — это другое (3-5% финсервисам + налоги), очевидно, что универсального решения быть не может

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

Можно определять минимальным функционалом, который вы планируете в продукте. Реализовали — выпускаем.

Критерии готовности продукта:

— [качество] нет ошибок, которые бы мешали использованию продукта
— [целостность] любой пользователь может пройти от начала до конца, не прибегая к помощи разработчика
— [обучаемость] приложение понятно настолько, что пришедшие 1000 пользователей не завалят поддержку тупыми/одинаковыми вопросами
— [нагрузка] приложение выдержит одновременную работу 1000 пользователей (цифра условная)
— [отслеживаемость] в любой момент вы понимаете где находится пользователь, что не получается, что не работает как задумано, есть возможность связаться с разработчиком и получить адекватный совет по дальнейшим шагам, есть возможность понять почему пользователь вывалился из workflow и возможность связаться с ним.

Я бы выбрал Юкассу — один из самых известных сервисов приема оплаты на сайте или платежный сервис Енот, у них почти все тоже самое но только процент по меньше

Без оформления юридического лица (хотя бы в формате ИП) вы не сможете подключить платежный агрегатор — Юкасса, ни Сбербанк, ни Робокасса или любой другой пейкипер работают только с юрлицами по проведению платежей.

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

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

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

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

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

приведу плюсы цифровой экономики в контексте торговых Площадок:

— трансграничность

— операции 24/7

— сокращение трансакционных издержек в экономике

а вот и несколько минусов:

— монополизация со всеми вытекающими

— отсюда —> угроза государству Как институту со стороны техногигантов. Провал IPO Alibaba демонстрирует приведённый аргумент

— государство тратит свой ресурс на противостояние власти техногигантов и часто возникает опасная тенденция: обосновать положение дел в экономике присутствием монополистов; обелить своё практически любое действие со ссылкой на третью силу имя ввиду ИТ монополии со своей экосистемой; пренебрежение базовыми правами и свободами обычных граждан. На этот Тезис приведу пример с закрытием iHerb, какую угрозу несёт для России эта площадка не до конца понятно, учитывая, что препараты из площадки успешно продаются а аптеках столицы… правда с ценником в полтора-три раза дороже

Но одна из самых интересных мыслей на счет новой экономки состоит в том, что всякая платформа в ИТ образует свою экосистему с причастными только ей атрибутами. Например, культура покупок в Лабиринте отличается от культуры покупок в Беру. И почти каждая платформа стремится расшириться за счёт новых участников. Это создает Эволюцию продукта и продажа прежде книг (Озон) сегодня выглядит как простой магазин с кучей всего. Тут уже нельзя говорить о культуре. Тут сплав. Культура разрушена. Цель предпринимателя в виде индивидуальных корыстных интересов достигнута. Пусть она в самом начале и была светлой и большой. И сегодня можно не обладать сопутствующей инфраструктурой и быть лидером рынка. Яндекс организует такси, не имея в парке авто. А общество сталкивается с ещё одним минусом-сплошная юберизация — покушение на институт труда. Работник теперь не в компании а самозанятый. Это крайне опасная история. В России пока не решена. А вот во Франции суд удовлетворил иск К юбер, сказав что водитель не может быть самозанятым, поскольку он не может работать на стороне и управлять ценообразованием, как положено самозанятым. Видимо в России можно этим заниматься )

другие примеры; банк без офисов и банкиров, телефония без коммутаторов (это все Тиньков — он один такоой). Airbnb — можно заниматься туризмом, не имея собственных отелей. И так далее.

Теперь нужно понять, куда приведёт могущество таких игроков и будет ли оно вписываться в цивилизационное развитие стран или это будет глобальная надстройка, которая реализует концепт мир-Большая деревня бег границ, без государств; мир со средним человеком, не стремящимся к грандиозному, с удовлетворёнными потребностями и обществу, с замедляющимся развитием 

Вы взяли два крайних варианта – благо или тормоз. Ни то ни другое.

Во-первых, нужно понимать, с чьей точки зрения мы планируем оценить пользу или вред маркетплейсов? С точки зрения частного покупателя, размещающего там товары предпринимателя, владельцев площадок, государственных органов?

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

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

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