Search Impact 2026-06-30 33 min read

How to Validate ParticleSearch on Your Shopify Store: A Query-by-Query Test Plan

Do not evaluate ParticleSearch from a feature checklist. Evaluate it against the buying paths your current search must support, using known products, variants, queries and expected outcomes.

ParticleSearch supports broad product and variant field coverage, exact identifier treatment, filters, variant-aware results, no-result recovery and search-linked reporting. These merchant-visible capabilities were checked on July 28, 2026. This guide shows how to verify that they work with your catalog, settings and theme.

A valid product test has four layers

Catalog evidence

Does the source contain the identity, attributes and state the buyer needs?

Keep: Product and variant IDs plus expected values

Search behavior

Does the request retrieve and order the right records under the intended context?

Keep: Request, response, matched fields and positions

Storefront behavior

Does the visible card and destination preserve the returned product and variant?

Keep: Card, URL, product page and cart evidence

Measurement

Can the team explain what the shopper saw and did?

Keep: Search-linked impressions, actions and coverage

Chapter 1 · Build the acceptance set

Choose queries that represent real catalog jobs

Start with actual store queries, support cases and known product-finding tasks. Add exact positives, useful substitutes where appropriate, hard negatives and boundary cases. A demo query that happens to work does not establish search quality.

For each query, record the expected product or graded result set, the required variant, important constraints, allowed substitutions, market, locale and storefront surface. Freeze this sheet before tuning so the expected answer does not move to match the output.

Query family	Input	Expected	Negative or boundary
Exact product	A unique current product title	The product appears at the first defensible position.	Old title, duplicate parent or unpublished record
Identifier	A unique SKU, barcode, model or part number	The matching product and variant appear without fuzzy displacement.	Punctuation changes and a near-collision
Attribute	A term unique to description, tag or a configured searchable metafield	The intended product is retrieved for the field that contains the evidence.	A similar product without the required attribute
Multi-constraint	Product type plus material, compatibility and option	Each returned product or variant satisfies the important constraints.	A cross-variant combination no single variant satisfies
Broad discovery	A short category or use-case query	The set is useful, diverse and ordered under the declared policy.	One brand, family or unavailable set dominating
No-result boundary	A real failed query plus a nonsense query	The real query receives bounded help; nonsense does not become false confidence.	Recovery presented as an exact match

Use acceptance criteria, not a pass percentage borrowed from another store. An exact part-number lookup can require zero identity mistakes, while a broad discovery query can use graded relevance. Set the consequence-aware threshold before testing.

Chapter 2 · Test identifier retrieval

An exact identifier should protect identity before discovery

ParticleSearch treats identifier-shaped queries differently from broad discovery so an exact SKU, barcode or part number can protect product and variant identity. Verify the full path with identifiers from your catalog, including punctuation changes and near-collisions.

Canonical

PM-12V-5A

Confirm exact searchable identity and matched variant.

Punctuation removed

PM12V5A

Measure normalization without assuming it for every identifier style.

Partial

12V-5A

Decide whether partial lookup is useful or dangerously ambiguous.

Near-collision

PM-12V-5B

Verify typo or semantic behavior cannot displace an exact neighbor.

Wrong resource

A product handle or internal ID

Confirm unsupported identifiers do not create misleading matches.

Pass condition

The exact available variant is returned first, the response identifies it, the card does not substitute another variant, and the destination and cart preserve it.

Investigate when

The parent is correct but the variant is wrong, punctuation changes identity, a near-collision outranks an exact match, or a broad semantic neighbor is presented as the answer.

The Shopify SKU Search guide explains how to build a collision-aware identifier test set.

Chapter 3 · Test field coverage

Test one unique value per required field

ParticleSearch can use product and variant identity, titles, descriptive fields, option data, collections, commerce state and configured metafields. Do not translate that into “every field is searchable.” The merchant’s field choices and available source values determine what is active.

Choose a value that exists in only one candidate field. Then compare the Shopify source with the search response and visible result. A successful title match cannot prove that the description or metafield is working.

Field	Source check	Query check	A failure can mean
Product title	Unique phrase exists in the current title.	Exact and shortened title retrieve the expected product.	Eligibility, provider, tokenization or ranking may be wrong.
Variant SKU or barcode	Unique value belongs to one variant.	Result returns the parent with that variant preserved.	Variant identity, field mapping or identifier policy may be wrong.
Description or tags	The term appears only in the intended field.	Result appears with title evidence unable to explain the match.	The field may be absent, unsearchable, weakly weighted or stale.
Configured product metafield	Definition, resource, type and value are known.	A unique value retrieves the correct product.	Field selection, store configuration or freshness may be wrong.
Configured variant metafield	Value belongs to one variant, not only the parent.	Result and destination preserve the matching variant.	Variant-level indexing or storefront handoff may be wrong.

Use the Shopify metafield search diagnostic when a configured field exists but cannot retrieve the expected product.

Chapter 4 · Test filters and scope

A filter passes only when values, counts, results and URL state agree

ParticleSearch exposes configured storefront filters and sorting controls, with counts based on the active result set. Test the allowed controls, combinations, empty intersections and shopper experience together.

Single facet

Apply one known vendor, option, collection, availability or price constraint.

Pass: Each result satisfies it and the active state remains visible.

Two facets

Combine constraints with a known non-empty intersection.

Pass: Counts and results update from the constrained set.

Empty intersection

Combine two valid values that no product satisfies together.

Pass: The UI explains the empty state and offers a bounded way to relax it.

Collection scope

