A Group products rule collects products that share the same group key — all the sizes of one shirt, all the offers for one barcode. From there you can do one of two things: add values computed across the whole group to every product ("4 variants", "from 19.99"), or keep just one product per group and leave the rest out. Your edits stay in a draft until you Publish.
Why group products#
Product feeds usually arrive one row per thing in stock, not one row per thing you want to advertise. Grouping closes that gap in two directions:
- Every product learns about its group. You can put the number of variants, the lowest price in the family, or a list of all available sizes onto every one of those products — and then use that value in a title, a description, or an ad template.
- One product per group is enough. If you advertise eight near-identical rows of the same shoe, you pay eight times to say one thing. Keep the cheapest one and drop the rest.
Grouping is the mirror image of splitting variants into products: splitting turns one row into many products, grouping brings many rows together.
How to add a Group products rule#
Grouping is an action on a rule, so it lives on the catalog's Rules tab alongside your other rules.
- Open the catalog from your project's Catalogs list and go to the Rules tab.
- Choose + Add rule, then set the action to Group products. The grouping editor opens straight away.
- Pick what grouping should do — Add computed fields to every product or Keep one product per group.
- Under Group products that share…, name the value that identifies a group (see below).
- Fill in the computed fields you want, and — in keep-one mode — which product to keep.
- Choose Done, then Publish the catalog. Nothing reprocesses until you publish.
While you're editing, the dialog shows a live count from a sample of your feed — "~50 products → ~12 groups in a sample" — so you can tell at a glance whether your group key groups too much or too little.
The group key#
Products that resolve to the same group key are one group. The key can be a single value — a variant family id, a barcode, a style code — or several values combined, in which case products have to match on all of them to be grouped together.
Each part of the key has the same matching choice you get when joining another feed:
- Smart — ignores capitalization and stray spaces. The safe default.
- Barcode — treats barcodes as equal even when one of them is missing leading zeros.
- Exact — matches character for character.
A product whose group key is blank isn't pooled with the other blank ones — it stays in a group of its own, and nothing is ever dropped because of a missing value. That means a feed that mixes variant families with standalone products just works.
If you'd rather group only part of your catalog, give the rule conditions like any other rule. Products the conditions don't match aren't group members at all: they aren't grouped, they aren't dropped, and they pass through untouched.
Add computed fields to every product#
In this mode every product stays in your catalog, and each one gets new columns holding values computed across its whole group. Each computed field is one line: a function, the value to compute it from, and the column to save it into.
| Function | What you get |
|---|---|
| Count | How many products are in the group. Needs no value. |
| Distinct count | How many different values the group has — the number of colours in a variant family, say. Repeats count once; blanks aren't counted at all. |
| Sum | The total of a value across the group. |
| Average | The mean of a value across the group — an average price, an average rating. |
| Smallest | The lowest value in the group. |
| Largest | The highest value in the group. |
| Values | Every value in the group, in feed order. |
| Distinct values | The same list with repeats removed — the first of each value is kept, in feed order. Blanks are left out, so this lines up with Distinct count (up to the 1,000-value limit below). |
| Any | true when at least one product in the group says yes, otherwise false. |
| All | true only when every product in the group says yes. |
Sum, Average, Smallest, and Largest produce plain numbers, not formatted prices. A group whose lowest price is 19.99 gives you 19.99, but one whose lowest price is a round 20 gives you 20.0 — not 20.00, and with no currency. So if you're building a "from 19.99" line for your ads, add a Round step (or a Pattern step for full control over decimals and currency) where you use the value — see Fixing your feed data with rules. Count and Distinct count are always whole numbers.
Any and All read a yes/no value. They understand true/false, yes/no, and 1/0 in any capitalization, and they write the word true or false into your column. Any of in_stock tells you the family is still buyable somewhere; All of on_sale tells you the whole family is on sale, so you can say so in the ad without over-promising.
The columns you save into behave like any other column you create with a rule: they show up in the Rule outputs list, and you can map them to a catalog field, read them in a later rule, or use them in an ad template. So Count of products saved as __variant_count becomes the "Available in 4 sizes" line in your ads. Count, Distinct count, Sum, Average, Smallest, and Largest columns are treated as numbers, so a later rule can compare them with "is greater than" and friends.
Because rules run top to bottom, a computed field is only available below the Group products rule — a rule above it sees an empty column.
Keep one product per group#
In this mode only one product per group reaches your catalog, and the others are left out. You choose which one to keep by naming a value and whether the lowest or the highest of it wins — "keep the product with the lowest price" is the common case.
Two details worth knowing:
- A product whose value isn't a number loses to any product that has one. If no product in the group has a usable number, the first one in your feed is kept.
- When two products tie, the first one in your feed is kept.
You don't have to add any computed fields in this mode. A rule that only keeps one product per group is de-duplication, and that's a perfectly good rule on its own.
Products left out this way are reported separately from excluded products: the catalog's import history counts them under Grouped into other products, never under Excluded, so a feed that goes from 4,200 rows to 900 products reads as intentional rather than broken.
Give the kept product a stable ID#
When you keep one product per group, the kept product can change from import to import — a different variant goes on sale, a price moves. If your ID field is mapped to something that differs between the products in a group (each row's own SKU, for example), the catalog id changes whenever the kept product changes, and every ad network treats that as a brand-new product.
The fix is to map the ID to your group key on the Mapping tab, so all the products in a group would produce the same id — then whichever one is kept, the id stays put and only its fields change. See Mapping your feed fields.
The grouping editor watches for this and warns you when the ID doesn't come from the group key, with a one-click way to point it there. It's advice, not a block: a churning id is sometimes what you actually want, so Renable lets you publish either way.
Where the grouping sits in its rule#
Group products is an ordinary action, so where you put it inside its rule matters — and you can use that.
- Actions above it run first. That's how you build the column you then group by: set a scratch column in the same rule, then group on it.
- Actions below it run only for the products that survive. In keep one product per group mode that's the kept product; in add computed fields mode it's every product in the group. It behaves exactly like a rule placed underneath.
- The grouping can live in the "Otherwise…" branch, where it applies to the products the rule's conditions don't match.
That last one solves the most common grouping headache: a group key that's empty on some products. Products with a blank key are never pooled together (each stands alone), but they also keep whatever id they had. One rule handles both cases:
When
item_group_idis blank → Set fielditem_group_idto the product's id Otherwise → Group products byitem_group_id, keeping the lowest price
Products with a real group id get grouped and reduced to the cheapest one; products without one get a group id of their own, so they still export a stable value and stay in your catalog untouched. You can ask Aimée for exactly this in plain language.
Limits and things to know#
- One Group products rule per catalog. A second one is rejected when you publish — including one hiding in an "Otherwise…" branch, which counts just the same.
- Grouping runs before splitting. You can't group products that a split produced — put the Group products rule above the split rule. (Reading a value that grouping created from inside a split works fine, since variants inherit their parent's columns.)
- A rule can group once, but it doesn't have to group alone. Other actions can sit beside Group products in the same rule, and the rule can have an "Otherwise…" branch — see Where the grouping sits in its rule above. What you can't do is group twice in one rule; the second grouping needs its own rule (and then you'd be over the one-per-catalog limit anyway).
- It only works on your main product feed, not on auxiliary feeds or mapping tables.
- Values a function can't read are skipped, not fatal. If a product's value isn't a number, it's left out of a Sum, Average, Smallest, or Largest calculation; if it isn't a yes/no value, it's left out of an Any or All. Either way your import reports a warning naming the column and still finishes. If no product in a group has a usable value, the column is simply left empty for that group — never a
0or afalseyou didn't ask for — and any fallback you've set where you use the value applies as normal. Count and Distinct count are the exceptions: they always write a number, and a Distinct count of0honestly means "no product in this group had a value". - Adding a group rule makes every import re-read your whole feed. Normally Renable skips products whose raw feed data hasn't changed since last time; it can't do that with grouping, because a change to one product changes the computed fields of all its siblings. Expect somewhat slower imports on a large feed — this is deliberate, and it's what keeps your computed fields correct.
- A very long list of values is trimmed. Values and Distinct values keep the first 1,000 values of a group and report a warning if there were more. Distinct count keeps counting past that, so a group with more than 1,000 different values gives you the true count beside a shortened list. Above 100,000 different values in a single group, Renable stops keeping track and reports that the count is approximate — a group that big almost always means the group key is wrong.
- Very large numbers of groups fail the import. If a feed produces more than 250,000 distinct groups, the import stops with a message telling you to check the group key — nearly always a sign the key is unique per product, which means nothing is being grouped at all.
Your changes aren't live until you Publish#
Like everything else in the catalog workspace, a Group products rule stays in a draft and doesn't reprocess anything until you Publish. And "Import now" uses your last published configuration, not your draft — so publish (or choose Publish & import) before you expect to see the change. The publish confirmation estimates how many products would be grouped into other products, so a rule that drops most of your catalog can't surprise you.
Or ask Aimée#
You don't have to build the rule yourself. Describe the outcome in plain language — "only advertise the cheapest variant of each shoe", or "put the number of sizes on every product" — and Aimée can set up the Group products rule and the ID mapping, then publish once you approve.
FAQ#
Does keeping one product per group delete my products?
No. Nothing is deleted anywhere. The products that aren't kept simply don't appear in the catalog this rule produces, so they don't reach your channels or ads. Remove the rule and republish and they're all back on the next import.
Can I group after splitting variants?
No — grouping always runs before splitting. If you need per-variant grouping, group on a value that's already present on the original feed row.
What's the difference between grouping and item_group_id?
They solve different problems. item_group_id tells the ad network which of your products are variants of one another, so it can show them as one listing — see Item group ID and variants. A Group products rule works inside Renable, before the feed goes out, either adding computed values or reducing the number of products you send. You can use both.
Can I use a computed field in a condition?
Yes, as long as the rule using it sits below the Group products rule. Rules run top to bottom, so a rule above it sees the column as empty.