Содержание 12
Краткий ответ
До тонкой настройки ставок в рекламе настольных игр стоит проверить данные: один тайтл может существовать как базовая игра, дополнение, отдельное издание, локализованная версия и набор. Рабочая основа складывается из чистой таксономии запросов, каталога с отдельными сущностями и фида, который точно описывает каждый физический товар. Измерение завершает эту систему: покупка остаётся основным действием, а каждый заказ получает уникальный идентификатор транзакции.
Спецификация данных 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 после изменений в тегах, аналитике или импорте.
Периодически пересматривайте и саму таксономию. Новое издание, локализация или набор меняют не только ассортимент: они добавляют новую сущность, новую посадочную страницу и отдельное намерение. Если каталог фиксирует эти отличия, рекламу легче диагностировать без предположений об «особом» поведении ниши.