How to Use Merchant Center Supplemental Sources

Start with one explicit problem, such as adding a missing custom label, correcting a governed title field for a bounded group, or providing a regional attribute. Google defines a supplemental data source as a secondary source that can add or update details missing from the primary source. It cannot add or remove products and cannot operate by itself. That boundary matters because the primary source remains the catalog authority.

Write a field ownership table before uploading anything. For every proposed attribute, name the source system, transformation, eligible product set, refresh owner, and rollback value. Avoid sending every catalog column simply because it is available. A narrow file makes conflicts visible and lets the team remove the supplemental layer without reconstructing unrelated fields. Keep price, availability, identifiers, and policy-sensitive data under the system that can update them reliably.

Enable the Advanced data source management add-on, create the supplemental source, and link it to the intended primary source. Google instructs merchants to match the product ID and feed label exactly and to align the language. Treat those fields as a join key contract. Normalize them before upload, reject blanks and duplicates, and compare a sample against the primary source before allowing a scheduled refresh.

Do not assume a successful file upload means a successful join. Inspect rows that matched, rows that did not match, and products that unexpectedly inherited a value. If multiple primary sources or subaccounts exist, document which source receives the supplement and whether account-level rules override subaccount behavior. Keep separate files when two business processes own different attributes so a later correction does not silently overwrite an unrelated workflow.

Build attribute rules as drafts and use Merchant Center's preview before applying them. Google says the rules test can show attribute changes and projected approved, disapproved, and excluded item states. Review a known product that should change, one that should stay unchanged, one with incomplete input, and one near a policy boundary. A passing happy path is not enough to approve a catalog-wide transformation.

Save the draft definition and test result with the source version. If the preview creates an item issue, changes a value outside the intended set, or cannot explain the output, stop and revise the rule. Google notes that a full test can take time, so schedule this as a controlled change rather than an emergency production edit. Apply only after the owner accepts the exact field and product impact.

Begin with a small, representative product set. Include common products, variants with edge-case identifiers, and items with existing issues. After processing, compare the effective attributes in Merchant Center with the approved input and inspect destination eligibility. Distinguish file-processing success from product approval and from ad or free-listing appearance. Each stage has different latency and failure causes, so one green status does not prove the whole path.

Record the submission time, source version, rule version, affected IDs, expected fields, processing result, item issues, and owner decision. Expand only when the canary behaves as designed. If results diverge, disable the rule or unlink the supplement using the documented rollback, then wait for the next processing cycle before deciding that recovery is complete. Do not stack another correction onto an unexplained first change.

Assign a refresh cadence that matches the attributes. Stable campaign labels may change slowly, while availability and price require a more reliable operational path. Monitor last successful fetch or upload, matched item count, rejected rows, changed fields, and newly introduced issues. Alert on stale data and unexpected volume changes. A spreadsheet that no one owns should not become a permanent dependency for product eligibility.

Review the source quarterly and whenever the primary catalog model changes. Remove fields that now belong in the primary system, retire obsolete rules, and verify that rollback files remain usable. Keep the supplemental source as a visible exception layer, not a hidden repair pile. The operating goal is a small, explainable set of enrichments whose origin, effect, and removal path are clear to both marketing and catalog teams.

Use a change log that names the business question behind each attribute, the product population, the approved transformation, and the evidence used to retire it. Reconcile a sample of effective Merchant Center values against both source files after every material catalog release. Include missing joins, stale values, unexpected overrides, and destination issues in the review queue. When a supplemental field repeatedly compensates for an upstream catalog defect, move the repair to the authoritative system under its own tested migration. When a temporary campaign enrichment expires, remove the data and rule instead of leaving dormant logic attached to the feed. This discipline keeps troubleshooting finite: operators can identify whether the primary source, supplemental file, attribute rule, processing cycle, or destination policy owns the observed value. It also prevents a successful short-term correction from quietly becoming permanent infrastructure with no accountable owner, refresh promise, or recovery plan.