Reviewing Product Matches: from Pending Queue to Confident Coverage

When the automated matching pipeline encounters a product observation it cannot confidently assign to a catalog entry on its own, it places that observation in a Pending Review queue for a human decision. This page walks you through finding those pending items, making approve/reject decisions in the Match Review interface, and understanding how those decisions flow downstream.

Note

This page covers exact-match product matching as users experience it. It does not cover Equivalent Matches or Market Benchmarks. Those are documented on Market Benchmarks.

Where to spot pending matches

The Matches page

Open Matches in the navigation. The Match Queue table lists every product observation across your monitored retailers, grouped by catalog product, 50 observations per page. Use the Status filter to narrow to Pending Review to see only the items awaiting a decision. Each grouped row shows:

• The master product image, name, and brand
• How many observations, or retailer listings, belong to that group
• Its matched category

Expand a group row to see the individual observations, each showing its confidence score, the match method used, and the matched product name. Hovering the matched product name reveals a mini side-by-side card comparing the observed product image and title with the matched catalog entry.

Observations that have no catalog product proposed for them yet are not part of any group. They appear together under a No Match Found heading at the end of the table.

Additional filters on the Matches page let you narrow by:

Filter	Options
Status	All Matches · Pending Review · Verified / Exact · Unmatched · Rejected
Confidence	High (90%+) · Medium (70–89%) · Low (<70%)
Market Presence	2+ · 3+ · 4+ · 5+ · 10+ retailers

You can also sort the table by product title or confidence score.

Match Stats

Click Match Stats from the top of the Matches page for an at-a-glance health view of your matching coverage:

• KPI cards. Catalog size, total observations (with the average number of retailers per product), exact matches (split into automatic and manual), pending review count, rejected count, and average confidence across all matches.
• Confidence Distribution. A horizontal bar chart showing how many observations, that is, retailer listings that have a proposed catalog product, fall into each confidence bucket: 100%, 90–99%, 70–89%, 40–69%, and <40%. The chart’s tooltip labels these counts “Products,” but each one is a matched observation, not a distinct catalog product.
• Match Method Breakdown. A donut chart showing which share of decisions each matching strategy accounts for: Barcode (GTIN), Identifier Match, Title Similarity, AI Verification, and others.
• Matching Activity (Last 35 Days). An area chart of daily matching activity over the last 35 days. The dashed “Products Discovered” line shows how many observations were seen each day. The stacked “Matched” area counts every observation seen that day that has a proposed catalog product, including ones still awaiting review. The “Pending” area counts the observations seen that day whose status is pending, so pending observations that have a proposed product are counted in both areas.
• Category Coverage. A table of total, verified, and pending counts and average confidence per product category, sorted by average confidence, so the least confident categories appear first.
• Retailer Match Coverage. A table of the same metrics broken down per retailer, plus each retailer’s most commonly used match method.

Note

Pending counts on Match Stats cover every observation with a pending status, including observations that have no proposed catalog product and observations the pipeline already finalized automatically. Neither kind appears in Match Review, which loads only pending observations that have a proposed product and are waiting for a manual decision. A high pending count in a category or retailer row therefore points to where to look, but it does not mean that many items are waiting in the review queue.

Entering the Match Review queue

From the Matches page, click Review Matches. This opens the Match Review queue, which loads up to 250 pending candidates in one batch and presents them one at a time in a three-panel layout. The page header shows the total number of pending matches awaiting review.

Once every group in the loaded batch has been approved, rejected, or skipped, a Batch complete screen appears. Click Load next batch (its label shows how many pending matches remain) to fetch the next 250, or, once none remain, Check for new matches.

When the queue is empty, the page shows All caught up. If you skipped anything during the session, the note tells you how many matches you skipped and reminds you to reload the page to review them again; otherwise it reads No matches left to review.

If a batch fails to load, the page shows Could not load matches with a Retry button. Decisions you already made are saved regardless.

The three-panel review layout

Left panel: Master Catalog

The left panel shows the catalog entry that the automated pipeline proposed as the match. Fields displayed:

• Product image, title, and brand
• GTIN and MPN, the manufacturer part number
• Physical attributes: bundle quantity and unit, weight, net content value and unit, dimensions

Title, brand, image, and the physical attributes come from the catalog record when it has them and from the group’s reference observation otherwise, so when no catalog enrichment exists yet, the left panel mirrors that reference listing for those fields. GTIN and MPN, however, are read from the catalog record only, with no such fallback, so a listing that carries an identifier the catalog record doesn’t have is highlighted as different even when it’s the reference observation itself; a different pending listing in the same group can likewise differ from the master panel and be highlighted. The price, category, mapped category, and description shown alongside these are not separate catalog-level values. They come from one of the pending retailer observations in the group being reviewed, specifically the first one carrying catalog enrichment, or the first observation if none carries catalog enrichment. This is often the same listing shown in the right panel.

Right panel: Match Candidate

The right panel shows the observed product as scraped from the retailer, with its title, image, price, identifiers, category, and description as listed by the retailer. Brand is shown from the catalog entry when it is known, and from the scraped brand otherwise. As a result, it generally mirrors the master panel’s brand and does not show brand drift that might exist in the listing itself.

