Splitting products

Splitting is the mirror image of merging. Merging takes several records of the same product and makes one. Splitting takes one record carrying variants that are not really the same product and makes several.

The situation it solves: a vendor sends one product called Crussis e-Largo with twelve variants — three colours in four sizes. In their feed that is one row. In your shop it should be three products, each offered in four sizes, because a customer shops for a black bike and expects to see a black bike.

What a split actually does

1. You choose the variant parameter to split by

   Colour, in the example above. The value has to live on the variant, not among the product's parameters — a size or a colour is what distinguishes one variant from another, which is exactly what makes it splittable.

2. The variants are grouped by that value

   Every variant carrying black forms one group, every white one another.

3. Each group becomes its own product

   It carries the value in its name, and it keeps the remaining variants — the four sizes. The other parameters travel with it.

4. The original is hidden, not deleted

   It stays in the system and the vendor's feed keeps updating it. It simply stops appearing in the shop and in export feeds.

You will find the module under Products → Splitting products (Opens in a new tab). It opens on the Overview tab, which restates the mechanics above in short.

The one thing worth knowing before you start

A derived product is system-managed. After every import from the vendor the split is re-projected: new prices, new stock and newly arrived variants are carried into the right derived product on their own.

That is what makes the feature useful, and it is also the one place where you can lose work. The reconcile rewrites the fields it owns.

The pinning is per field, not per product. Correcting a derived product's brand does not freeze its description too — otherwise one small fix would quietly cut the whole product out of the projection.

The pin can also release itself. If you edit a name back to what the split would have derived anyway, it stops counting as a manual edit and the projection takes the field over again.

Splitting products by hand

Select the products on the product list (Opens in a new tab), then use Split selected in the bulk toolbar. That opens the split screen, which does something unusual and worth understanding:

You configure one recipe against one sample product, and it is replayed across the whole selection. You pick the parameter and the name pattern while looking at one real product, see exactly what it would become, and confirm. The other products get the same treatment.

At most 100 products go into a single run. Select more and the screen tells you how many were dropped.

The preview is the safety net

Nothing runs until you have seen the preview. It shows, for the sample product:

• how many new products would be created, and what each would be called;
• the code each one would get;
• how many variants each keeps, and how many of those are active;
• any variants that have no value for the chosen parameter — they are collected into a product of their own rather than being silently dropped.

What gets skipped, and why

A run reports each product separately, so a problem with one never stops the rest. The reasons you may see:

Rules: splitting that keeps happening

Splitting by hand handles what is in the catalogue today. A rule handles what arrives tomorrow.

A rule remembers a filter and the parameter to split by. It splits everything matching the filter, and — if you leave Apply after every import on — it also splits products that start matching later, such as ones the vendor adds to the feed next week.

Rules live on the Rules tab. You can also save one straight from the product list: filter the list the way you want, then choose Save as splitting rule.

Each rule can be switched off without being deleted, and deleting a rule leaves the products it already created alone — they simply stop being refreshed by it. Where two rules could both claim a product, the higher priority wins; a product belongs to at most one split.

Photos on the derived products

This is the setting people ask about most, and it has four answers:

The AI option costs one call per product, per run — and only for products it actually has to look at. Where the photos can be matched without it, nothing is charged. You can try it on a single product first: the product's detail page offers a dry run that shows which photo each derived product would receive and changes nothing. If the result is not confident enough, pick the photos yourself by clicking them, then apply — that costs nothing further.

Living with a split product

Both sides of a split say what they are, on their own detail page.

The original carries a banner saying it was split, how many products it became, and links to each of them. It is marked hidden.

A derived product carries a banner pointing back at the original, plus the note about which edits survive. Its gallery has two extra controls:

• Import photos from the original — for when you deleted too much and want the missing ones back.
• Return to automatic — hands the gallery back to the projection, undoing your manual ownership of it.

Reversing a split

Every split can be undone, from the History tab. Each active split there offers two actions:

1. Reconcile with the feed

   Re-runs the projection now instead of waiting for the next import. Useful after you have changed something on the original.

2. Undo the split

   Reverses it. The derived products are archived and the original comes back into the shop.

Undoing archives the derived products by default rather than deleting them, so nothing is lost. There is a second mode that deletes them outright, and it exists for one specific purpose: archived products keep their product codes, so splitting the same product again would produce codes with a suffix appended. Delete frees the codes up.

The Ledger below the list records every split, undo and automatic reconcile — who ran it, when, and what triggered it: by hand, by a rule, after an import, or through the API. It is what answers "why did forty products appear last night".

Who may do what

An editor can create a hundred products with one confirmation, but only an admin can take them back — the same split of responsibility that merging uses.