Продуктовий контент на маркетплейсах: заголовки, описи, фото та rich content, які дійсно збільшують продажі.
Автор: Borys Terlecki · продажі та впровадження на маркетплейсах у Commercraft · оновлено: жовтень 2026
Коротко
Картка товару робить три речі одночасно: просуває пропозицію в пошуку платформи, переконує клієнта й зменшує кількість повернень. Заголовок має 60 символів, а фото продають ще до того, як хтось прочитає опис.
Продуктові дані потребують системного рішення: окреме джерело для транзакцій (ERP), окреме для контенту (PIM або магазин) і канальний шар в інтеграторі, бо кожна платформа по-своєму визначає варіант, категорію та ідентифікатор.
За даними дослідження Salsify 2026, 45% покупців повернули покупку через помилкову інформацію, а 45% представників покоління Z відмовилися від покупки, коли дані різнилися на різних сайтах. Узгодженість даних між каналами є умовою конверсії.
На маркетплейсі клієнт не торкнеться товару, не роздивиться його на світлі й не запитає продавця за прилавком. Усе, що він знає, походить із картки товару. Тому добрий продуктовий контент працює як найдешевший і найефективніший продавець, якого Ви маєте, і його не варто сприймати як прикрасу. Покажемо, з чого складається картка, яка продає, і як її побудувати.
Добра картка водночас просуває товар у пошуку платформи, переконує клієнта купити й зменшує кількість повернень, бо точно описує, що покупець отримає. Ці три функції, тобто видимість, конверсію та відповідність очікуванням, варто тримати в голові під час роботи над кожним елементом.
Заголовок алгоритм читає найуважніше, а клієнт бачить першим. Добрий заголовок містить бренд, тип товару й найважливіші характеристики (модель, розмір, колір, призначення) у природному, зрозумілому порядку. Не напихайте в нього ключові слова силоміць: платформи дедалі краще це розпізнають, а клієнт і так оминає «спамні» заголовки.
Більшість рішень про покупку починається з фото. Варто подбати про:
Кожна платформа має власні технічні вимоги. Їх виконання впливає не лише на естетику: часто від нього залежить, чи пропозицію взагалі допустять до продажу.
Погляд клієнта, який швидко переглядає сторінку, спершу вихоплює марковані характеристики, тож саме в них мають бути найважливіші переваги й параметри. Довший опис розгортає тему: сфери застосування, чим товар відрізняється від конкурентів, що входить у комплект. Пишіть мовою клієнта, без внутрішнього жаргону, і відповідайте на запитання ще до того, як їх поставлять, бо кожне запитання без відповіді означає покинутий кошик або повернення.
Параметри легко вважати бюрократією, проте саме за ними клієнт фільтрує результати. Що повніше й точніше Ви заповните атрибути (розмір, матеріал, колір, сумісність), то частіше товар з’являтиметься у правильних фільтрах і результатах. Неповні дані означають просто менше показів.
Заголовок, опис, атрибути й фото можна зберігати в трьох місцях: у магазині (польські платформи Shoper та IdoSell, а також PrestaShop, Magento), в окремій PIM-системі (Akeneo, Pimcore, Plytix) або на платформі інтегратора (Base.com, Apilo, Sellasist, ChannelEngine, Tradebyte, Mirakl Connect). Base.com, Apilo і Sellasist є поширеними в Польщі системами, які з’єднують магазин із маркетплейсами й керують залишками та замовленнями. Кожен із цих інструментів охоче стане «базою товарів», а помилка полягає в тому, що в багатьох компаніях нею стають усі три одночасно. Тоді той самий товар має три заголовки, два набори атрибутів, і ніхто не знає, яка версія правильна.
Замість питання «яку систему обрати» поставте питання з управління даними: яка система є системою-джерелом (system of record) для кожного типу даних. На практиці запис товару має три шари з різними власниками та різним темпом змін. Транзакційні дані (ціна, залишок, собівартість) змінюються щогодини й належать ERP або WMS. Описові дані (назва, опис, атрибути, медіа, переклади) змінюються рідко, потребують редакторської роботи й належать PIM або, якщо каталог невеликий, магазину. Канальні дані (категорія на Allegro, найбільшому маркетплейсі Польщі, скорочений заголовок для Amazon, набір атрибутів для Kaufland, перевизначення) живуть в інтеграторі, бо лише він знає вимоги кожного каналу. Документація ChannelEngine описує це прямо: дані зіставляють окремо для кожного каналу в так званих content mappings, а вручну перевизначене значення «має пріоритет над зіставленням» (джерело: support.channelengine.com). Mirakl Connect, своєю чергою, відокремлює товар (таксономія, спільна для всіх) від пропозиції (ціна, залишок, канальні атрибути) і радить декларувати «лише ті атрибути, які канал справді використовує» (джерело: developer.mirakl.com).
Лише коли шари так розписано, вибір інструмента стає простим. Матриця нижче впорядковує типові конфігурації за двома осями: кількістю каналів і ринків та складністю каталогу (варіанти, кількість атрибутів, мови).
ERP / WMS
ціна, залишок, собівартість: транзакційне джерело
PIM або магазин
назва, опис, атрибути, медіа: джерело контенту
Інтегратор
зіставлення категорій і атрибутів, перевизначення для кожного каналу
Маркетплейс
картка товару й пропозиція у форматі платформи
Три шари запису товару та їхні системи-джерела. Опрацювання Commercraft на основі документації ChannelEngine, Mirakl Connect і Akeneo.
Схема показує напрям потоку, кількість інструментів тут може бути різною: у малій компанії перші два шари може обслуговувати один магазин, у великій кожен із них є окремою системою з власним власником.
Матриця рішень: де зберігати продуктовий контент
Складний каталог, мало каналів
Мода, взуття, меблі з конфігураціями: варіанти на двох рівнях, кілька мов. Легка PIM-система (Akeneo Community, Plytix) або інтегратор з ієрархією (Tradebyte, ChannelEngine) як джерело контенту. Магазин лише отримує дані.
Складний каталог, багато каналів і ринків
Бренд із тисячами SKU на 5 і більше платформах у кількох країнах. Повноцінна PIM як джерело контенту, ERP як джерело транзакцій, інтегратор корпоративного класу як канальний шар. Окремий власник даних.
Простий каталог, мало каналів
Кілька сотень товарів без варіантів, магазин плюс один чи два маркетплейси. Магазин є джерелом контенту, інтегратор (Base.com, Apilo, Sellasist) зіставляє категорії та параметри. Без PIM.
Простий каталог, багато каналів
Гуртівня або дистриб’ютор із широким пласким асортиментом на багатьох платформах. Інтегратор із власною базою товарів як єдине місце редагування контенту. Магазин і ERP постачають лише ціни й залишки.
Спрощена портфельна модель (як матриця BCG): дві осі, чотири типові конфігурації. Межі між квадрантами умовні й спираються на практику впроваджень Commercraft, жорстких порогів тут немає.
Найчастіше дані «не проходять» між системами через різне визначення товару, відсутнє поле трапляється рідше. Кожна платформа по-своєму розуміє, що таке варіант, до чого прив’язує ціну й на якому рівні присвоює ідентифікатор. Zalando веде артикул на трьох рівнях: модель (назва, бренд, силует), конфігурація (колір) і окремий артикул із розміром, EAN і ціною (джерело: partner.zalando.com). Amazon об’єднує варіанти в parent і child, причому батьківський товар не продається, а заголовок і опис на сторінці часто беруться саме з нього. Allegro працює навпаки: батьківського товару немає, пропозицію прив’язують до картки товару в каталозі Allegro за кодом EAN (так звана продуктизація), а параметри обов’язкові залежно від категорії. Пропозиції без повного набору параметрів втрачають видимість у фільтрах (джерело: apilo.com). На маркетплейсах, побудованих на Mirakl (Empik, Decathlon, Leroy Merlin, Super-Pharm), варіанти об’єднує спільний ідентифікатор батьківського товару, а сам батьківський товар не може потрапити у файл пропозицій. Leroy Merlin допускає щонайбільше 50 варіантів у групі (джерело: help.lengow.com).
Інтегратори й PIM мають власні моделі, які мусять усе це вмістити. ChannelEngine працює на трьох рівнях: grandparent, parent і child, причому «кожен дочірній товар має власну ціну, залишок, SKU і GTIN», а батьківські товари мають бути у файлі товарів або генеруються автоматично (джерело: support.channelengine.com). Tradebyte розділяє PRODUCT і ARTICLE, атрибути товару (P_TAGS) і атрибути варіанта (A_TAGS), а осі варіантів описує в A_VARIANTDATA. Канальні категорії імпортують окремо для кожного каналу (джерело: tradebyte.io). Akeneo має модель товару й товари-варіанти щонайбільше з двома рівнями варіативності, а кожен атрибут може бути «scopable» (інше значення для кожного каналу) і «localizable» (інше для кожної мови). Канал там є фільтром експорту з власною мірою повноти (джерело: api.akeneo.com). Польські інтегратори йдуть шляхом простоти: Apilo виходить з того, що «кожен фізичний товар має відповідати одній складській позиції», пов’язаній через SKU або EAN (джерело: apilo.com), Base.com зіставляє параметри складу з параметрами платформи за правилами «скопіювати зі складу», «встановити значення» і «вставити з поля», які створюють окремо для кожного складу (джерело: base.com), а Sellasist веде параметри Allegro окремо для товарів і варіантів та пов’язує категорії магазину з категоріями платформ (джерело: sellasist.pl).
До цього додається шар ідентифікаторів. Згідно зі стандартом GS1, кожна комбінація фасону, кольору й розміру є окремим товаром із власним GTIN, а зміна розміру або ваги брутто більш ніж на 20% потребує нового номера (джерело: GS1 GTIN Management Standard). Якщо Ваш магазин тримає один EAN для всіх розмірів, жоден інтегратор цього не виправить: ChannelEngine попереджає, що за одного GTIN на кілька розмірів «більшість маркетплейсів відмовляє у створенні кількох пропозицій або публікує лише одну».
Цей висновок стосується архітектури системи загалом. Джерело даних має відображати найглибшу ієрархію, якої вимагає найвибагливіший канал (зазвичай Zalando або Amazon), а пласкі канали (Allegro, Kaufland) отримують сплощене подання. Зворотний шлях, тобто побудова ієрархії лише в інтеграторі, означає, що батьківські товари генеруються автоматично, а Ви втрачаєте контроль над тим, який заголовок і яке фото канал покаже як головні.
| Система | Рівні варіантів | Ідентифікатор для продажу | Канальні дані | Джерело |
|---|---|---|---|---|
| Allegro | мультиваріантна пропозиція, без батьківського товару | EAN прив’язує пропозицію до картки (продуктизація) | параметри обов’язкові залежно від категорії | apilo.com |
| Amazon | parent i child | ASIN дочірнього товару, GTIN | заголовок і опис часто з батьківського товару | ChannelEngine, Amazon |
| Zalando | модель, конфігурація (колір), артикул (розмір) | EAN на артикулі | атрибути для кожного типу товару, таблиці розмірів | partner.zalando.com |
| Mirakl (Empik, Decathlon, Leroy Merlin) | батьківський товар об’єднує варіанти, у файл пропозицій не входить | SKU пропозиції та EAN товару | товар спільний, пропозиція для кожного каналу | developer.mirakl.com, Lengow |
| ChannelEngine | grandparent, parent, child | GTIN і SKU на кожному дочірньому товарі | content mappings для кожного каналу, перевизначення мають пріоритет | support.channelengine.com |
| Tradebyte TB.One | PRODUCT і ARTICLE, осі в A_VARIANTDATA | EAN на ARTICLE | P_TAGS і A_TAGS, канальні категорії з CSV | tradebyte.io |
| Akeneo PIM | модель товару, до 2 рівнів варіативності | ідентифікатор товару | атрибути scopable і localizable, повнота для кожного каналу | api.akeneo.com |
| Apilo | одна складська позиція на фізичний товар | SKU або EAN | зіставлення категорій і параметрів для кожної платформи | apilo.com |
| Base.com | товар із варіантами на складі | SKU, EAN | правила зіставлення параметрів, окремо для кожного складу | base.com |
| Sellasist | товар і варіанти | SKU, EAN | параметри Allegro для товару й варіанта, зв’язування категорій | sellasist.pl |
Стан документації: вересень 2026. Моделі даних інтеграторів змінюються, тож перед впровадженням перевірте актуальну документацію постачальника.
Коли варіанти відрізняються параметром, який вирішує покупку, наприклад розміром простирадла чи об’ємом контейнера для зберігання, варто розглянути виставлення їх як окремих пропозицій. Кожен варіант тоді потребує власного EAN. Покупець одразу бачить потрібний розмір у назві й на фото і не мусить перебирати список варіантів.
Окрема пропозиція має й власну назву з розміром, яку пошук платформи та Google можуть зіставити з конкретним запитом, наприклад «простирадло 160×200». У рекламних кампаніях Ви просуваєте кожну таку пропозицію окремо, з власною фразою і ставкою, і одразу бачите, який розмір продається.
Це має свою ціну. Відгуки й історія продажів розподіляються між кількома пропозиціями. Там, де платформа й так об’єднує варіанти в одній картці, як Amazon чи Zalando, ми дотримуємося її моделі. Рішення ухвалюємо окремо для кожного каналу, дивлячись на те, як покупці шукають цей товар.
Масштаб проблеми показує дослідження Salsify за жовтень 2025 року на вибірці з 2712 покупців у США, Канаді та Великій Британії: 45% респондентів повернули покупку через «неправильну або оманливу інформацію», а 45% покупців із покоління Z відмовилися від покупки, коли «деталі товару не збігалися на різних сайтах». 54% перевіряють товар у двох чи трьох джерелах, а 22% уже використовують інструменти ШІ для пошуку інформації про товари (джерело: Salsify, Consumer Research 2026). Порівнянного дослідження для Польщі немає, але механізм той самий: клієнт порівнює Вашу картку на Allegro з карткою у Вашому магазині та на Amazon, і кожна розбіжність коштує довіри. Узгодженість даних між каналами перестала бути питанням естетики й стала умовою конверсії.
Скільки коштують неузгоджені продуктові дані (частка покупців)
| % | |
|---|---|
| повернули покупку через помилкову або оманливу інформацію | 45% |
| покоління Z: відмовилися від покупки, коли дані різнилися на різних сайтах | 45% |
| перевіряють товар у 2 або 3 джерелах | 54% |
| використовують інструменти ШІ для пошуку інформації про товар | 22% |
Salsify, Consumer Research 2026: 2712 покупців із США, Канади та Великої Британії, жовтень 2025.
Перш ніж обирати інструмент, запишіть відповіді на п’ять запитань. Саме вони визначають архітектуру, а інструмент лише випливає з неї:
Якщо відповіді вказують на одне джерело контенту, одне джерело транзакцій і один канальний шар, Ви маєте архітектуру, яку підтримуватиме одна людина. Якщо вони вказують на три бази товарів, жоден інструмент не замінить рішення, яку з них Ви вимикаєте.
Якщо у Вас кілька сотень товарів без варіантів і два канали, то ні. Джерелом контенту може бути магазин, а інтегратор додає канальний шар. PIM починає окуповуватися, коли каталог має варіанти на кількох рівнях, кілька мов і над контентом працює більше ніж одна людина.
Може, і для багатьох торговельних компаній це добре рішення. Умова: інтегратор тоді є єдиним місцем редагування контенту, а магазин і маркетплейси лише отримують дані. Проблеми починаються, коли хтось виправляє опис безпосередньо в магазині або в панелі Allegro.
З пулу GS1, закріпленого за Вашою компанією, окремий номер для кожної комбінації розміру й кольору. Коди, куплені поза GS1, або один код на кілька розмірів закінчуються відхиленням пропозицій на більшості платформ.
Зберігайте в джерелі надмножину атрибутів в одному стандарті, а зіставлення з полями кожної платформи залиште інтегратору. Тоді новий канал означає лише нове зіставлення, а каталог залишається тим самим.
Виходячи на новий ринок, не перекладайте картку машинним перекладом. Покупець усюди очікує точного, грамотного опису своєю мовою, а частина інформації, наприклад попередження й дані з безпеки, має бути там також з міркувань відповідності вимогам. Це працює в обидва боки: і коли польський бренд виходить у DACH, CEE чи Бенілюкс, і коли іноземний бренд виходить на ринок Польщі. Локальний контент, написаний або перевірений носієм мови, зміцнює довіру до бренду й дає реальну перевагу над конкурентами, які пішли коротшим шляхом.
Ми створюємо й оптимізуємо картки товарів під конкретні платформи та ринки: від заголовків і bullet points, через галереї та інфографіку, до повного набору атрибутів і правильної локалізації для кожного ринку, де Ви продаєте (DACH, CEE, Бенілюкс). Контент, який водночас просуває, продає й зменшує кількість повернень. Хочете, щоб Ваші картки працювали на результат? Напишіть нам.
Більше про вимоги окремих платформ Ви знайдете в тексті про стандарти продуктових даних, а про те, скільки систем Вам справді потрібно, у посібнику PIM, ERP, WMS.
Borys Terlecki – продажі та впровадження на маркетплейсах у Commercraft. Раніше працював на боці оператора маркетплейс-платформ (Mirakl, Мюнхен), сьогодні виводить бренди на маркетплейси Польщі та регіону DACH і веде їхні облікові записи.
Допоможемо застосувати ці знання на практиці – від інтеграції до кампаній.
+48 797 810 997
×
