Resolution Layer Case Study · Read & Diagnose
Athletic footwear specs.
A catalog read of a global athletic footwear brand's US men's shoes category — where the product pages carry a deep product record, and in places that record disagrees with itself.
This is a real EKOM catalog analysis, with the client's identity removed. The subject is a global athletic footwear brand's own US store, read in its men's shoes category. The product pages sampled carry a deep record: availability, fit, upper material, surface, closure, weight, stack height and drop where published, and a barcode for each size. Twenty-two findings are reported here. Page eight accounts for the ones that were not.
A shoe is chosen on its specs — a width for a foot, a drop for a stride, a surface for a ground. On this store those specs are stated twice: once as structured attributes, which the site's filters and comparisons are built on and which AI assistants can lean on, and once in the copy a shopper reads. This read asks whether the record agrees with itself.
The deeper a product record is, the more ways it can disagree with itself. A wide shoe that is not in the wide filter is not missing data. It has the data twice, and the two copies say different things.
Product names and article numbers are described rather than quoted here. Counts are exact, as of the two days the pages were read.
What's inside
- At a glance — the severity split, where the twenty-two concentrate, and how the read was done.
- Launches told to search engines as in stock — the lead finding.
- Specs that contradict the shoe's own page — fit, material, surface and closure.
- Stack heights no comparison can use — geometry that breaks its own arithmetic.
- Colorways, types and copy — one shoe with two records, and the smaller items.
- Confirming against source, and where it traces back — what was set aside, and the four mechanisms EKOM reads in the rest.
Nothing was supplied and no internal system was touched. Everything below was read from the product data the brand embeds in its own public pages.
3 of 3
"Coming soon" shoes that
tell search engines they're in stock
11
Shoes in a sample of 100 whose
specs contradict their own page
5 of 24
Shoes publishing stack height
with self-contradicting geometry
4 of 5
Same-shoe colorway pairs
that disagree on spec
Where the twenty-two concentrate
Theme
What it is
Findings
Availability signals
Pre-release shoes told to search engines as in stock
1
Shoe geometry
Heel, toe and drop figures that are impossible or reversed
3
Specs vs the shoe's own page
Fit, upper, surface, closure and measurements that contradict the copy or every comparable shoe
7
Colorway consistency
Colorways of one shoe with different specs; editions classed apart from their model
2
Product classification
Missing product types, a kids' shoe in men's, malformed model codes
3
Copy and naming
Template errors, markup residue, models titled in two letter cases
6
How EKOM read this catalog
1
Read
An analyst browsed the store as a shopper would, signed out, one page at a time, and saved each page as it loaded. No crawler, no credentials, no integration.
The category listing, and 100 product pages covering every product line, sale and full price, sold out and coming soon.
→
2
Analyze
Infer what each field is for from how the catalog itself uses it, then hold every shoe to that. Surface the disagreements, rate severity, and tie each to the shoes behind it.
22 findings, 6 themes, 4 mechanisms.
→
3
Check
An analyst checked every result against the original saved pages, recomputed every count, and asked of each whether the pattern could be deliberate.
58 raised, 22 held as defects; the rest are accounted for on page eight.
Signals from a read of the published data, checked by an analyst; not yet confirmed against the brand's own systems. Severity: 4 high, 12 medium, 6 low. A sample, not a census, for product pages. Counts like "3 of 3" show that a pattern exists; they are not its rate across the catalog. Two days, during an active sale. A finding may have been corrected since.
Launches told to search engines as in stock.
Every sampled product page carries structured data that search engines and shopping surfaces can read, and that AI shopping assistants can read to answer "can I buy this?". On the "coming soon" pages, it says something the page itself does not.
High · Availability signals
All three "coming soon" shoes in the sample publish "in stock". None of their sizes can be bought.
Each of the three pre-release pages tells search engines the shoe is in stock, while the brand's own stock data on the same page marks every size as pre-release. Search results and shopping ads can then show these shoes as buyable before launch, and any assistant that reads the value is told the same. The schema.org vocabulary has a value made for exactly this state: pre-order.
Everything else in the sample was consistent
Of the other 97 sampled pages, 93 were in stock and said so, and 4 were out of stock and said so. That points to one missing mapping rather than page-by-page errors: if the pre-release status has no value today, mapping it to pre-order publishes every launch correctly from then on.
A launch page is where a brand gathers demand before a drop. A shopper who finds one of these shoes through a search result or an assistant can be told it is in stock, and arrive at a page where no size can be added to the bag.
Specs that contradict the shoe's own page.
On eleven of the 100 sampled pages, the structured attributes disagree with the shoe's own description or feature lines, or with every comparable shoe.
Medium · Specs vs the shoe's own page
An extra-wide running shoe filed as regular fit, and a nylon-and-suede shoe filed as leather.
A shoe whose name says extra wide carries a regular fit; a shoe whose copy says narrow carries no fit at all. A shoe described as nylon with suede overlays is filed as a leather upper. A baseball cleat carries a tennis surface, where every other baseball cleat in the sample is multi-ground. A slip-on mule is filed as hook-and-loop, and three laced shoes carry no closure. Two more carry a weight or a stack figure that differs from the numbers in their own copy, and one has its heel and toe reversed (page six).
Who reads the attribute, not the copy
A shopper who filters for wide does not see the extra-wide shoe. A shopper who filters for leather is shown nylon and suede, and one who filters for laces misses three laced shoes. An assistant asked for a wide running shoe can lean on the fit attribute — and where the attribute and the copy disagree, nothing on the page says which is right.
The correction is a check, not eleven edits: each attribute read against the copy on the same page and against comparable shoes, every disagreement flagged with the proposed value and the text it came from, and the brand's product team deciding once which source wins.
Stack heights no comparison can use.
Stack height and drop are how a runner compares one shoe with the next. Drop is heel stack minus toe stack. Of the 24 sampled shoes that publish real stack values, five break that arithmetic.
High · Shoe geometry
Drops many times the heel-to-toe difference, two zero drops on raised heels, and one shoe with heel and toe reversed.
One sneaker carries a drop several times taller than its own heel. Another carries a drop nearly ten times its heel-minus-toe. Two shoes whose heels sit above their toes carry a drop of zero. And a running shoe has its heel and toe stored the wrong way round, so it reads as heel-low; its own copy gives the right values. Any filter, sort or side-by-side comparison built on stack or drop can put each one in the wrong place.
Most sampled shoes do not publish stack height at all
76 of the 100 sampled shoes carry 0.00 for heel and toe stack — a placeholder for "not provided", applied consistently, so it is not counted as a defect. But a filter or comparison can read it as zero, not as missing. Storing it as empty keeps those shoes out of a "lowest stack" sort they do not belong in.
One validation rule — drop equals heel minus toe, within a millimeter — catches all five before they publish. Four correct from their own record; the fifth needs the spec sheet to say which number is wrong. Three more shoes sit 1 mm off, consistent with rounding from inches, and are not counted.
Colorways, types and copy.
Medium · Colorway consistency
Four of five same-shoe colorway pairs disagree on spec.
EKOM deliberately sampled five shoes in two colorways each. In four of the five pairs, attributes that should not change with color — sport, closure, features, upper material — differ between the two. Each disagreement can mean one colorway shows up under a filter and its twin does not. Separately, two special editions of a lifestyle shoe are classed in the performance line while every other shoe on their models is in the lifestyle line.
The smaller items
- Product classification (3): six shoes with no product type where comparable shoes have one; a kids' cleat listed in the men's category; and two model codes with a stray suffix, so those shoes do not group with their model.
- Copy and naming (6): a search snippet template that doubles a word when the product name begins with it; "N/A" as a feature line, a malformed markup tag and a misspelled unit in feature text; descriptions that open with blank lines; one model's name in mixed case; product names in all capitals beside title case; and 38 models whose colorways are titled in two different letter cases.
Why the casing needs a rule with exceptions
A blanket title-case transform would break the names that are right — technology and line abbreviations written in capitals on purpose. The correction is one approved casing per model, with a protected list of brand and technology names.
Confirming against source.
The automated analysis raised fifty-eight findings. Twenty-two are reported. Every one of the others is accounted for here.
Set aside · twenty-nine findings
Seven came from how EKOM collected or reshaped the data, not from the brand's. Twenty were deliberate choices or normal behavior: ratings shown at model level on every colorway, a "no reviews" placeholder that is never displayed, a "rarely on sale" badge that is used as a sale message, a gender word in subtitles applied exactly to the men's products, a soccer-only shoe type, and a color name spelled the brand's own way. Two were not supported by the source.
Patterns noted, not counted · four
Discount badges that round down and never overstate the cut; stack heights unpublished on most sampled shoes; no product type for slides, because the type list has no value for them; and one-line launch copy on all three sampled collaboration releases. Each is applied consistently enough to look intentional.
Open questions, not claims · three
Two unrelated models that show exactly the same rating and review count; a group of shoes whose weights may be per pair rather than per shoe; and a placeholder model code shared by a run of university editions. Each is real in the data, and its cause cannot be settled from outside.
Asking whether a pattern could be deliberate is part of the read. Twenty findings that looked like defects were deliberate choices or normal behavior, and are not counted.
Most of the twenty-two collapse into four 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.
The same fact stored twice, and never reconciled
The tell: attributes and copy on the same page that disagree, and an availability value that tracks stock on every other sampled page but appears to have no value for pre-release.
Shoe-level attributes kept per colorway
The tell: sport, closure, features, upper, product line and name casing that differ between colorways of the same model.
Measurements entered without a rule
The tell: a drop that is not heel minus toe, heel and toe reversed, and copy that gives measurements in inches and grams beside fields kept in millimeters and ounces.
Templates and taxonomies with an unguarded edge
The tell: a snippet template that doubles a word, "N/A" as a feature, shoes with no product type, and a kids' cleat in the men's category.
What this means, and what's next.
An athletic footwear brand builds shoes a shopper can choose with precision — a fit for a wide foot, a drop for a particular stride, a surface for a particular ground. The product record is where that precision is kept or lost. On most of what EKOM read, it is kept. Where it is lost, a shopper filtering for a wide shoe does not see the one built for it, a runner comparing drop is shown a number that contradicts the shoe's own figures, and a launch is described as available before any size can be bought.
None of this needed access to the brand's systems. Every defect here was found in data the store already publishes in its own pages — the same data search engines, shopping surfaces and assistants can read.
This pass read and diagnosed. The same structural understanding powers what follows — turning a diagnosed catalog into one whose record agrees with itself.
1 · Apply the corrections the record already answers for itself
Map pre-release to pre-order. Correct four of the five geometries by arithmetic. Clear the template residue. Approved as rules, not shoe by shoe.
2 · Settle the questions that gate the rest
Which of two values the product team signed off where attribute and copy disagree, the true geometry where the record cannot say, and where a kids' shoe belongs. Each is a judgment the data can show but cannot make.
3 · Hold the line at publish
Keep shoe-level attributes on the model so every new colorway inherits them, and check each new article's attributes against its own copy before it goes live.
This is how EKOM moves a catalog from insight to impact —
and keeps every shoe's record in agreement as the catalog grows.