Thirty SKUs Are Not Thirty Stories: Build the Product Family Map

Imagine a cordless-drill brand preparing a global launch. The catalog contains three torque levels, two battery capacities, multiple plug standards, a fast charger, a spare battery and a hard case. The merchandising team sees thirty SKUs. A production vendor receives thirty rows in a shot list. The buyer is trying to resolve only three decisions: which model fits the job, how the options differ, and whether the new purchase will work with what they already own.

Buying a separate hero set, lifestyle set and short video for every SKU can produce thirty polished packages without producing one coherent product family. A human may still piece the relationships together from filters and tabs. A shopping agent must infer them from data and evidence.

That is why a recent set of optional Google Merchant Center conversational attributes matters. Google now documents item_group_title for the common title of a variant group, variant_option for the properties and values that identify variants, and related_product for relationships such as required parts, accessories, substitutes and frequently bought-together products. Google says these attributes complement the primary product specification; they do not replace it or affect product approval. They can support both conversational experiences in AI Mode and traditional Search. Google Merchant Center: conversational attributes

This does not prove that commerce has converged on one universal product graph. It does establish something narrower and more useful: product relationships are becoming machine-readable buying information, not merely clues left for a shopper to assemble on a page.

The catalog problem is not SKU volume. It is product identity.

Shopify’s June 17, 2026 engineering account of catalog clustering for agentic commerce separates two risks. A precision failure groups products that should remain separate. A recall failure leaves a valid variant out of its family. Shopify describes a precision-first approach because showing the wrong product can be worse than omitting one valid variant. Shopify Engineering: product understanding for agentic commerce

Its practical test is stronger than “same title means same product”: does an attribute change the core value proposition of what the customer is buying? If the answer is no, the attribute can behave like a variant. If it changes the purpose, capability or reason to buy, the item may deserve a separate product identity.

A drill’s color is usually a variant. A torque class that moves the tool into a different job may not be. A skincare bottle size can be a variant, while a formula, skin indication or regulated claim may change the product itself. The right grouping rule follows the buying decision, not the convenience of the database.

The ONCE Product Family Decision Graph

Before commissioning assets, create one graph that merchandising, content, ecommerce and production can all use. It has six fields:

1. Family anchor — What basic product does the customer believe they are choosing? Define the shared structure, use and central promise.
2. Decision axes — Which properties genuinely change the choice: color, size, capacity, voltage, configuration, application or something else?
3. Unique combination — Which values define each sellable SKU? Google’s variant_option guidance says products in a group should use the same set of property names and a unique combination of values. Google Merchant Center: variant option
4. Visual proof — Can the distinction be communicated reliably in data, or must a buyer see, compare or verify it?
5. Relationship and compatibility — Is another item a required part, accessory, set member, common companion or substitute? Google’s current related_product schema supports those relationships and allows up to thirty related products. Google Merchant Center: related product
6. Version owner — Who updates the source data, approves physical accuracy and triggers asset changes when packaging, interfaces or specifications change?

This is not another feed template. It is a production-routing system. Once the six fields are connected, each product difference falls into one of three evidence levels.

Level 1: data only

If a difference is not visible and does not change installation, operation or the outcome of the choice, data may be enough. Internal batch codes, warehouse identifiers or packaging fields that do not affect use rarely justify a new video.

The acceptance test is whether the SKU can be uniquely identified and correctly matched—not whether the asset count went up.

Level 2: comparative visual proof

If the difference is visible but does not need an action demonstration, use a comparison still, scale reference or a controlled variant grid. Color, length, connector position, capacity marking and external dimensions belong here. Lock camera position, light, scale and framing so the difference can be compared directly.

This is where one shared capture can split into a master layer and a variable layer. The master holds composition, environment, scale and handling. The variable layer replaces only the part that must be verified. If generative tools extend the setting, the product body, label, color and interfaces should remain anchored to approved physical references. A peer workflow from Versely similarly argues for a fixed reference-image spine and human QA; its focus is per-SKU batch output, while the family graph decides which SKU differences actually merit new evidence. Versely: AI content for ecommerce catalogs

Level 3: independent action proof

When a variant changes installation, fit, compatibility, performance or a safety boundary, create a dedicated proof moment. Two battery capacities may not need separate brand films, but a difference that changes runtime, weight or charging method deserves a specific handling clip, scale comparison or compatibility demonstration.

The same logic applies to related products. A required part should show what cannot be completed without it. An accessory should demonstrate the capability it adds. A substitute needs a condition under which substitution is appropriate. The image or video should not repeat the relationship field; it should make that relationship verifiable.

Replace “one asset kit per SKU” with shared structure plus decisive branches

Rewrite the production brief in this order:

• Approve one family master covering shared design, common use, standard handling and scale.
• List every decision axis and mark it data-only, comparison-proof or action-proof.
• Batch low-risk visual variations under a locked camera and lighting setup.
• Assign separate shots to installation, compatibility, performance and safety differences.
• Bind every proof shot to the relevant SKU or relationship in the source system.
• Only then create market, language, aspect-ratio and channel versions.

This method does not guarantee a smaller budget. Brands with inconsistent grouping and fast-changing specifications may spend more initially on data cleanup and ownership. The return is not “cheap content.” It is less duplicated capture, fewer gaps at important decision points and a system that can be maintained when the catalog changes.

If the brand already maintains reusable 3D or digital product assets, the family graph should decide what deserves that investment. Keep geometry, materials and actions that can be reused across many decision branches; use physical capture where accuracy or interaction must be proven. ONCE’s related framework, Stop Buying Product Content One Asset at a Time, explains how to calculate that reuse threshold.

Measure cost per verified buying branch

“Cost per finished video” is the wrong denominator for a product family. Use:

Cost per verified buying branch = (family mapping + fact review + shared capture + variant-specific proof + localization + maintenance) / verified decision branches

A branch is verified only when the SKU combination is unique, the landing page agrees with the feed, the visual does not invent color, scale, ports or features, and every compatibility or substitution claim has an owner and version.

This exposes two forms of false economy. The first is thirty complete videos whose footage is mostly repeated. The second is one master video stretched across thirty SKUs without proving any decisive difference. The former wastes production spend. The latter transfers selection risk to the buyer and support team.

Google’s structured-data documentation reinforces the same separation between group-level and variant-level information. It recommends ProductGroup with hasVariant, distinct variant URLs where appropriate, and consistent group data alongside variant-specific properties such as variesBy. It supports both single-page and multi-page variant implementations. Google Search Central: product variant structured data

Five deliverables to request before the next catalog shoot

1. A family map that identifies variants, separate products, required parts, accessories and substitutes.
2. One controlled vocabulary for the family’s decision axes and a unique combination for every SKU.
3. A proof matrix explaining why each difference needs only data, a comparison image or an independent action clip.
4. An approved physical reference set covering shape, color, label, interfaces and scale.
5. A change trigger defining which assets must be revised after packaging, hardware, compatibility or claims change.

The new Merchant Center attributes do not require a brand to reshoot its catalog, and filling them in is not a promise of more exposure. They are an early signal that shopping interfaces will increasingly depend on explicit product relationships.

For brands connected to complex Chinese supply chains, the immediate decision is not whether to buy more content for every SKU. It is whether the organization can state which buying branches matter and attach trustworthy evidence to each one. When product data and visual production share the same family map, content becomes a maintained decision asset rather than a pile of isolated deliverables.