The advisor starts with an approved product set

An advisor uses an owned catalogue or eligible saved website products and prepares its own product snapshot. Selecting already imported products is not the same as starting another website scrape. Product identity, URL, image, usable positive price, currency, and processing readiness are checked before a product can qualify for the reviewed creation runtime. A saved row that failed processing must not silently become a recommendation.

Where attributes come from

Structured product data, offers, metadata, supported page text, and connector attributes can supply product fields. Exact source identity matters: an accessory description should not contaminate the identity of the main product. A value inferred from a general category is weaker than an explicit model specification. Review material differences such as compatibility, revision, layout, capacity, and pack size before approving the offer set.

Useful questions need product variation

The default question builder derives questions from usable attributes in the selected catalogue, with budget ranges based on actual product prices. Questions should distinguish products rather than ask shoppers about attributes that never vary. The applicable question set can adapt to a selected category. Optional AI-generated question proposals are a separate configured workflow: proposals still need validation against real attributes and options rather than inventing catalogue facts.

Requirements versus preferences

Hard requirements exclude products that cannot satisfy the selected answer. Weighted preferences rank otherwise eligible products according to supported matches. An unanswered optional or neutral preference is different from an invalid choice. Unknown compatibility is not proof of compatibility, and an in-stock filter requires a positive stock field in the snapshot. The current snapshot can still be older than the live store.

The reviewed ranking path

In the versioned creation runtime, approved and eligible products first pass applicable requirements. Weighted taste preferences then contribute ranking evidence; ties use a stable product identity order. For mapped preferences, a supported match adds the question's bounded weight and a supported mismatch subtracts it. For inferred taste affinities, coverage and reliability dampen the contribution. This internal ranking is not a shopper-facing probability of suitability.

Example
Simplified recommendation path
selected catalogue snapshot
  -> approved + eligible products
  -> configured availability gate
  -> applicable requirement matches
  -> weighted preference score
  -> stable ordering and configured result count

No fitting product is an honest result.
Do not silently remove a compatibility requirement to force a recommendation.

Draft, preview, and published state

A draft stores configuration and revision state so edits can be resumed. Preview tests the current questions and mappings. Publishing validates and commits the intended configuration as a coherent release; it is not equivalent to saving an incomplete draft. Public configuration excludes private draft notes and operational metadata. Re-test after changing the catalogue, questions, mappings, or rules.

Test boundary cases

Test a shopper with a clear supported match, a valid preference with several matches, an impossible requirement, a missing attribute, a revised answer after going back, a narrow budget, and a product whose availability changed. Inspect the actual product URL and price source. A high-quality advisor should explain why it recommends a product without inventing a percentage match or silently relaxing a hard constraint.

Design advisor rules and test recommendationsProduct Advisor sessions, choices, and abandonment analyticsThe advisor shows no suitable products