MerchentiaHow to set up Shop The Look before you generate any looks
There are a lot of settings, and most of them don’t matter much. What matters is when each one takes effect. A handful are baked into a look at the moment it is built — get those wrong and you regenerate. Everything else applies instantly and can be tuned any time. This guide walks the settings in the order you meet them and says which kind each one is.
The one distinction that saves you a rebuild
Settings fall into two groups:
- Build-time — read when a look is generated and frozen into it. Changing them later does nothing until you rebuild or regenerate. These are the ones to set first.
- Serve-time — read every time a shopper loads the page. Changes are live immediately, so they can wait.
Only four settings are build-time: Similar match, Candidates stored per category, Match items to the same kind, and Match scope. If you read nothing else, set those before you generate.
Step 0 — read the readiness card first
Before touching a setting, open Home or Looks by AI and read the “Is your store ready for Shop the Look?” card. It runs no AI and calls nothing — it just measures your catalogue and answers whether a look can be filled at all. Four tiles:
- Products usable — how many products are Active, in stock, on the Online Store sales channel, and have a photo. Green at 70%+, amber from 30%, red below.
- Outfit categories — how many of the eight garment rows (Tops, Bottoms, Dresses, Outerwear, Shoes, Bags, Hats, Jewelry) you can actually fill. A category counts only with 3 or more buyable products, because below three every look shows the same item. Green at 6 of 8, amber at 4–5.
- Colour readable — the share of products whose colour value the matcher can interpret. Green at 90%+.
- Looks built and published, and whether the widget is actually placed in your theme.
What it does not do, and this matters: it checks that a product has a photo, not what is in that photo. Whether a photo actually yields a look — which needs a real person wearing or carrying the items — is only decided later, at generation time. A store can score green across the board and still produce empty looks if the catalogue is shot entirely in packshots. It also doesn’t pick products for you: there is deliberately no “generate these first” shortlist, because which products deserve a look is a merchandising judgement.
One quirk worth knowing: the outfit-category counts come from products that have finished syncing and embedding. Right after install, while the first catalogue sync is still running, the strip can read lower than your real catalogue. Give it a few minutes before drawing conclusions.
Also note the category a product is filed under comes from your metadata — its title, Shopify taxonomy, product type and the collections it sits in — not from the image. Badly-typed products land in the wrong row, and that is fixable in Shopify, not in the app.
Match thresholds
Similar match — default 38% · build-time
This is the real quality floor. Any candidate scoring below it is dropped and never appears in a look. Raise it for fewer, closer matches; lower it to fill more rows with looser ones. If a garment row is missing from a look, this is usually why.
The trap: it is applied when the look is built, not when it is served. Moving the slider changes nothing on your storefront until you rebuild.
Exact match — default 62% · labelling only
This one causes more confusion than any other setting, so plainly: it does not decide what gets recommended. It only decides whether a matched product is labelled “exact” or “similar” on the candidate cards inside the app’s own look-review screen. Shoppers never see either word. Treat it as your triage label when reviewing looks, not as a storefront promise.
The trap: dragging Exact down below the current Similar value silently drags Similar down with it — and Similar does change what is recommended. Watch the second slider when you move the first.
Candidates stored per category — default 6 · build-time
How many ranked backups are kept for each detected garment. The widget shows the top one that is currently buyable; the rest are the substitution chain behind it, which is what lets a sold-out item be replaced with no rebuild.
The trap: raising this does not put more products in a row. Each garment slot shows exactly one card. More candidates buys resilience, not breadth.
Match scope — default: whole catalogue · build-time
Tick collections to restrict where matches are drawn from; leave everything unticked to search everything. Narrowing this is the single most effective fix when looks keep pulling in the wrong department.
The biggest trap on the page: this is only a default for future generation runs. Every look permanently records the scope it was built under, and Rebuild looks deliberately reuses the recorded scope — not today’s setting. Changing Match scope and pressing Rebuild changes nothing. Those looks have to be regenerated.
Rebuild looks (button)
Re-runs matching for every existing look using the current thresholds, candidate count and category matching. It reuses AI detection already on disk, so it costs no AI allowance. It never un-publishes anything, and a rebuild that would produce an empty look is discarded rather than wiping the look you had.
The trap: as above — it does not apply a changed Match scope.
Categories
Match items to the same kind of product — build-time
On, each detected garment is matched only against products of the same kind — tops with tops, shoes with shoes. Off, anything in scope can fill any slot. Leave it on unless you have a specific reason.
Show these detected categories — serve-time
Twelve checkboxes deciding which kinds of detected item may appear on the storefront. Unticking one hides that row from shoppers instantly, with no rebuild.
The traps: ticking every box and ticking none are stored identically (both mean “all allowed”). And if the allow-list empties a look entirely, the widget doesn’t necessarily go blank — the app falls through to a hand-built look for that product if one exists, then to the similar-products fallback if that is on.
When no look can be detected
Show similar products when no look is found — default off
For products whose photo has no model — so no outfit can be detected — this fills the widget with similar products instead of leaving it empty.
The timing is asymmetric, and it catches people out: turning it off hides fallbacks immediately. Turning it on only produces fallbacks for products analysed after the change — products already analysed while it was off have no fallback stored, so they need re-analysing before anything appears.
Keep looks up to date
Refresh my looks when I add new products — default off, paid plans
Lets the app quietly update an existing look when a newly added product is a better match for one of its slots. Off by default on purpose: an approved look shouldn’t change under you without asking. It uses your Similar threshold as the bar a new product must clear, so tightening that makes this fire less often.
Related products — the second widget
This is the “You may also like” row, and it is a separate widget with its own settings. It runs on catalogue data rather than image content, so it works on catalogues where a styled look never will.
- Show the Related products widget — default off. Switching it on kicks off a one-off background build for the whole catalogue, so on a large store the row stays empty for a few minutes.
- Heading — default “You may also like”. Note this heading lives here in the app, unlike the Shop the look heading, which lives in the theme editor.
- Products to show — default 4. Sold-out and off-channel products are skipped at serve time and the row de-duplicates against whatever the look already showed, so the visible count can land under your number.
- Minimum similarity — default 50%, and unlike the Shop the look thresholds this one is serve-time: changes are live instantly. Raise it too far and the row empties.
- Rebuild now — only needed when the content of the similar lists is stale, e.g. after importing a batch of products. Heading, count and minimum similarity never need it.
Save settings
One button saves the whole page. It is disabled — with no explanation beside it — in exactly two cases: the Similar threshold is above the Exact threshold, or every detected-category box is unticked. Saving also doesn’t rebuild anything; the build-time settings still need Rebuild or a fresh generation.
The theme editor settings
The rest of the configuration isn’t in the app at all. The Settings page has deep links that open your published theme on the product template with the right block ready to place. Both widgets have their own block, each with the same design controls: Layout (carousel, grid, or pinned image), Show “Add to cart” buttons, Size / colour picker, Card width (190px), Image shape, Corner rounding, Button style, Heading size and Custom CSS.
Three things worth knowing:
- The Shop the look heading is here, not in the app — the exact opposite of the Related products heading. This is the single most common “where is that setting?” question.
- The two blocks are styled independently. If both sit on one page, match the card width and image shape by hand or the rows won’t line up.
- Pinned image applies to hand-built looks and falls back to the carousel when a look has no pins — choosing it does not turn AI looks into hotspots.
- The deep links always target your published theme and the product template. Working in a draft theme means navigating there yourself.
Generating looks — the per-run choices
The Generate dialog has two controls that are not saved settings. Generate looks for covers either everything in the current view or just the products you ticked — it opens on whichever you came in by. Additional filter overrides Match scope for this run only, pre-filled from your saved default.
Because each look records the scope it was generated under, that per-run override is permanent for those looks. The dialog also now shows what it skipped — products that aren’t Active, and products with no photo. A high skip count there is your real problem, not a setting.
What isn’t a setting
Per-look curation is separate and lives on the look itself: adding an item by category, replacing, removing or reordering cards, publishing one look or all of them, and discarding a hand-built look. Those edits stick — a rebuild deliberately re-applies them rather than overwriting your work.
A sane order to do it in
- Read the readiness card. Fix catalogue problems in Shopify first — no setting compensates for a category with two products in it.
- Set the four build-time settings: Similar match, Candidates per category, Match items to the same kind, Match scope.
- Place both blocks in the theme editor and set the Shop the look heading there.
- Generate looks for a small set first. Review them. Adjust. Only then run the rest.
- Tune the serve-time settings — category allow-list, related-products controls, design — once real looks exist to judge.
Do it with Shop The Look
Merch - Shop The Look ships with working defaults, so the honest answer is that most stores need to change two things before generating: the Match scope, and whether the related-products widget is on. Everything else is tuning you can do once you can see real looks. The readiness card tells you whether the catalogue is ready before you spend a single AI look, and both widgets install as no-code theme app blocks. Live on the Shopify App Store, with plans from a free tier up to Enterprise.
Install on the Shopify App Store →
Frequently asked questions
Which settings must I get right before generating looks?
Four: Similar match (the quality floor), Candidates stored per category, Match items to the same kind, and Match scope. These are applied when a look is built, so changing them later means rebuilding or regenerating.
What is the difference between Exact match and Similar match?
Similar match is the real quality floor — anything below it is dropped and never appears in a look. Exact match only decides how a matched product is labelled inside the app’s own review screen; it’s a triage label for you, not something shoppers see.
Does Rebuild looks apply all my settings?
No. Rebuild applies the thresholds, the candidate count and category matching to looks you already have. A changed Match scope is not applied by Rebuild — every look permanently records the scope it was built under, so a new scope only takes effect on looks you regenerate.
Does the readiness card tell me if my photos will work?
No. It checks that a product has a photo, not what’s in it. A look also needs a photo showing a real person wearing or carrying the items, and that’s only checked later when the look is generated.
Why is the Save settings button greyed out?
Two reasons, neither explained next to the button: the Similar threshold is higher than the Exact threshold, or every detected-category checkbox is unticked. Fix either and it re-enables.
Where is the Shop the look heading set?
In the theme editor on the block itself, not in the app. The Related products heading is the opposite — that one lives in the app’s Settings page. This asymmetry sends a lot of merchants hunting in the wrong place.