Shopping Feeds: The Hidden Ceiling on Ecommerce PPC

Ask most ecommerce operators where their Shopping performance comes from, and you'll hear answers about bidding strategies, budget allocation, audience signals, and maybe Performance Max tuning. Rarely does anyone answer "the product feed". And yet the feed is the single most important input to every one of those things. It's the raw material Google works with. If it's thin, inconsistent, or misaligned, nothing downstream can compensate.

The feed is also the part of ecom PPC that tends to get set up once and then quietly ignored. A store, whether it's built on Shopify, Magento, BigCommerce, WooCommerce, or a bespoke platform, plugs into Google Merchant Center through a native app or plugin, products start flowing, ads start running, and attention moves on to the parts of the account that feel more active. Meanwhile the feed sits in the background, shaping what gets shown for which query, how competitive the listing looks, and whether Google even understands what's being sold.

This article is about why that lack of attention is expensive, and what a well-managed feed actually looks like in practice.

The problem with out-of-the-box platform-to-Merchant-Center integrations

Every major ecommerce platform ships with some form of native integration into Google Merchant Center. They're convenient: install the app or enable the channel, authorise it, and product data starts syncing. For a new store with a handful of products, this is usually fine. Enough to get you onto the shelf.

The trouble starts as soon as the catalogue gets bigger, more complex, or needs to be tuned for performance. These native connections are pipes, not tools. They move fields from the store to GMC largely unchanged. If your product titles are written for your brand voice, those titles go into Merchant Center as-is, whether or not they contain the keywords a shopper would actually search for. If your categories are named for internal use rather than Google's taxonomy, those names go across unchanged. If you need to exclude a subset of products from Shopping, your control is usually limited to what the native app exposes.

The limitations aren't minor. They compound:

• No rules or transformations. You can't rewrite titles, enrich descriptions, map your internal categories to Google's taxonomy, strip boilerplate text, or apply conditional logic based on price, product type, stock status, or margin.
• Limited supplemental data. Layering on custom labels for budget grouping, margin bands, or seasonal flags is either clumsy or not supported at all.
• Poor multi-market control. If you sell across several countries, each with different currencies, tax treatments, or catalogue availability, managing this through the native connection becomes messy quickly.
• Opaque exclusions. When products are being filtered out, you often can't see why. The native integrations rarely give you a clear "removed by rule" breakdown.
• Hard to collaborate on. When an agency needs to optimise the feed, they either need admin access to your store or a workaround through a developer. Neither is ideal.

None of this is a criticism of the platforms or Google. The native integrations do what they're designed to do. But Shopping advertising beyond the starter phase needs more control than a simple pipe can provide.

What a dedicated feed tool gives you

