Реклама меблевого магазину: каталог, варіанти й доставка

У меблевій рекламі один із практичних ризиків виникає, коли фід описує не той стан товару, який людина може придбати на сайті. Матеріал, оздоблення, розмір, модульність і доставка мають бути узгоджені між каталогом, Merchant Center, посадковою сторінкою та оформленням замовлення. Тому роботу варто починати з моделі асортименту, а вже потім переходити до креативів і кампаній.

Практичний порядок такий: визначити, що є моделлю, варіантом, модулем і комплектом; описати кожний доступний до покупки SKU; розвести габарити виробу та пакування; перевірити ціну, наявність і доставку на посадковій; налаштувати вимірювання покупки. Цей playbook допомагає провести таку перевірку без припущень про майбутні результати.

Модель каталогу: що саме продається

Перш ніж мапити поля фіда, розкладіть асортимент за операційними сутностями:

• Родина продуктів. Спільна лінійка з єдиною назвою або дизайном. Вона може бути навігаційною сторінкою, але не обов’язково окремим товаром.
• Модель. Конкретний виріб із визначеною конструкцією, наприклад диван певної форми або шафа певної ширини.
• Варіант. Та сама модель в іншому матеріалі, кольорі, оздобленні чи стабільному розмірі, який можна придбати окремо.
• Модуль. Самостійно продавана секція системи: кутовий елемент, полиця, тумба або оттоманка.
• Комплект. Набір, що продається як одна одиниця, має визначений склад, ціну й артикул.
• Конфігурація під замовлення. Виріб, параметри якого покупець обирає у конфігураторі.

Для кожного типу запишіть правило: чи потрапляє він у фід, чи має власний SKU та URL, де зберігаються ціна й наявність, які дані є джерелом істини. Конфігурований виріб не стає набором варіантів автоматично. У фід варто виводити лише стабільні конфігурації, які справді можна придбати за переданою ціною та відкрити у відповідному стані сторінки.

Специфікація даних Merchant Center включає базові поля id, title, description, link, image_link, price та availability. Вимоги до інших атрибутів залежать від товару, країни й формату показу. Не переносіть правило для однієї категорії або ринку на весь каталог без перевірки документації.

Варіанти та item_group_id

Довідка про item_group_id описує справжні варіанти як окремі товари з унікальними id і спільним ідентифікатором групи. Групування має відповідати вибору на посадковій сторінці. Кожний варіант потребує власної URL-адреси або стану з попередньо вибраними характеристиками.

Об’єднуйте варіанти, коли виконуються всі умови:

• покупець може придбати кожний варіант окремо;
• у нього є власна ціна й наявність;
• посилання відкриває потрібний матеріал, колір, оздоблення або розмір без додаткового вибору;
• зображення та атрибути у фіді відповідають відкритому стану;
• ідентифікатор групи не використовується для іншої моделі.

Не об’єднуйте диван і комплект «диван + пуф», різні модулі системи або стару й нову конструкції лише через спільну назву колекції. Модуль є окремим товаром, якщо його можна купити самостійно. Його кольорові виконання можуть бути варіантами, але сусідня секція виконує іншу функцію й потребує власної групи.

Після зміни ERP або генератора фіда перевірте стабільність id та item_group_id. Їхнє випадкове перестворення ускладнює діагностику й може розірвати правильне групування.

Дані товару: що передавати

Назва. Використовуйте послідовний шаблон: тип виробу, модель або серія, характеристика варіанта, розмір чи кількість місць, якщо це справді розрізняє SKU. Не додавайте складські коди й оцінні вставки на кшталт «хіт» або «найкращий».

Опис. Дайте факти, потрібні для вибору: конструкцію, матеріал каркаса, оздоблення, механізм, наповнення, догляд і комплектацію. Якщо характеристика залежить від конфігурації, так і напишіть. Не приписуйте всій серії властивість, підтверджену лише для одного варіанта.

Ідентифікатори. Передавайте бренд, GTIN і MPN там, де вони застосовні й надані виробником. Не генеруйте GTIN самостійно. Для власного виробництва використовуйте реальні дані бренду й артикул виробника відповідно до чинної специфікації.

