Bigcommerce Google ads agency

Google Ads on BigCommerce: variants sent with their own SKUs, customer group pricing kept out of the feed, custom fields mapped to Google attributes.

BigCommerce carries more product data natively than most platforms, which makes the feed work easier and creates one specific trap. The trap is pricing. Price lists and customer groups can show a different price to a trade customer, a logged-in member or a wholesale account, and a feed built without thinking about that can send a price no anonymous shopper will ever see. Google compares the feed against what its crawler sees while logged out, and the mismatch disapproves items.

The second BigCommerce specific point is the difference between options and variants. Options are choices on a page. Variants are real records with their own SKU, price and inventory. A feed can only carry variants properly, so a store that built its size range as options has a catalogue that cannot be advertised at variant level until that is corrected.

The good news is the fields you need are already there. Brand, GTIN, MPN and condition are native, custom fields can carry anything else, and the channel connection keeps the catalogue synced. We map what exists rather than rebuilding it in a separate feed layer, and run everything in your own accounts.

Native on BigCommerce

The channel manager connection that syncs the catalogue to Merchant Center
Variants with their own SKU, price, weight and inventory, ready to be sent individually
Native brand, GTIN, MPN and condition fields on every product
Custom fields, which can carry attributes Google reads but BigCommerce has no default field for
Price lists and customer groups, which change the price shown to signed-in shoppers
Multi-currency settings that can be matched to a Merchant Center target

Settings that matter

Send variants rather than options

Only a variant has a SKU, a price and an inventory count of its own, which is what a feed item needs. If size or colour was built as an option rather than a variant, the feed can only advertise the parent, so specific searches never match and the price shown may not be the price of the item someone wanted. Converting options to variants is catalogue work, it takes time on a large store, and it is worth doing before any budget increase.

Keep customer group pricing out of the feed

The feed must carry the price an anonymous visitor sees on the page, because that is what Google's crawler sees. Trade pricing, member pricing and any price list attached to a group belongs to a signed-in experience and should never be the value exported. We check the price source the connection is reading, and where a product is only visible or purchasable after login, we exclude it from advertising rather than pointing ads at a page that will not sell.

Map custom fields to the attributes Google reads

Google uses attributes such as material, pattern, age group, gender and size type for matching, and BigCommerce holds most of these in custom fields rather than dedicated ones. We agree a naming convention, populate it in bulk across the catalogue, then map each field to the corresponding Google attribute. Once the convention exists, new products can be created correctly instead of being cleaned up afterwards.

Match currency and shipping to the target country

If the store presents multiple currencies, the feed target has to agree with what a visitor in that country actually sees, including shipping rates and tax treatment. We set one target per country rather than sending a converted price into a single feed, keep a campaign per market, and check that the products published to that storefront are the ones being advertised there.

What we avoid

Advertising products whose real price or availability only appears after a customer signs in
Exporting parent products when the buyable item is a variant with its own SKU
Adding an external feed tool before the native fields and custom fields have been filled properly

Questions

The most common cause is that they are options rather than variants, so no separate record exists to export. After that it is usually a missing identifier, a variant with no image of its own, or an inventory setting that reports it unavailable. Checking the item count in Merchant Center against your variant count in BigCommerce shows the size of the gap quickly.

They affect it whenever the exported price is taken from a list rather than from the default retail price. Google compares against the logged-out page, so a trade price in the feed reads as a mismatch. Keep price lists for the signed-in experience and export the public price, or exclude group-only products from the feed altogether.

Often not. Between the native fields, custom fields and the channel connection, most catalogues can be described accurately without an extra layer. A tool becomes worthwhile when you need category-specific title patterns, supplemental data from outside the store, or outputs shaped differently for several channels at once.

Not through Shopping, and it is better to accept that than to work around it. A shopping ad promises a public price and a page anyone can buy from. If the product needs an approved account, advertise the category or the application process through search campaigns instead, and keep the restricted items out of the feed entirely.

Send your BigCommerce store.

The plan is written for your store on the platform it runs on.