What is catalog data coverage?
Catalog data coverage is the percentage of product fields that have a valid value out of those that should have one, counting only the fields that apply to each product: color on a t-shirt yes, on a USB cable no. Catalog data coverage measures how much of what search engines and assistants ask for is present and usable.
Key takeaways
- Catalog data coverage is a ratio: fields with a valid value divided by the fields that product should have.
- It is calculated over applicable fields: Google Merchant Center requires some attributes only for certain categories or conditions, such as condition for a refurbished product.
- A field filled with "N/A" or "unknown" does not count as covered: Google and OpenAI both expressly ask you not to use those filler values.
- Each destination has its own list: coverage for the ChatGPT feed is not the same as for Google's merchant listings.
- High coverage says the data exists in the catalog, not that it is published or correct.
Catalog data coverage answers a question that looks simple: of the data your products should have, how much do they really have? It has nothing to do with indexing coverage, the kind that measures how many of your site's pages Google has in its index; here the fields of each product are counted, the ones that then feed its product page, its markup and its feeds, not URLs. It matters to you because the sites that read your product catalog, from Google Merchant Center to the ChatGPT feed, work from lists of fields, and one missing field can be enough for a product not to show. For this term there is no published standard: what follows is one way of calculating it, built on how Google and OpenAI tier their requirements.
How it is calculated
The formula is a division: fields with a valid value, divided by applicable fields. The two words that matter are "valid" and "applicable," and almost every measurement mistake comes from skipping one of them.
Applicable: not every field is for every product. The Merchant Center product data specification puts it in three levels: required (if you do not send it, the product cannot appear in ads or free listings), "depends" (on the product or the countries where it is shown) and optional. And many attributes change level depending on the product. Condition (condition) is required if the product is used or refurbished, and optional if it is new. Color, gender and age group are required for apparel targeting certain countries and for free listings across the whole apparel and accessories category, and optional for the rest. Brand is required for new products, except movies, books and music, and for a product that truly has no brand Google asks you to leave the field empty.[1]Google Merchant Center Help. Product data specification Counting that empty field as a gap punishes the store for doing what Google asks.
Valid: filled is not the same as covered. OpenAI, in its feed specification for ChatGPT, asks that an optional field with no data be omitted, that filler text such as null, unknown or n/a not be used (except where unknown is allowed) and makes clear that an empty value does not mean zero or false.[2]OpenAI Developers. Products (Agentic Commerce, file upload specification) Merchant Center runs along the same lines: for brand, no "N/A," "Generic" or "No brand"; for color, no "multicolor," "various" or a code like #fff000.[1]Google Merchant Center Help. Product data specification A catalog with every field filled with "N/A" has an apparent coverage of 100% and a real one that is much lower.
By destination: each reader has its own list. Google's merchant listings require in the markup a name, an image and an offer with a price greater than zero.[3]Google Search Central. Merchant listing (Product, Offer) structured data OpenAI's feed asks for nine required fields (identifier, title, description, URL, brand, seller name, image, price and availability), and rejects the whole row if availability is missing or is not one of the accepted values.[2]OpenAI Developers. Products (Agentic Commerce, file upload specification) Variants add their own fields, required only when the product has variants.[2]OpenAI Developers. Products (Agentic Commerce, file upload specification) That is why coverage without a destination says nothing: you have to say what it is being measured for.
In a store
Four products from a store, a fictional example, with eight fields, measured two ways. Applicability follows the Merchant Center rules cited in the previous section: color counts on the t-shirt, which comes in several colors; condition, on the refurbished phone; brand, on all but the handmade mug, which has none.
| Product (fictional example) | Applicable fields | With a valid value | What fails |
|---|---|---|---|
| Cotton t-shirt, several colors | 7 of 8 (condition does not apply: new) | 6 | Color says "multicolor" |
| USB-C cable, new, one color | 6 of 8 | 6 | Nothing |
| Refurbished phone | 7 of 8 | 6 | Condition is missing |
| Handmade mug, no brand | 5 of 8 | 5 | Nothing (brand says "N/A," but it does not apply) |
| Total | 25 | 23 |
Measured over applicable fields, coverage is 23 out of 25, or 92%, and the two gaps are exactly the ones that matter: apparel color and refurbished condition, which Merchant Center requires in those cases.[1]Google Merchant Center Help. Product data specification Measured the naive way (any value counts, over the eight fields of each product) it would come out at 25 of 32, or 78%: lower, because it penalizes fields that do not apply, and misleading at the same time, because it counts "multicolor" and "N/A" as good. The right number is higher and points at fewer things, but the things it points at are the ones that block.
What people often get wrong
Reading coverage as a 100% target for everything. In product data, 100% is measured over what applies, not over all the fields in the specification. Google says something similar about its own "coverage," the indexing kind: you should not expect every URL on a site to be indexed, only the canonical ones.[4]Search Console Help. Page indexing report In both cases, a lower number can be the right one, and forcing it upward with filler makes the data you send worse.[2]OpenAI Developers. Products (Agentic Commerce, file upload specification)
How to check it
- Export the catalog from your store's admin, with all the product and variant columns.
- Pick the destination and copy its list of fields: the Merchant Center specification, OpenAI's feed or the properties of Google's merchant listings, each with its requirement level.[1]Google Merchant Center Help. Product data specification[2]OpenAI Developers. Products (Agentic Commerce, file upload specification)[3]Google Search Central. Merchant listing (Product, Offer) structured data
- Mark which fields apply to each product according to its category, its condition and whether it has variants, before counting anything.[1]Google Merchant Center Help. Product data specification
- Count only valid values: discard the empty ones, the "N/A," the "unknown" where it is not allowed and the values the specification prohibits.[2]OpenAI Developers. Products (Agentic Commerce, file upload specification)
- Report by field and by destination, with the required fields apart, and repeat the measurement after every import or sync. If you send the catalog with Clione, the feed settings show the last five versions generated, what each one left out and why.
Related concept: catalog enrichment
Coverage measures the gap; catalog enrichment fills it with data that is missing or that is not usable as it stands. They go in that order: without a coverage measure you do not know what to enrich first, and without repeating it afterward you do not know whether the enrichment worked. The catalog audit is the broader exercise, which besides counting fields checks whether their values are good. And none of the three says whether the data reaches the public page: that is publication verification.
To go further, the guide to auditing a product page goes down to the detail of a single page, and the measurement and verification reading path orders the rest of the terms.
Synonyms
- English
- catalog data coverage, product data completeness
- Español
- completitud de los datos de producto
Sources
- [1] Google Merchant Center Help. Product data specification. Accessed . ↑ ↑ ↑ ↑ ↑
- [2] OpenAI Developers. Products (Agentic Commerce, file upload specification). Accessed . ↑ ↑ ↑ ↑ ↑ ↑
- [3] Google Search Central. Merchant listing (Product, Offer) structured data. Accessed . ↑ ↑
- [4] Search Console Help. Page indexing report. Accessed . ↑
Change history
- First English version.
This definition is published under CC BY 4.0. Reuse this definition freely, crediting Clione with a link to this page.
Related terms
Product attributes
What product attributes are, where they are stored, how filters, Merchant Center and schema.org read them, and which attributes create variants.
Product feed
What a product feed is, which fields it carries, how Google Merchant Center and ChatGPT receive it and why it has to match the published product page.
Catalog enrichment
What catalog enrichment is, what data it completes on each product and how to tell original data, inferred data and the human decision apart.
Catalog audit
What a catalog audit is, what it checks in your product data, how the sample is chosen and why the result is a list of failures, not a score.
Google Merchant Center
What Google Merchant Center is, how your product data gets there, where Google shows it and how to check that the feed and the product page match.
Schema Markup Validator
What a schema validator is, what the Schema Markup Validator checks, how it differs from Google's Rich Results Test and which errors neither one sees.
Make your catalog easy for bots to read
Clione fills every product page with what bots read best: the JSON-LD graph with its structured data, the meta description and the FAQs. You review and press Push; then we check your live store so it all stays published.