They Were Happy With the ROAS on the Ads That Ran. Nobody Asked About the 66% That Weren't.
Google Merchant Centre is often classed as a Google Ads add-on but it's much more than that. You can identify lots of missed opportunities by using these simple techniques.
I was in a brand review about three months ago and their Merchant Center account was sitting at around 34% of products approved and running. The paid team's response was essentially: "we're working through the disapprovals, it's a feed issue." The founder's response was: "okay, what's the ROAS on the ones that are running?"
Nobody asked the question I was interested in, which was: what does it mean for the brand that a third of your product catalogue can't be verified by Google?
That's the conversation I want to have in this article. Because most brands treat Merchant Center as the administrative back office for their Shopping campaigns, and it's considerably more than that.
The reframe most paid teams will push back on
Merchant Center is one of the primary input mechanisms for the Google Shopping Graph. The feed you submit isn't just powering your paid product listings. It’s a structured data source that Google uses to build and maintain its canonical representation of your products. When Google resolves which seller is the authoritative source for a product, feed data is one of the signals it draws on alongside on-site schema, reviews, and entity coherence.
Free Listings, the organic Shopping service, was broadly rolled out a few years back and most brands running Shopping campaigns are already on it. Your organic Shopping visibility is determined by the same feed quality signals as your paid listings.
So a disapproval isn't just an ad that isn't running. It's a product that doesn't appear in organic Shopping either. And depending on how Google is using that feed data downstream, it may be affecting how AI shopping agents represent your products when someone asks a query you'd want to own.
I've raised this with a few paid media agencies and the usual response is somewhere between "interesting" and "that's not really our remit." And that's exactly the problem. Merchant Center falls under paid, but the feed quality work that actually matters lives much closer to technical SEO and structured data. So nobody does it properly.
Two sources of truth, and they usually disagree
Most brands are generating their Merchant Center feed from one system. Typically a direct export from Shopify via an app, or a feed through a third-party like DataFeedWatch or Channable and their on-site product schema from another. Sometimes the schema is auto-generated by the theme. Sometimes it's coming through a separate app. Rarely is anyone checking whether the two are saying the same thing.
When they diverge, Google has two conflicting data points about your product and has to make a judgement call about which to trust. The most common conflict I see is around price. The feed has a price, the on-site schema has a slightly different one, possibly because currency formatting has been handled differently or because the feed was generated at a different point in time. Google flags this as a mismatched price disapproval.
That disapproval category is probably the most telling of all the disapproval types. It's not saying your product violates a policy. It's saying: "your two structured data sources are giving us different information, and we can't reconcile them." That's a data fidelity problem, and it's exactly the kind of signal that matters for entity trust. Not just for paid listings but for how Google builds confidence in your product data overall.
The fields where divergence is most common and most damaging:
GTIN - feed has it, schema doesn't (or vice versa, or they're different values)
Brand - feed has the brand name, schema either omits it or uses a different string
Price - currency formatting, tax inclusion, sale price handling
Availability - in stock in the feed, out of stock on site (timing mismatch on drops)
Product title - feed title has been edited for shopping performance, schema title is the raw product name
None of these are hard to fix individually. The problem is that fixing them requires someone to own both the feed and the schema, and in most organisations, those two things belong to different people who have never been in the same conversation.
GTINs in the feed are doing something different to GTINs in your schema
I've written in earlier articles about GTINs as a provenance signal. The way that a correctly assigned GTIN ties your product to a specific manufacturing event and makes it very difficult for a counterfeit operation to claim the same product legitimately. That argument is about entity trust over the long term.
The GTIN argument in Merchant Center is more immediate and more commercial.
When Google can match your product listing to a GTIN in the Shopping Graph, your product gets what Google internally calls canonical entity matching. It can show up in the Product Card which contains a comparison panel that appears for product searches and pulls in pricing from multiple retailers which includes review aggregates, and specifications. Without a GTIN match, your listing is essentially a standalone entry. It might appear in Shopping, but it's not connected to Google's richer product knowledge.
For drop-model brands selling unique product, some of this doesn't apply in the same way. You're not competing against other retailers on the same SKU, because there's often only one source. But for any product where you have a GTIN and that GTIN has been seen elsewhere (licensed product, collab items, anything that gets resold), the matching matters significantly.
The specific failure mode I see in drop brands is timing. The GTIN workflow of getting GTINs assigned, getting them into the product record in Shopify, having the feed regenerate and submit. This often runs behind the product launch. The product goes live, the feed submits, and the GTIN field is blank because it hadn't been entered yet. The product gets a GTIN-exception approval and runs without it. Nobody goes back to add it in once it's there. By the time the GTIN is in the product record, the feed has already established a pattern without it and the team has moved on.
It's a sequencing problem more than a data problem. The GTIN needs to be in the product record before the first feed submission, not added retrospectively.
What disapprovals are actually telling you
Feed disapprovals tend to get triaged by severity of business impact. So, "is it stopping the ad from running" rather than by what they signal about data integrity. That's the wrong frame if you care about anything beyond campaign performance.
The common disapproval categories and what they're actually saying:
Mismatched price or availability - your feed and your landing page disagree. Either your feed is stale, or your schema is wrong, or someone has edited one without updating the other. For drop brands this often happens at the moment of launch. The product goes live, availability flips to in-stock on site, but the feed hasn't refreshed yet.
Missing GTIN - Google wanted a GTIN and you didn't provide one. The policy exemption exists (brand exclusivity, custom/handmade, etc.) but it requires you to explicitly apply for it. A lot of brands are sitting on implicit GTIN-required products without the exemption and getting degraded placement as a result.
Invalid GTIN - you provided a GTIN but it failed validation. Either it's not a real GS1-registered GTIN, or it's been entered incorrectly, or it belongs to a different product. This one matters for the counterfeit angle. Lifting a GTIN from a legitimate product is easy, but getting it to validate against GS1's registry for your specific product is not.
Policy violations - usually content-related (restricted categories, image quality requirements). Less relevant for the entity trust argument but still affects feed health scoring overall.
The aggregate picture of your disapproval categories is a diagnostic report on your data quality. Most brands check it to fix ads. The more useful read is treating it as a structured audit of where your product data is inconsistent.
Pre-drop feed strategy
This is where Merchant Center gets specifically relevant to drop-model operations, and where I see teams get caught out most often.
The standard approach is to publish the product when the drop goes live and let the feed pick it up on the next refresh cycle. If your feed is set to daily refresh, that means a product launched at 10am might not appear in Shopping until the following morning. For a drop that sells out in hours, that's the entire window gone.
There are a few ways to handle this, with different trade-offs.
Pre-submit with out-of-stock status. Add the products to your feed days before the drop with availability set to out-of-stock. Google can index the listing, review it, and have it approved before launch. When you flip availability to in-stock, the listing is already in the system. The risk is that a pre-submitted product with detailed information becomes visible to anyone paying attention to Shopping before you're ready for that. For most drops this is manageable. Shopping listings don't carry the same hype surface as Instagram but worth knowing.
Trigger a manual feed fetch on launch. In Merchant Center you can manually trigger a feed refresh rather than waiting for the scheduled cycle. Build this into your launch runbook. The product goes live, immediately trigger the fetch, the feed updates within about 20-30 minutes. It's not instant, but it significantly reduces the window.
Ensure schema and feed are pulling from the same source. The availability mismatch disapproval is most likely to fire at launch because availability is flipping from false to true at a specific moment. If your feed refresh and your schema update don't sync at the same time, you'll have a window of disagreement. On a high-traffic launch this can spike disapprovals briefly, which is mostly a nuisance but adds friction to the feed health record.
One thing that often gets missed in this planning: if you've been building out pre-launch entity signals such as schema published, authored content with author markup, reviews seeded from early access buyers then the feed submission is the commercial layer that sits on top of all of that. Getting the feed right at launch is how that entity preparation work converts into Shopping visibility.
Supplemental feeds. The underused fix
The primary feed is usually generated automatically from your product catalogue. Adding or changing attributes in the primary feed requires either changing the source system or modifying the feed logic, which often means involving a developer or a feed management platform.
A supplemental feed lets you add or override specific attributes without touching the primary feed. You upload a simple spreadsheet with a product ID column and whatever attribute columns you want to add or overwrite. It's one of the most practical tools in Merchant Center for resolving exactly the kind of data gaps I've been describing.
Common uses for a supplemental feed in this context:
- Adding GTINs that aren't making it through from Shopify correctly
- Adding custom labels to flag drop products, GTIN-verified products, or high-margin SKUs
- Correcting brand field inconsistencies without touching the primary export
- Adding product type hierarchies that are missing from the automated feed
I've seen brands spend weeks trying to fix their Shopify feed export to include a specific attribute, when the fix was a supplemental feed that could be built in an afternoon. The gap is usually just that whoever manages Merchant Center doesn't know the supplemental feed exists, or doesn't realise they can use it without touching the primary feed logic.
Custom labels and drop strategy
Custom labels in Merchant Center are five free text attribute fields you can apply to products for segmentation and bidding purposes. They don't affect listing eligibility or organic visibility, but they're useful for layering drop-specific strategy onto your Shopping campaigns.
The most direct application for drop brands: label your drop products specifically so you can separate them in campaign structure and apply higher bids during the launch window. Most drop brands are running their drop products in the same campaigns as their evergreen catalogue, which means their bidding strategy is averaged across products with very different conversion urgency profiles.
A custom label approach for a drop: `custom_label_0 = drop_ss25_01` for all products in a specific drop. Segment those into their own campaign or ad group. Apply a time-limited bid modifier for the first 48 hours. Return to standard bidding after the window.
This is basic campaign hygiene for drop operations but I've worked with brands doing significant volume on drops with no feed segmentation at all.
Where this sits in the broader picture
The Shopping Graph article I wrote earlier in this series covers how Google's product knowledge base is built from multiple input signals. Merchant Center is the most direct, structured, and commercially weighted of those inputs. Everything else including on-site schema, authoritative content, and entity coherence builds the trust context. The Merchant Center feed is the product-level data layer that sits on top of that context and determines how your products actually appear in Shopping surfaces.
The reason brands get this wrong isn't technical complexity. It's the same coordination problem that affects structured data work generally. Merchant Center belongs to paid, schema belongs to technical SEO, and the question of whether they're consistent with each other belongs to nobody. Most teams are optimising within their lane and nobody's checked whether the lanes are pointing in the same direction.
What I usually recommend as a starting point is a simple consistency audit: pull your live feed data and your on-site schema for the same 50 products and compare the key fields side by side. GTIN, brand, price, availability, title. The divergence rate is almost always higher than anyone expects. That audit takes a few hours and usually generates a list of specific, fixable problems that can be sequenced and prioritised without a major platform project.
It's not glamorous work. But it's the layer that connects your entity trust strategy to your actual commercial outcomes in Search. Without it, the schema work sits one level removed from the surface where it matters.