Матеріал, колір, оздоблення. Розділяйте технічну назву тканини й зрозумілий покупцеві колір. Значення у фіді, назві варіанта, фотографії та конфігураторі мають описувати один стан товару.

Зображення. Головний кадр показує конкретний варіант. Не використовуйте фотографію одного кольору для всіх SKU, якщо оголошення називає інший. Додаткові кадри можна розподілити за ролями: загальний вигляд, деталь матеріалу, виріб у кімнаті, схема з розмірами, модульна композиція.

Ціна й наявність. Значення у фіді повинно збігатися з відкритим варіантом і шляхом покупки. Формулювання «від» не замінює ціну конкретної конфігурації. Для товарів під замовлення передавайте статус, який відповідає фактичній можливості оформити цей товар.

Доставка: виріб і пакування мають різні габарити

Атрибути shipping_length, shipping_width і shipping_height описують габарити пакування, а не розмір зібраного виробу. Для меблів ця різниця принципова: шафа може мати одні розміри в кімнаті й їхати в кількох пласких упаковках.

Операційний чекліст:

• беріть вагу й габарити з пакувальної специфікації, а не з маркетингової картки;
• використовуйте узгоджені підтримувані одиниці;
• не підставляйте приблизні виміри для товару, який ще не пакували;
• окремо документуйте вироби з кількома вантажними місцями;
• після зміни упаковки оновлюйте дані в джерелі, з якого формується фід;
• не плутайте розміри для підбору меблів із розмірами для розрахунку доставки.

Налаштування доставки Merchant Center мають бути якомога ближчими до умов на сайті. shipping_label дає змогу прив’язувати політики до груп товарів, а вага й розміри пакування підтримують розрахунки, що залежать від цих параметрів. На рівні операційних груп можна відокремити негабаритні, крихкі, компактні та замовні позиції, якщо для них справді діють різні правила.

Пам’ятайте про пріоритет налаштувань: дані доставки на рівні товару можуть перевизначати правила акаунта. Інтеграція або API також може перезаписати ручну зміну. Після релізу чи синхронізації звіряйте не лише фід, а й фактичні політики в Merchant Center.

Не обіцяйте в креативі вартість або швидкість доставки, якщо вони залежать від міста, поверху, заносу, складання чи конфігурації й не підтверджені для всього цільового асортименту.

Перевірка посадкової сторінки

Вимоги Merchant Center передбачають, що link веде на сторінку конкретного товару, а назва, опис, зображення, ціна, валюта й наявність узгоджені з фідом. Суттєвий досвід не повинен відрізнятися залежно від пристрою, браузера, розташування, cookies або user agent.

Перевірте вибірку з кожного типу товару:

• URL відкриває потрібну модель, а не сторінку колекції чи пошук;
• матеріал, колір, оздоблення й розмір уже вибрані;
• зображення змінюється разом із варіантом;
• показана ціна саме цього стану, а не мінімальна ціна серії;
• наявність не суперечить фіду;
• спосіб покупки або замовлення зрозумілий;
• блок доставки не створює враження однакових умов для всіх регіонів, якщо це не так;
• конфігуратор працює на мобільному, не приховує ціну й не скидає вибір;
• бот отримує той самий товар і суттєві дані, що й покупець;
• після переадресації зберігається потрібний варіант.

Для товарів із регіональною логікою протестуйте доступні сценарії окремо. Якщо сайт підставляє склад або доставку після вибору міста, фід має вести до стану, який не суперечить цій логіці.

Креативна матриця та групи активів

Групи активів Performance Max є колекціями креативів навколо теми або аудиторії, з яких система створює оголошення. Це не окремі кампанії та не самостійні регулятори ставок. Будуйте їх як тематичні бібліотеки, узгоджені з товарами у відповідній групі лістингів.

Для кожної теми підготуйте кілька типів доказового креативу:

• Кімната й контекст. Покажіть виріб у реальному сценарії використання без перебільшення простору.
• Матеріал і деталь. Дайте крупний план тканини, дерева, фурнітури, шва або механізму.
• Масштаб і розміри. Використайте схему або зрозумілий орієнтир; цифри мають збігатися з карткою.
• Модуль і варіант. Покажіть доступні композиції та чітко відокремте їх від того, що входить у конкретну ціну.
• Нейтральний текст. Називайте перевірені характеристики, не додаючи непідтверджених строків, «вічної» якості чи універсальної сумісності.

