Product Feed Variants: When to Merge Them and When Not To

Why variant structure matters in your product feed

A seemingly simple catalog can get complicated fast. A t-shirt available in five colors and four sizes produces 20 individual rows in your product feed - one per variant. Scale that across a full catalog and you can end up with tens of thousands of rows representing a fraction of the actual products.

That raises a practical question: should your feed contain one row per variant, or one consolidated row per parent product? The answer depends entirely on which channel or tool is receiving the feed and what it expects to do with the data.

The default: one row per variant

Most feed management systems export one row per variant by default, and for good reason. Modern shopping channels are built around variant-level data. When a shopper searches for a "red running shoe in size 43," the channel algorithm needs that exact entry in your feed to match the query. A single merged row listing "red, blue, black" in the color field is too vague to be useful.

Variant-level feeds are the right choice for any channel that does dynamic matching, retargeting, or personalization based on what a user has viewed or interacted with.

What variant merging actually does

When you merge variants, the feed collapses all versions of a product into one row. For each field, you define a merge strategy that controls how values from multiple variants get combined into a single output.

Take a product with a blue variant priced at €99 and a red variant at €79. Merged with sensible strategies, it might output like this:

• Title: the common part shared by all variants - "Classic Sneaker" instead of "Classic Sneaker Blue" and "Classic Sneaker Red"
• Color: a list of all values - "blue, red"
• Price: the lowest value - €79
• Stock: the sum across all variants - combined inventory count

One row, blended data. Less granular, but exactly what some systems need.

Channels that require separate variants

Paid shopping and dynamic ad channels are almost always built around variant-level data. Keep variants separate when sending to these:

• Google Shopping: matches search queries against specific product attributes. Merging removes the size and color signals the algorithm relies on to surface the right product.
• Meta Dynamic Product Ads: retargets users based on the exact variant they viewed. Merging breaks the connection between the viewed item and the ad shown.
• TikTok, Pinterest, Snapchat: dynamic ad logic on these platforms mirrors how Meta works. Variant-level data drives matching and retargeting accuracy.
• Microsoft Shopping (Bing): same model as Google Shopping - attribute-level matching requires variant rows.

The rule is consistent: if a channel supports variants natively, it expects them. Merging strips out signals the channel uses to serve the right ad to the right person.

Channels that prefer merged products

Some platforms don't model variants at all. They treat every row in your feed as a standalone product. Sending 20 nearly identical variant rows to one of these tools just creates noise and duplication.

• Email and SMS marketing platforms: many of these treat the product feed as a flat catalog. Multiple rows for the same product break recommendation logic and create duplicate references in automated messages.
• Catalog tools without variant support: when the receiving system has no concept of parent-child product relationships, merged rows are cleaner and more reliable.

For these destinations, merging isn't a preference - it's the only way to get usable data into the system.

The gray areas

Creative templates that work at the parent level

If you're building dynamic ad creatives that show a "from €X" price, you usually want one image per product rather than near-identical versions for every variant. Merging with a "lowest price" strategy gives you the entry-point price you need for the creative.

Inventory aggregations

If the tool receiving your feed filters out out-of-stock products, summing inventory across variants may give a more accurate picture than checking each variant individually.

Variant URLs that aren't unique

If your store uses one URL per parent product and variants have different prices, some channels will flag a mismatch between the price in the feed and the price on the landing page. Sending one merged row with a single price sidesteps this issue. The cleaner fix is unique URLs per variant, but merging at the parent level is a reasonable workaround if that's not an option.

Choosing the right merge strategy per field

Once you decide to merge, you need to define how each field gets combined. The right strategy depends on what the field represents:

• List all / list unique values: best for attributes that vary across the product - colors, sizes, materials. The "unique" version deduplicates in case of messy source data.
• Take the common part: ideal for titles. Automatically extracts the shared text across variant names.
• Take the lowest value: standard for price. Shows the cheapest entry point and creates a strong "from €X" signal in ads.
• Take the highest value: useful when you want to show maximum capacity, size, or weight.
• Sum all values: the right choice for inventory and stock counts.
• Take the first variant's value: a fallback when no other strategy applies cleanly.

Performance trade-offs to keep in mind

Merging gives you cleaner data for systems that can't handle variants. But on channels that do support them, merging costs you:

• Variant-level bidding: you lose the ability to bid differently on high-demand vs. slow-moving variants.
• Granular reporting: channel-side reports won't show which color or size drives performance.
• Precise matching: narrow attribute searches match less accurately.
• Stock-aware exclusions: without per-variant stock data, you can't exclude individual sold-out variants. If four of five colors are unavailable but the merged row still shows "in stock," you'll keep paying for clicks that lead nowhere.

The simplest summary: merging is a good trade for platforms that don't understand variants. It's a bad trade for channels that do.

A decision framework you can use

When you're unsure whether to merge, work through these questions in order:

• Does the channel support variants natively? If no - merge. If yes - keep reading.
• Does the receiving tool flatten or ignore variant data? If yes - merge. There's no value in sending duplicate-looking rows a system won't use.
• Is your catalog very large relative to your ad budget? If so, consider product sets first - a curated subset of your catalog the campaign optimizes against, with variants intact. Only merge if that's not enough.
• Do you need parent-level creative or pricing logic? If yes - merge with an appropriate price and title strategy.

If none of those apply, start with variants separate. It's easier to merge later than to recover from a flattened feed that's already broken your retargeting.

How Campaign Builder handles feed variants

Campaign Builder's feed management tools let you configure variant behavior per feed, so the same product catalog can be sent to different channels in exactly the format each one expects. Variant-level data goes to Google and Meta. Merged parent products go to your email platform. Same source, different output.

Ready to get started? Explore Feed Management on Campaign Builder - build, filter, and configure product feeds for every channel from one place.