The feed is part of the media system
Shopping campaigns often look simple inside Google Ads.
Products appear, bids are automated and the platform distributes spend.
The complexity sits underneath.
Every product Google can understand, approve, match to a query and price correctly depends on Merchant Center product data. Titles, identifiers, availability, price, category, product type, images, promotions and custom attributes all influence what inventory is eligible and how it can be organized.
That makes Merchant Center a performance system.
A feed error can remove a high-margin SKU from auctions. A weak title can reduce relevance. An incorrect GTIN can damage matching. A broken price sync can create disapprovals. A product taxonomy can determine whether the media team is able to isolate a category before a promotion or control bidding around margin.
Professional feed operations should therefore be treated with the same seriousness as conversion tracking.
Stop thinking in terms of one static feed
Google now uses the broader concept of data sources in Merchant Center.
A primary product data source supplies the core product inventory. Supplemental data sources can add or override attributes for products that already exist in the primary source. Product data can arrive through ecommerce platform integrations, files, Google Sheets, automatic store discovery or the Merchant API.
Google's Merchant API also exposes data-source management programmatically. A processed product in Merchant Center can be built from one primary input plus multiple supplemental inputs after rules are applied.
That architecture matters because it allows teams to separate systems of responsibility.
The ecommerce platform can remain the source of truth for SKU, price and availability. A supplemental source can add campaign-oriented attributes such as custom labels. A promotions source can manage offer data. Product review data can follow its own pipeline. The API can support high-frequency updates without rebuilding the entire catalog.
The goal is not to maximize the number of sources.
It is to avoid turning one monolithic export into the only place every team must make every change.
Define attribute ownership
Every important product attribute should have an owner.
A useful operating table might look like this:
- Price and availability: ecommerce platform or ERP
- Title and description: ecommerce merchandising team
- GTIN, MPN and brand: product master
- Images: DAM or ecommerce platform
- Product type: internal merchandising taxonomy
- Custom labels: marketing or analytics layer
- Promotion IDs: promotion-management workflow
- Margin or lifecycle labels: finance/BI-derived supplemental source
Ownership prevents silent conflicts.
If the ecommerce platform says a product is in stock but a manually maintained spreadsheet says it is out of stock, the team needs to know which system wins before the discrepancy reaches Google.
Product identifiers are infrastructure
Some of the least glamorous attributes carry disproportionate operational importance.
Google's product data specification requires GTIN for new products when the manufacturer has assigned one, and brand is required for most new products. Google explicitly warns advertisers not to invent GTIN values.
These identifiers help Google match an offer to the correct product entity.
Incorrect identifiers create worse problems than missing optional marketing copy because they can make the product look like something it is not.
Teams should validate:
- GTIN length and checksum;
- brand consistency;
- MPN formatting where relevant;
- variant identifiers;
- offer IDs;
- feed labels and language combinations;
- SKU uniqueness across data sources.
For API-based setups, Google also warns that products submitted through different data sources can overwrite one another if identifiers are not distinguished correctly.
Feed governance therefore belongs partly to engineering.
Build taxonomy for decisions, not decoration
The internal `product_type` attribute is especially valuable because it can mirror the retailer's own merchandising hierarchy.
Google says the first product type value can be used to organize bidding and reporting in Shopping campaigns.
That means taxonomy should be designed around decisions the media team may need to make.
A hierarchy such as:
`Women > Footwear > Running > Stability`
is more useful than:
`Products > Category 4 > Group B`
because it creates a coherent language across merchandising, reporting and campaign operations.
Custom labels can add another decision layer.
Typical labels might represent:
- contribution-margin band;
- inventory risk;
- bestseller status;
- promotional eligibility;
- lifecycle stage;
- season;
- price band;
- new-customer strategic importance.
The key is stability.
A custom label that changes meaning every week is not an operating system. It is a temporary spreadsheet column.
Feed optimization begins with data quality, not keyword stuffing
Product-title optimization is important, but feed work should not be reduced to inserting more keywords.
The first priorities are accuracy, specificity and consistency.
A title should help distinguish the product. The description should reflect the actual item. Images should represent the offer clearly. Price and availability must match the landing page. Variant relationships should be valid. Identifiers should be correct.
Only after that should teams work on search relevance.
For many retailers, feed optimization becomes a structured testing program:
- Establish a clean baseline.
- Identify query families or product groups where relevance is weak.
- Test title structure or attribute enrichment.
- Measure impression eligibility, click behavior and downstream economics.
- Roll successful patterns through automation or transformation rules.
A feed is a dataset, which means optimization should be reproducible.
Use supplemental sources to protect the product master
Marketing teams often need to move faster than ecommerce engineering.
That is where supplemental data sources are useful.
Google describes them as secondary sources that add or update attributes for products already present in the primary source; they cannot independently add or remove products.
This makes them appropriate for attributes that should not require editing the product master.
A media team can, for example, add custom labels for margin tiers or campaign groupings without changing the ERP.
But supplemental sources need governance too.
Document:
- what fields they are allowed to override;
- who owns the file or API;
- update frequency;
- joining key;
- fallback behavior;
- removal procedure;
- QA before large updates.
An uncontrolled supplemental feed can damage the catalog just as efficiently as a bad primary feed.
Merchant API changes the operating cadence
API-based operations reduce the gap between the store and Merchant Center.
Google's Merchant API lets integrations create data sources, insert product inputs and retrieve processed products. It can also expose product issues through reporting APIs.
That creates the possibility of automated QA.
Instead of waiting for someone to notice a red diagnostic badge in the UI, a retailer can monitor:
- sudden drops in approved product count;
- price mismatch clusters;
- missing identifiers;
- products with no eligible destination;
- feed-processing failures;
- stale update timestamps;
- new policy issues;
- changes in product availability.
For larger catalogs, this is where feed management stops being a marketing task and becomes reliability engineering.
Build a daily diagnostics workflow
Feed issues have different levels of urgency.
A useful daily workflow separates them into:
Revenue-critical: Large groups of products disapproved, price mismatch, checkout or destination problems, widespread availability failures.
Performance-degrading: Missing identifiers, weak product categorization, image problems, incomplete attributes.
Optimization backlog: Title testing, custom-label refinement, promotional enrichment, review coverage and taxonomy improvements.
This triage prevents teams from spending time polishing titles while a pricing error has removed the top-selling category from ads.
Promotions and reviews are separate data products
The product catalog is only one part of Merchant Center.
Google supports separate promotion and product-review data sources. Eligible Product Ratings accounts can submit review data with product identifiers so ratings can be matched correctly. Promotions can also be uploaded through dedicated data sources.
These systems deserve the same discipline as the main catalog.
A promotion that is technically live but absent from the promotion data source can weaken ad competitiveness. A review feed with bad identifiers can fail to attach ratings to the correct products.
That is why the best feed teams maintain a data map of every surface that can influence an offer.
Feed quality should be measured commercially
Approval rate is a health metric, not the final objective.
A catalog can be 99% approved while the missing 1% contains the highest-margin products.
The media team should therefore combine Merchant Center health with business data.
Useful views include:
- approved spend-weighted inventory;
- approved margin-weighted inventory;
- revenue at risk from disapprovals;
- impression share by margin tier;
- spend by stock depth;
- feed issue rate by product category;
- promotion coverage;
- product-level conversion value quality.
This is where Merchant Center becomes part of acquisition economics rather than a technical prerequisite.
The campaign can only be as intelligent as the catalog
Performance Max and Shopping automation can process enormous amounts of auction data.
They cannot repair a business that sends the wrong price, weak product identity, stale availability or meaningless category labels.
Feed operations are therefore not secondary to media buying.
They are one of the ways professional media buying is performed.
