Complete the look recommendations: outfit logic is not product similarity

Start the data work with roles, not with the algorithm. Every product that can appear in an outfit module needs a role tag: base, layer, bottom, shoe, bag, finishing piece, and the module should be built to fill empty roles around the viewed product, never to duplicate its role. A dress page needs the shoe, the layer for evening, the bag. It does not need three more dresses, however similar the engine finds them, because the shopper cannot wear the rail.

Role tagging is manual, unglamorous, and mostly a one time cost per product with a check at range change. Stores resist it because it cannot be automated from the catalogue as it stands, which is precisely why modules built without it all look the same. The tagging is the merchandising. The software is just the shelf it sits on.

Roles before products

Within the right role, three filters decide whether a recommendation can actually be worn with the main product. Palette: the colours must combine, which in practice means a compatibility table at colour family level, maintained by someone with eyes, not a rule that everything neutral goes with everything. Fabric weight and formality: a chunky knit layer over a silk occasion dress fails on both counts at once, and the failure is visible to any shopper in half a second.

Occasion is the filter engines skip because the catalogue does not state it. The product page implies it: the wedding guest dress, the work trouser, the holiday sandal. A completing piece from the wrong occasion makes the whole module read as random, and random is fatal because the modules promise is judgement. One visibly wrong pick teaches the shopper to ignore the rail everywhere on the site, not just on that page.

Compatibility is palette, weight, and occasion

Full manual outfit building does not scale, and full automation does not convince. The working split is familiar to anyone who has run it: hand build complete outfits for the hero products and the high traffic pages, where a stylists choices will be seen and will sell, and run role and compatibility rules for the long tail, reviewed in samples. The hand built outfits also become the training examples that show what the rules are trying to imitate.

Price the whole outfit on the module and let it be added as a set, with sizes chosen per piece. The moment of outfit desire is the whole look at once. Sending the shopper to four product pages to rebuild it piece by piece converts that moment into homework, and the basket that results is usually the main product alone, which the shopper could have bought without the module.

Hand build the heroes, systematise the rest

Outfits break daily in a live range, and the module needs a substitution rule with taste: same role, same palette family, similar price band, in that order of priority, or the outfit should be withdrawn rather than patched with whatever is in stock. A module that silently swaps the shoe for an incompatible one because the size curve was available has chosen a full rail over a true one, and shoppers can tell.

Measure the module on outfit attach: orders containing the main product plus a completing piece, against orders with the main product alone, split by hand built and rule built pages. The gap between those two numbers is the honest price of automation on your range, and it tells you exactly how many more hand built outfits the traffic justifies.

When the completing piece sells out

Keep reading: How should recommendations change when a shopper keeps returning the same category?, How do you keep recommendation carousels from showing the same five products everywhere?.