Skip to article
ParticleSearch Guides 2026-07-2936 min read

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.

StrategyJobContextWatch
Similar productsHelp a shopper compare alternatives to the current product.Current productDo not confuse broad category membership with substitute suitability.
Frequently bought togetherOffer products that commonly belong in the same purchase.Current product and verified store evidence when availableCo-purchase does not replace compatibility facts.
Complete the lookSupport a coordinated outfit, room, set, or aesthetic.Current product and catalogue relationshipsStyle still needs stock, market, size, and practical fit.
Cart cross-sellFind a useful addition not already covered by the basket.Products already in the cartThe shelf must not repeat cart items or obstruct checkout.
TrendingHelp an exploratory shopper see products with recent store interest.Store performance evidence and catalogueTrend is a discovery signal, not product-to-product similarity.
Best sellersGive broad discovery a dependable popularity path.Verified store performance when availableBest-selling does not mean complementary or right for every shopper.
New arrivalsShow returning or browsing shoppers what changed in the catalogue.Current eligible catalogueNewness 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.

1

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.

2

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.

3

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

ControlScopeWhat changes
Recommendations availableStore-wideTurns recommendation shelves on or off as a storefront capability
Placement ownershipProduct and cartKeeps the storefront block as source of truth or moves that placement into dashboard control
Shown statePer managed placementHides a placement without deleting its storefront block
StrategyPer managed placementChooses the recommendation job for that surface
Shelf headingPer managed placementExplains the job to the shopper in store language
Product countPer managed placementSelects 4, 6, 8, 10, or 12 products, subject to eligible results
Experiment treatmentRecommendation surfaceCompares 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 stateFirst boundaryInterpretation
No recommendation moduleTheme block or placement availabilityConfirm the matching block exists and the intended template owns it.
Module exists but is hiddenStore-wide or placement shown stateCheck whether recommendations and the managed placement are enabled.
Module is emptyContext, eligibility, relationship coverageReview the strategy, anchor or cart context, product state, and available candidates.
Products appear but feel wrongStrategy contract or catalogue relationshipCompare the heading and expected/prohibited candidates before changing presentation.
Products are useful but ignoredVisibility, timing, heading, card evidence, densityVerify the row became visible and the product action is clear on the actual viewport.
Clicks exist but revenue is missingAttribution lineage, reporting window, shopper pathDo not call missing verified revenue zero value; validate the connected order evidence.
Attributed revenue exists but the decision is unclearCausalityRun 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

The matching recommendation block exists on the intended theme template.
The placement is controlled by the intended source: theme or ParticleSearch dashboard.
The heading accurately describes the chosen strategy.
The current product and products already in context do not repeat in the visible shelf.
Products are purchasable in the active storefront context.
Desktop and mobile cards expose the information and action the shopper needs.
Empty, error, visible, and interacted placements remain distinguishable in analytics.
The team has named anchors or carts with expected and prohibited candidates.
Any experiment has one primary decision metric and explicit guardrails.

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.