Content produktowy na marketplace’ach: tytuły, opisy, zdjęcia i rich content, które realnie zwiększają sprzedaż.
Autor: Borys Terlecki · Global Business Development, Marketing w Commercraft · aktualizacja: 06.11.2026
W skrócie
Karta produktu robi trzy rzeczy naraz: pozycjonuje ofertę w wyszukiwarce platformy, przekonuje kupującego i ogranicza zwroty. Najwięcej uwagi wymagają tytuł i zdjęcia, bo to je kupujący widzi, zanim przeczyta opis.
Dane produktowe wymagają decyzji systemowej: osobne źródło dla transakcji (ERP), osobne dla treści (PIM lub sklep) i warstwa kanałowa w integratorze, bo każda platforma inaczej definiuje wariant, kategorię i identyfikator.
W badaniu Salsify opublikowanym w 2026 roku 45% kupujących w USA, Kanadzie i Wielkiej Brytanii zwróciło zakup przez błędne lub mylące informacje, a do 45% kupujących z pokolenia Z porzuca zakup, gdy dane produktu różnią się między stronami [1]. Spójność danych między kanałami jest więc warunkiem konwersji.
Zastrzeżenia prawne
Stan dokumentacji platform i narzędzi: 06.11.2026. Ten tekst to informacja, nie porada prawna ani podatkowa; Commercraft nie jest kancelarią ani biurem doradztwa podatkowego. Przed decyzją sprawdź źródła wymienione na końcu albo zapytaj swojego doradcy.
Na marketplace klient nie dotknie produktu, nie obejrzy go pod światło i nie zapyta sprzedawcy zza lady. Wszystko, co wie, pochodzi z karty produktowej. Dlatego dobry content produktowy to nie ozdoba, lecz najtańszy i najskuteczniejszy sprzedawca, jakiego masz. Pokażemy, z czego składa się karta, która sprzedaje – i jak ją zbudować.
Dobra karta jednocześnie pozycjonuje produkt w wyszukiwarce platformy, przekonuje klienta do zakupu i ogranicza zwroty, bo precyzyjnie opisuje, co kupujący dostanie. Te trzy funkcje – widoczność, konwersja i zgodność oczekiwań – warto mieć z tyłu głowy przy każdym elemencie.
Tytuł to pole, które algorytm czyta najuważniej, a klient widzi jako pierwsze. Dobry tytuł zawiera markę, typ produktu i najważniejsze cechy (model, rozmiar, kolor, przeznaczenie) w naturalnej, czytelnej kolejności. Bez upychania słów kluczowych na siłę – platformy coraz lepiej to wychwytują, a klient i tak omija „spamerskie” tytuły.
Większość decyzji zakupowych zaczyna się od zdjęcia. Warto zadbać o:
Każda platforma ma własne wymagania techniczne – ich spełnienie to warunek nie tylko estetyki, ale często samego dopuszczenia oferty.
Skanujący wzrok klienta najpierw łapie punktowane cechy, więc to w nich powinny znaleźć się najważniejsze korzyści i parametry. Dłuższy opis rozwija temat: zastosowania, czym produkt różni się od konkurencji, co jest w zestawie. Pisz językiem klienta, nie wewnętrznym żargonem – i odpowiadaj na pytania, zanim padną, bo każde pytanie bez odpowiedzi to porzucony koszyk lub zwrot.
Parametry to nie biurokracja, lecz to, po czym klient filtruje wyniki. Im pełniej i poprawniej wypełnisz atrybuty (rozmiar, materiał, kolor, kompatybilność), tym częściej produkt pojawia się we właściwych filtrach i wynikach. Niekompletne dane to po prostu mniej wyświetleń.
Tytuł, opis, atrybuty i zdjęcia można utrzymywać w trzech miejscach: w sklepie (Shoper, IdoSell, PrestaShop, Magento), w dedykowanym PIM (Akeneo, Pimcore, Plytix) albo w platformie integratora, takiej jak Base.com (dawniej Baselinker), Apilo, Sellasist, ChannelEngine, Tradebyte czy Mirakl Connect. Każde z tych narzędzi chętnie zostanie „bazą produktów”, a błąd polega na tym, że w wielu firmach zostają nią wszystkie trzy naraz. Wtedy ten sam produkt ma trzy tytuły, dwa zestawy atrybutów i nikt nie wie, która wersja jest prawdziwa.
Zamiast pytać „jaki system wybrać”, zadaj pytanie z zarządzania danymi: który system jest systemem źródłowym (system of record) dla każdego typu danych. W praktyce rekord produktu ma trzy warstwy o różnych właścicielach i różnym tempie zmian. Dane transakcyjne (cena, stan, koszt) zmieniają się co godzinę i należą do ERP lub WMS. Dane opisowe (nazwa, opis, atrybuty, media, tłumaczenia) zmieniają się rzadko, wymagają pracy redakcyjnej i należą do PIM albo, przy małym katalogu, do sklepu. Dane kanałowe (kategoria na Allegro, tytuł skrócony pod Amazon, zestaw atrybutów pod Kaufland, nadpisania) żyją w integratorze, bo tylko on zna wymagania każdego kanału. Dokumentacja ChannelEngine opisuje to wprost: dane mapuje się per kanał w tzw. content mappings, a wartość nadpisana ręcznie „ma pierwszeństwo przed mapowaniem” [2]. Mirakl Connect rozdziela z kolei produkt (taksonomia, wspólna dla wszystkich) od oferty (cena, stan, atrybuty kanałowe) i zaleca deklarować „tylko te atrybuty, których kanał naprawdę używa” [3].
Dopiero z tak rozpisanymi warstwami wybór narzędzia staje się prosty. Poniższa macierz porządkuje typowe konfiguracje według dwóch osi: liczby kanałów i rynków oraz złożoności katalogu (warianty, liczba atrybutów, języki).
ERP / WMS
cena, stan, koszt: źródło transakcyjne
PIM lub sklep
nazwa, opis, atrybuty, media: źródło treści
Integrator
mapowanie kategorii i atrybutów, nadpisania per kanał
Marketplace
karta produktu i oferta w formacie platformy
Trzy warstwy rekordu produktu i ich systemy źródłowe. Opracowanie Commercraft na podstawie dokumentacji ChannelEngine, Mirakl Connect i Akeneo.
Schemat pokazuje kierunek przepływu, nie liczbę narzędzi: w małej firmie dwie pierwsze warstwy może obsłużyć jeden sklep, w dużej każda z nich to osobny system z własnym właścicielem.
Macierz decyzyjna: gdzie utrzymywać treść produktową
Złożony katalog, mało kanałów
Moda, obuwie, meble z konfiguracjami: warianty na dwóch poziomach, kilka języków. Lekki PIM (Akeneo Community, Plytix) albo integrator z hierarchią (Tradebyte, ChannelEngine) jako źródło treści; sklep tylko odbiera.
Złożony katalog, wiele kanałów i rynków
Marka z tysiącami SKU na 5 i więcej platformach w kilku krajach. Pełny PIM jako źródło treści, ERP jako źródło transakcji, integrator klasy enterprise jako warstwa kanałowa. Osobny właściciel danych.
Prosty katalog, mało kanałów
Kilkaset produktów bez wariantów, sklep plus jeden lub dwa marketplace'y. Sklep jest źródłem treści, integrator (Base.com, Apilo, Sellasist) mapuje kategorie i parametry. Bez PIM.
Prosty katalog, wiele kanałów
Hurtownia lub dystrybutor z szerokim, płaskim asortymentem na wielu platformach. Integrator z własną bazą produktów jako jedyne miejsce edycji treści; sklep i ERP dostarczają tylko ceny i stany.
Uproszczony model portfelowy (jak macierz BCG): dwie osie, cztery typowe konfiguracje. Granice między ćwiartkami wyznacza praktyka wdrożeń Commercraft, nie sztywne progi.
Najczęstszy powód, dla którego dane „nie przechodzą” między systemami, to nie brak pola, lecz inna definicja produktu. Każda platforma inaczej rozumie, czym jest wariant, do czego przypina cenę i na jakim poziomie nadaje identyfikator. Zalando grupuje dane artykułu na trzech poziomach: model (nazwa, marka, sylwetka), styl (kolor) i artykuł z rozmiarem, EAN i ceną [4]. Amazon łączy warianty w parent i child. Rodzic nie jest produktem na sprzedaż, a w niektórych kategoriach tytuł i opis na stronie pochodzą właśnie z niego [7]. Allegro działa odwrotnie: nie ma rodzica, a od 1.07.2024 każda oferta musi być połączona z produktem w Katalogu produktów Allegro (tak zwana produktyzacja), przy czym parametry obowiązkowe zależą od kategorii [5]. Na Leroy Merlin, platformie opartej na Miraklu, warianty łączy wspólny identyfikator rodzica, produkty-rodzice nie trafiają do pliku wysyłanego na platformę, a jedna grupa ma najwyżej 50 wariantów [6].
Integratory i PIM mają własne modele, które muszą to wszystko pomieścić. ChannelEngine pracuje na trzech poziomach: grandparent, parent i child, przy czym „każde dziecko ma własną cenę, stan, SKU i GTIN”, a rodzice muszą istnieć w pliku produktowym albo zostać wygenerowani automatycznie [7]. Tradebyte rozdziela PRODUCT od ARTICLE, atrybuty produktu (P_TAGS) od atrybutów wariantu (A_TAGS), a wartości wariantów opisuje w A_VARIANTDATA. Kategorie kanałowe mają w dokumentacji osobną sekcję [8]. Akeneo ma model produktu i produkty-warianty, a każdy atrybut może być „scopable” (inna wartość per kanał) i „localizable” (inna per język); kanał działa jak filtr eksportu z własną miarą kompletności [9]. Polskie integratory idą w stronę prostoty: Apilo zakłada, że „każdy fizyczny produkt powinien odpowiadać jednej pozycji magazynowej”, łączonej po SKU lub EAN [10], Base.com mapuje parametry magazynu na parametry platformy regułami „ustaw wartość”, „skopiuj z parametru z magazynu”, „skopiuj z pola z magazynu” i „wstaw wartość”, tworzonymi osobno dla każdego magazynu [11], a Sellasist pozwala tworzyć parametry Allegro osobno dla produktów i dla wariantów [12].
Do tego dochodzi warstwa identyfikatorów. Według standardu GS1 każda kombinacja fasonu, koloru i rozmiaru to osobny produkt z własnym GTIN, a zmiana wymiaru lub wagi brutto o ponad 20% wymaga nowego numeru [13]. Jeśli Twój sklep trzyma jeden EAN na wszystkie rozmiary, żaden integrator tego nie naprawi: ChannelEngine ostrzega, że przy jednym GTIN na kilka rozmiarów „większość marketplace'ów odrzuca tworzenie wielu ofert albo publikuje tylko jedną” [7].
Wniosek jest systemowy, nie techniczny. Źródło danych musi wyrażać najgłębszą hierarchię, jakiej wymaga najbardziej wymagający kanał (zwykle Zalando lub Amazon), a płaskie kanały (Allegro, Kaufland) dostają spłaszczony widok. Odwrotna droga, czyli budowanie hierarchii dopiero w integratorze, oznacza, że rodzice są generowani automatycznie, a Ty tracisz kontrolę nad tym, który tytuł i które zdjęcie kanał pokaże jako główne.
| System | Poziomy wariantu | Identyfikator na sprzedaż | Dane kanałowe | Źródło |
|---|---|---|---|---|
| Allegro | oferta wielowariantowa, bez rodzica | oferta połączona z produktem w Katalogu produktów (produktyzacja) | parametry obowiązkowe zależne od kategorii | [5] |
| Amazon | parent i child | ASIN dziecka, GTIN | tytuł i opis często z rodzica | [7] |
| Zalando | model, styl (kolor), artykuł (rozmiar) | EAN na artykule | atrybuty per typ produktu, tabele rozmiarów | [4] |
| Mirakl (na przykładzie Leroy Merlin) | rodzic łączy warianty, rodzic poza plikiem ofert | SKU oferty i EAN produktu | produkt wspólny, oferta per kanał | [3], [6] |
| ChannelEngine | grandparent, parent, child | GTIN i SKU na każdym dziecku | content mappings per kanał, nadpisania mają pierwszeństwo | [2], [7] |
| Tradebyte TB.One | PRODUCT i ARTICLE, osie w A_VARIANTDATA | EAN na ARTICLE | P_TAGS i A_TAGS, kategorie kanałowe | [8] |
| Akeneo PIM | model produktu i warianty | identyfikator produktu | atrybuty scopable i localizable, kompletność per kanał | [9] |
| Apilo | jedna pozycja magazynowa na produkt fizyczny | SKU lub EAN | mapowanie kategorii i parametrów per platforma | [10] |
| Base.com | produkt z wariantami w magazynie | SKU, EAN | reguły mapowania parametrów, osobno per magazyn | [11] |
| Sellasist | produkt i warianty | SKU, EAN | parametry Allegro dla produktu i wariantu | [12] |
Stan dokumentacji: 06.11.2026. Modele danych integratorów zmieniają się, przed wdrożeniem sprawdź aktualną dokumentację dostawcy.
Przykład. Producent odzieży ma 50 fasonów koszulek, każdy w 3 kolorach i 5 rozmiarach. Według GS1 każda taka kombinacja dostaje własny GTIN [13], więc katalog potrzebuje 750 numerów (50 × 3 × 5, przeliczenie nasze). Jeśli sklep trzyma jeden EAN na fason w danym kolorze, ma 150 kodów, a 600 wariantów zostaje bez własnego numeru. Na kanale, który wymaga GTIN na każdym wariancie, te 600 rozmiarów może zostać odrzuconych albo pokazanych jako jedna oferta [7].
Gdy warianty różnią się wymiarem, który decyduje o zakupie, na przykład rozmiarem prześcieradła albo pojemnością pojemnika, warto rozważyć wystawienie ich jako osobnych ofert. Każdy wariant musi mieć wtedy własny kod EAN. Kupujący od razu widzi w tytule i na zdjęciu wymiar, którego szuka, i nie musi przeklikiwać listy wyboru.
Osobna oferta ma też własny tytuł z wymiarem. Wyszukiwarka platformy i Google mogą go dopasować do konkretnego zapytania, na przykład „prześcieradło 160×200”. W kampaniach reklamowych każdą taką ofertę promujesz osobno, z własną frazą i stawką, i od razu widzisz, który rozmiar się sprzedaje.
Ma to swoją cenę. Opinie i historia sprzedaży rozkładają się na kilka ofert. Tam, gdzie platforma i tak łączy warianty w jednej karcie, jak Amazon albo Zalando, trzymamy się jej modelu. Decyzję podejmujemy osobno dla każdego kanału, patrząc na to, jak kupujący szukają danego produktu.
Skalę problemu pokazuje badanie Salsify z października 2025 roku na próbie 2712 kupujących w Stanach Zjednoczonych, Kanadzie i Wielkiej Brytanii: 45% respondentów zwróciło zakup z powodu „nieprawidłowych lub wprowadzających w błąd informacji”, a nawet 45% kupujących z pokolenia Z porzuca zakup, gdy „szczegóły produktu nie zgadzały się między stronami”. 54% sprawdza produkt w dwóch lub trzech źródłach, a 22% używa już narzędzi AI do researchu produktowego [1]. Porównywalnego badania dla Polski nie ma, ale mechanizm jest ten sam: kupujący porównuje Twoją kartę na Allegro z kartą w Twoim sklepie i na Amazonie, a każda rozbieżność kosztuje zaufanie. Spójność danych między kanałami przestała być kwestią estetyki, stała się warunkiem konwersji.
Ile kosztują niespójne dane produktowe (odsetek kupujących)
| % | |
|---|---|
| zwrócili zakup przez błędne lub mylące informacje | 45% |
| pokolenie Z: porzucili zakup, gdy dane różniły się między stronami | 45% |
| sprawdzają produkt w 2 do 3 źródłach | 54% |
| używają narzędzi AI do researchu produktu | 22% |
Salsify, Consumer Research 2026: 2712 kupujących z USA, Kanady i Wielkiej Brytanii, październik 2025.
Zanim wybierzesz narzędzie, spisz odpowiedzi na pięć pytań. To one wyznaczają architekturę, a narzędzie jest tylko jej konsekwencją:
Jeśli odpowiedzi wskazują na jedno źródło treści, jedno źródło transakcji i jedną warstwę kanałową, masz architekturę, którą utrzyma jedna osoba. Jeśli wskazują na trzy bazy produktów, żadne narzędzie nie zastąpi decyzji, którą z nich wygaszasz.
Wchodząc na nowy rynek, nie tłumacz karty automatem. Kupujący wszędzie oczekuje precyzyjnego, poprawnego językowo opisu we własnym języku, a część informacji, na przykład ostrzeżenia i dane bezpieczeństwa, musi tam być również z powodów zgodności. Działa to w obie strony, zarówno przy wejściu polskiej marki do DACH, CEE czy Beneluksu, jak i przy wprowadzaniu marki zagranicznej do Polski. Lokalny content, napisany albo sprawdzony przez native speakera, buduje wiarygodność marki i daje realną przewagę nad konkurencją, która poszła na skróty.
Przygotowujemy treści i karty produktów pod wymagania każdej platformy, na której sprzedajesz: tytuły, opisy, galerie zdjęć i komplet atrybutów. Przy wejściu na nowe rynki dochodzą tłumaczenia, które sprawdza osoba znająca język rynku.
Zaczynamy od danych. Ustalamy, który system jest źródłem treści, a potem przy integracji mapujemy kategorie i parametry na każdy kanał. Poprawka zrobiona raz w źródle trafia wtedy do wszystkich ofert, więc możemy wystawiać nowe produkty bez ręcznego poprawiania w każdym panelu.
W raportach pokazujemy, które oferty mają niekompletne dane albo słabo się sprzedają, żeby wiedzieć, od których kart zacząć poprawki. Więcej o wymaganiach platform znajdziesz w tekście o standardach danych produktowych, a o tym, ile systemów naprawdę potrzebujesz, w przewodniku PIM, ERP, WMS.
Przy kilkuset produktach bez wariantów i dwóch kanałach zwykle nie. Źródłem treści może być sklep, a integrator dokłada warstwę kanałową. PIM zaczyna się opłacać, gdy katalog ma warianty na kilku poziomach, kilka języków i więcej niż jedną osobę pracującą nad treścią.
Może, i dla wielu firm handlowych to dobra decyzja. Warunek: integrator jest wtedy jedynym miejscem edycji treści, a sklep i marketplace’y tylko odbierają dane. Problem zaczyna się, gdy ktoś poprawia opis bezpośrednio w sklepie albo w panelu Allegro.
Utrzymuj w źródle nadzbiór atrybutów w jednym standardzie, a mapowanie na pola każdej platformy zostaw integratorowi. Nowy kanał oznacza wtedy nowe mapowanie zamiast nowego katalogu.
Borys Terlecki, Global Business Development, Marketing w Commercraft. Odpowiada za rozwój biznesu i marketing, w tym za współpracę z operatorami marketplace’ów. Wcześniej pracował w Mirakl w Monachium, po stronie operatorów.
Pomożemy wdrożyć tę wiedzę operacyjnie, od integracji po kampanie.
+48 797 810 997
×
