In a marketplace serving both a browse feed and a typed product search, what does the typed query change about the candidate set?

## Two surfaces, one funnel A marketplace that shows a browse feed on its home surface and a typed product search over the same catalogue usually runs **one funnel** for both: a cheap **retrieval tier** that produces a few hundred to a few thousand candidates, a heavier **scoring stage** that ranks only those survivors, and a final list-editing pass. The boxes on the whiteboard are the same. What changes is what the first box is given to work with. ## What the typed query does An explicit query — plus whatever facets the shopper ticked — behaves as a **constraint on retrieval**, not as one more input feature to the ranking model: - It is resolved **before** any model scores anything, so items that fail a hard constraint are never assembled into the candidate set at all. - It is **cheap to apply**, because the retrieval tier is already an index lookup and the constraint rides along with the lookup. - It is **stated by the user**, so getting it wrong is visible. Someone who typed `waterproof hiking boots size 44` can see immediately that slot three is a sandal. The consequence for the rest of the funnel is that the scoring stage starts from a pool that is already roughly on-intent. Its job narrows to *ordering items that are all plausible*, which is why a query surface can often hit page quality with a smaller shortlist than a feed needs. ## What the browse feed has to do instead The feed has no assertion to work from, so retrieval has to **manufacture** an intent out of what is known about the viewer: recent views and purchases, the session's context, the viewer's segment, what is trending, what inventory is new. - Several retrieval sources run in parallel and their outputs are merged, because no single source covers the whole of "what might interest this person". - The candidate pool is **wider and lower-precision**, so the scoring stage carries more of the burden of being right. - A mediocre feed item is a wasted slot rather than a contradiction of something the shopper said out loud. ## Where each surface's recall ceiling sits | | browse feed | typed product search | |---|---|---| | what bounds retrieval | the profile and context signals available | how the query was interpreted | | typical retrieval failure | the viewer's real interest was never a source | the derived constraint was tighter than intended | | the scoring stage's job | separate interesting from uninteresting | order items that are already eligible | | a wrong item on the page | a wasted slot | a visible contradiction of stated intent | This is why the surfaces fail differently. A feed's recall problem is "we never generated that candidate"; a search surface's recall problem is "the constraint we derived from the query excluded the right item" — a misparsed attribute, an over-eager facet, a spelling the index did not fold. Both are **retrieval-tier** bugs, and neither is fixable by a better scoring model, because the scoring model never sees what retrieval did not produce. That single sentence is most of the value of drawing the funnel as stages in the first place. ## What this changes downstream Because the constraint lands first, every later stage inherits it: 1. **Shortlist budget.** A query surface can spend a smaller shortlist on the heavy scoring stage, because the pool is already relevant; a feed usually needs a bigger one to reach the same page quality. 2. **Exploration.** A feed can afford a slot on something speculative. A query surface has far less room, because the shopper has already said what they want. 3. **The empty case.** A query can legitimately have no good answer in the catalogue, so the search surface needs a relevance cutoff. The feed has no stated intent to contradict and almost always has something plausible to show. 4. **Evaluation.** A click on the feed and a click on a search result do not mean the same thing, so the two surfaces cannot honestly be judged by one pooled number. ## The nuance an interviewer listens for The tidy version of this answer is "search filters, feed recommends", and it is not quite right. Two refinements matter. First, a query is not uniformly a hard filter: ticked facets usually are hard, while free-text terms are usually **soft** — a partial or relaxed match is still a legitimate candidate — and a system that treats every typed word as a hard requirement returns nothing far too often. Second, the feed is not intent-free; it is **weak, inferred intent**. A good design treats the browse feed, a broad query and a precise query as one spectrum of intent strength, with the same funnel tuned differently along it, rather than as two unrelated products that happen to share a catalogue.