Catalog management: first-party retailer vs multi-vendor marketplace

A first-party retailer buys the stock, writes the product page and sells under its own name. A multi-vendor marketplace sells other people's products under its roof: the sellers own their offers, the marketplace owns the page those offers sit on. In catalogue terms that is the whole difference. Everything else in this post follows from it.

One line of housekeeping first, because "first-party" means three different things depending on which corner of the web you are reading. In Amazon circles it means selling wholesale to Amazon (the 1P versus 3P debate). In retail strategy it means your own assortment as opposed to the marketplace assortment you bolt on beside it. Here it means the operating model: you are the retailer, and the stock and the page are yours.

There is a third model sitting between the two, dropship, and the rule that separates all three is who the seller of record is.

Mirakl and fabric describe the split the same way, and the business-model pros and cons have been written up many times over. This is not another one of those. It is about what the split does to the product data. (If your question is about tool categories rather than operating models, the PIM vs marketplace catalog management post covers that.)

On your own site, the product page and the offer are the same object. You write the title, the description, the attributes, the price, and the stock, and it is all one record. Marketplaces come in two shapes. The Etsy shape gives every product to one seller and has no shared page. The Amazon shape, which is also how Mirakl-powered retail marketplaces such as B&Q and Decathlon work, keeps one product record per item and lets many sellers hang their offers off it, matched by barcode. Your offer is the price, the stock, the condition. The page belongs to the house.

Who gets to write the page varies. On Amazon, several sellers can contribute text and images to the same page and Amazon picks whose version shows, with brand-registered owners winning by default (Riverbend Consulting). On Mirakl-run marketplaces each operator decides whether sellers may create products at all or only attach offers to what already exists, and each operator keeps its own category tree (WISEPIM).

For a retailer selling other people's brands, that changes the job in a way that is easy to miss until it happens. You do not publish a product to a marketplace. You join a page as one more seller. Where the page is thin or wrong, retailers do try to fix or improve it, and the marketplace sometimes accepts the change and sometimes does not. Your content is a proposal. And the data model you are proposing into is theirs: every attribute you hold has to be mapped to their field, modelled as a new channel field, or derived from what you already have.

On your own site you write the page. On a marketplace you apply to it.

And if you are the one thinking of becoming the marketplace? Then the crowd's catalogue becomes yours. Platform vendors describe the model as offloading the catalogue work to sellers. The people who build operator tooling describe category mapping, attribute normalisation and duplicate detection as ongoing operations that work at twenty vendors and become a bottleneck at two hundred (Gradion). Both are true at different sizes. Whoever owns the record owns the gap-closing, and that does not change because the sellers are now other companies.

Some honesty before the list. If you are the brand owner and registered as such, most of what follows is softer: the page tends to be yours to control. If you are a retailer listing brands you do not own, which is the case for many multi-channel operators, this is the daily reality. Four things change.

1. The page may already belong to anyone. Sometimes the supplier created it. Sometimes a competing retailer did. Sometimes nobody in particular owns it. Your clean, complete catalogue record does not change which of these it is.
2. Your edit may never show, and nobody tells you. Sellers on Amazon's own forums describe submitting a better title or a correct description and finding, weeks later, that the page has not changed, with the message that the field "is being contributed by another seller and cannot be changed". There is no refusal email. Pushed is a fact about your system; shown is a fact about theirs. It is the content version of a listing that is pushed but not live.
3. The Buy Box is a separate fight. Who gets the sale on a shared page is decided by landed price, delivery speed and seller health, and it has nothing to do with whose text is on the page. Around four in five Amazon sales go through it (ChannelEngine). You can win the Buy Box and still be selling on a rival's bad photos.
4. If you ever pull the listings back, you import the crowd. Connect a marketplace account to a catalogue tool and you get every seller's submissions along with your products: years of colour values, correct, misspelled, written out as sentences. A shared page looks tidy from the front. From the inside it is other people's catalogue debt, and it is now yours to sort.

None of that makes marketplaces a bad idea. It makes them a different kind of catalogue work, and it is worth knowing which kind you are signing up for. What that work looks like day to day, requirement changes and all, is in the marketplace PIM post.

No. Whether you hold the stock or the supplier ships it for you, the product data work is the same conversation. The dropship model decides who is seller of record and who carries the inventory risk. It does not decide how much work sits between the supplier's file and a product someone can buy. Two retailers with the same range and the same tools could be months apart on that, and the difference is what arrived in the spreadsheet.

Which brings us to the thing that stays the same.

Whichever model you run, the supplier sends you a spreadsheet. Sometimes it is clean: images, prices, titles, attributes, all there. Sometimes it is a sheet plus a pile of shared-drive folders that someone has to reconcile. Either way the retailer builds the listing. And there is no honest number for how long that takes without seeing the file. Great data is fast. Bad data is slow. That is the whole rule.

The scale has two ends, and they fail differently. At the full end, the supplier sends complete content and you publish it. Fast, but the copy was written for the brand's positioning, not for your channel, your audience or your category, so it tends to go live flat. In categories where presentation moves conversion, that is a commercial trade-off rather than a neutral shortcut.

At the empty end sits what we call the three-column file: a SKU, a name and a price, and nothing else. No description, no details, no compatibility, no sizing. Everything a shopper would buy on is missing, and it all lands on the retailer. In our experience it tends not to get written, because producing product content for someone else's brand from a bare SKU is a job nobody budgeted for. Those products are not slow to list. They are never listed, and never sold.

That matters more than it used to. A product missing its structured attributes is found only by shoppers filtering on price, and increasingly by nobody at all, because AI shopping assistants filter on attributes before they ever show a page.

So the practical move sits before any of this. Ask for the feed before you sign the supplier. If it is a three-column file, budget for writing the content yourself, or do not budget for the sales.

A product nobody wrote is a product nobody sells.

OneSila's seat in all of this is the first-party catalogue: the record you own, whichever channels it ends up on. The measure is not where the data lives but how many supplier products become sellable per week. The supplier's spreadsheet is imported directly, and matching their columns to your fields happens inside the application rather than on your desk. The AI then assigns images: if the sheet names the file, it takes that file; if it does not, it works out which photo belongs to which product.

What the AI cannot resolve is shown, not hidden. Missing images and missing attributes appear as gaps on the product from import onward, so you know on day one which of the eighty products can go live and which are waiting on the supplier. Closing those gaps is your team's job, usually by going back to the supplier, because a product with gaps does not sell.

Two honest limits. OneSila does not go hunting the internet for a missing image or email your supplier for a size chart. Teams that want that bring their own AI and connect it through OneSila's MCP connector, so the agent works inside the workflow you configured rather than as another button. And OneSila is not the tool for running a marketplace. If you are the one onboarding four hundred sellers into one catalogue, that is the operator's seat, and Mirakl Catalog Manager and its peers are built for it.

From the owned record, products flow to every channel, Amazon, bol, eBay and Mirakl-powered marketplaces included. Content can differ per channel where your setup calls for it, in tone and format rather than just in which fields are sent. When a marketplace objects, both kinds of error land in the product record: validation errors, where a value is missing or incompatible, and policy rejections, where the channel objects to what the listing says. What OneSila does not do is tell you whether Amazon adopted your text on a shared page. The product flow is ours. The account, and the page, are the marketplace's.

Whichever model you run, someone is going to hand you a spreadsheet. What is in it decides more than the model does. Your bottom line will thank you for asking to see it first.