Buy Constructor if the job is a smarter search box on one site; buy Anglera if the job is a better catalog everywhere. Constructor's enrichment lives in its own index; Anglera cites every value and writes it back to your PIM.
Both claim to enrich product data. This page is about where that claim stops.
Product data is a practice, not a project — and Constructor's Attribute Enrichment is documented as tagging products "regularly" so its own search and browse indexes rank and filter better, which leaves the practice living downstream of that: the export, the next supplier drop, the spec that changed, the field the marketplace feed still reads as blank.
Mine every spec from every source.
Every value traced to a document you can open. The catalog is only as honest as what it was built from.
Aim the catalog at the buyer who actually buys.
Grounded data still loses if it answers questions nobody asked. Alignment is what turns specs into conversion.
Product data is a practice, not a project.
Markets move, suppliers reissue, buyers change what they ask for. A catalog that is right in March is wrong by August unless something is watching.
Scored against public documentation. Grouped by the three acts — so you can see which ones Constructor leaves on your desk.
Mines catalog text and images; no supplier document mining
PDFs, spec tables, drawings, manuals, images, sites
Mints trend attributes from search signals; stays in search index
Proposes fields your schema never had
Normalizes values for facets; no versioned governed pick lists
Normalizes and governs allowed values, versioned
Auto-categorizes SKUs; onsite taxonomy, not marketplace channel mapping
Auto-classifies; channel and marketplace mapping
Confidence and precision scores; no per-value source citation
Every value cites its source doc and page
Personalizes attribute affinities per shopper; no persona-specific copy
B2B specifier and B2C shopper enriched differently
Onsite search queries and clickstream drive daily attribute creation
Reviews, search, competitor rails, social — fed back
Generates collection landing pages, not titles or descriptions
Original copy per persona and channel
Reads product images for attributes; does not generate
Generates studio-grade imagery for photoless SKUs
Re-tags products daily as buyer preferences shift
Re-enriches on its own after go-live
Coverage, precision, mismatch metrics; scoped to enriched attributes
Scored against your standards; nothing publishes below bar
CSV export for manual PIM upload; no direct write-back
Writes back to PIM, ERP, warehouse, commerce
Catalog API and webhooks; MCP is docs-search only
API, webhooks, and MCP servers
Software auto-tags; merchandisers review, dismiss, and export
Anglera owns the work; review is a guardrail
“Buyer signals” is the emptiest phrase in this category, so here is the literal thing. Each of these is an observation from a live market, the gap it exposes, and the field that gets created as a result.
"apartment sofa" and "sofa under 80 inches" climb week over week. The width is in the copy, not in a field: one listing says "W: 84.5\"", the next says "eighty-four and a half inches wide", a third only gives it in the assembly PDF.
Overall width sits in prose, so it can be matched on as text but not filtered on, ranged, or sent to a channel that requires a number and a unit. The furniture feed to the marketplace ships the dimension group empty.
overall_width_in — numeric, inches, one decimal, sourced from the manufacturer drawing rather than the marketing lineUnit-normalised numeric: inches to 0.1; cm and mm converted on ingest; fractional notation (84 1/2) parsed to 84.5; assembled width only, never carton width"Ordered the 10 Wide, fits like a standard D" and "true to length, way too narrow through the forefoot" show up across three vendors. Supplier catalogs carry width as M, W, XW, D, 2E, EE — sometimes two spellings for the same last inside one brand.
Width exists in the record as free text rather than a governed value, so the site has nothing to filter on, the size chart contradicts the vendor sheet, and returns get coded as "wrong size" with no way to separate length from width.
shoe_width_designation — governed US width code, plus last_id so two vendors' "Wide" can be told apartB | D | 2E | 4E | 6E, with a mapping table: Narrow→B, Medium/M/Standard→D, Wide/W/EE→2E, X-Wide/XW→4E, XX-Wide→6EA private-label granola is rejected: "allergen declaration required." The phrase "produced on equipment that also processes peanuts and sesame" is sitting in the ingredient paragraph. The allergen field on the record is null.
The allergen statement lives in a scanned label PDF and in free text rather than a structured field, and carries no distinction between "contains" and "may contain" — which is the distinction the receiving channel validates against.
allergen_declaration — multi-select, paired with declaration_type per allergen, extracted from the label artwork and dated to the artwork revisionMilk | Egg | Fish | Crustacean shellfish | Tree nuts | Peanuts | Wheat | Soybeans | Sesame; declaration_type: contains | may contain | free fromConstructor's documentation says where enriched attributes go: "Once identified, enriched attributes are ingested into your search and browse indexes," and they "appear in your dashboard where your team can review them (and dismiss them, if necessary)." For a system of record, the route the docs describe is an export: "If you wish to, you can export a CSV file with these attributes to upload to your PIM manually." That is coherent design for a discovery platform. Anglera's argument starts after the export. A CSV is a snapshot. The docs say enrichment tags products "regularly," so the index keeps moving; the exported file does not. A supplier drops 400 SKUs, a vendor reworks a spec sheet, sesame moves from "may contain" to "contains" — and the record and the index disagree. The marketplace feed, the dealer portal and the print sheet all read the record. A shopper filters by heel height on the site while the same SKU syndicates with that field blank.
Values are normalized into a governed, versioned set of allowed values — so a filter works, and keeps working after the next import.
3/4 in0.75"3/4"19mm3/4 inchDN200.75 in (DN20)Six suppliers, six spellings, one physical size. Filters only work once they agree.
BlkblackBLACK MATTEMatte BlkRAL 9005Black — MatteFree text makes a colour filter useless. A governed value makes it a facet.
SS316316 StainlessStainless Steel 316A4 StainlessStainless Steel — 316 / A4Same alloy, four vocabularies, plus a trade name. Buyers search all of them.
Filling the fields you defined has an invisible ceiling: a catalog can hit 100% complete and still miss the attribute that loses the sale, because completeness is measured against a schema someone drew years ago. Schema Foundry reads competitor listings, buyer searches, review complaints and your supplier docs, and proposes the fields you never defined — which is where Constructor stops.
How Schema Foundry works
Constructor is an AI-powered search and product discovery platform for enterprise ecommerce that uses behavioral clickstream data to personalize search results, recommendations, and browse experiences. It includes a product data enrichment feature that automatically tags attributes to improve on-site discovery within the Constructor index.
Pricing: Custom enterprise pricing; estimated average contract value $150K–$300K/year based on interaction volume.
Constructor websiteEcommerce teams whose problem is onsite conversion: clickstream-personalized search, SKUs auto-categorized and re-tagged daily as demand shifts, and enrichment that only has to serve that index.
We'd rather tell you here than in month three of an implementation.
Capability verdicts reviewed against Constructor's public documentation on July 14, 2026. Vendors ship quickly — if something here is out of date, tell us and we'll correct it.
Bring one category and your supplier files. In 30 minutes you'll see it enriched — complete, structured, and consistent enough to launch on — plus the attributes your schema didn't have yet.
Book a demo