A third-party feed management tool, such as DataFeedWatch, Channable, GoDataFeed, or Feedonomics, sits between your source (whatever platform you're on) and Google Merchant Center. It ingests your raw product data, applies whatever rules you configure, and publishes a transformed, optimised feed to GMC and other channels (Meta, Amazon, Bing, and so on).

The core benefit isn't any single feature. It's control. You can see exactly what's going out, edit the rules, version the changes, and trace why a specific product is or isn't appearing. A few of the things this opens up:

• Rule-based transformations. Rewrite product titles to front-load the keywords that actually matter. Append brand, colour, or material when they're missing. Strip out shop-specific jargon. Apply different rules to different product categories.
• Clean category mapping. Map your internal product taxonomy to Google's product categories in a way that makes your products discoverable. The default inferred category is rarely the best one.
• Supplemental attributes. Add custom labels at scale: margin bands, best-seller flags, new-in, sale status, seasonal groupings. This gives you flexible ways to segment campaigns and bids later.
• Surgical exclusions. Remove specific products from the feed without removing them from the store. Exclude low-margin SKUs from Shopping while keeping the store inventory intact. Pull underperforming lines without touching the merchandiser's catalogue.
• Multi-channel reuse. Build once, publish to multiple channels (GMC, Meta, Bing, marketplaces) with channel-specific rules where needed. Native store integrations typically only target a single channel.
• Visibility into what's blocked. A good tool tells you which products failed which rules, so you can see at a glance whether you're filtering legitimately or filtering by mistake.

For an agency managing a Shopping account on your behalf, a feed tool is closer to essential than optional. Without it, every feed change requires a round-trip through the client's admin panel or a developer. With it, changes are self-contained, auditable, and reversible, and the agency can work on the feed the same way they work on the account.

What to actually optimise

Having the tool is only the starting point. The question is what to do with it. The things that matter most aren't exotic. They're just rarely given enough thought.

Product titles

Titles are the single biggest lever in a Shopping feed. They're what Google matches against search queries, and what shoppers scan before deciding to click. Most titles pulled straight from an ecommerce platform are optimised for on-store display, not for search.

A title like "Classic Compass" works on a product page because the category, brand, and context are already visible. As a Shopping title, it's nearly invisible. A better version, "Brass Pocket Compass with Engraving, Gift Boxed", tells Google (and the shopper) everything they need to know within the first few words.

The practical rule is to front-load the attributes that matter most: brand, product type, defining attribute (material, colour, size, key feature), and a differentiator if there's space. The first 70 characters do most of the work, because that's what's visible in most ad placements before truncation.

Descriptions

Descriptions don't appear in standard Shopping ads. What the shopper sees is the image, title, price, and a few data points. But Google still reads descriptions, and uses them to decide what queries a product should be eligible to show against. They're a relevance signal feeding into the matching algorithm, even though they don't display in the ad itself. Descriptions also appear in the Shopping tab where richer product data is surfaced, which makes them doubly worth getting right.

Descriptions pulled from ecommerce platforms often contain marketing language that reads beautifully but carries no signal, like "timeless elegance", "meticulously crafted", "a joy to own". Fine for the product page. In the feed, it's noise. A good description describes the product plainly: what it is, what it's made of, how big, what it's for, which attributes matter. Keep the brand voice on the product page. Keep the clarity in the feed.

There's a balance to strike. Keyword-rich is good. Keyword-stuffed is bad. Google can and does flag obviously spammy descriptions. Write for humans first, with the right keywords woven in where they read naturally.

Product type

The product_type attribute is your own hierarchical classification of the product, separate from Google's official google_product_category taxonomy. There are two schools of thought on how to use it.

The first approach is Google's official best practice: reflect your site's navigation hierarchy, so product_type reads like a breadcrumb, for example "Accessories > Watches > Pocket Watches". This is clean, readable, and helps organise campaigns by product grouping.

The second approach, which we often use for clients, is to treat product_type as a strategic text field, front-loading it with the high-value search terms you actually want the product to compete for. For a pocket watch, rather than Accessories > Watches > Pocket Watches, the product_type might read men's pocket watch > pocket watch with chain > vintage pocket watch > engraved pocket watch. You lose the site-hierarchy readability, but you gain an additional signal field that tells Google which queries you consider most relevant. This approach works especially well when paired with campaign structures that use product_type for segmentation.

Neither is wrong. The right choice depends on how you're structuring campaigns downstream and how much you trust Google's inferred relevance versus wanting to push it in a specific direction. Most stores leave product_type blank or populated with inconsistent default data. Either of the approaches above beats that by a wide margin.

Images

Shopping is a visual format. The image does more work than any individual ad copy line. A few things that quietly hurt image performance:

• White-background product-only images almost always outperform lifestyle images for transactional intent. Lifestyle images have their place, but the primary image in GMC should be clean, unambiguous, and show the product clearly.
• Images cropped too close or too far from the product reduce click-through rate.
• Consistent image style across the catalogue matters. Mixing white-background and lifestyle at random makes the brand look inconsistent in the Shopping grid.

Most feed tools don't let you edit the image itself. They let you choose which image to send. If your store product has five images and the primary one is a lifestyle shot, you can configure the feed to send image #3 (the white-background product shot) while the store keeps using the lifestyle image first.

Worth knowing: Google Merchant Center now has a built-in feature called Product Studio that most advertisers haven't noticed yet. It's free, uses generative AI, and offers background removal, scene generation (placing your product into lifestyle settings), image upscaling, and (in some markets, including the UK) AI-generated video from product images. It won't replace a real product shoot for brand-critical imagery, but for cleaning up inconsistent catalogues or enriching listings with lifestyle backgrounds at scale, it's a genuinely useful tool that costs nothing to try.

The core attributes Google expects

Beyond the obvious fields, Google expects a set of core attributes that sharpen its understanding of each product. Missing or inconsistent values here cost you reach and relevance:

• Brand: always populated, consistently spelled
• GTIN / MPN: for any product that has one; Google weights listings with valid GTINs favourably
• Condition: new, used, refurbished
• Availability: in stock, out of stock, preorder
• Colour, size, material, pattern: where applicable; particularly important for apparel and fashion
• Gender and age group: essential for apparel, often left blank for everything else
• Shipping weight: affects shipping cost calculations in the ad
• Google product category: the official Google taxonomy code, not your internal one

These attributes look like admin. They're actually about giving Google enough information to advertise your products correctly. A product listed with no material, no colour, no size, and no product type has to compete on title alone. A product listed with brand, type, material, colour, gift-readiness, and proper taxonomy gives Google multiple pathways to surface it for relevant queries.

Where margin data fits in

There's a growing conversation in ecom PPC around feeding margin or cost-of-goods data to Google so Smart Bidding can optimise for profit rather than revenue, known as Profit On Ad Spend (POAS) rather than Return On Ad Spend (ROAS). This is real, and Google now supports it directly.

Merchant Center has an official cost_of_goods_sold attribute. You populate it either on the primary feed or, more commonly, via a supplemental feed so the COGS data stays separate from your main product data and is easier to maintain. Once Google has COGS at the SKU level, it can report on gross profit alongside revenue, and target ROAS bidding factors it into optimisation so the algorithm is no longer blind to margin differences between products.

This matters most when margin varies a lot across the catalogue. If all your products sit in a narrow 40-50% margin band, POAS and ROAS give you similar answers. If margins span 10% to 60%, ROAS will happily push Smart Bidding toward the revenue-heavy, margin-thin SKUs while your genuinely profitable products get starved. POAS prevents that, but only if Google has the COGS data to work with.

Note that COGS is one of several attributes that should be treated carefully. It exposes your cost structure to Google, and some businesses prefer to keep margin data server-side and pass pre-calculated profit as the conversion value instead. Both approaches work. The point is that profit-aware bidding is available, supported natively in Merchant Center, and worth the set-up effort for stores with meaningful margin variation.

What a well-managed feed looks like in practice

A Shopping feed that's genuinely doing its job has a few observable traits:

• Product counts in GMC match what you'd expect to be advertisable, accounting for exclusions you intentionally applied.
• Disapproval rates are low and attributable to individual product issues, not systemic feed problems.
• Title conventions are consistent across the catalogue. The first 50 characters always give the same type of information, in the same order.
• Categories map cleanly to Google's taxonomy with very few "uncategorised" or inferred items.
• Every product has populated values for the core attributes relevant to its category.
• Exclusions are auditable. You can pull a list at any time showing which SKUs are being filtered and why.

None of that is glamorous. But it's the difference between Shopping campaigns that have a ceiling hardwired into the feed, and Shopping campaigns where the feed is working with you rather than against you.

The takeaway

The reason Shopping feeds go underinvested is that they don't feel like the interesting part of the account. The campaigns and the creative and the bidding feel strategic. The feed feels like data entry.

But Google can only advertise what it understands. Everything Smart Bidding does, every algorithmic decision about where to show which product to which shopper for which query, starts with the product data you hand it. A rich, consistent, optimised feed gives the rest of the machine a chance to work. A thin, default feed caps performance long before any of the strategic levers get to matter.

If your Shopping account is running on a native store-to-Merchant-Center app and no one has looked hard at the feed itself in a while, there's a good chance that's where the next step-change in performance lives. It's also the least visible thing to compete on, which is exactly why it pays.