Board games in e-commerce: catalogue, feed and measurement

Short answer

Before fine-tuning bids on board game ads, check the data: a single title can exist as a base game, an expansion, a separate edition, a localised version and a bundle. A workable foundation consists of a clean query taxonomy, a catalogue with distinct entities, and a feed that describes each physical product accurately. Measurement completes the system: the purchase remains the primary action, and every order receives a unique transaction identifier.

The Merchant Center product data specification includes the base attributes id, title, description, link, image_link, price and availability. The status of other fields depends on the category, country and format. That distinction matters: not every field is required for every game, but every value you send must be truthful and consistent with the product.

Query taxonomy: what answer the person expects

Before building campaigns, sort queries by the page that best matches the intent. If someone needs rules or a comparison, a product page will not always be the appropriate answer. If they name a specific game, edition or expansion, they need the exact product page.

Intent type	Example phrasing	What to answer with
Specific title	game name + "buy"	Base game page
Edition or localisation	name + "in Ukrainian", "deluxe"	Page for that specific edition
Expansion	name + "expansion"	Expansion page
Mechanic or genre	co-op, deduction, card games	Collection or filter
Group composition	for two, for a group, family	Curated collection
Occasion	gift, party, travel	Selection with stated criteria
Rules and support	rules, how to play, PDF	Content or service page
Accessories	sleeves, organiser, playmat	Page for a compatible accessory

This is an internal analysis model, not demand statistics. It helps separate navigational intent, where the person is still comparing options, from transactional intent, where a product has already been named. For each group, fix the target page, the permitted ad formats and the queries that must be excluded.

Check ambiguous titles separately. A title may coincide with the name of a book, a film, an app or an ordinary word. In that case, look at the full query and the actual page rather than drawing a conclusion from a single word.

Catalogue architecture

The catalogue should reflect what the buyer actually receives. It helps the team to fix several entity types:

• Base game. A standalone base game with its own SKU.
• Expansion. An add-on sold separately that may require the base game. It is not a variant of the base.
• Edition. A deluxe, anniversary or updated edition with its own contents.
• Language edition. A separate language version, if the box, components, rules or identifier differ.
• Bundle. A set with clearly described contents and its own SKU.
• Preorder. A sales status of a specific product, not a new title.
• Out of stock. An availability state that must appear identically in the catalogue, the feed and on the page.

For an expansion, state the dependency on the base game explicitly in the title and description, where such a dependency exists. For a bundle, list the contents. For an edition, show that edition's own box and specifications. This lets the buyer tell the products apart before reaching the cart, and gives the ad system unambiguous data.

Do not merge entities simply because they belong to the same series. A base game, an expansion and a deluxe edition answer different queries and may differ in price, availability and landing page.

The feed: titles, descriptions, identifiers and images

Title. Use a consistent template: game name, product type, edition or language, where these distinguish the SKU. For an expansion, add the word "expansion" so it is visible without reading the whole description.

Description. Give the facts needed to make a choice: what is in the box, what language the components and rules are in, whether the base game is required, what makes the edition distinctive. Report player count and age marking as the manufacturer stated them, without widening the range yourself.

Identifiers. Send brand, GTIN and MPN in line with the attribute rules and the manufacturer's data. Do not copy one GTIN across different physical products, and do not create a number yourself. If the manufacturer has not supplied an identifier, fill the fields according to the current specification rather than inventing values.

Images. The main photo must show the specific product. Do not substitute the base game box for an expansion, or the cover of a different language version. The buyer should recognise the product they receive from the ad and the page.

Price and availability. The data source for the feed, the product page and checkout must be consistent. A preorder should not be marked as in stock. After a change to contents or a promotion, verify that the update has reached every surface.

When to use item_group_id

The item_group_id help article describes variants as separate products with unique id values and a shared group identifier. The grouping must match the choice available on the landing page; values should not be reused for another product or changed frequently.

For board games, grouping can be appropriate where the difference remains a variant of the same product — for example, the colour of an accessory or the size of a playmat. It is not suitable for pairs such as:

• a base game and an expansion;
• a standard and a deluxe edition with different contents;
• a standalone product and a bundle;
• different games in the same series;
• language editions, where these are different physical products with their own identifiers.

Before grouping, open the target page. Does the buyer see exactly the variant that appeared in the ad? Do its image, price, availability and identifier match? If there is no clear answer, it is better to keep the products separate.

Checking landing pages

The Merchant Center landing page requirements expect link to lead to the page of a specific product, not to a category, a search or a general page. The title, description, image, price, currency and availability must match the data in the feed. Material information must not change depending on device, browser, location, cookies or user agent.