Run the same query inside and outside a collection.

Pass: Collection scope changes the set without leaking products from another collection.

Unavailable boundary

Test sellable, unavailable and continue-selling variants under the store policy.

Pass: Filtering and badges agree with the destination and cart.

Unsupported field

Try a filter or sort option that is not enabled for the storefront.

Pass: The interface does not expose or silently apply an unsupported control.

The Faceted Navigation Guide covers facet selection, counts, empty intersections, mobile controls and analytics in depth.

Chapter 5 · Test variant handoff

Follow one variant from query to cart

ParticleSearch can group variants under a product while preserving the variant that matched the query, including its commercial state and destination. The storefront must still preserve that record.

Query

The term points to one SKU, barcode, option or compatibility value.

Identity: Expected variant ID

Response

Matched variant data explains why the parent product was returned.

Identity: Returned variant ID

Card

Image, price, compare-at price and stock correspond to that variant or a labeled product summary.

Identity: Visible variant state

Destination

The product page opens the same variant explicitly.

Identity: Selected variant ID

Cart

The line item is the intended merchandise record with the expected price and eligibility.

Identity: Cart variant ID

A parent-product match is not enough. Fail the test when an exact variant query opens another option, changes image or price without explanation, shows a different availability state, or adds the wrong line to cart.

Use the wrong-price and stock data-path diagnostic when the returned identity is right but commercial values diverge.

Chapter 6 · Test no-result recovery

Recovery should help without pretending the original query succeeded

ParticleSearch can offer a correction, disclose a relaxed filter, or show a broader recovery when the primary result set is empty. The storefront should explain what changed and reporting should preserve the distinction.

Misspelling with an obvious intended term

Acceptable: A correction is visible, reversible and measured separately from the original query.

Reject: The system silently changes the query and reports the result as an exact success.

Over-constrained filters

Acceptable: The UI names the active constraints and offers to remove a specific one.

Reject: The experience removes filters without telling the shopper what changed.

No lexical candidates

Acceptable: A broader recovery appears only when it remains useful and is labeled as related or recovered.

Reject: Semantically adjacent products imply the requested item exists.

Nonsense or unsupported identifier

Acceptable: A clear empty state, query-editing path and relevant navigation.

Reject: Popular products are presented as if they satisfy the query.

The zero-results recovery guide covers interface states and cause-matched recovery.

Chapter 7 · Test analytics lineage

Prove the event chain before trusting the dashboard

ParticleSearch reporting can connect visible results with clicks, refinements, filters, cart actions and available order touchpoints. Test each transition and calculate coverage before interpreting missing events as missing engagement.

Event stage	Identity and context	Controlled test
Search response	Query reference, visible products, variants and positions	Run a controlled search and confirm the result view appears in reporting.
Viewport impression	Visible product, position, duration, availability and price context	Scroll results and confirm only actually visible records are counted.
Click	Query reference, product or variant, position and destination	Click a lower result and confirm its position is preserved.
Filter or refinement	Previous and new search state, applied filters or changed query	Change one constraint and confirm the new state links to the previous one.
Add to cart	Search lineage, product, variant, quantity and visible commercial context	Use quick add and product-page add separately.
Order touchpoint	Order line connected to stored search interaction when available	Confirm event delivery, consent and the declared attribution boundary.

Do not use attributed revenue as proof of incrementality. It describes a recorded association under the chosen identity and window. Use the Ecommerce Search Analytics Guide to separate instrumentation, attribution and experimentation.

Chapter 8 · Test the visible experience

A correct API response can still produce an unusable storefront

Run the experience checks on the target theme, devices and navigation paths. The goal is not a perfect demo route. It is a reliable search modal and results page under the store’s real layout, content and traffic conditions.

Keyboard

Open search, type, move focus through interactive controls, choose a result, close and return focus without a pointer.

Screen reader

Confirm input naming, result-count announcements, selected filters, loading, empty and corrected states.

Mobile layout

Test search, filters, sorting, long titles, price ranges, virtual keyboard and result continuation at narrow widths.

Network and loading

Throttle the request and verify a stable loading state, stale-response protection and actionable error state.

Navigation

Use back, forward, refresh and copied URLs. Query, filters, sort and scroll expectations should remain coherent.

Performance

Measure the experience on the target theme and device mix. Do not substitute an API response time for visible usability.

The search modal UX guide and search results page guide provide state-by-state interface acceptance criteria.

Chapter 9 · Decide with release gates

Approve the store behavior, not the feature list

A store is ready when the acceptance set, commercial context, visible experience, event coverage and rollback path meet explicit standards. A capability can remain useful even when one gate needs work, but the unresolved boundary should be owned and visible before launch.

Gate	Required evidence	Owner
Relevance	Judged query set meets the store’s exact, attribute, broad and negative criteria.	Search and merchandising
Variant integrity	Matched variants survive response, card, destination and cart.	Search and storefront
Commercial accuracy	Market, currency, price, sale and availability remain consistent.	Commerce operations
Freshness	Create, update, inventory and removal paths meet measured store thresholds.	Integration
Experience	Loading, empty, error, mobile, keyboard and navigation states are usable.	Storefront
Measurement	Event coverage and lineage are known; gaps are not misread as shopper behavior.	Analytics
Rollback	A tested way to disable or bypass the integration restores a known storefront path.	Release owner

The ParticleSearch architecture guide explains the merchant-visible data and experience boundaries behind these tests. Review current product capabilities and the ParticleSearch data path alongside the store-specific evidence before making the release decision.