SKU rationalization: how to prune the long tail with data

SKU rationalization is the review in which you decide, product by product, which SKUs to keep, which to fix, which to fold into another product as a variant and which to retire. It looks at what each SKU earns (sales, gross profit, returns) and what it costs to carry (stock, handling and, in an online catalog, the product data you keep current on every channel).

The short version of the process: pull 12 months of sales, margin and return data per SKU, add the data upkeep each SKU needs, sort out look-alikes that should be one product with variants, fix the products that sell badly because their content is weak, and retire the rest in a controlled way so feeds, links and search do not break. Most guides stop at the sales ranking. This one adds the catalog side, because in a multichannel web shop every tail SKU also costs content work, not only warehouse space.

Four outcomes for every SKU in the review

Treat the review as sorting, not cutting. Every SKU leaves with one of four labels:

• Keep: it earns its place on profit, or it does a job the numbers undersell, such as completing baskets or covering a niche search.
• Fix: it would sell if shoppers could understand it. Thin descriptions, one blurry image or missing size data are common reasons a product sits in the tail.
• Merge: it is the same model as another product in a different color, size or pack, imported as a separate product. It becomes a variant of one parent.
• Retire: it loses money or attention and nothing depends on it. It goes through a product retirement process: sell-off, delisting, redirect, archive.

The second and third labels are where catalog teams win the most. A merge cuts data work without losing a single sale, and a fix can lift a product out of the tail without a buying decision.

The data to pull per SKU before you decide

Use 12 months so seasonal products get a fair run, and compare seasonal items season to season. Leave out SKUs launched in the last six months; they have not had a chance yet. Per SKU you want:

• Units and revenue over the period, plus the trend (last quarter against the same quarter a year earlier).
• Gross margin after discounts and returns. List price margin flatters products that are always on promotion.
• Return rate and the main return reason. A 14% return rate driven by "lid leaks" is a product problem, not a content problem.
• Stock on hand and days of cover, so you know what a retirement leaves to sell off.
• Basket role: how often the SKU appears in orders with other products, and whether it is part of a bundle or gift set.
• Search demand: impressions and clicks on its product page. Some tail products are how new customers find you.
• Data quality: a completeness or quality score, number of images, filled attributes and languages covered.
• Data cost: how many content items the SKU carries across languages and channels (next section).

What a SKU costs to keep in the catalog: content per language and channel

Inventory guides count storage and capital. In a multichannel web shop each SKU also carries a stack of product data that someone has to create and keep current: a title and description, attributes, images in the formats each channel wants, a category per channel, translations for every market, and the compliance and logistics fields (HS code, country of origin, safety information) that marketplaces and customs ask for.

Multiply it out for a store selling in Dutch, German and French on its own shop, Google Shopping and one marketplace. One SKU means three descriptions, three titles and three sets of translated attribute values, and the same images checked against three channel rules. Every copy change, price rule or new channel requirement repeats that work for every SKU, including the ones that sell 20 units a year.

Some of that cost is easy to put a number on. In WISEPIM one AI credit covers one translation into one language, and credits cost EUR 0.15 to EUR 0.06 depending on the pack. Translating 400 tail SKUs into two extra languages is 800 credits each time their content is rewritten. Small per product, but it recurs, and the review time to check those translations does not shrink with the price.

Products that nobody sells but everybody maintains are close cousins of ghost SKUs: records that live on in feeds and systems after the stock is gone. Count both.

Worked example: a ceramic mug range of nine SKUs

Here is an illustrative range from a homeware store that imported its catalog from a supplier spreadsheet. The Nordic mug came in five glazes, and each glaze arrived as its own product with its own title, description and images. The numbers are made up for the example; the decisions follow the logic above.

What the table shows that a revenue ranking hides:

• The five Nordic glazes are one product. Merged into one parent with a Color option, the range needs one description, one set of translations and one product page that ranks, instead of five near-duplicates competing with each other. The ink glaze stays as a variant, and its weak photos get fixed.
• Lilac goes, but through the variant. At 22 units and a 9% return rate it is the weakest glaze. Once it is a variant, retiring it means switching off one option after the sell-off, not deleting a product page.
• The espresso cup is a clean retire. 18 units, the highest breakage returns, the lowest quality score and no bundle depends on it.
• The travel mug is not a content problem. Its quality score is middling, but the 14% return rate comes from a leaking lid. Pause it and take it up with the supplier; better copy will not stop the returns.
• The gift set earns more than its rank suggests. It is the main outlet for the slower glazes, so cutting colors that feed it would hurt a product that makes EUR 4,056 gross profit.

