Resolution Layer Case Study · Read & Diagnose
Eyewear structured data.
A catalog read across one premium brand's sunglasses at a specialty eyewear retailer — where every frame and lens combination has its own page, and a second copy of the product, written for search engines, is supposed to say the same thing.
This is a real EKOM catalog analysis, with the client's identity removed. The subject is a specialty eyewear retailer that sells a premium sunglasses brand frame by frame, each frame and lens combination with its own barcode and its own page. EKOM read the structured product data that every one of that brand's pages publishes for search engines, and raised twenty findings. Fifteen are reported here. Four were withdrawn and one was merged into another. None of those five is in any count below, and page nine says what happened to each.
What makes this catalog different is that, on the five pages opened, the page a shopper reads is right. On the pages opened, the title, the trademark symbol and the price all render correctly. Beneath the page sits a second copy of each product, written for search engines and shopping listings: a name, an identifier, a group, a category. Most of what this read found is in that copy, and none of it was visible on those five pages.
The shopper reads the page. The search engine reads the record. When the record is wrong, the page can look perfect and the product can still be grouped, named and filed wrongly in what a search engine reads.
Product names and values are described rather than quoted here. Counts are exact, and every one of them is the analyst's recount from the saved product records, not the automated pass's first estimate.
What's inside
- At a glance — the severity split, where the fifteen concentrate, and how the read was done.
- Two records, one page — the lead finding, and a trademark symbol written as text.
- Group IDs cut to six characters — different models in one group, one model in many, and team editions.
- One line set up differently — a youth line with almost no data, and a batch of products on another template.
- Smaller items, coverage and price signals — what is rated low, and what is not rated at all.
- Confirming against source, and where it traces back — the findings that did not survive, and the six likely mechanisms EKOM reads in them.
Nothing was supplied and no internal system was touched. Everything below was read from the structured data the retailer's product pages publish, and five of them were opened in a browser to compare the page with the data behind it.
15
Findings reported
(20 raised)
Where the fifteen concentrate
Theme
What it is
Findings
Two records
Two embedded records per page that disagree on what identifies the product
1
A character that does not render
A trademark symbol written as the text of its code point
1
Product groups
A six-character group ID that joins different models and splits one model
2
A youth line
Twelve products with almost no data, and part numbers off pattern
2
Fields in different forms
Taxonomy paths, name formats, material codes, colour casing, image names
6
Coverage gaps
Pages with no record, and barcodes at two addresses
2
A sale signal with no sale
A "sale" price equal to the list price
1
How EKOM read this catalog
1
Read
The product record that every page of the brand embeds, read a page at a time from the public endpoint of the vendor that serves it, at an address its robots.txt permits. No file handoff, no credentials, no integration.
Every page answered. A small number carry no product record.
→
2
Analyze
Infer what each field is for from how the rest of the catalog uses it, then hold every record to that. Surface the disagreements, rate severity, and bind each to the products behind it.
15 findings, 7 themes, 6 mechanisms.
→
3
Check live
Open five pages in a browser and compare what the shopper sees with the data embedded in the page.
The visible page is mostly right. The data behind it is where the findings sit.
Machine-surfaced signals from a cold read, not a verified defect list. Some will prove intentional, which is why each is tied to the values behind it. One brand, one day. Other parts of the catalog may share these patterns; that was not measured, and the data is a point-in-time read.
High · Two records
Every page checked embeds two product records, and they disagree on what identifies the product.
On all five pages opened in a browser, one record comes from the vendor that serves the structured data and one from the site itself. On the page examined in detail, the vendor's record makes the SKU the barcode and the part number the model, and the site's record does the opposite. The names differ, and the vendor's record carries a product group ID where the site's carries none. Prices agreed between the two records and with the visible page on every page checked. A search engine receives two descriptions of one item with the identifiers swapped, and has to pick one.
Field
Vendor-served record / site's own record
Verdict
sku
the barcode / the model
differ
mpn
the model / the barcode
differ
name
a long templated title / a short marketing name
differ
group ID
present / none
differ
High · Character not rendered
Twenty-five products carry the text “U+2122” where the trademark symbol belongs.
The literal characters appear in the description of twenty-five products, in the name of ten of them, and in the colour of ten. No product name, description or colour contains a real trademark symbol. On the live pages checked, the visible title and heading show the symbol correctly, while the data embedded in the same page carries the text. Shoppers do not see it on the pages checked; a search engine that reads the embedded data receives it. The site's own copy also disagrees with the vendor's on which mark one product carries, registered or trademark.
Which record is the record of record is the retailer's to say. The other defects in this read were measured in the vendor-served record, and the site's own record was checked on five pages only. The two-record pattern is why they matter: a feed that reads one record and a feed that reads the other will not agree on what the product is, however clean each is on its own.
Group IDs cut to six characters.
The product group ID is the field Google Shopping uses to group the colour and size variants of one product. Here it is a fixed six-character code built from the model or collection name, and it fails in both directions.
High · Group ID cut to six characters
Fifty-one group IDs each span more than one model, together covering 690 products.
Longer names are cut mid-word, shorter ones are padded with zeros (72 products carry a padded ID), and trademark and registered marks count as characters. All but one of the products that carry a group ID follows the rule. The widest groups hold ninety-five products across nine models, sixty-nine across nine, forty-four across five, and twenty-one across fourteen. Which side cuts the ID, the retailer's data or the vendor's, was not determined.
Same finding · The other direction
Forty models are split across more than one group ID, covering 488 products.
One model sits under eight group IDs, two of them city prefixes and not the model; one licensed team model sits under thirty-one. A grouping field that splits one model puts its variants in different groups.
High · Team editions share a prefix
Licensed editions appear to be grouped by the first six characters of a team name, so teams from one city share a group.
One group holds nine products across five model numbers, covering two teams of one city, and another holds four across three. On the live page checked, the vendor's record carries the group ID and the site's own record carries none. How team editions should group, by team, by frame or both, is a call only the merchandising side can make.
The grouping is derived from a name, not decided. A group ID cut from a name collides where names share a prefix and splits where one model is named several ways; the model number is on nearly every record, but it does not settle team editions, which share one across teams.
One line set up differently.
High · Sparse records
Twelve products in a youth line have no barcode field, colour, material, group ID, category, gender, minimum age or sale price.
They carry one image where every other product carries two, and the product category is missing on them alone. The barcode is not lost: it is in the SKU and in the web address. The descriptions use their own template, so colour and size are there as text. Checked live on one of them, both embedded records were equally thin — on that page, how the product is set up and not a gap in one source.
High · Part numbers off pattern
The same twelve products do not use the base model number as their part number.
Ten carry a model plus colour code, and two carry the barcode itself. Every other product uses the base model number with an optional letter.
Medium · Fourteen products on another template
Fourteen products carry a taxonomy path in the category field, in seven spellings, and are named in a second format.
Every other product's category is the audience: men, women or unisex. These fourteen hold a free-text breadcrumb instead, so a filter built on the audience would not match them. Their names read like marketing titles where the rest follow one template, the youth line uses a third, and the visible page title a fourth. On the one checked live, the path and the name are in the embedded data only.
Both are batches set up outside the main template, each differing from the rest in several fields at once, in the same way across the batch. For the youth line, the barcode, colour and size are recoverable from the record itself.
Smaller items, coverage and price signals.
Four findings are rated low, and three more came from EKOM's own checks across the full set and are reported without a rating.
Low · Material as internal codes
Two internal codes stand in for the frame material on the large majority of products (1,124 carry one, 32 the other), and the descriptions repeat them. Other materials appear as plain words on some of the rest.
Low · An unexplained word in 492 descriptions
One word follows the material in 492 descriptions and not in others, across three of the materials. What it means is not stated in the data and is not assumed here.
Low · Colour casing
One colour value is capitalised differently from the name that describes it, on 31 products. The same colour appears under two spellings.
Low · Image naming
Eight products use a different image filename pattern from the rest, and the youth line uses a third. Image content was not compared.
Not rated · Pages with no product record
32 product pages carry no vendor-served product record: 24 return an empty record and 8 return only a page entry. For these the vendor serves no product data to a search engine.
Not rated · One barcode, two addresses
114 barcodes are listed under two different web addresses in the retailer's sitemap. This one is measured across all brands in the sitemap, not the one brand alone.
Not rated · A sale price equal to the list price
85 products carry a "sale" price equal to the list price — 54 in stock and 31 out of stock — beside discounts elsewhere in the catalog. A feed that reads a sale price as a sale reads these as a discount of nothing.
Filled in is not the same as right.
One idea about the findings rather than more findings — because it explains why almost none of this would appear on a fill-rate report.
Nearly everything this study found is filled in. The group ID is populated — with a code cut from a name. The name is populated — with a code point written out as text. The category is populated — with a breadcrumb. A completeness check scores those fields as filled; for the products affected, they hold the wrong value.
What is strong · stated before the accounting
Several things are consistent.
Prices agreed across the vendor's record, the site's own record and the visible page on every page checked, and every offer price equals its sale price or, with no sale, its list price. Every product with a barcode carries it consistently, in the barcode field and in the field that matches its length. The product category is present on everything but the youth line, no product appears twice, and every request in the read was answered. For several of the defects, the right answer is already on the same page.
The defects are wrong values in fields that exist, not fields that are missing. A correction has somewhere to land, and it reaches Google through a channel that already works.
Confirming against source.
Twenty findings were raised and fifteen are reported. Every one of the other five is accounted for here — and so are the principal figures that moved between the automated pass and the analyst's recount.
Withdrawn — the reading, not the catalog · two findings
One said a lowercase "unisex" value sat beside "Male" and "Female"; the second asked for a ruling on that casing. In the data the values are namespaced and the plain value is the only one without a prefix, so converting the data for analysis created the contrast. Both described EKOM's own conversion.
Withdrawn — not defects · two findings
One said a product name combines several kinds of information; a display title is meant to be composed. One said the 13-digit barcode field is mostly empty; a barcode goes in the 12-digit or 13-digit field according to its length, and every product that has one carries it.
Merged · one finding
A second field carrying the same trademark-symbol text is the same defect as the first, in another field. It is reported once.
Recounted · four principal figures
The automated pass's first counts did not match the saved records: thirteen products with the symbol text became twenty-five, five with the colour casing became thirty-one, thirteen taxonomy paths became fourteen, and twenty-two off-template names became twenty-six. The recounts are the figures used throughout.
Found by EKOM's own checks · five findings
Five of the fifteen came from EKOM's own checks across the full set and the live pages, and are counted among the fifteen.
Withdrawing findings is what a cold read is for. A report that had shipped the casing finding would have told a retailer its gender field was inconsistent when the inconsistency was ours.
Fifteen findings sound like fifteen problems. Most of them collapse into six likely mechanisms — and a mechanism can be corrected once and stopped from recurring. Each tell below is a pattern in the data; the mechanism is EKOM's reading of it.
Two producers of one page's data, not reconciled
The tell: two records per page that disagree on what identifies the product, with different names, and a group ID on only one of them.
An identifier built by rule from a display name
The tell: a fixed six-character code, cut when long and zero-padded when short, counting trademark marks as characters. All but one product that carries one follows it.
A character that reaches the embedded record as text
The tell: on the pages checked, the visible page renders the symbol correctly; the embedded record carries the code as text, as served.
Product lines set up outside the main template
The tell: two batches, twelve and fourteen products, each differing from the rest in several fields at once, in the same way across the batch.
Internal codes passed through as display values
The tell: a material shown as a code, a word after the material on some descriptions and not others, and a colour in a different case from the name that describes it.
No check at the point of publication
The tell: pages with no record, a barcode at two addresses, and a sale price equal to the list price are all consistent with no check where the record is published.
Replacing the character on twenty-five products corrects twenty-five products. Building the group ID from the model, and checking the record before it is published, corrects those and every product added after them.
What this means, and what's next.
An eyewear retailer sells how a product looks and how it fits. The shopper comparing two pairs reads the title, the colour and the price, and assumes the page is telling one story. Online, the data behind the page carries that story to search engines and shopping listings — and on these products it tells a different one: a name that reads as code, a group that joins fourteen models, a record with no barcode field, and a sale of nothing.
None of this needed access to the retailer's systems. Every defect here was found by reading data that each page already publishes to anyone who asks — the data Google reads — so the same read is open to any search engine, marketplace or assistant.
This pass read and diagnosed. The same structural understanding powers what follows — turning a diagnosed catalog into one that tells a shopper, a search engine and an assistant the same thing about every product.
1 · Apply the corrections the record already answers for itself
Write the symbol where the text stands. Move the youth line's barcode, colour and size from where they sit into the fields a feed reads. Replace the fourteen taxonomy paths with the audience each product's own gender gives, and match the colour casing to the names. Approved as patterns, not product by product.
2 · Settle the questions that gate the rest
Build the group ID from the model instead of a name, once the retailer confirms how team editions should group. Decide which of the two records is the record. Say whether the sale-equals-list prices, the pages with no record and the sparse youth records are intended. Each is a judgment the data can show but cannot make.
3 · Hold the line at publish
Keep ongoing intelligence where the record is published, so the next product that goes live with a cut group ID, a code point written as text or no record at all can be checked as it is published rather than found later by a search engine.
This is how EKOM moves a catalog from insight to impact —
and keeps the machine's copy of every product agreeing with the page as the business grows.