feedsmerchant-centereligibility

Approved is not visible: Merchant Center eligibility, parity and reporting contexts

Audit Merchant Center at offer-and-context grain, preserve source identity through migrations, and separate approval from actual serving.

The short version

“Approved” does not mean visible, and it does not mean serving. Merchant Center evaluates products separately by destination and offer context; campaign exclusions, feed-to-page mismatches and weak auction access can still keep an approved product out of sight.

Audit the complete offer instance—channel, language, feed label and offer ID. Before any API or app migration, snapshot source identities and dependencies; after cutover, prove that rules, supplemental links, campaign labels and processed IDs still match.

Separate the three gates

Treat exposure as three successive gates:

  1. Eligibility: is this offer approved for the destination and market instance?
  2. Visibility: can it enter the intended surface, or is another rule excluding it?
  3. Serving: did it receive impressions in the period reviewed?

Each gate has a different owner and fix. A disapproval needs a product-data or policy correction. An approved but excluded offer needs a campaign or inventory-filter change. An included offer that rarely serves may need a bid, budget, relevance or demand diagnosis.

Protect the source graph before a migration

A new primary data source is not proof that the old configuration carried over. Before changing an API, plugin or app, snapshot:

  • primary data-source ID;
  • feed label and language;
  • attribute rules;
  • supplemental-source links;
  • processed item-ID format;
  • label-bound campaign selection;
  • item-ID exclusions;
  • remarketing and cart-data IDs.

After cutover, diff the snapshot. If the primary source changed, rebuild or relink every source-scoped dependency before trusting product coverage. This is especially important for migrations that replace a Content API-created source with a new Merchant API source; Google also supports preserving existing sources, so replacement is not inevitable.

Name the reporting context before counting

A product can be approved for Shopping ads and disapproved for free listings at the same time. Every denominator must state its destination and snapshot date.

“92% approved” is incomplete. “92% of active UK Shopping-ad offer instances approved on August 29” is auditable.

Keep contexts separate until the final summary so a healthy paid-feed population cannot hide a free-listing problem—or the reverse.

Join at offer-instance grain, not SKU grain

The same SKU can appear in several channel, language, feed-label and country combinations. Those instances can carry different prices, statuses and issues.

Retain at least:

  • channel;
  • content language;
  • feed label or market scope;
  • offer ID;
  • destination or reporting context.

Before analysis, report source rows, unique processed instances, matched and unmatched rows, duplicate keys, destination and snapshot date. Low match coverage is a measurement problem, not a weak business result.

Build the population from products worth selling

Start from active, purchasable, in-stock offers. Add margin or a defensible margin band, recent demand, stock depth and issue duration where repeated snapshots exist.

Split the population into:

  1. missing from the feed;
  2. present but pending;
  3. present but disapproved;
  4. approved but not included;
  5. included but not serving;
  6. serving.

Rank gaps by commercial value, not item count. A small group of profitable products can matter more than thousands of low-value warnings.

Verify parity from feed to checkout

For a value-weighted sample, compare:

  1. the processed feed instance;
  2. the rendered product page and structured data;
  3. checkout.

Check price, sale dates, currency, availability, GTIN and brand, image, variant identity and landing URL. Record the exact offer key, conflicting values, surfaces checked, request time and owner; retest the same offer after the fix.

Check the gates after approval

Cross-check high-value approved offers against listing-group exclusions, inventory filters, campaign priorities and negatives, market and feed-label selection, bids, budgets and actual impressions.

No impressions do not automatically prove a feed defect. First show that the offer is eligible, included by campaign structure and measured in a comparable reporting window.

When enriching titles, identifiers or labels, use a reversible supplemental source rather than replacing the primary feed. Limit its fields and product population, save the pre-change baseline and define the rollback condition.

Preserve time and definition boundaries

A single snapshot proves current scope, not duration. Repeated snapshots or issue timestamps are required for “broken for weeks.”

Merchant Center's August 24, 2026 reporting update also separates YouTube affiliate traffic, restates affected history from July 1 and expands ads product reporting. A step across that boundary may be classification or coverage—not better or worse serving.

Save the pull time, timezone, destination and market filters, traffic definitions, query or export method and reporting window. Split time series at definition changes or recut both periods like for like.

Run the audit in this order

  1. Inventory primary, supplemental and API-written sources, with last-success times.
  2. Snapshot source identities and dependencies before migrations.
  3. Define active, purchasable, in-stock offers and add commercial weight.
  4. Export processed identities and per-context statuses.
  5. Join at full offer-instance grain; stop on weak coverage or duplicates.
  6. Quantify missing, pending and disapproved value by destination.
  7. Sample high-value offers for feed-to-page-to-checkout parity.
  8. Cross-check approved offers against campaign inclusion and impressions.
  9. Rank fixes by margin, demand and duration.
  10. Assign an owner, reversible change and verification condition.
  11. Repeat the same extracts and samples after the fix.

Run the product feed scanner before upload. Then verify processed status and serving in Merchant Center and Google Ads; a clean source file is only the first gate.

The finished report

State the population, join grain, match coverage, destination denominators, snapshot dates and reporting definitions. The top result should be a mechanism someone can fix: a parity break verified end to end, a value-weighted eligibility hole, a migration dependency that did not carry over or a serving gate on profitable approved inventory.

Sources