Групуйте активи за типом виробу, приміщенням або підтвердженим сценарієм вибору. Внутрішня структура складу зрозуміла команді, але рідко дає покупцеві корисний контекст.

Вимірювання: покупка й окремі заявки

Конверсійні дії об’єднуються в цілі Google Ads. Purchase goal може включати кілька дій; його склад впливає на оптимізацію, ставки та звітність. Перевірте, щоб у цілі покупки не опинилися перегляд товару, додавання в кошик або відкриття контактів.

Запит консультації, заміру або прорахунку конфігурації можна вести як окрему дію, якщо він справді має цінність і не дублює оформлену покупку. Не змішуйте заявку та оплачене замовлення в одну назву або одну ціль: команді потрібно бачити, на якому етапі завершилась дія.

Для покупки передавайте унікальний transaction ID, який генерує бекенд або e-commerce платформа. Він допомагає мінімізувати дублікати при повторному завантаженні сторінки підтвердження. Однаковий ID для різних замовлень може спричинити недооблік, тому статичне значення неприйнятне.

Повернення, скасування й відмови звіряйте з бекофісом окремо. Не припускайте, що рекламна система вже знає про подію після покупки: це залежить від фактично реалізованого імпорту або коригування.

Симптом, перевірка, дія

Симптом	Що перевірити	Дія
Варіанти відкривають однаковий стан	URL, преселект, фото й атрибути	Розвести стани та повторно перевірити item_group_id
Фід показує мінімальну ціну серії	Ціну конкретного доступного SKU	Виводити лише стабільну конфігурацію з відповідною ціною
Доставка на сайті дорожча	Політику акаунта, товарне перевизначення, калькулятор	Синхронізувати правила й перевірити інтеграцію
Негабарит рахується як компактний товар	Джерело ваги й пакувальних розмірів	Оновити специфікацію та shipping_label
Модулі показуються як взаємозамінні варіанти	Логіку групи	Дати кожному типу модуля окрему групу
Покупок у звіті більше, ніж замовлень	Повторний запуск тегу й transaction ID	Передавати унікальний ID з бекенду
Система оптимізується на мікроподії	Склад Purchase goal	Відокремити покупку від діагностичних дій

Чекліст запуску

• Каталог розкладено на родини, моделі, варіанти, модулі, комплекти й замовні конфігурації.
• Для кожної сутності визначено, чи є вона окремим товаром у фіді.
• id стабільні, а item_group_id пов’язує лише справжні варіанти.
• Назви, описи, ідентифікатори й зображення відповідають конкретному SKU.
• Ціна та наявність збігаються з попередньо вибраним станом сторінки.
• Пакувальні габарити не переплутані з розмірами зібраного виробу.
• Політики доставки та мітки відповідають умовам сайту.
• Конфігуратор перевірено на мобільному й у чистій сесії.
• Креативи показують підтверджені матеріали, розміри й комплектацію.
• Purchase goal містить покупки, а консультації та заміри відокремлені.
• Transaction ID надходить із бекенду та є унікальним.

Щотижневий контроль

Напрям	Що перевірити
Фід	Нові відхилення, зміни SKU, ціни, наявності й зображень
Варіанти	Нові товари без групи, неправильний преселект, повторне використання груп
Доставка	Розбіжності із сайтом, товари без потрібної мітки, перезапис ручних правил
Посадкові	Картки після релізів, мобільний конфігуратор, регіональні стани
Креативи	Застарілі тканини, комплектації, розміри або твердження
Вимірювання	Звірка замовлень за transaction ID, склад цілей, повернення й скасування

Періодичний контроль потрібний через зміни асортименту, пакування, сайту та інтеграцій. Коли команда виправляє джерело даних, а не окремий симптом у Merchant Center, наступне оновлення менше ризикує повернути ту саму розбіжність.

Пов’язані матеріали UPLIFY

• Performance Max і Shopping
• Аудит Google Ads
• Усі playbooks
• Редакційна політика