The Listing Inheritance: Why Your Second Marketplace Must Not Be Built From Your First Listing

Telephone is a children's game: at the end of the line, something completely different arrives than what was whispered at the start. In marketplace business, the same game is called expansion.

If you perform well on one marketplace, as a retailer or as a manufacturer, you have built something valuable: a listing that sells. The title works, the bullet points convince, the variants are tidy, and the images meet the requirements. At the next marketplace, almost the same thing always happens: someone exports that listing and uses it to fill the new channel. It is fast, and it feels sensible.

It is also the moment where scaling begins to fail. The listing you copy is not your product information. It is a translation of your product information into the logic of exactly one channel.

The thesis of this article: the listing on your first marketplace has quietly become your master record, and every further channel inherits its compromises.

The listing is already your master record

Nobody decides this. It happens because the listing is the place where product data comes together for the first time as complete, checked and ready to sell. Your ERP knows the article number, dimensions and price. The supplier delivers a spreadsheet or a PDF. Only the marketplace forces you to turn both into a complete record, because it does not accept incomplete offers. So the listing is the first place where the data is good. And what is good gets copied.

The problem is that this listing is lossy. The title was trimmed to one channel's search logic. The bullet points follow the structure that channel demands. The category is that channel's category. The variants are built the way that channel represents them. The images were chosen and cropped to its rules. Every one of these decisions was right, for that one channel. Together they form a document from which your original product information can no longer be cleanly recovered.

Telephone: how a compromise becomes a chain

At the second marketplace, you copy the compromises of the first and add those of the second. At the third, it gets worse: the third channel is often no longer filled from the first listing but from whichever listing looks most current and complete, which is the second. From here on, every channel depends on its predecessor, and every station whispers the data a little further out of shape.

We call this the listing inheritance: the sum of all channel-specific decisions a listing carries inside it, which a follow-up channel takes over without anyone noticing. The inheritance grows with every channel, and nobody can say where a particular quirk came from. When a value is wrong on the fourth marketplace, the search leads through three exports, two Excel files and a colleague's memory.

What breaks at the second, third and tenth marketplace? Five breaking points

Every marketplace is its own small data model with its own rules. The differences are large enough in five places that copying stops working. Which rules apply in detail is decided by each marketplace itself, and they change over time. What matters is the structure of the problem. How this plays out for marketplaces on the same Mirakl backend is described in Commerce Velocity: Die Falle im gemeinsamen Mirakl-Backend.

1. Attributes and mandatory fields

Every marketplace defines its own mandatory fields, its own attribute names and its own permitted values. What was a free-text field on the first channel is a selection list on the second, and on the third the field is missing or called something else. An export from the first listing then delivers exactly what the first channel needed. Anything only the second channel demands is missing, because it never had to be maintained in the source listing.

2. Category mapping

Categories are not truth, they are an offer made by the respective channel. A product that sits at a certain place in one marketplace's tree often belongs in a category with a different scope and different mandatory attributes on another. The category decides which fields are asked for at all. If you carry over the category of the first channel, you start with the wrong list of questions.

3. Variant logic

Whether size and colour are managed as variants of one product or as separate articles, which attributes define a variant and how grouping works differs from channel to channel. A listing optimised for one marketplace's variant structure cannot simply be rebuilt on another. Variants turn into duplicates, or duplicates turn into wrongly grouped variants.

4. Text and image requirements

Title structure, length and structure of descriptions, permitted content, image formats, backgrounds, order: everything is channel-specific. A title trimmed for visibility on one channel is often too long, too short or too promotional on the next. The source you could rewrite from is the unaltered product record, not the finished title.

5. Languages and countries

When you expand into a marketplace in another country, you often translate the finished listing in practice. Then you are translating a text trimmed for one channel, and the compromises of the source channel migrate into the target language. On top come units of measurement, currencies and mandatory information that differ by market. Translating a listing means translating a translation. How adapting to languages and markets works cleanly is shown in KI für mehrsprachige und multikulturelle Märkte.

An example: the garden chair with four faces on four channels

A manufacturer sells a folding garden chair in four colours and two sizes. On the first marketplace it performs well. The title contains the search terms that work there, the variants hang under a parent article, and the images are cropped on a white background.

On the second marketplace, the listing is taken over one to one. The category does not quite fit, so two mandatory attributes for material and load capacity are missing. The title is awkwardly built for this channel. The third channel is filled from the second listing, including its gaps. At the fourth, in another country, the title is translated. Four marketplaces, four different data states, and no record that could say which one is right.

The example is invented, but anyone who serves more than one channel knows the pattern.

How do you scale to more marketplaces? Free the master record

The solution is not a better copy template. It is to lift the master record out of the listing and put it where it belongs: in a central, channel-neutral product data foundation. There, the information lies as it is: complete, structured, with attributes that describe the product and not the channel. Every marketplace is then served in a channel-appropriate way from this source, not from the listing of its predecessor.

That is the idea behind ainavio as a PIM with AI. Product data from ERP, supplier spreadsheets and PDFs comes together in one central record (the golden record, in which sources can be prioritised). The data model is configurable, mandatory attributes prevent an incomplete product from going out, and shared properties can be inherited by variants. On this foundation, the AI Agents do the work that used to be left undone when copying from channel to channel:

• The Marketplace Agent assigns categories and mandatory attributes to the fields of 26 shops and marketplaces, including Amazon, OTTO and Kaufland. You decide whether content applies uniformly to all products or is adjusted per category and product.
• The Enrichment Agent adds missing attributes and creates titles, descriptions and bullet points from the master record, not from another channel's finished listing.
• The Translation Agent translates product information into any language you need and converts units of measurement, starting from the source rather than from an already translated listing.
• The Quality Agent detects missing information, duplicates and inconsistencies. Before every export, multichannel publishing checks completeness and channel conformity, so faulty data does not go out in the first place.

New channels such as eBay or Hornbach are then no longer a project that starts from the predecessor's listing, but one more output from the same source.

Four questions before you connect the next marketplace

• Where does the new channel's data come from? If the answer is "from the listing on channel A", you have a listing inheritance.
• Where is the channel-neutral version? If it does not exist, the listing is your master record.
• Which mandatory fields does the new channel require that the old one never needed? These fields are most likely not maintained in your data.
• How many stations lie between the source and the target channel? Every station is a chance for Telephone.

The end of Telephone

Marketplaces do not scale with the number of channels but with the quality of the source. If you fill every new channel from the listing of the last, you speed up at first and later lose control over what is published where. If you free the source instead, you can add channel after channel without carrying the errors of your predecessors along.

The listing is the last step of the chain, not the first.