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

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

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

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

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

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

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

таблица товаров, таблица опций, таблица связей товар-опция
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 — можно заниматься туризмом, не имея собственных отелей. И так далее.

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