Настільні ігри в e-commerce: каталог, фід і вимірювання

Коротка відповідь

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

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

Таксономія запитів: яку відповідь очікує людина

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

Тип наміру	Приклад формулювання	Чим відповідати
Конкретний тайтл	назва гри + «купити»	Картка базової гри
Видання або локалізація	назва + «українською», «делюкс»	Картка конкретного видання
Доповнення	назва + «доповнення»	Картка доповнення
Механіка або жанр	кооперативні, дедукція, карткові	Колекція чи фільтр
Склад учасників	для двох, для компанії, сімейні	Кураторська колекція
Нагода	подарунок, вечірка, подорож	Добірка з поясненими критеріями
Правила й підтримка	правила, як грати, PDF	Контентна або сервісна сторінка
Аксесуари	протектори, органайзер, мат	Картка сумісного аксесуара

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

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

Архітектура каталогу

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

• Base game. Самостійна базова гра з власним SKU.
• Expansion. Доповнення, яке продається окремо й може вимагати базову гру. Це не варіант бази.
• Edition. Делюкс, ювілейне або оновлене видання з власною комплектацією.
• Language edition. Окрема мовна версія, якщо відрізняються коробка, компоненти, правила або ідентифікатор.
• Bundle. Набір із чітко описаним складом і власним SKU.
• Preorder. Статус продажу конкретного товару, а не новий тайтл.
• Out of stock. Стан наявності, який має однаково відображатися в каталозі, фіді й на сторінці.

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

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

Фід: назви, описи, ідентифікатори та зображення

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

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

Ідентифікатори. Передавайте brand, GTIN і MPN відповідно до правил атрибутів та даних виробника. Не копіюйте один GTIN на різні фізичні продукти й не створюйте номер самостійно. Якщо виробник не надав ідентифікатор, заповнюйте поля за чинною специфікацією, а не вигадуйте значення.

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

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

Коли використовувати item_group_id

Довідка про item_group_id описує варіанти як окремі товари з унікальними id і спільним ідентифікатором групи. Групування має відповідати вибору на посадковій сторінці; значення не варто повторно використовувати для іншого продукту або часто змінювати.

Для настільних ігор групування може бути доречним, коли відмінність залишається варіантом того самого продукту, наприклад колір аксесуара чи розмір мату. Воно не підходить для таких пар:

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

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

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

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

Перевіряйте URL з телефона й комп’ютера, у чистій сесії та без авторизації:

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

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

Search і Performance Max: розподіліть ролі

У Search ключові слова дають явний спосіб працювати з конкретними тайтлами, виданнями, доповненнями й аксесуарами. Структура груп має відповідати посадковим сторінкам. Запит про доповнення не варто вести на базову гру лише через спільну назву серії.

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

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

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

Вимірювання покупок

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

За довідкою про conversion goals, конверсійні дії групуються в цілі, а Purchase goal може містити кілька дій, пов’язаних із покупкою. Склад цілі впливає на оптимізацію, призначення ставок і звітність. Перевірте, які саме дії включено до Purchase, і приберіть ті, що не підтверджують замовлення.

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

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

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

Симптом	Що перевірити	Дія
Доповнення показується як базова гра	Тип SKU та спільний item_group_id	Розділити товари й виправити групування
Покупці плутають видання	Назву, фото, мову й опис на всіх поверхнях	Уточнити атрибути та замінити невідповідне зображення
Merchant Center бачить дублікати	id, GTIN і групи варіантів	Повернути кожному фізичному товару його реальні дані
Ціна або наявність не збігається	Фід, сторінку й оформлення замовлення	Синхронізувати джерело та повторити перевірку
Сторінка недоступна краулеру	Переадресації, user agent, географію, cookies	Прибрати вибіркову віддачу й перевірити URL знову
У PMax з’явилися нерелевантні запити	Пошукові теми й фактичні запити	Прибрати дублікати тем, додати обґрунтовані виключення
Конверсій більше, ніж замовлень	Повторний запуск тегу й transaction ID	Передавати унікальний ID з бекенду
Оптимізація враховує мікроподії як покупки	Склад Purchase goal	Залишити в цілі лише підтверджені покупки

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

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

Щотижневий огляд

• Переглядайте нові SKU та зміни статусу: тип сутності, ідентифікатори, зображення, ціна, наявність.
• Розбирайте кожне нове відхилення в Merchant Center за конкретною причиною.
• Вибірково відкривайте посадкові сторінки з фіда у чистій сесії та на різних пристроях.
• Переглядайте фактичні запити, особливо неоднозначні назви й сервісні наміри.
• Перевіряйте пошукові теми на повтори та формулювання, які вже повністю описані у фіді.
• Звіряйте покупки з внутрішніми замовленнями за transaction ID.
• Перевіряйте склад Purchase goal після змін у тегах, аналітиці або імпорті.

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

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

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