Product content on marketplaces: titles, descriptions, photos and rich content that genuinely increase sales.
Author: Borys Terlecki · marketplace sales and implementations at Commercraft · updated: October 2026
In brief
A product page does three jobs at once: it ranks your offer in the platform’s search, persuades the buyer and cuts returns. The title gets 60 characters, and photos sell before anyone reads the description.
Product data needs a system decision: one source for transactions (ERP), another for content (PIM or your shop) and a channel layer in the integrator, because every platform defines variants, categories and identifiers differently.
In the Salsify 2026 study, 45% of shoppers returned a purchase because of wrong information, and 45% of Gen Z abandoned a purchase when details differed between sites. Consistent data across channels is a precondition for conversion.
On a marketplace, the buyer cannot touch the product, hold it up to the light or ask a sales assistant across the counter. Everything they know comes from the product page. That makes good product content the cheapest and most effective salesperson you have. Here is what a selling product page is made of, and how to build one.
A good product page ranks the product in the platform’s search, persuades the buyer to purchase and cuts returns, because it describes precisely what the buyer will receive. Keep these three functions in mind for every element: visibility, conversion and matching expectations.
The title is the field the algorithm reads most carefully and the buyer sees first. A good title contains the brand, the product type and the key features (model, size, colour, intended use) in a natural, readable order. Avoid forcing keywords in: platforms are getting better at spotting it, and buyers skip “spammy” titles anyway.
Most purchase decisions start with a photo. Make sure you have:
Every platform has its own technical requirements. Meeting them is about more than looks: often it decides whether the offer is accepted.
A buyer scanning the page picks up the bullet points first, so that is where the key benefits and specifications belong. The longer description goes deeper: uses, how the product differs from competitors, what is in the box. Write in your customer’s language rather than internal jargon. Answer questions before they are asked, because every unanswered question means an abandoned basket or a return.
Buyers filter search results by specifications, so attributes are far more than paperwork. The more fully and accurately you fill in attributes (size, material, colour, compatibility), the more often the product appears in the right filters and results. Incomplete data simply means fewer impressions.
You can maintain titles, descriptions, attributes and photos in three places: in your shop platform (Shoper, IdoSell, PrestaShop, Magento), in a dedicated PIM (Akeneo, Pimcore, Plytix) or in an integrator platform (Base.com, Apilo, Sellasist, ChannelEngine, Tradebyte, Mirakl Connect). Each of these tools is happy to become your “product database”, and in many companies all three end up playing that role at once. Then the same product has three titles, two sets of attributes and nobody knows which version is true.
Instead of asking “which system should I choose”, ask a data management question: which system is the system of record (single source of truth) for each type of data. In practice, a product record has three layers with different owners and different rates of change. Transactional data (price, stock, cost) changes hourly and belongs to the ERP or WMS. Descriptive data (name, description, attributes, media, translations) changes rarely, needs editorial work and belongs to the PIM or, for a small catalogue, to the shop. Channel data (the category on Allegro, Poland’s largest marketplace, a shortened title for Amazon, the attribute set for Kaufland, overrides) lives in the integrator, because only it knows each channel’s requirements. ChannelEngine’s documentation says so directly: data is mapped per channel in content mappings, and a manually overridden value “takes priority over mapping” (source: support.channelengine.com). Mirakl Connect, in turn, separates the product (taxonomy, shared by all) from the offer (price, stock, channel attributes) and recommends declaring “only the attributes the channel really uses” (source: developer.mirakl.com).
With the layers mapped out, choosing a tool is simple. The matrix below sorts typical set-ups along two axes: the number of channels and markets, and catalogue complexity (variants, number of attributes, languages).
ERP / WMS
price, stock, cost: transactional source
PIM or shop
name, description, attributes, media: content source
Integrator
category and attribute mapping, per-channel overrides
Marketplace
product page and offer in the platform’s format
Three layers of the product record and their systems of record. Commercraft analysis based on ChannelEngine, Mirakl Connect and Akeneo documentation.
The diagram shows the direction of flow, and the number of tools varies: in a small company one shop can handle the first two layers, while in a large one each is a separate system with its own owner.
Decision matrix: where to keep product content
Complex catalogue, few channels
Fashion, footwear, configurable furniture: variants on two levels, several languages. A light PIM (Akeneo Community, Plytix) or an integrator with a hierarchy (Tradebyte, ChannelEngine) as the content source; the shop only receives data.
Complex catalogue, many channels and markets
A brand with thousands of SKUs on 5 or more platforms in several countries. A full PIM as the content source, the ERP as the transaction source and an enterprise-class integrator as the channel layer. A dedicated data owner.
Simple catalogue, few channels
A few hundred products without variants, a shop plus one or two marketplaces. The shop is the content source, and the integrator (Base.com, Apilo, Sellasist) maps categories and parameters. No PIM.
Simple catalogue, many channels
A wholesaler or distributor with a broad, flat range on many platforms. An integrator with its own product database is the only place where content is edited; the shop and ERP supply only prices and stock.
A simplified portfolio model (like the BCG matrix): two axes, four typical set-ups. Quadrant boundaries are drawn from Commercraft’s implementation practice and serve as a guide rather than fixed thresholds.
When data “does not transfer” between systems, the cause is far more often a different definition of the product than a missing field. Each platform has its own idea of what a variant is, what the price is attached to and at what level the identifier is assigned. Zalando manages an article on three levels: the model (name, brand, silhouette), the configuration (colour) and the individual article with size, EAN and price (source: partner.zalando.com). Amazon groups variants into parent and child; the parent is not a product for sale, yet the title and description on the page often come from it. Allegro works the other way round: there is no parent, the offer is attached to a product card in the Allegro catalogue by EAN code (known as productisation), and parameters are required per category; offers without a complete set of parameters lose visibility in filters (source: apilo.com). On marketplaces built on Mirakl (Empik, Decathlon, Leroy Merlin, Super-Pharm), variants are linked by a shared parent identifier, and the parent itself cannot go into the offer file; Leroy Merlin allows at most 50 variants in a group (source: help.lengow.com).
Integrators and PIMs have their own models, which must accommodate all of this. ChannelEngine works on three levels, grandparent, parent and child, where “every child has its own price, stock, Merchant product number, and GTIN”, and parents must either exist in the product file or be generated automatically (source: support.channelengine.com). Tradebyte separates PRODUCT from ARTICLE and product attributes (P_TAGS) from variant attributes (A_TAGS), and describes the variant axes in A_VARIANTDATA; channel categories are imported separately for each channel (source: tradebyte.io). Akeneo has a product model and variant products with at most two levels of variation, and every attribute can be “scopable” (a different value per channel) and “localizable” (a different value per language); a channel is an export filter with its own completeness measure (source: api.akeneo.com). Polish integrators lean towards simplicity. Apilo assumes that “each physical product should correspond to one stock item”, linked by SKU or EAN (source: apilo.com), Base.com maps inventory parameters to platform parameters with “copy from inventory”, “set value” and “insert from field” rules, created separately for each inventory (source: base.com), and Sellasist keeps Allegro parameters separately for products and variants and links shop categories to platform categories (source: sellasist.pl).
Then there is the identifier layer. Under the GS1 standard, every combination of style, colour and size is a separate product with its own GTIN, and a change of more than 20% in any dimension or in gross weight requires a new number (source: GS1 GTIN Management Standard). If your shop holds one EAN for all sizes, no integrator will fix it: ChannelEngine warns that with one GTIN across several sizes “most marketplaces either reject creating multiple listings or list only one of the products”.
The conclusion concerns your system design more than any single tool. Your data source must express the deepest hierarchy that the most demanding channel requires (usually Zalando or Amazon), while flat channels (Allegro, Kaufland) receive a flattened view. The reverse route, building the hierarchy only in the integrator, means parents are generated automatically and you lose control over which title and which photo the channel shows as the main one.
| System | Variant levels | Sellable identifier | Channel data | Source |
|---|---|---|---|---|
| Allegro | multi-variant offer, no parent | EAN attaches the offer to the product card (productisation) | parameters required per category | apilo.com |
| Amazon | parent and child | child ASIN, GTIN | title and description often from the parent | ChannelEngine, Amazon |
| Zalando | model, configuration (colour), article (size) | EAN on the article | attributes per product type, size charts | partner.zalando.com |
| Mirakl (Empik, Decathlon, Leroy Merlin) | parent links variants, parent kept out of the offer file | offer SKU and product EAN | shared product, offer per channel | developer.mirakl.com, Lengow |
| ChannelEngine | grandparent, parent, child | GTIN and SKU on every child | content mappings per channel, overrides take precedence | support.channelengine.com |
| Tradebyte TB.One | PRODUCT and ARTICLE, axes in A_VARIANTDATA | EAN on ARTICLE | P_TAGS and A_TAGS, channel categories from CSV | tradebyte.io |
| Akeneo PIM | product model, up to 2 levels of variation | product identifier | scopable and localizable attributes, completeness per channel | api.akeneo.com |
| Apilo | one stock item per physical product | SKU or EAN | category and parameter mapping per platform | apilo.com |
| Base.com | product with variants in the inventory | SKU, EAN | parameter mapping rules, set per inventory | base.com |
| Sellasist | product and variants | SKU, EAN | Allegro parameters for product and variant, category linking | sellasist.pl |
Documentation as of September 2026. Integrator data models change, so check the vendor’s current documentation before implementation.
When variants differ in a dimension that drives the purchase, such as the size of a fitted sheet or the capacity of a storage box, consider listing them as separate offers. Each variant then needs its own EAN. Shoppers see the size they are looking for in the title and the photo straight away, without clicking through a selector.
A separate offer also gets its own title with the dimension in it. The platform’s search and Google can match that title to a specific query, such as “fitted sheet 160×200”. In ad campaigns you promote each offer on its own, with its own keyword and bid, and you see at once which size sells.
There is a cost. Reviews and sales history are split across several offers. Where a platform groups variants on one product page anyway, as Amazon and Zalando do, follow its model. We decide channel by channel, based on how shoppers search for the product.
A Salsify study of 2712 shoppers in the United States, Canada and the United Kingdom (October 2025) shows the scale of the problem: 45% of respondents returned a purchase because of “incorrect or misleading information”, and 45% of Gen Z shoppers abandoned a purchase when “product details do not match across sites”. 54% check a product in two or three sources, and 22% already use AI tools for product research (source: Salsify, Consumer Research 2026). There is no comparable study for Poland, but the mechanism is the same: the buyer compares your product page on Allegro with the one in your own shop and on Amazon, and every discrepancy costs trust. Consistent data across channels has stopped being a matter of looks and has become a precondition for conversion.
The cost of inconsistent product data (share of shoppers)
| % | |
|---|---|
| returned a purchase because of wrong or misleading information | 45% |
| Gen Z: abandoned a purchase when details differed between sites | 45% |
| check a product in 2 to 3 sources | 54% |
| use AI tools for product research | 22% |
Salsify, Consumer Research 2026: 2712 shoppers from the USA, Canada and the UK, October 2025.
Before you choose a tool, write down your answers to five questions. They define the architecture, and the tool simply follows from it:
If the answers point to one content source, one transaction source and one channel layer, you have an architecture that one person can maintain. If they point to three product databases, no tool will replace the decision about which of them you switch off.
Not with a few hundred products without variants and two channels. The shop can be the content source, with the integrator adding the channel layer. A PIM starts to pay off when the catalogue has variants on several levels, several languages and more than one person working on content.
It can, and for many trading companies it is a good decision. The condition: the integrator becomes the only place where content is edited, and the shop and marketplaces only receive data. Problems start when someone edits a description directly in the shop or in the Allegro seller panel.
From the GS1 number range assigned to your company, with a separate number for every combination of size and colour. Codes bought outside GS1, or one code for many sizes, get offers rejected on most platforms.
Keep a superset of attributes in your source in one standard, and leave the mapping to each platform’s fields to the integrator. A new channel then needs only a new mapping.
On a new market, never machine-translate your product pages. Buyers everywhere expect a precise, correctly written description in their own language, and some information, such as warnings and safety data, must be there for compliance reasons too. This works both ways: when a Polish brand enters DACH, CEE or Benelux, and when a foreign brand launches in Poland. Local content, written or checked by a native speaker, builds brand credibility and gives you a real edge over competitors who cut corners.
We create and optimise product pages for specific platforms and markets: titles and bullet points, galleries and infographics, a complete set of attributes and proper localisation for every market you sell in, whether DACH, CEE or Benelux. Content that ranks, sells and cuts returns at the same time. Want your product pages to drive sales? Get in touch.
Read more on each platform’s requirements in our article on product data standards, and on how many systems you really need in the guide PIM, ERP, WMS. Before you commit, run the numbers in our marketplace ROI calculator.
Borys Terlecki – marketplace sales and implementations at Commercraft. He previously worked on the operator side of marketplace platforms (Mirakl, Munich) and today onboards brands on marketplaces in Poland and the DACH region and runs their accounts.
We will help you put this knowledge into practice, from integration to campaigns.
+48 797 810 997
×
