What to Put in a Product Embedding: Composing the Text You Index

The vector is only as good as the text you feed it

A product's embedding represents whatever text you put into it. Get the product embedding text right and search understands the product; feed it the raw description page and the vector ends up representing "generic e-commerce content" as much as the item.

What goes in

A clean composed field, in roughly this order of importance:

• Title.
• Salient structured attributes — colour, material, size range, key specs.
• Category.
• A concise description — the useful sentences, not the full marketing copy.

What stays out

• Raw description HTML — tags, layout markup.
• Shipping and returns boilerplate — it's identical across every product and adds noise.
• SEO keyword stuffing — it's there to game a different system and it dilutes the signal.

Each of these makes the vector a little less about this product.

Weighting

Most embedding models weight position and repetition, so the title and top attributes should be front-loaded, not buried after the twelfth line of care instructions. If "waterproof" and "hiking" are the words shoppers use, they need to be near the top of the composed field, not implied somewhere in paragraph three.

Keep structured attributes as filters too

The composed field is for the semantic match. Size, colour, and price also stay as separate filterable fields, so "red dress size 12 under £50" narrows the set before the vector match runs. You need both — the field for meaning, the filters for constraints.

The multi-supplier problem

Suppliers name things inconsistently. Normalise what you can into the composed field. On our semantic search project the residue that normalisation can't fix — an odd supplier abbreviation, an invented category name — is handled by a merchandising console that boosts and buries as data, without an engineering ticket.

Test the composition

Search your own query set and read what comes back. A product that should match "waterproof hiking boot" but doesn't usually has a composed field missing "waterproof" or "hiking." The composition recipe is versioned — changing it means re-embedding the catalogue, so it's a deliberate change, like swapping the model.

Before and after, on one product

Before — the raw product page: site navigation, "Free returns within 30 days. Add to wishlist. Customers also viewed…", a block of HTML, and a keyword list stuffed in for SEO. Maybe 40% of it is about the actual product.

After — a composed field: "Waterproof leather hiking boot. Brown, full-grain leather, rubber lug sole, GORE-TEX lining. Category: Footwear > Hiking. Ankle support, waterproof, breathable, built for multi-day trails." Every word is about the boot.

The second one produces a vector that matches "waterproof hiking boots" and "leather trail boots for wet weather." The first one produces a vector that also, faintly, matches "free returns" and "add to wishlist."

Versioning the recipe

Store the recipe version on each vector record. When you change how the composed field is built, you know exactly which products are still on the old format and need re-embedding, and a full re-index becomes a one-command job rather than a guess about what's stale.

Where this stops being right

• A sparse catalogue — titles only, no attributes — limits what you can compose; the search is only as rich as the data.
• A small, stable catalogue doesn't need an elaborate composition — keep it simple.
• Auto-generating descriptions to fill gaps can help or can add noise — measure it against your query set before rolling it out.

FAQ

What text should go into the embedding? A clean composed field — title, key attributes, category, short description — not raw HTML or boilerplate.

Should structured attributes be in the embedding? Put them in the composed field for the semantic match and keep them as separate filters. You need both.

What if suppliers name things inconsistently? Normalise into the composed field where you can; a merchandising console handles the rest without a deploy.

How often do we change the recipe? Rarely — a few times a year at most. Each change means a full re-index, so batch several improvements into one recipe update rather than tweaking it continuously.

ISTRALLEN builds the indexing pipeline around a clean composed field per product, versioned like the model; see AI for Retail.