The result is a range that goes from nine product pages to four (the Nordic parent with four glazes, the classic mug, the travel mug once fixed, and the gift set), while losing roughly EUR 227 of gross profit from the two retired SKUs before any substitution.

Merge into variants or retire? A decision path

The order matters. Teams that start with "is it profitable?" retire products that should have been variants, and lose the colors or sizes that made the range complete. Teams that skip the data-quality question retire products whose only problem was a missing image.

Folding look-alike products into one parent with variants

Look-alikes are products that differ only in a variant dimension: color, size, capacity, pack size. They usually come from supplier files that list each article on its own row, or from years of adding products one at a time. The variant management guide covers the data model; for a rationalization the steps are:

1. Pick the parent. Usually the best seller with the best content. Its description becomes the shared description.
2. Name the option. "Color" with values Sand, Sage, Rust, Ink. Keep option values consistent across the catalog so filters work.
3. Strip the variant word from the parent title. "Nordic stoneware mug 350 ml", not "Nordic stoneware mug 350 ml sand".
4. Keep variant-level fields on the variant: SKU, GTIN, price, stock, weight and the image that shows that glaze.
5. Check platform limits. Shopify allows up to three options and 2,048 variants per product; the Shopify variant limit post covers what to do when a range does not fit.
6. Redirect the old product URLs to the new parent (see the retirement steps below).

In WISEPIM you can select the products and run the Group as variants bulk action (up to 500 products at a time), or let the Catalog Jobs job "Turn look-alikes into variants" find the groups and put them in a review queue, where you accept or reject each suggested group.

Separate merging from deduplication. Two records for the same SKU are duplicates and one of them should go; the deduplication guide covers that case. Look-alikes are different products that belong under one parent.

Retiring a SKU without breaking feeds, links or search

A retirement touches more systems than a delete button. Two platform facts shape the order of the steps. On Shopify you can only create a redirect from a URL that is broken, so the product page has to stop resolving before the redirect works. And Google does not index URLs that return a 4xx status and drops already indexed ones over time, so a retired page without a good replacement can simply return a 404.

Finding the tail in your sales and quality data

Most of the numbers come from your store or ERP. The useful extra is seeing sales and data quality side by side, because that separates "nobody wants it" from "nobody can tell what it is". WISEPIM's product performance analytics rank every product by revenue, units and trend next to its quality score, using the orders from your connected store.

Margin needs cost prices, which many catalogs do not hold per SKU. If yours does not, add gross margin from your ERP or bookkeeping export into the review sheet rather than estimating it.

How often to run a SKU rationalization review

Twice a year works for most web shops: once before the main buying season and once after it, when you know what sold. Fast-moving categories such as fashion follow their own season calendar, and if you run category management, the review fits naturally into each category's planning cycle. Between reviews, a few rules keep the tail from regrowing:

• Set an entry bar for new products: a new SKU arrives with the minimum content per channel (title, description, key attributes, images) or it does not go live.
• Give each new SKU a review date six to twelve months after launch.
• Import variants as variants. Most look-alikes start as separate rows in a supplier file; mapping them to a parent at import avoids the cleanup later.
• Track the count of active SKUs per category next to revenue per category, so growth in range size is a decision, not an accident.

Six ways a SKU cut goes wrong

1. Ranking on revenue only. It retires high-margin niche products and keeps busy low-margin ones.
2. Ignoring the basket. An accessory that sells 30 units a year can be what completes 300 orders.
3. Retiring what should be a variant. You lose the option a shopper wanted and keep the content duplication.
4. Blaming the product for bad data. Fix the images and description first and give it a quarter.
5. Deleting instead of archiving. Returns, warranty questions and reporting break when the record disappears.
6. Leaving the feeds and links behind. Dead products in Shopping feeds and broken related-product links outlast the decision by months.

WISEPIM keeps the catalog side of the review in one place: the sales and quality data to find the tail, Group as variants and the look-alike job to merge, and product status, feeds and channel connections to retire cleanly. You can try it on your own catalog on the free plan with up to 100 products.