ParticleSearch Product Recommendations: Strategies, Placements, Controls, and Evidence
ParticleSearch product recommendations are designed around a merchant decision: what useful next step should appear for this shopping moment, and how will the team know whether the placement worked?
The product supports seven recommendation strategies, explicit product-page and cart placement controls, storefront recommendation blocks, recommendation event states, controlled strategy experiments, and verified-order attribution. This guide explains how those parts fit together, what each choice means, and where merchant judgement still matters.
Why it exists
One generic shelf cannot answer every discovery question
A shopper comparing a sofa needs alternatives. A shopper buying that sofa may need cushions, care products, or coordinated furniture. A shopper with several items in the cart needs a small addition that is not already covered. A shopper opening search without a precise query may need new arrivals or best sellers.
These are different jobs, even when they use the same product-card component. ParticleSearch keeps the strategy and placement explicit so the storefront label, candidate relationship, analytics, and experiment all refer to the same decision.
Moment
What is the shopper doing?
Strategy
Which relationship helps?
Placement
Where is it actionable?
Evidence
What actually happened?
Fit decision
ParticleSearch is useful when the recommendation job needs explicit control and evidence
A store does not need to replace a recommendation surface merely because another product exists. The decision begins with a failed contract: the wrong relationship, insufficient placement control, indistinguishable failure states, or no responsible way to compare strategies.
ParticleSearch is strongest when recommendations should share the same eligible catalogue and product-card truth as storefront search, while giving the merchant a named strategy and an observable placement. It is not a substitute for missing compatibility or unreliable source data.
Situation
The theme already shows useful native related and complementary products
Answer
Keep the existing approach when its relationships, placement, controls, and reporting satisfy the store’s actual tests.
Reason
Replacing a working surface adds operating work without solving a proved problem.
Situation
Different shopping moments need different recommendation jobs
Answer
ParticleSearch is a fit when the team needs named strategies such as similar, complete the look, cart cross-sell, popularity, or newness.
Reason
The strategy, heading, placement, evidence, and experiment can refer to the same merchant decision.
Situation
The team cannot distinguish no candidates from no exposure or delivery failure
Answer
ParticleSearch is a fit when empty, error, view, product action, and verified-order evidence need to remain separate.
Reason
A merchant can investigate the responsible boundary instead of treating every weak report as bad relevance.
Situation
Compatibility or curation must be exact and is not represented in the catalogue
Answer
Repair or curate the relationship source before expecting any recommendation surface to infer it safely.
Reason
ParticleSearch preserves product context and evidence, but it cannot invent a private compatibility fact.
Seven strategies
Choose the strategy by shopper job, not by the most impressive label
The strategy name is a contract with the shopper. It should describe the relationship behind the row and the next action the placement is meant to support.
| Strategy | Job | Context | Watch |
|---|---|---|---|
| Similar products | Help a shopper compare alternatives to the current product. | Current product | Do not confuse broad category membership with substitute suitability. |
| Frequently bought together | Offer products that commonly belong in the same purchase. | Current product and verified store evidence when available | Co-purchase does not replace compatibility facts. |
| Complete the look | Support a coordinated outfit, room, set, or aesthetic. | Current product and catalogue relationships | Style still needs stock, market, size, and practical fit. |
| Cart cross-sell | Find a useful addition not already covered by the basket. | Products already in the cart | The shelf must not repeat cart items or obstruct checkout. |
| Trending | Help an exploratory shopper see products with recent store interest. | Store performance evidence and catalogue | Trend is a discovery signal, not product-to-product similarity. |
| Best sellers | Give broad discovery a dependable popularity path. | Verified store performance when available | Best-selling does not mean complementary or right for every shopper. |
| New arrivals | Show returning or browsing shoppers what changed in the catalogue. | Current eligible catalogue | Newness is the relationship. Label it honestly. |
For a deeper treatment of alternatives and complements, use the similar-products guide and cross-sell guide.
Merchant workflows
Follow one shopping moment from problem to acceptance
The recommendation settings become meaningful only when they connect a merchant problem to a storefront change and a falsifiable test. These workflows show that complete path.
Product-page comparison
Problem
A shopper likes a dining table but needs a smaller footprint or lower price.
Control
Product placement, Similar products strategy, heading “Compare dining tables,” and a restrained product count.
Storefront
The anchor does not repeat. Eligible tables provide real tradeoffs rather than unrelated furniture.
Evidence
Review view, empty, error, product action, and any strategy experiment for the product placement.
Acceptance
Named anchors return expected alternatives, reject coffee tables and duplicates, and remain usable on mobile.
Product-page completion
Problem
A shopper has selected a camera body and may need products that make the purchase usable.
Control
Product placement with Frequently bought together or another verified complement strategy and a precise heading.
Storefront
The row adds compatible products rather than replacing the camera or showing broad best sellers.
Evidence
Inspect recommendation actions and verified order context without assuming the shelf caused the order.
Acceptance
Known incompatible accessories never appear and sparse evidence produces an honest fallback or empty state.
Cart completion
Problem
The basket contains several products and a useful need may remain before checkout.
Control
Cart placement, Cart cross-sell strategy, a small product count, and a heading that describes an addition.
Storefront
Products already in context are excluded and the module does not obscure totals or checkout.
Evidence
Compare visible recommendation actions, direct adds, removals, checkout guardrails, and verified order context.
Acceptance
Changing the cart refreshes the relationship and no existing line is recommended back to the shopper.
Placement
The storefront block and dashboard setting solve different parts of the job
A matching recommendation block must exist in the storefront theme where the shelf should appear. ParticleSearch does not silently insert a product row into an arbitrary part of the theme. That keeps placement and surrounding design under storefront control.
Each supported product or cart placement can remain theme-managed, or the merchant can make the ParticleSearch dashboard the source of truth for the shown state, strategy, heading, and product count. Keeping ownership explicit avoids a common failure where the theme and dashboard appear to disagree because both are assumed to control the same setting.
Theme-managed placement
The storefront editor remains the source of truth for the heading, strategy, and product count.
Dashboard-managed placement
The merchant controls shown state, strategy, heading, and product count from ParticleSearch while the theme block provides the location.
Publish path
Configuration is complete only when the storefront reports the intended state
The visible workflow has two owners. The theme determines where the recommendation block lives. The placement setting determines whether the theme or dashboard owns the strategy, heading, product count, and shown state. Publishing one side without checking the other creates a configuration that looks saved but does not prove a shopper saw it.
Theme block
Place the surface
Ownership
Choose theme or dashboard
Configuration
Set job, heading, and count
Live evidence
Verify view, empty, or error
Use the ParticleSearch launch guide when the recommendation placement is part of a broader storefront rollout.
Controls
Every control changes a named part of the shopper experience
| Control | Scope | What changes |
|---|---|---|
| Recommendations available | Store-wide | Turns recommendation shelves on or off as a storefront capability |
| Placement ownership | Product and cart | Keeps the storefront block as source of truth or moves that placement into dashboard control |
| Shown state | Per managed placement | Hides a placement without deleting its storefront block |
| Strategy | Per managed placement | Chooses the recommendation job for that surface |
| Shelf heading | Per managed placement | Explains the job to the shopper in store language |
| Product count | Per managed placement | Selects 4, 6, 8, 10, or 12 products, subject to eligible results |
| Experiment treatment | Recommendation surface | Compares a named recommendation strategy against another experience |
Product count is a ceiling, not a promise
A placement configured for eight products should not fill the row with ineligible or repeated products merely to reach eight. Fewer credible products are better than a full weak shelf.
Diagnosis from evidence
The observed state tells the merchant where to investigate first
| Observed state | First boundary | Interpretation |
|---|---|---|
| No recommendation module | Theme block or placement availability | Confirm the matching block exists and the intended template owns it. |
| Module exists but is hidden | Store-wide or placement shown state | Check whether recommendations and the managed placement are enabled. |
| Module is empty | Context, eligibility, relationship coverage | Review the strategy, anchor or cart context, product state, and available candidates. |
| Products appear but feel wrong | Strategy contract or catalogue relationship | Compare the heading and expected/prohibited candidates before changing presentation. |
| Products are useful but ignored | Visibility, timing, heading, card evidence, density | Verify the row became visible and the product action is clear on the actual viewport. |
| Clicks exist but revenue is missing | Attribution lineage, reporting window, shopper path | Do not call missing verified revenue zero value; validate the connected order evidence. |
| Attributed revenue exists but the decision is unclear | Causality | Run a controlled recommendation experiment with guardrails when incremental effect matters. |
The recommendation quality guide turns these states into judgement sets, regression checks, and release gates.
Candidate safety
Contextual products do not belong back in the result
On a product page, the anchor product is removed from the visible recommendation set. For contextual strategies, products already represented by the supplied context are also excluded. This prevents the shelf from recommending the item the shopper is already viewing or repeating a product that is already in the cart.
The remaining candidates still depend on the available catalogue, product state, market, and the quality of relationships the store can support. An empty shelf can therefore be the correct result. ParticleSearch records that state separately instead of pretending a broad fallback was an exact relationship.
Observable states
A missing outcome should not be reported as a weak click rate
ParticleSearch keeps delivery, candidate availability, visible exposure, product action, and verified-order attribution distinct. The strategy and placement travel with recommendation evidence so a merchant can compare the right experiences.
View
A recommendation placement produced visible products.
Exposure denominator for recommendation interaction.
Empty
The placement ran but had no visible eligible products.
Find sparse relationships, exclusions, and unsuitable strategy-placement pairs.
Error
The recommendation request did not complete successfully.
Keep delivery failure out of quality and no-candidate analysis.
Product action
A shopper acted on a product from the shelf.
Connect the action to strategy, placement, and available evidence.
Verified-order attribution
A Shopify-verified order total is linked to a verified recommendation touchpoint.
Explain observed revenue paths without claiming causal lift.
Experiments
Compare recommendation strategies without changing search at the same time
ParticleSearch experiments can target the recommendation surface and assign a named recommendation strategy to a variant. A recommendation treatment does not also change search relevance in the same treatment. This keeps the decision interpretable.
Choose one primary metric that matches the job, such as a visible recommendation product action or direct add. Protect empty-module rate, duplicate or incompatible candidates, product-page conversion, cart completion, and verified-order evidence as guardrails. Revenue attached to a verified touchpoint supports interpretation, but it is not automatic proof of incremental revenue.
The ParticleSearch experiments guide explains traffic, variants, decision rules, and evidence thresholds.
What merchants gain
The recommendation workflow no longer has to be a collection of unexplained theme rows
Named jobs
Similar, basket completion, coordinated discovery, popularity, and newness remain separate choices.
Explicit ownership
The team knows whether the theme or ParticleSearch dashboard controls each supported placement.
Honest states
Empty, failed, visible, and interacted placements do not collapse into one engagement number.
Context-aware exclusion
The anchor and supplied contextual products do not return as visible recommendations.
Controlled comparison
Strategy experiments can answer a defined recommendation question without bundling a search change.
Verified revenue context
Order totals appear only when Shopify order evidence and recommendation touchpoint lineage can be connected.
Launch acceptance
Approve the placement with evidence from the actual catalogue
Boundaries
What ParticleSearch does not decide for the merchant
ParticleSearch cannot know an undocumented compatibility rule, repair a misleading product attribute by presentation alone, or decide whether a recommendation relationship is acceptable for the store’s return risk. Those facts belong in catalogue data, merchant curation, and the acceptance set.
It also does not treat attributed revenue as guaranteed lift. The product makes the strategy, placement, event state, experiment variant, and verified-order connection visible so the team can make a better decision without exposing the system’s internal implementation.
Product evidence checked July 30, 2026
ParticleSearch widget recommendation blocks, recommendation settings, product and cart placement controls, strategy treatments, analytics states, and verified-order attribution contracts were inspected across the current widget, dashboard, and backend repositories. This article describes merchant-visible behaviour and omits implementation details.
Review the recommendations feature page or start with the complete recommendation strategy pillar.