A buyer finds the right second-hand desk, opens the listing, and discovers it has sold. The marketplace knows something useful: the buyer was interested in that particular desk. Sending them back to a generic category page throws much of that information away.

A better next step is a small set of available alternatives that preserve the important parts of the original listing. For a desk, that might mean dimensions, price, condition and collection distance. A visually similar desk on the other side of the country may be less useful than a less similar one nearby.

This is a recommendation problem with a clear operational constraint. The system must find a reasonable substitute without recommending stock the buyer cannot obtain. It also needs to admit when there is no good substitute.

Keep the sold listing as evidence of intent

One-off inventory behaves differently from a catalogue of replenishable products. When a used item sells, another unit may never appear under the same listing ID. Historical interest can remain valuable even though the item itself is no longer eligible for recommendation.

Separate those roles. The sold listing can describe the buyer's intent while the current catalogue supplies the alternatives. Removing an item from the eligible result set does not mean its category, description or attributes have become useless.

Consider a buyer looking at a compact oak desk for £120, available for collection nearby. A useful alternative might preserve the size and collection area while allowing a modest difference in finish. Another oak desk costing £900 is probably a poor replacement, even if its description produces a strong similarity score.

The right trade-offs depend on the category. Buyers may tolerate a different colour but not a different shoe size. They may accept a longer collection journey for a rare piece of furniture. A classifieds platform should decide which constraints are mandatory and which preferences can vary, rather than treating every field as interchangeable evidence of similarity.

Show the sold status clearly. The recommendation module should help the buyer continue, not make the unavailable item look purchasable.

Establish eligibility before choosing the best alternatives

Start with the listings the buyer can actually use. Depending on the marketplace, eligibility may include an active listing status, seller restrictions, a permitted region and the relevant delivery or collection arrangement.

Then rank the eligible candidates for relevance. Content-based retrieval can find listings with similar descriptions or attributes. Behavioural signals can add useful context when there is enough reliable interaction history, but newly listed stock may have little or none. A system for one-off inventory needs a credible path for those new listings too.

Keep mandatory conditions separate from ranking preferences. A preference for a nearby seller can affect order. A listing outside a strict collection radius may need to be excluded altogether. Combining both into an opaque score makes the policy harder to inspect and easier to violate.

Filtering can also leave too few results. A pipeline that retrieves a tiny set and then removes most of it may return an empty rail despite having eligible stock elsewhere. Candidate generation, filter placement and retrieval depth need to be designed together. The implementation should be tested against the actual inventory distribution, particularly in sparse categories.

For the underlying retrieval choices, see the guide to content-based recommendation and the ItemKNN explainer. Neither method removes the need for current eligibility data.

Treat availability as a data-freshness problem

A recommendation engine cannot filter out a sale it has not heard about. If the marketplace's transaction system says an item has sold while the recommendation catalogue still says it is active, better ranking will not repair the disagreement.

Map the path from a sale or withdrawal to the data used for recommendation serving. Identify where updates can queue, fail or arrive out of order. Measure how long it takes for an unavailable listing to stop appearing, including any caches between the catalogue and the rendered page.

Do not assume that a successful catalogue update proves every cached response is fresh. Equally, a fresh recommendation response cannot reserve an item. Someone else may buy it between the response and the buyer's click. The listing page and transaction flow must still check the authoritative status.

Use the same scrutiny for withdrawn, expired and moderated listings. Their reasons differ, but they should not reappear simply because an old recommendation response survives longer than the listing's eligible status.

This boundary matters when evaluating a recommendation provider. Ask how availability is supplied, where it is evaluated and what freshness guarantees are actually documented. A claim of real-time recommendations is not, by itself, a guarantee of synchronisation with your transaction system.

Define fallbacks without quietly changing the buyer's request

Sometimes there are no suitable alternatives. A rural collection category may contain only a few active listings. A rare size or unusual specification may leave none.

Write down the fallback policy before deploying it. A marketplace might first return close matches, then offer an explicitly labelled option to broaden the price range or collection distance. It could instead offer a saved-search path if that capability already exists in the product.

Do not silently relax mandatory conditions to fill a row. Showing a desk outside the buyer's stated collection area may create more frustration than showing an honest empty state. Nor should the interface present a broad popular-items list as though it contains close substitutes.

Seller concentration deserves attention as well. Ten similar listings from one seller may offer less useful choice than a shorter, more varied set. Whether to diversify depends on the category and supply, and should be evaluated rather than imposed uniformly.

The interface can make the policy understandable with simple labels such as “Similar available listings” and “Further away”. Those labels must describe the results actually returned.

Start with one surface and measure what happens next

A sold-listing page is a bounded place to evaluate recommendation quality. The buyer has expressed interest, the unavailable item provides a reference, and the next useful action is relatively clear.

Begin with one category where listings have reasonably complete attributes. Record which alternatives were displayed and which were clicked. Where the marketplace can measure them reliably, follow subsequent actions such as a seller enquiry or purchase. Define the attribution window and event meanings before comparing approaches.

Track failures alongside engagement. How often do recommended alternatives turn out to be unavailable when opened? How often does the module have no eligible results? Does a better click-through rate lead to more useful buyer actions, or just more browsing?

A simpler baseline is worth keeping: available listings in the same category, ordered by a straightforward policy. It helps establish whether more elaborate retrieval adds value. If running an experiment, keep the eligibility requirements consistent across variants so that the comparison tests relevance rather than different availability rules.

NeuronSearchLab provides recommendation contexts and rules that can support separate policies for different surfaces. A sold-listing surface may need different constraints from a homepage rail. The rules guide explains the available controls; the marketplace still owns the accuracy and timeliness of its listing data.

For an evaluation, bring a representative catalogue sample, the listing lifecycle and a definition of a useful buyer action. The getting-started guide and documentation provide the integration starting point. Agree the availability boundary before judging the ranking.

FAQ

Should sold listings disappear from the recommendation catalogue?

They should not be eligible as available alternatives. Whether you retain them as historical records or reference items depends on your data model and serving implementation. Preserve useful intent where possible without making a sold item look active.

Can content similarity handle new listings?

It can provide a starting point when the listing has useful descriptions and attributes but little interaction history. Results still depend on metadata quality, candidate supply and the constraints applied to the request.

Should the module always return a full row?

No. A shorter set of eligible alternatives is preferable to padding the row with unavailable or unsuitable listings. If you broaden the search, make the change clear to the buyer.

Does recommendation filtering guarantee an item is still available?

No. Filtering works against the data available at evaluation time. Update delays, caching and concurrent purchases can change the status afterwards. The destination listing and transaction flow must check the authoritative state.