Guided Selling: Quizzes, Finders and Routine Builders on Shopify

Definition

Diagnostic quizzes and product finders that turn answers into a recommended routine — questions and rules authored as metaobjects, matching run client-side, results captured into the ESP. Also covers integrating third-party quiz and skin-analysis engines and instrumenting them as measurable funnel steps.

The Evidence

• Evidence strength: 8 live, Deploi-authored builds across 3 Shopify storefronts.
• Split by storefront: LUS Brands 3, Three Ships 3, Nudestix 2.
• Split by attribution: all 8 Deploi-authored — no vendor theme code in this set.
• Evidence quality: three carry code plus client working records. Five are documented from the code; no client-side record of the decision survives.
• Confidence: 2 strong, 6 moderate.
• Surfaces: a dedicated quiz page, product pages, landing pages, home.
• Status: Live, verified 2026-09-06.

Eight is the smallest evidence base of the hubs published so far. It is not thin — the qualifier band starts at three — but it is a depth claim rather than a breadth claim, and it rests mostly on one storefront. Read it that way.

How It's Actually Built

The interesting build here is not a quiz. It is a quiz whose entire content model is Shopify data.

On LUS Brands the curl quiz is six metaobject definitions and no metafields: curl_quiz holds the quiz, curl_quiz_question the nine questions, curl_quiz_option the answers, curl_quiz_logic_rule the recommendation rules, curl_quiz_product_recommendation the products those rules resolve to, and curl_quiz_result_section the groups they land in — 103 entries in all. curl-quiz.liquid reads the quiz entry and renders one pane per question, projecting every behavioural rule onto data attributes the controller reads: data-cq-selection-type, data-cq-min, data-cq-max, and per option data-cq-option-key and data-cq-exclusive. The section carries one theme-editor setting, the quiz handle. Everything else a merchandiser changes, they change in the admin.

Quiz and results are two separate sections joined by a contract rather than a call. Completion dispatches a window-level curl-quiz:results event, and answers are mirrored into the querystring as cq_<question_key>=opt1,opt2 through history.replaceState. That one decision lets the halves be placed independently in the theme editor, lets a resumed link replay into the right step, and makes a finished routine a shareable URL that reconstructs itself with no backend behind it.

The recommendation half is where the engineering is. Rule entries are evaluated against three predicates — every requiredOptions present, at least one anyOptions present where that list is non-empty, no blockedOptions present — sorted by an explicit priority rather than first-match-wins. The 34 live rules sit in bands: foundation at 10–13, challenges at 100–105, goals at 200–205, the porosity-and-strand moisture chain at 300–305, hold at 400–405, scalp and fragrance at 500–505, so a new rule slots into a band without disturbing its neighbours. Suppression is data rather than code — the fragrance-free exclusion that hides the scalp scrub is a blockedOptions list a brand team can edit.

The rendering underneath is why the results are real commerce and not a summary screen. Liquid pre-renders every possible recommendation once, at page load, into <template data-recommendation-template> elements — each a full {% render 'card-product' %} with quick add enabled — and serialises the rule graph into a <script type="application/json"> block. The controller clones the survivors into their result groups, de-duplicated by recommendation key and again by product id, so two rules resolving to the same product yield one tile. Price, currency, availability and quick add stay server-rendered and correct, and the branching costs no request.

The rule set is verified rather than trusted, by a harness described under "Where this gets hard" below.

Nudestix is the other pattern, and the engine is not ours. A licensed shade-matching quiz runs on the product page, and what the theme owns is which products offer it and what it reports. A per-product metafield decides where the Shade Finder button appears, so adding a product to the finder is a merchandising action in the admin rather than a code change. It opens in a native <dialog> sized from section settings per breakpoint. Measurement is the other half: a message listener validates the sender's origin before pushing a shade_finder_interaction event carrying the action and the matched shade.

The Buy-vs-Build Position

The corpus records no single verdict for this capability, and the reason is honest: the three storefronts landed in different places. On LUS Brands the engine is theme-native and the answer-to-product mapping is Shopify data the client owns and can export. On Nudestix the quiz itself stays licensed and what we built is the gate and the measurement around it. On Three Ships our published work in this capability is the entry points and a tabbed gift finder — not an engine.

That spread is the argument, not an inconsistency. Hosted quiz platforms are a genuinely good buy: they ship an authoring UI, analytics and a support line, and for most catalogues the mapping is simple enough that the vendor dashboard is the right place for it. What made building defensible on one storefront was that the mapping was still being negotiated while the theme was in development, that it is conditional in several directions at once, and that it had to stay editable by the brand team without a deploy. Our full reasoning is on the product quiz and finder decision page.

The Builds

Four of the 8 have published pages. Three of the rest — the shade-finder integration and its GA4 instrumentation, the tabbed holiday gift finder and the press strip used on the quiz landing page — are documented and will follow. The fourth folds into a build page already published here.

LUS Brands

• Curl Quiz 3.0: a nine-step diagnostic quiz rendered entirely from Shopify metaobjects — questions, options and selection rules as metaobject entries, with URL state and a resumable step ladder. High complexity, quiz page.
• Quiz results: a 34-rule, priority-ordered recommendation engine running client-side from metaobject data — required/any/blocked matching over pre-rendered Liquid product cards, with the routine pushed to the ESP on completion. High complexity, quiz page.

Nudestix

