Missing GTINs, Bundles, and a Corrupted Custom Label

Ranking

1. GTIN completion for the 950 single items. These have a real, verifiable GTIN that the feed omits, so the fix removes an eligibility/matching constraint and is mechanical to execute: build a GTIN column keyed on SKU, upload as a supplemental feed with a feed rule that takes GTIN from the supplement when the primary is empty. This is where the 'Limited performance' overlap most likely sits, and it is the only fix with a direct eligibility upside.
2. Bundle identifier handling. The 700 bundles are legitimately identifier_exists: no, but if the attribute is set inconsistently they may sit in the same warning bucket as fixable items, masking the real problem and inviting a blanket override later.
3. Custom-label cleanup. Zero direct revenue effect; it unlocks segmentation, so it is cheap but not urgent.

Confirmation data

• Overlap count: items flagged 'Limited performance' that also appear in the 950 vs the 700.
• Pre/post comparison on a matched cohort: add GTINs for half the 950 first, hold the other half for two weeks, compare impressions, click share and ROAS.
• Check whether the 140% ROAS of the no-GTIN group is driven by the 700 bundles (structural, low-value) rather than the 950 (fixable). If the 950 look like the bundles, re-rank.

Rule logic

• If GTIN (or brand + MPN) is populated and validates to 8/12/13/14 digits with a correct check digit → set identifier_exists: yes and suppress any manual override.
• If SKU is in the bundle/multipack list AND no manufacturer GTIN exists for the bundle as sold → identifier_exists: no.
• If SKU is a single item with a known GTIN but the column is empty → leave identifier_exists unset and raise it as a data-quality exception, rather than defaulting to 'no'.
• Never derive the value from 'GTIN is blank' alone; blank is a data gap, not evidence of non-existence.

Why a blanket 'no' is risky

It converts a fixable gap into a permanent declaration. You tell Google the product has no identifier, which suppresses matching to the product catalog and any GTIN-based enrichment, and you lose the ability to detect the real gap later because the warning disappears. It also scales the problem: 950 SKUs silently move from 'fixable' to 'misdeclared'. If they are audited or the policy tightens, the whole group is exposed. Keep the override list narrow, source it from a maintained bundle table, and review it monthly so the exceptions do not quietly become the default.

Scheme

Use one attribute for one decision, with a closed value set:

• custom_label_0 = season, values season_ss24, season_fw24, season_ss25, season_core (evergreen), season_clearance. Five values, lowercase, no spaces.
• Move other decisions to the empty labels: custom_label_1 = margin tier, custom_label_2 = stock status or bestseller rank.

Add a feed rule that maps raw values to canonical values (a lookup on the 14 variants), so the source system can keep its messy input while Merchant Center receives five clean values. Enforce the set at upload with a validation that rejects unknown values.

Migration without losing history

Do not rename everything in one upload. Reporting is keyed on the label value, so a rename looks like a new segment. Sequence it: (1) add the canonical values alongside the old ones for one full reporting cycle, (2) confirm the mapping covers 100% of SKUs and that no SKU carries both an old and a new value, (3) switch the campaign product groups to the new values, (4) keep the old values for 90 days as a reference before dropping them. Export a SKU-to-old-value-to-new-value mapping table so any historical comparison can be reconstructed offline.