'%20clip-path='url(%23canvas-clip)'/%3e%3cg%20clip-path='url(%23canvas-clip)'%3e%3cg%20transform='rotate(0,%20256,%20256)'%3e%3cg%20transform='translate(87%2087)%20scale(14.083333333333334%2014.083333333333334)%20translate(0%200)'%3e%3cpath%20fill='none'%20stroke='%23FFFFFF'%20stroke-linecap='round'%20stroke-linejoin='round'%20stroke-width='2'%20d='m18.064%2010.877l-4.89-7.26c-.42-.625-1.287-.803-1.936-.397a1.4%201.4%200%200%200-.41.397l-4.893%207.26C4.24%2013.715%204.9%2017.318%207.502%2019.423a7.13%207.13%200%200%200%204.168%201.572M15%2018a3%203%200%201%200%206%200a3%203%200%201%200-6%200m5.2%202.2L22%2022'/%3e%3c/g%3e%3c/g%3e%3c/g%3e%3c/svg%3e)
ParticleSearch Search Analytics: Turn Shopper Queries into a Review Queue
Search analytics should help a merchant decide what to inspect next. A large query list or a conversion percentage is not enough. You need to know what was measured, where the shopper stopped, whether the pattern repeats, and which intervention fits the evidence.
ParticleSearch organises that work around shopper searches, request executions, returned products, product actions, quality goals, Fixes, and follow-up. This guide explains how to read those signals without turning correlation into a story the data cannot support.
A repeated query with no product action is a question, not a verdict. The results may be wrong, the cards may hide the deciding attribute, the shopper may have learned the price without clicking, or the event may be missing. The dashboard narrows where to inspect; the storefront replay and catalogue evidence explain what happened.
Dashboard behaviour checked August 4, 2026. The interface and metric contracts in this guide were verified against the current ParticleSearch dashboard and product code. Available history and figures depend on the store, selected period, installed surfaces, consent state, and recorded events.
Chapter 1 · The dashboard's job
The dashboard turns recorded behavior into a review queue
A report describes what the system recorded. A review queue helps someone act. The ParticleSearch overview brings both together: performance context explains the period, while recurring query evidence points toward work that may deserve attention.
The distinction matters. A single search with no action may be noise, research, a bot, an accidental query, or a legitimate failure. Repetition and supporting evidence make the case stronger, but a merchant still decides what the query means.
Overview signal
Shopper searches and requests
Question
How much committed demand and storefront search work exists in this period?
How to read it
A shopper search is a query left stable long enough to view or followed by a product action. Request executions include intermediate typing, filters, pages, and refinements. One shopper journey can generate several requests.
Next move
Open Performance for the trend or Queries for the wording behind the total.
Overview signal
Quality goal
Question
Which measurable direction has the store team chosen to improve?
How to read it
The published goal compares the current request-based zero-result, products-found, or click-through rate with a target. It is a progress aid, not causation or diagnosis.
Next move
Check the denominator and guardrails, then inspect query-level evidence before changing search.
Overview signal
Products found
Question
How often did the primary search return at least one eligible product?
How to read it
This separates an empty retrieval problem from a post-result problem. It does not say that the returned products were relevant, visible early, or commercially useful.
Next move
Open Queries for no-result and thin-result rows, then inspect the live product set.
Overview signal
Product actions
Question
Did shoppers open a result or add directly from a ParticleSearch surface?
How to read it
Product opens and direct adds are stronger evidence than products being served. They still describe observed actions, not the shopper’s reason for acting or leaving.
Next move
Open Products to see which items received actions and Queries to see which wording led there.
Overview signal
Fixes review queue
Question
Which repeated search patterns have enough evidence for a merchant look?
How to read it
Fixes represents repeated observations, not an automatic to-do list. ParticleSearch can watch demand and measure published changes, while ranking and catalogue changes still wait for merchant review.
Next move
Inspect one query, record the diagnosis, and choose catalog repair, a focused control, or no change.
Overview signal
Index and event health
Question
Can the dashboard and storefront evidence be trusted right now?
How to read it
A stale catalog, unhealthy storefront delivery, or missing event contract can explain a metric change before shopper behavior does.
Next move
Resolve operational health before comparing periods or publishing a search rule.
Quality goal
Give the team one measurable direction.
Choose zero-result rate, products-found rate, or search click-through. Refine the target locally, then publish it as a durable store goal.
Current
Observed rate
Check the request-based definition and evidence window.
Target
Chosen direction
Add relevance and protected-query guardrails.
Status
Prompt to inspect
On track is not proof of causation or quality.
Demand monitor
Repeated issues wait until the evidence is strong enough to justify merchant attention.
Proof loop
Published search changes remain under observation before another decision is suggested.
Regression protection
Protected searches preserve proven winners while aggregate metrics change.
Observe
A query settles into a committed shopper search while requests render products, filters, pages, and refinements.
Qualify
The dashboard separates demand from request work, then surfaces repeated patterns only when enough evidence supports review.
Inspect
A merchant opens the query, checks returned products, catalog coverage, intent, and storefront behavior.
Choose
The smallest responsible action may be catalog repair, ranking, a true synonym, a redirect, or no change.
Follow up
After publishing or repairing data, the proof loop observes comparable evidence while protected searches guard known winners.
The short answer
Use the dashboard to choose one repair, not to admire a score
The right operating sequence is simple: check whether the evidence is trustworthy, find one repeated shopper pattern, inspect the live result and source data, then choose the smallest change that could resolve it.
That is why ParticleSearch puts health, queries, products, fixes, query tools, and follow-up in the same workflow. The dashboard is not claiming to know the shopper’s intent. It shortens the distance between a measured signal and a decision a merchant can explain.
01
Trust the evidence
Confirm health, period, event scope, and catalog freshness.
02
Inspect one pattern
Open the query or product and reproduce the visible result.
03
Change one layer
Repair data, adjust a control, test presentation, or make no change.
Chapter 2 · Metric contracts
Read the definition before you read the number
Analytics terms often sound broader than the events behind them. Use these contracts when you discuss performance internally, compare periods, or decide whether a query needs work.
Shopper searches
Committed search journeys
Queries left stable long enough to view or followed by a product action. This is a demand unit, not a count of unique people.
Use it to
Use it to distinguish deliberate shopper search journeys from intermediate system work.
Do not infer
Do not describe it as people, sessions, purchases, or every request execution.
Request executions
Typing and refinement work
Search requests recorded while shoppers type, filter, paginate, or refine. Current products-found and action rates remain request-based for historical comparability during rollout.
Use it to
Use it for instrumentation, operating context, and the denominator of current request-based rates.
Do not infer
Do not treat each request as a separate shopper decision.
Products found
Searches with a result
Recorded searches that returned at least one eligible product in the measured search surface.
Use it to
Use it to separate retrieval failures from post-result problems.
Do not infer
Do not assume every returned result was visible, useful, or relevant.
Product actions
Opens and direct adds
Product opens and direct add-to-cart actions recorded from ParticleSearch surfaces.
Use it to
Use them as stronger signals than result delivery alone.
Do not infer
Do not treat no action as proof that every returned product was wrong.
Attributed value
Associated orders
Order value associated with a recorded search journey under the active attribution rules.
Use it to
Use it to inspect paths and prioritize follow-up.
Do not infer
Do not call it causal revenue lift without a controlled comparison.
Two measurements need extra care. Engine processing time is not the full delay a shopper experiences. Network, rendering, imagery, theme code, and device performance also affect visible speed.
Attributed order value is an association under a defined window. It can help prioritize journeys and commercial questions, but it does not prove that search caused the order or that a rule caused incremental revenue.
Chapter 3 · Diagnose the pattern
The same metric can lead to different repairs
Start with the observed pattern, then ask the question that can separate its plausible causes. The final column is a review path, not an automatic recommendation.
Observed pattern
Repeated searches, no products found
Ask first
Does the catalog contain an eligible product with searchable source data?
Review path
Catalog coverage, search wording, or an intentional no-result state
Observed pattern
Products found, almost no product actions
Ask first
Are useful products visible early and presented with enough decision information?
Review path
Inspect relevance, result order, card state, price, availability, and query intent
Observed pattern
A result opens, but the buyer does not continue
Ask first
Did search hand off the right product or variant, and does the product page keep the promise?
Review path
Product detail, variant identity, availability, or downstream UX
Observed pattern
Navigation language repeats
Ask first
Is the shopper asking for a destination rather than a ranked product set?
Review path
Consider a tightly scoped redirect
Observed pattern
Searches succeed but filters are rarely used
Ask first
Are filters relevant, visible, correctly counted, and understandable for this result set?
Review path
Filter configuration, labeling, mobile access, or no change if filters are unnecessary
A no-action query is not a failed query by definition. The shopper may have read enough on the card, changed the query, left for reasons outside search, or encountered a relevance problem. Inspect the returned products and the visible storefront state before choosing a fix.
Demo evidence: “table”
In the July 28 demo capture, “table” represented 25 recorded search events and was selected as the next query to inspect. The dashboard did not prescribe a ranking rule. It asked the merchant to review what appears first and decide whether the products need stronger ordering or better presentation.
That distinction is the product design. Repeated demand earns attention. The returned products, their order, source data, availability, and visible cards determine the intervention. The correct conclusion may still be that the current result is defensible and no rule is needed.
Read a signal through a real query
The dashboard becomes useful when the metric changes your next question
These examples show the reasoning path. They are not benchmark results. Replace the queries with the phrases that matter to your store and keep the interpretation bounded by the evidence you can actually inspect.
Exact identifier
“PM-12V-5A”
Observation
The query repeats, but the result set is empty or returns adjacent products.
Interpretation
Do not add a broad synonym first. Confirm that the identifier exists on the intended product or variant, that the record is eligible, and that the same value is represented in the search surface.
Responsible action
Repair the source record or investigate field coverage. Use a ranking change only after the correct product is eligible.
Broad category
“work table”
Observation
Products are found, but shoppers rarely open or add one.
Interpretation
The problem may be ordering, card information, price or availability state, filter access, or a mismatch between the broad query and the products shown.
Responsible action
Inspect the first result set and the visible card before changing relevance. Test one presentation or ranking hypothesis with a guardrail query.
Navigation intent
“shipping policy”
Observation
The phrase is repeated and shoppers leave the product result without taking a product action.
Interpretation
The shopper may be asking for a page, not a product. A product ranking rule would change the wrong surface.
Responsible action
Link the phrase to the correct page only if the destination is stable, specific, and clearly intended.
Operational change
“All queries”
Observation
Search activity or product actions change sharply after a theme, catalog, consent, or widget release.
Interpretation
Treat the timing as a health and instrumentation question before interpreting it as a relevance change.
Responsible action
Check storefront status, catalog parity, event delivery, and the release boundary. Re-establish a trustworthy baseline before tuning.
Chapter 4 · Choose the right view
Each analytics view answers a different question
Performance
Is the search journey changing over the selected period?
Read activity, result coverage, product actions, and associated value together.
Avoid
Optimizing one headline number without checking its denominator or definition.
Decision
Decide whether the change is broad enough to investigate at the store level or whether you should move into a query, product, or context view.
Queries
Which requests deserve a merchant review?
Inspect repeated demand, no-result patterns, low-action result sets, and individual query evidence.
Avoid
Adding rules for every rare or ambiguous phrase.
Decision
Decide which query has a clear enough problem and enough repeated evidence to justify a live result inspection.
Products
Which products are being found and acted on?
Compare search exposure with opens and direct adds, then inspect catalog and card quality.
Avoid
Calling a frequently returned product successful only because it was served.
Decision
Decide whether the product needs better source data, better presentation, different order, or no intervention.
Filters
Do shoppers use the narrowing paths the catalog provides?
Review filter use alongside the queries and result sets that made those filters available.
Avoid
Treating low use as a filter defect before checking whether narrowing was needed.
Decision
Decide whether a field helps product comparison, whether its values are understandable, and whether combinations repeatedly create empty or very thin results.
Behaviour
Where does the recorded path continue or stop?
Inspect the order of search, product, and commerce actions without inventing intent.
Avoid
Treating an observed sequence as proof of why the shopper acted.
Decision
Decide which surface, collection, relevance mode, market, locale, refinement, or exit pattern deserves a closer controlled test.
Audit
Can the team verify what was recorded and when?
Use event-level evidence for instrumentation checks, unusual patterns, and support investigation.
Avoid
Using raw events as the everyday executive dashboard.
Decision
Decide whether a surprising metric is a real shopper pattern or an instrumentation, consent, duplication, or timing issue.
Chapter 5 · Verify the evidence
Run a controlled journey before trusting the funnel
A dashboard cannot compensate for missing or duplicated instrumentation. Run a small controlled test after installation, theme changes, widget changes, consent changes, or analytics releases.
The goal is not to manufacture a perfect conversion rate. It is to confirm that each merchant-visible stage records the event you think it records.
Prepare
Choose a distinctive test query and one known product. Avoid a phrase real shoppers are likely to use during the test.
Search
Run the query once in the intended ParticleSearch surface and record the time.
Inspect
Confirm the returned count and product identity before taking another action.
Act
Open the known product, return, apply one filter if relevant, then perform one direct add only if the card safely supports it.
Verify
Check that the dashboard records the intended stages once the reporting window has updated.
Clean up
Exclude or annotate test activity in your working notes so it is not mistaken for shopper demand.
Once the evidence is trustworthy, continue with ParticleSearch Query Tools. It explains when to rank, add a synonym, redirect, repair the catalog, or leave the query alone.
Chapter 6 · A repeatable operating rhythm
A useful review ends with one owned decision
The cadence can be weekly, campaign-based, or tied to catalog releases. The important part is the order: establish that the evidence is trustworthy, choose one repeated pattern, inspect the visible result, and assign a bounded next action.
Establish trust
Check health, period, and metric definitions
Confirm the catalog and event surfaces are current, note any release or campaign change, and make sure the comparison uses the same definitions.
Choose evidence
Select one repeated query or product pattern
Prefer a problem with repeated demand and a falsifiable question over a long list of low-volume curiosities.
Inspect the storefront
Reproduce the visible result and source data
Check what the shopper sees, which products and variants are eligible, and whether the card and destination preserve the intended product.
Assign one outcome
Repair, draft a control, test the interface, or document no change
The review is complete when an owner knows the next action and the condition that will make the team revisit it.
For broader measurement design, read the Shopify search analytics guide. For storefront acceptance, use the ParticleSearch widget guide.
Operating example · dashboard diagnosis
A dashboard number is a starting point for diagnosis
Suppose “PM-12V-5A” appears in a review queue. The operator should move from the aggregate to the query, returned products, event audit, and protected search before deciding what changed.
Expected evidence
The query has a stable event path, returns the intended product or variant, records a product action when the shopper chooses it, and keeps the identifier intact through the handoff.
Weak evidence
Products-found rate is healthy and clicks are present, but the result is a cable rather than the requested supply or the card loses variant identity. The metric says coverage, not that the answer solved the job.
Failure evidence
The query is absent from the audit, the event is duplicated, the result is empty, or the dashboard and storefront disagree. Do not change ranking while the evidence chain is untrustworthy.
Next decision
Open Queries for wording, Products for catalogue evidence, or Audit for instrumentation. Assign one owner to the failing layer, verify the repair on the same query, and only then review aggregate movement.
Strongest alternative: if the event contract is not trustworthy, use protected query replay and storefront inspection as the immediate decision surface. A polished dashboard cannot compensate for missing evidence.
Acceptance judgement
Accept a dashboard review when the operator can explain the metric grain, inspect one real query, identify the failure layer, assign a bounded next action, and verify the result. A rising click or products-found rate without diagnosis is not an accepted improvement.