• Grouped shade swatch picker with shade-finder dialog and GA4 shade-finder events — a licensed shade quiz gated by metafield and instrumented as a funnel step next to the swatch picker. High complexity, product page.

Three Ships

• Skin quiz entry-point sections: separate desktop and mobile artwork in one section — art-directed quiz CTA panels with separate desktop and mobile artwork, re-shootable per campaign without a developer. Low complexity, landing and home.

What This Rests On

• Metaobjects — the whole content model: questions, options, rules, recommendations, result groups.
• Liquid section schema and settings — deliberately sparse; one setting on the quiz section is the point.
• Metafields — the per-product gate deciding which products offer a finder.
• Custom elements and History API — the pane controller, and the querystring that makes a result a link.
• Cart AJAX API — quick add on the recommended cards.
• Analytics event layer — the theme-side push that turns a third-party quiz into a measurable funnel step rather than a black box.
• Klaviyo — the ESP the completed routine is tracked into, wired at section level rather than through an app block.

What Varies by Storefront

Theme base matters least here, which is unusual. LUS Brands runs Dawn 15.4.1, Nudestix Dawn 6.0.2, Three Ships Palo Alto 5.8.0 by Presidio Creative, a paid premium theme — but all 8 builds are Deploi-authored sections rather than modifications of vendor code, because a quiz is a new surface rather than an extension of an existing one.

What varies is what the answers resolve to. Haircare rewards a rules engine: strand thickness, density, porosity and curl pattern interact, the recommendation is conditional in several directions at once, and the same product can be reached by more than one path — which is why de-duplication by product id exists at all. Colour cosmetics is a different shape. There is one question, "which shade suits me", it is answered visually, and the answer is a variant rather than a routine, so the guided-selling work sits beside the swatch picker instead of on its own page and the sensible build is the gate and the measurement around a specialist engine. Skincare is a third shape, where the quiz is an acquisition funnel and the theme-side work is the entry point, the art direction and a tabbed finder reusing the site's existing routine merchandising.

The last difference is who owns the content. Questions in metaobjects are edited by whoever has admin access; a licensed engine is edited in the vendor's dashboard. Neither is wrong, but they hand the ongoing job to different people, and that is worth deciding before the build.

Where This Gets Hard

A rule set is a product that needs an owner. Nine questions and 34 rules is already a matrix nobody holds in their head, and each new product, question or answer option multiplies the interactions rather than adding to them. The only way we found to keep it honest was a validation harness that re-implements the same matcher and the same two-stage de-duplication against a snapshot of the live metaobject data, pinning behavioural cases beside config-integrity assertions — including the two-sided scalp case, where one fragrance answer must include the scalp scrub and the other must exclude it. Beside it sits a generated expectation table listing, per answer option, every rule it can trigger and the products that result; that table is what the brand team signs off against. Both are real work and ongoing work — a rule added without re-running them is a rule nobody has checked.

A quiz also cannot be better than the catalogue behind it. If every need maps to one obvious product, a diagnostic quiz is a decorative funnel: nine questions to arrive somewhere the collection page already offered. This one earns its place because fragrance preference decides which system is shown at all, porosity crossed with strand thickness decides the moisture product, and one answer suppresses a product outright.

It is also a permanent merchandising surface, not a launch. Someone adds the rule when a product ships, retires it when the product goes, and re-checks the expectations when a question is reworded — the recurring cost most often left out of the estimate.

So we advise against building this more often than the page above implies. If your mapping is a lookup table rather than a conditional graph, buy the quiz — a hosted platform is faster and you will not be maintaining a matcher. If nobody will own the rules after launch, buy it too: a vendor dashboard fails more visibly than a rule set that quietly stops matching. Build when the mapping is genuinely conditional, when it has to change without a deploy, and when it matters that the logic stays in Shopify where you can export it.

Related Capabilities

• Variant swatches and shade pickers — where the shade finder sits.
• Filters, faceted navigation and progressive grid loading — the other way a shopper narrows a catalogue, and the one to try first.
• Collection merchandising and product rails — the card components a results page reuses.
• Metafield-driven PDP content blocks — the same "content is data, not code" pattern on the product page.

Answers to Help You Make Smart Decisions

Can you build a product quiz on Shopify without an app? Yes. On one storefront here the questions, answer options, recommendation rules and result groups are Shopify metaobject entries, and the theme renders the quiz from them — one section setting, no vendor script. The trade is that the theme now owns the step logic, the matcher and the recommendation contract, all of which a hosted platform would have owned instead.

Where should the answer-to-product mapping live? Wherever the people who change it can reach it. In metaobjects it stays in Shopify, exports with your data, and survives a theme change; in a vendor dashboard it is easier to author and it leaves with the vendor. Pick on who owns merchandising, not on which is more technical.

Do quiz results have to be a separate page load? No. Here the quiz publishes a browser event and encodes its answers in the URL, and the results section listens for it — so results render instantly, and a completed routine is a shareable link that rebuilds itself. It works because Liquid pre-renders every possible recommendation card up front and the browser only chooses between them.

How do you measure a third-party quiz you didn't build? Through the message channel it already uses. On one storefront the embedded engine posts its results to the page, the theme validates the sender's origin, then pushes an analytics event carrying the action and the matched result — so every step from opening the quiz to seeing a match is measurable, not just completion.

Ready to Find Out Whether Your Catalogue Needs a Quiz?

Half the quizzes we're asked to build are answered better by a good filter. Contact us today and we'll tell you which one yours is — and if it really is a quiz, where the rules should live.