Search and product discovery
A buyer who cannot find the article phones your Innendienst, and the shop has saved nobody any work. Search is not a feature of a B2B storefront. On most days it is the storefront.
The four routes to one article
| Route | What the buyer types or does | What has to be right |
|---|---|---|
| Part number | 4711-A, or the manufacturer's number, or their own material number | Exact-match and partial-match on identifier fields |
| Words | "Edelstahl Verschraubung 10 bar" | Product names, synonyms, and a search that tolerates German compounds |
| Browsing | Clicks down the category tree | A tree built for buyers, not for the ERP's material groups |
| Filtering | Narrows a listing by thread size, material, norm | Attributes marked filterable, with clean values |
Most B2B buyers use route one. They arrive knowing what they want. This is the opposite of B2C, where discovery is the whole design problem, and it changes what you optimise: an exact part number must return one result at the top, not a relevance-ranked list of forty similar things.
Route one has a faster version worth having: a field that takes part numbers and quantities, typed or pasted as a list, and fills the basket without opening a single product page. For a purchaser re-ordering the same twelve articles every month, that field decides whether they use the shop at all. Whether your storefront offers it depends on the theme; the substrate it fills from, order lists, is on the tenant today.
What the index knows
The product search index is defined by the catalog, per channel and per locale. It carries:
| Searchable | Facetable |
|---|---|
| SKU, product name, description | Product kind (simple, model, variant) |
| Manufacturer, EAN | Enabled or not |
| Category codes and labels | Manufacturer, categories |
Everything else an attribute holds travels with the product as data but is not searched by default. Two consequences follow. A competitor's part number that you keep in a custom attribute is not found by typing it until that attribute is in the index. And "the search cannot find it" is very often "the value is in a field the index does not look at", which is a catalog decision rather than a search one.
Facets: which filters appear
A facet is a filter on a listing page: Material: V4A, Thread size: G 1/2, Pressure rating: 100–250 bar.
Facets do not come from the storefront. They come from attributes that are marked Filterable (facet) in the catalog. The storefront renders what the data offers. So the work splits cleanly:
- In the catalog, decide which attributes are filterable and keep their
values clean. A filter over
materialis only useful if every product saysv4aand not sometimesV4A, sometimes1.4571, sometimesEdelstahl. Use a select attribute with defined options rather than free text. - In the storefront, decide how many facets show at once, in what order, and which ones are relevant in which part of the tree. That is theme configuration.
Four rules that hold up:
- Five to eight facets per listing. More than that and buyers stop reading.
- Order by how buyers decide, not alphabetically. In technischer Großhandel the first cut is usually dimension or thread, not manufacturer.
- Facets are per category. Thread size matters on fittings and is noise on packaging. A single global facet list is the most common mistake here.
- Give numeric attributes ranges. Twenty-four checkboxes for pressure ratings is a worse filter than three ranges.
Autocomplete
The dropdown under the search box does three jobs: it completes part numbers as they are typed (by far the highest-value one), suggests products so the buyer can jump straight to a product page, and suggests categories so a vague word lands on a listing rather than a result set. The dropdown itself belongs to the theme, so what it does depends on the theme you installed.
Test it with a partial part number. If typing 4711 does not surface 4711-A
within three characters of the end, the identifier fields are not indexed the
way buyers type them.
Synonyms and the vocabulary gap
Your catalog uses your company's words. Buyers use theirs: their old supplier's
words, their ERP's words, the word the fitter on site uses. The gap shows up as
regional names (Schlauchschelle versus Schlauchbinder), norm names against
trade names (1.4571 versus V4A versus Edelstahl A4), abbreviations (VA,
NIRO, Inox, all meaning stainless), English terms in a German catalog, and
competitor part numbers, which buyers type constantly after a supplier change.
A synonym list is the cheapest quality improvement available on a B2B shop, and it is never finished. Build it from what buyers type, not from a brainstorm. The synonym list is a Search app screen and is planned; start collecting the pairs now, in a spreadsheet, from the Innendienst.
Some of this belongs in the data instead, and that part you can do today: a competitor's part number is better modelled as a searchable attribute on the product than as a synonym rule, because then it also works in exports and punchout catalogs.
Zero results: the report nobody reads
The list of searches that returned nothing is the single most useful document about your catalog. Every line is a buyer who wanted something and left. When Search analytics ship, read it monthly and sort each line into one of four buckets:
| The search returned nothing because | Fix |
|---|---|
| You do not sell it | Nothing, or a sales lead |
| You sell it, under another word | Synonym, or add the word to the product |
| You sell it, but it is not in this channel | Assortment: the product is not assigned |
| The data is incomplete | Fill the attribute; see Completeness |
The third one is the ambush. A closed channel that hides unassigned products hides them from search too, silently and correctly.
Until the report exists, the twenty-search test below is your substitute. It finds the same four buckets, on a sample instead of the full log.
How this works in the Revenue Cloud
- Filterable attributes: the Filterable (facet) flag on an attribute, under Commerce Studio › PIM › Data model › Attributes.
- The category tree: PIM › Categories, including rule-based categories that fill themselves from a membership rule on attribute values, recomputed nightly or on demand. These make excellent landing pages: "Stainless steel fittings" as a real, self-maintaining page rather than a saved filter.
- What is searchable at all: the channel. A channel set to Hidden until assigned (closed) restricts search to the negotiated assortment.
- Related products: product associations carry accessories, spare parts and replacements, which is how a buyer who found the pump also finds its seal.
- The search UI itself: the search box, the autocomplete dropdown and the facet rendering belong to the storefront theme. What it offers depends on the theme you installed; check its listing under Marketplace.
- Synonyms, curation and search analytics: the Search app, planned.
What to check
Do the twenty-search test before launch, and again every quarter:
- Write down twenty things buyers ask for. Get them from the Innendienst, not from marketing.
- Search for each one in the storefront, signed in as a real customer.
- Count how many put the right article in the first three results.
Under fifteen out of twenty and the problem is your data, not your search engine. Anything you fix after this test is worth more than anything you tune before it.
Next
- Attributes: where facets are decided.
- Categories: the tree, and rule-based categories.