It also displays:

• Retailer name and sub-retailer, when present
• SKU as listed by the retailer
• A View on retailer site link to the live product page on the retailer’s site

Any field that differs from the value shown in the Master Catalog panel is highlighted in amber: image, title, brand, price, identifiers, category, mapped category, physical attributes, and description. The comparison is case-insensitive and ignores surrounding whitespace, and a field the master panel shows as empty counts as a difference when the candidate has a value. The reseller SKU has no equivalent on the master panel, so it is never highlighted.

Center panel: Decision

The center panel contains the match decision summary, action controls, and navigation:

Match decision summary. Shows the confidence score as a percentage, the method the pipeline used, for example Barcode (GTIN), Title Similarity, or AI Verification, and a plain-language reason. If a full match trace is available for this candidate, the summary is drawn from it; otherwise it is derived from the candidate’s own matching fields.

Action buttons. Two large buttons let you act on the current candidate:

• Confirm Match. This green button approves the proposed link between the candidate and the master catalog product. A manual approval is recorded with full confidence and carries the reviewer’s identity in the audit trail.
• Reject. This outlined red button severs the proposed link. The observation is marked rejected, leaves the Match Review queue, and no longer sits in the product group it was proposed to join on the Matches page.

Both actions are applied immediately and are not reversible from this interface.

Candidate navigation. Chevron buttons, or the ← → arrow keys, move through multiple observations within the same product group when more than one pending candidate maps to the same catalog entry. The center panel shows Candidate N of M to indicate your position.

Group progress. A progress bar and Group X of Y label track how far through the full review batch you are. Once all candidates in a group are actioned, the queue auto-advances to the next group.

Skip group. If you want to defer a group without deciding, click Skip group or press N. The group remains in the pending queue.

Other Candidates. If the current group contains additional pending observations beyond the one on screen, up to six of them appear as a list below the action controls. Clicking any entry switches the right panel to that observation.

Keyboard shortcuts

Key	Action
SPACE	Confirm Match (approve)
X	Reject
←	Previous candidate in group
→	Next candidate in group
N	Skip group

Shortcuts are disabled while focus is inside a text field, a dropdown, or an open dialog. Space and Enter are also left to a focused button or link, so clicking a button with the mouse doesn’t also trigger Confirm Match.

The match trace

When the pipeline recorded a detailed trace for a candidate, a View Full Trace button appears in the center panel. Clicking it opens a modal with the step-by-step record of every strategy the pipeline ran:

Stage	What it represents
Category Mapping	How the product’s category was resolved
Historical Match	Whether a prior match for this product exists
Identifier Match	Lookup by GTIN or MPN. A retailer SKU is only used when the SKU value itself is a valid GTIN.
Title Fuzzy Match	Fuzzy text similarity against catalog titles
Description Match	Similarity against product descriptions
Vector Similarity	Embedding-based nearest-neighbor similarity search
Semantic Search	Resolves the listing’s category to a node in the global taxonomy so later stages can use category agreement as a signal; it does not propose candidates itself
AI Verification	LLM confirmation pass
Retailer Collision	Rejection when the retailer already holds this catalog product
Abstain Guard	Hold-for-review signal raised when a vector-similarity-only match has weak corroboration (a low score, or too small a lead over the runner-up candidate), when an identifier match below 100% isn’t confirmed by another strategy and the runner-up candidate scores close behind it, or when the top candidates score too close together
Final Decision	The outcome the pipeline sent to the review queue

Each stage shows its strategy label, a status such as Found, No matches, AI confirmed, or Held for review, and how long it took. Where relevant, it also lists the candidate products it considered, by their catalog ID, with a match score, an optional rejection reason such as Brand mismatch or Retailer already has this product, and supporting signal tags. Hovering a candidate opens a preview card with that product’s image, title, brand, category, and identifiers, or a note that the product isn’t in the catalog, either because it’s been removed or because the import that would add it hasn’t finished yet.

If no trace is available for a candidate, the center panel falls back to showing the confidence score, method, and reason from the candidate’s own matching record. You can still approve or reject without a trace.

How decisions take effect

Approvals and rejections are written atomically: the candidate’s status is updated, the match trace is updated to record the reviewer’s decision, and an audit event is recorded, keyed to the reviewer’s identity. Manual decisions are authoritative. Later automated proposals for the same observation do not override them.

A pending observation already contributes to matched-product surfaces before you act on it: the pipeline’s proposal is what puts it on the Prices matrix as a price cell and in that product’s Common Products drill-down. Approving a candidate doesn’t add it to those surfaces for the first time. It confirms the same catalog link, now recorded at full confidence, and locks it against later automated proposals for that observation.

Rejecting moves the observation to the Rejected status shown in the Matches page filter. It is no longer proposed against that catalog product in the Match Review queue or in the Matches page grouping, though it isn’t removed from your data. The Common Products drill-down can still pair a rejected listing with the product it was formerly proposed for. The pending count on Match Stats decreases as decisions are recorded. Navigating to or reloading the Match Stats page after making decisions will show updated counts.