Why your product feed is lying to someone right now

Peter Tomko — Mon, 09 Nov 2026 21:21:00 +0000

Why your product feed is lying to someone right now

Part 1 of 6 in CatalogSentry's launch series.

Every feed-format validator will tell you your feed is clean. Every field is present. Every
price is a number. Every GTIN matches the expected pattern. And your feed can still be
wrong — not malformed, wrong — in ways that none of that checking catches.

Here's the gap: field-format validation asks "does this field exist, and is it the right
type?" It never asks "do these two fields, both describing the same product, actually agree
with each other?"

The silent contradiction

Picture a listing for a phone. The title says "Samsung Galaxy S24 256GB." The description
says "with 128GB storage, stunning display and all-day battery." Both fields are present.
Both are well-formed strings. A format validator has nothing to flag. But a buyer reading
the full listing — or a marketplace's own content-quality system — is looking at two
different products described as one.

This isn't a hypothetical. It's one of the four examples baked into CatalogSentry's own demo
fixture, and we'll show the exact output in part 3 of this series. The point here is the
shape of the problem: a feed can pass every format check it owns and still contradict
itself in the fields that actually describe the product to a buyer.

What this actually costs

Three concrete failure modes, in order of how visible they are:

Marketplace rejections or suspensions. Marketplaces increasingly run their own content-quality checks on listings before (or after) they go live. A title/description mismatch, a duplicate GTIN across two SKUs, or two "variants" that are secretly identical products are the kind of thing that gets a listing pulled or a seller account flagged — and you find out from the marketplace, not from your own tooling.
Confused buyers, and the support/return cost that follows. A buyer who orders based on "256GB" and receives something that was actually specced at 128GB in the fine print is a buyer who returns the item, opens a support ticket, or leaves a bad review — all of which cost more than catching the contradiction before the listing went live would have.
Lost conversions from duplicate or indistinguishable listings. Two SKUs secretly describing the same product split your reviews, split your sales rank, and confuse shoppers comparing "variants" that turn out to be identical. None of that shows up as an error — it shows up as quietly worse performance you can't easily trace back to the feed.

Why this keeps happening

Feeds get built from multiple source systems — a PIM, a spreadsheet a merchandiser edits by
hand, a supplier data dump — and titles, descriptions, and attributes often get written or
updated independently of each other. Nobody intends to ship a contradiction. It accumulates
from reasonable, independent edits to fields that nothing checks against each other.
At catalog volume — hundreds or thousands of SKUs, updated on a schedule, by more than one
person — this isn't a rare accident. It's a predictable rate of drift, and the only way to
catch it reliably is a check that compares fields against each other, every run, the same
way every time.

What catches this

That's the layer CatalogSentry adds on top of your existing feed: it checks that your
product feed agrees with itself — not just that each field is present and the right type.
Deterministic checks, no inference calls, no vibes — every finding names the exact SKU, quotes
the conflicting values, and recommends a fix. We'll walk through exactly what the original four
checks do, with real output, in the rest of this series (see part 2 for the current, larger set).

Worth saying plainly up front, since we'd rather you hear it from us than discover it
yourselves: this is an early-stage tool. It's been run once, end-to-end, against a real
995-product public catalog (not a synthetic fixture) with every check enabled — no crashes,
real findings, real evidence. It has not yet been run against a real customer's own feed. What
we're telling you in this series is what it does today, not a promise about what it will catch
in every feed you throw at it.

Next: Part 2 — what CatalogSentry actually checks today

Want to see this run against a real feed before reading further? Try
the interactive demo, or run CatalogSentry (AI Product Intelligence Engine) directly
on Apify Store — it's live today.

DEV Community: Peter Tomko

Why your product feed is lying to someone right now

Why your product feed is lying to someone right now

The silent contradiction

What this actually costs

Why this keeps happening

What catches this