Check URLs on a phone and a desktop, in a clean session and while logged out:

• the correct edition or language version is selected;
• price and currency are visible before adding to the cart;
• the availability status matches the feed;
• the image shows the same SKU;
• there is no forced redirect to a category or another country;
• the page is accessible to the crawler and does not show it a different product;
• the expansion states the base game required;
• the bundle describes its contents clearly.

Repeat a spot check after site releases. A change in routing, localisation or the inventory system can break consistency even without any edit to the feed itself.

Search and Performance Max: divide the roles

In Search, keywords give you an explicit way to work with specific titles, editions, expansions and accessories. The group structure should follow the landing pages. A query about an expansion should not be sent to the base game just because they share a series name.

In Performance Max, search themes are an optional broader signal that gives the system context missing from creatives, the feed or the landing page. They are not keywords and not a hard limit on impressions. Google advises adding new information, avoiding repetition and near-duplicate phrasing, and keeping themes broad enough.

For this category, themes can describe a mechanic, a use situation or a type of assortment that is not visible from product titles. A list of all titles would duplicate the feed and explain little about the structure of demand. After launch, review the actual queries, separate out service intents such as rules or free materials, and adjust exclusions in line with what you actually see in the report.

Do not carry a negative keyword list between campaigns without checking it. The word "rules" may be an informational query for a base game, yet a useful part of a query for a rulebook or an accessory, if such a product really is on sale.

Measuring purchases

The purchase should be the primary business action. Product views, add-to-cart and checkout starts are useful for diagnostics, but they do not become equivalent to a sale simply because there are more of them.

According to the conversion goals help article, conversion actions are grouped into goals, and a Purchase goal may contain several purchase-related actions. The composition of the goal affects optimisation, bidding and reporting. Check exactly which actions are included in Purchase, and remove those that do not confirm an order.

For each purchase, send a unique transaction ID generated by the backend or the e-commerce platform. This helps minimise duplicates when the confirmation page is opened again. The same ID across different orders, by contrast, causes undercounting.

When checking, reconcile ad conversions against real orders using the same identifier. Record returns and cancellations separately in your internal system. Do not assume they already flow into ad reporting: that depends on how the import and adjustments are actually implemented.

Symptom, check, action

Symptom	What to check	Action
An expansion shows as the base game	SKU type and a shared item_group_id	Split the products and fix the grouping
Buyers confuse editions	Title, photo, language and description on every surface	Refine the attributes and replace the mismatched image
Merchant Center sees duplicates	id, GTIN and variant groups	Give each physical product back its real data
Price or availability does not match	Feed, page and checkout	Sync the source and repeat the check
The page is not accessible to the crawler	Redirects, user agent, geography, cookies	Remove selective serving and check the URL again
Irrelevant queries have appeared in PMax	Search themes and actual queries	Remove duplicate themes, add justified exclusions
More conversions than orders	Repeat tag firing and transaction ID	Send a unique ID from the backend
Optimisation counts micro-events as purchases	Composition of the Purchase goal	Keep only confirmed purchases in the goal

Launch checklist

• The catalogue is split into base games, expansions, editions, language versions, bundles and accessories.
• Every SKU has a stable id and genuine manufacturer identifiers, where these exist.
• Titles make it possible to tell a base game from an expansion, and one edition from another.
• Descriptions contain the facts needed to make a choice, with no unverified properties.
• item_group_id is used only for genuine variants.
• Every link leads to the page of a specific product.
• Price, currency, availability and images match between the feed and the site.
• Search themes add new context rather than duplicating the entire catalogue.
• The Purchase goal contains only relevant actions.
• The transaction ID is unique and comes from the backend or the shop platform.

Weekly review

• Review new SKUs and status changes: entity type, identifiers, images, price, availability.
• Work through each new Merchant Center disapproval by its specific reason.
• Spot-open landing pages from the feed in a clean session and on different devices.
• Review actual queries, especially ambiguous titles and service intents.
• Check search themes for repetition and for phrasing already fully described in the feed.
• Reconcile purchases against internal orders by transaction ID.
• Check the composition of the Purchase goal after changes to tags, analytics or the import.

Review the taxonomy itself from time to time. A new edition, localisation or bundle changes more than the assortment: it adds a new entity, a new landing page and a separate intent. If the catalogue captures these differences, the advertising is easier to diagnose without assumptions about the niche behaving "specially".

Related UPLIFY resources

• Performance Max and Shopping
• Google Ads audit
• All Playbooks
• Editorial policy