Intelligence

AI Product Intelligence is not its own admin page. It is a stat group and four checklist rows inside Insights → SEO.

Despite the name, no model is called. The whole thing is a rule engine reading your catalog.

It scores each published product on three questions: does it expose structured attributes, does it carry intent tags, and does it sit in a recommendation graph. The same attribute transform that answers the first question also publishes those facts to the product page's JSON-LD and to the product feed.

The reason to care is that an AI shopping assistant cannot infer that a shirt is available in medium from a paragraph of marketing copy. It can read a declared attribute pair.

The four audit rows

The report flags products in four categories:

1. No structured specs at all
2. Fewer specs than your minimum
3. No intent tags
4. No related or add-on products linked

The minimum spec count is a setting, and it defaults to:

3

A published product carrying fewer structured specs than that is flagged as thin.

Each row appears in Insights → SEO prefixed with AI ·, alongside the ordinary SEO findings.

The peer norm

The most useful of the checks is the one that does not need you to define anything: the comparison against a product's own category.

An attribute counts as expected in a category once at least half its products declare it:

≥ 50% of a category's products must declare a key
only in categories holding ≥ 3 products

Both halves of that rule matter.

The 50% threshold means the norm comes from what you actually sell, not from a fixed list somebody wrote. If most of your jackets declare a shell material, a jacket that does not is visibly incomplete — and the report says so without anyone having configured a "jackets need shell material" rule.

The three-product floor stops a category of two from inventing a norm. With two products, one declaring a key makes it a 50% majority, which would be noise rather than a signal.

A product missing an expected key is listed with the exact labels its peers declare, so the fix is a copy of a string that already exists in your catalog rather than a guess at what to call it.

The comparison ignores case and surrounding whitespace, which means Material and material are treated as one attribute. Without that, an inconsistent capital letter would split a category's norm in half and hide the gap.

Discrete attribute pairs

A product's attribute set is built from two sources merged together:

• Its curated specifications
• Its variant option axes

Specifications win on a key conflict.

The important part is what happens to the values. Each value becomes its own pair:

Size = S
Size = M
Size = L

Not one comma-joined string reading Size = S, M, L.

A machine reading the first form can answer "do you have this in medium?". A machine reading the second has to parse a sentence, and will sometimes get it wrong.

Keys are never enumerated in code, so whatever you choose to name an attribute flows straight through. There is no list of supported attribute names to petition for an addition to.

Output is capped at:

60 pairs per product

One transform, two surfaces

The same attribute, keyword and related-product helpers feed both places this data is published.

On the product page, they produce:

• additionalProperty
• keywords
• isRelatedTo

In the product feed at /api/products/feed, they produce the equivalent JSON-LD.

Because it is one transform rather than two implementations, the two surfaces cannot disagree about a product's attributes. A fix made once shows up in both.

The feed goes one step further than the product page: it also emits per-SKU attributes, drawn from each variant's chosen option values.

What is stated once, and what is not

The return policy is derived from your return window setting, and appears as MerchantReturnPolicy in both the product page schema and the feed.

When you offer no finite return window, it is omitted entirely rather than published as a guess. A wrong returns promise in structured data is worse than an absent one — it is a claim a shopper's assistant will repeat back to them.

Two things are not shared this way yet:

• Shipping details are not published through this transform
• Price and availability are still computed separately in each surface

That last one is worth remembering: unlike the attributes, price and availability have two code paths, so they are not protected by the "cannot disagree" property above.

Where the rules live

For a developer who wants to read the rule engine rather than its output:

lib/aio/attributes.ts
lib/aio/audit.ts
lib/aio/commerce.ts
server/admin/aio/queries.ts

Nothing there calls a model, and nothing there writes a stored score.

Working the rows

Curate product specifications and options first. Both count toward the attribute set, so an option axis you already needed for variants is doing double duty.

Then open Insights → SEO and work the four AI · rows — missing specs, thin specs, missing intent tags, no recommendation graph — plus the peer gaps.

Take the peer gaps seriously even when the product looks finished. They are the only findings sourced from what your own catalog already agrees is normal, and they hand you the exact label to use.

Publish, and both surfaces update from the same read.

The question the whole feature is asking about each product is:

If a machine had to answer a shopper's question about this product without reading the marketing copy, could it?

Related