Your reviews are a line-planning memo. Is anyone reading them?

A regional footwear brand pulls up 4,000 reviews on its bestselling walking shoe. Buried in paragraph three of dozens of them: "wish it came in wide." Nobody flagged it. Nobody rolled it up. The merchandiser reading reviews for star ratings and the customer service rep scanning for return triggers both skimmed past what was, in effect, a line-planning memo written by the customer base itself.

That's the waste. Reviews get read for sentiment (are people happy) and for risk (are people returning this). Almost nobody reads them for content: the specific, repeated, structured information about what a product does well, what it does poorly, and what customers want that doesn't exist yet. That information is sitting in free text, which means it's invisible to any system that aggregates by attribute rather than by paragraph.

Reviews are unstructured attribute data

Every review is a customer manually doing enrichment work your catalog didn't do for them. "Runs a full size small," "the mesh panel breathes way better than the old model," "the strap digs in after an hour" — these are attribute-level claims about fit, material performance, and comfort, written in the customer's own words because your product page didn't capture them as fields in the first place.

The problem is scale and structure, not scarcity. One review saying a shoe runs small is an anecdote. Three hundred reviews across a size run, tagged by size ordered and fit sentiment, is a pattern a demand planner can act on before next season's buy is finalized. The gap between those two is extraction: turning "the toe box felt tight for the first week but broke in fine" into structured fields like fit_signal: runs_narrow, break_in_period: yes, severity: moderate.

Academic work on this is maturing fast. Researchers building product-design pipelines from online reviews now treat review mining as a formal input to the design process, using NLP to extract feature-level sentiment and unmet needs directly from review text rather than relying on manual reading (see this product design improvement method driven by online reviews). Separate work on multi-attribute review mining shows that reviews routinely discuss specific product attributes in ways star ratings never capture, and that the volume of attribute-level detail in a review is itself informative about what customers actually weigh when deciding to keep or return an item (the informational value of multi-attribute reviews). None of this is exotic. It's the same extraction logic Anglera applies to a spec sheet or a tech pack, pointed at a different unstructured source.

Three signal types worth extracting

Not every sentence in a review is worth structuring. Three categories consistently pay off:

Praise signals. The specific feature customers volunteer credit for — "the cushion tech in the heel," "true to size for once," "held up after a season of trail runs." This is validation for what to keep or expand into adjacent styles. It also happens to be some of the best organic PDP copy available, because it's in the customer's actual language.

Complaint signals. Repeated, specific friction — a strap that digs in, a fabric that pills, a zipper that catches. One complaint is noise. The same complaint appearing across dozens of units of the same style, same material lot, or same supplier is a signal worth routing to whoever owns that spec.

Unmet-need signals. Explicit requests for something that doesn't exist yet: wide widths, a color the line doesn't carry, a strap length for a different body type. These are the closest thing to a customer-written line-planning memo, and they're almost always ignored because they show up as a stray sentence in review 214 of 600, not as a ticket in anyone's backlog.

Sizing and returns data reinforce why fit signals in particular matter for planning, not just for the product page: return-rate research on apparel repeatedly finds that reviews mentioning "runs small" or "sizing inconsistent" precede size-level return spikes, and that fixing the underlying sizing signal — not just refunding more politely — is what actually moves the return rate (e-commerce return rates and sizing data).

From review text to a line-planning input

The mechanism looks like this: extract mentions of fit, material, comfort, durability, and requested variants from review text at the SKU level, normalize them into a shared vocabulary (so "runs small," "tight through the toe," and "sized down" all map to the same fit_signal value), attach a confidence or frequency weight, and then roll the SKU-level tags up to the style, category, or supplier level.

That rollup is what turns anecdote into a planning input. A single mention of a wide-width request is nothing. A width_option unmet-need tag appearing across 40 SKUs in a running category, aggregated the same way a demand planner already aggregates sell-through by size, is evidence for next season's assortment brief. A strap_pressure complaint concentrated on SKUs sharing one supplier's hardware is evidence for a spec change, not a marketing tweak.

The same extracted fields serve three audiences without three separate projects: demand and merchandising planners get fit and unmet-need rollups for the assortment brief, product and quality teams get complaint clusters tied to supplier or material, and e-commerce teams get praise language ready to drop into PDP copy and filters. One extraction pipeline, three consumers, no re-reading of the same 4,000 reviews three times.

Anglera doesn't replace whatever system holds your reviews or your PIM — it reads the unstructured source, extracts the attribute-level signal, and writes it back as structured, queryable fields your planning tools and your PDP already know how to consume. Your PIM stores the data. Anglera does the work of turning what customers already told you into something a forecast, a brief, or a filter can actually use.