# Catalog Data Coverage: What It Is and How to Measure It

> What catalog data coverage is, why it is calculated over the fields that apply to each product and how to measure it for Google and ChatGPT.

URL: https://clione.ai/glossary/catalog-data-coverage/
Lang: en

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](/glossary/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](/glossary/product-page/), its markup and its feeds, not URLs. It matters to you because the sites that read your [product catalog](/glossary/product-catalog/), from [Google Merchant Center](/glossary/google-merchant-center/) to the [ChatGPT feed](/glossary/chatgpt-product-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**.[^mc-spec] 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.[^openai-feed-spec] 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`.[^mc-spec] 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](/glossary/merchant-listings/) require in the markup a name, an image and an offer with a price greater than zero.[^google-merchant-listing] OpenAI's feed asks for nine required fields (identifier, title, description, URL, brand, seller name, image, [price and availability](/glossary/price-and-availability/)), and rejects the whole row if availability is missing or is not one of the accepted values.[^openai-feed-spec] Variants add their own fields, required only when the product has variants.[^openai-feed-spec] 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.[^mc-spec] 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.**


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.[^gsc-page-indexing] **In both cases, a lower number can be the right one**, and forcing it upward with filler makes the data you send worse.[^openai-feed-spec]


## How to check it

1. **Export the catalog** from your store's admin, with all the product and variant columns.
2. **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.[^mc-spec][^openai-feed-spec][^google-merchant-listing]
3. **Mark which fields apply to each product** according to its category, its condition and whether it has variants, before counting anything.[^mc-spec]
4. **Count only valid values**: discard the empty ones, the "N/A," the "unknown" where it is not allowed and the values the specification prohibits.[^openai-feed-spec]
5. **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](/glossary/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](/glossary/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](/glossary/publication-verification/).

To go further, the guide to [auditing a product page](/guides/audit-product-page-structured-data/) goes down to the detail of a single page, and the [measurement and verification reading path](/learn/measurement-and-verification/) orders the rest of the terms.