BigCommerce PPC: What Moves the Number and What Is Noise

BigCommerce PPC is what a $3M+ operator is running the moment a Google Shopping or Search campaign points at a BigCommerce catalogue, and on most accounts it is structured the same way regardless of what is actually in that catalogue: one product feed, one bid strategy, one blended return-on-ad-spend figure read as the verdict on whether the spend is working. It usually is not the verdict. The mechanism that actually decides whether BigCommerce PPC pays for itself sits below the platform’s own dashboard, in how the feed is split before a bid is ever set — the part a software directory listing or an agency service page ranking for this query has no reason to explain, because neither is built from a real account.

What Actually Moves the Number in a BigCommerce PPC Account?

A BigCommerce PPC account’s number moves when spend is allocated by product segment — margin and sales velocity — rather than spread evenly across the whole catalogue at one bid. The default state of most accounts is the opposite: BigCommerce’s own catalogue syncs into Google Merchant Center carrying the attributes Google’s product data specification actually requires — title, price, availability, image, GTIN or MPN — and nothing about what a SKU is worth to sell (Google Merchant Center Help, Product data specification). Margin is not a field Merchant Center asks for, and no ad platform can infer it from a price alone.

Every SKU in that feed then competes for the same shared budget under whatever automated bidding strategy the campaign uses, with no signal telling the algorithm that two SKUs are different bets — an illustrative $12-margin bestseller and a $2-margin clearance item, say. The algorithm optimises to whatever value it is given, usually revenue or a target ROAS, with no visibility into which SKU is actually paying for that number. The fix is not a better bid strategy on top of that structure; it is giving the feed a segmentation signal the bid strategy can actually use, which is a feed-and-campaign-structure problem before it is a bidding problem.

How Is Running PPC on BigCommerce Different From Running It on Shopify?

Running PPC on BigCommerce differs from running it on Shopify in one structural way that matters directly for segmentation: BigCommerce owns Feedonomics, the feed-management platform most operators reach for once manual segmentation inside Merchant Center’s own feed rules stops scaling on a large catalogue (BigCommerce, Acquisition of Feedonomics announcement, 2021, vendor-reported). A Shopify store buying the same feed-rules capability is buying it from a company with no ownership relationship to the storefront platform at all. Both platforms ship a free native app that syncs a catalogue into Google Merchant Center — BigCommerce’s is called Ads and Listings on Google (BigCommerce, launch announcement, 2021, vendor-reported) — and neither native sync writes margin or velocity into the feed on its own; that layer is added the same way on either platform, through Merchant Center’s own custom labels or a dedicated feed-rules tool.

BigCommerce’s ownership of Feedonomics does not buy a BigCommerce operator a cheaper price — Feedonomics is not free, and its pricing is not published — but one fewer vendor relationship to negotiate and one fewer integration to keep working when BigCommerce ships a catalogue change. Whether that saving is worth paying for against a comparable third-party feed tool on Shopify is a quote-by-quote comparison, not a platform-level fact either company states.

Why Doesn’t Account-Level ROAS Tell You Whether BigCommerce PPC Is Working?

Account-level ROAS does not tell you whether BigCommerce PPC is working because it blends every SKU’s margin into one ratio, and a dollar of revenue from a clearance item counts exactly the same as a dollar of revenue from a full-margin bestseller. A campaign can report an excellent blended ROAS while losing money on the SKUs actually driving that ROAS, if the low-margin items happen to convert at a higher rate than the high-margin ones — and there is no way to see that from the account’s own summary metric, because the summary metric is precisely what is hiding it.

A fair amount of what ranks for this query overstates what can honestly be claimed about BigCommerce PPC: a software directory listing and an agency service page both currently claim PPC delivers something close to “the highest conversion rate possible,” without naming an account, a time frame, or a baseline to check it against. That is an unfalsifiable claim under any real claim-discipline standard — nobody reading it can verify it, and nobody publishing it is offering to.

The honest position is that a representative BigCommerce PPC CAC or ROAS figure — one Google’s or Meta’s own dashboards would let an operator copy and trust — is — metric to confirm. No platform publishes one, and no aggregator’s number is a substitute; the way to get a figure worth trusting is to build it from a specific account’s own segment-level data, CAC compared against contribution margin, segment by segment, not one blended figure for the whole catalogue.

How Do You Segment a BigCommerce Product Feed With Several Thousand SKUs?

A BigCommerce feed with several thousand SKUs is segmented by writing a margin or velocity signal into Google Merchant Center’s custom-label fields, then giving each label its own campaign with its own bid ceiling and campaign priority. Merchant Center allows five custom-label attributes per product — custom_label_0 through custom_label_4 — each accepting one value per product, up to 1,000 unique values per attribute across an account (Google Merchant Center Help, Custom label 0–4). That is enough range to encode margin band, sales-velocity tier, seasonal relevance and clearance status on the same catalogue at once, without touching the underlying product data BigCommerce itself manages.

BigCommerce’s admin does not write to Merchant Center’s custom-label fields directly, so the value has to be computed somewhere before the feed reaches Merchant Center — either through Merchant Center’s own conditional feed rules, referencing a BigCommerce field that already correlates with margin or velocity such as category or brand, or through Feedonomics’ rules engine, which can compute the label from margin and sales data the operator supplies rather than infer it from category alone. The second route is the more accurate one on a catalogue where margin varies inside a category rather than between categories, which is the normal case once a catalogue reaches several thousand SKUs.

Once the labels exist, Google Ads’ own campaign priority setting is what makes the segments actually compete separately for budget: the higher-priority campaign bids first for a given SKU, and where two campaigns overlap on the same product at the same priority, the higher bid wins (Google Ads Help, campaign priority documentation). Without that priority setting configured deliberately, two overlapping campaigns targeting the same SKU can bid against each other rather than the segmentation doing its job.

What Should a $3M+ BigCommerce Store Actually Budget for PPC?

No primary source publishes a representative PPC spend-to-revenue ratio for a $3M+ BigCommerce store, and none can: Google, Meta and BigCommerce itself have no access to a store’s own contribution margin, so no platform-reported average could ever be more than a guess dressed up as a benchmark. The workable answer is built bottom-up, from a growth target and a CAC ceiling, not borrowed as a percentage from somewhere else.

This budget model is illustrative arithmetic built from a hypothetical $3,000,000 BigCommerce store, not a published benchmark or an average across real accounts — recompute every line against your own AOV, margin and growth target before treating any figure in it as a plan.

The two percentages this budget model produces — spend against the incremental revenue target, and spend against current total revenue — are not a rule of thumb to copy; they are the output of this specific store’s AOV, margin and growth target, and they move meaningfully if any of the three inputs does. A store with the same revenue but a thinner margin needs a lower CAC ceiling for the same order count, which raises the required order volume and the resulting percentage of revenue; a store with a lower growth target needs less incremental spend regardless of margin. That sensitivity is the actual finding, more than either percentage is: a single “budget X% of revenue on PPC” figure could only ever be right by coincidence for a store with your specific numbers.

What Do Most BigCommerce Stores Get Wrong Running Google Shopping?

Most BigCommerce stores running Google Shopping build a segmented campaign structure and then run a Performance Max campaign alongside it without checking which one actually serves for the products both target. Performance Max historically took automatic priority over standard Shopping campaigns targeting the same product; Google Ads’ current documentation states that ad rank, not campaign type, now decides which campaign serves when both target the same SKU (Google Ads Help, campaign priority documentation). A segmented standard-Shopping structure sitting in the same account as an unconstrained Performance Max campaign has to actually win that ad-rank comparison to matter — it does not win automatically just by existing.

A second common mistake in BigCommerce Shopping accounts is leaving Merchant Center’s custom-label fields entirely unset on a catalogue large enough to need them. Custom labels are available on every Merchant Center account regardless of platform or spend level; on a multi-thousand-SKU catalogue they are close to universally unused, not unavailable, which means the wasted spend an unsegmented feed produces is a choice being made by omission rather than a limitation of the tools.

A third common mistake in the same accounts is treating a rising overall budget as a fix for a flat or declining blended ROAS. A larger budget on an unsegmented campaign gives the platform’s bidding algorithm more room to spend on whatever mix of SKUs it is already favouring — the blended number can hold steady or even improve while the underlying contribution-margin outcome, segment by segment, gets no more visible than it was before the increase.

What Does It Cost to Run a Segmented BigCommerce PPC Account?

Running a segmented BigCommerce PPC account costs more than a blanket campaign in two places: the tooling layer that computes and writes the segmentation signal, and the ongoing review that keeps it accurate as the catalogue changes. Feedonomics’ own pricing is not published; what it costs a specific store is — metric to confirm, and getting it means requesting a quote scoped to catalogue size and channel count rather than assuming a figure. Merchant Center’s own conditional feed rules are free and cover simpler cases — a catalogue where margin correlates cleanly with an existing field such as category — without adding a vendor relationship at all.

The recurring cost is the review cadence, not a one-off setup fee: a margin or velocity tier assigned once and never revisited drifts out of date as SKUs move between segments — a test-tier SKU proving out its velocity, a core SKU going on clearance — and an unrevisited label set is only marginally better than no segmentation at all once enough of the catalogue has moved. The realistic pattern is a scheduled reconciliation between the feed’s labels and the store’s own current margin and sales data, run often enough that the gap between the two stays small, which is a recurring operational task rather than a project with an end date.

Segmenting a BigCommerce feed by margin and velocity is not a copywriting or keyword problem once an account is live — it is a paid-media problem, in the specific sense that the signal deciding whether BigCommerce PPC works sits outside any ad platform’s own dashboard. Contribution margin and sales velocity live in BigCommerce’s own order and cost data, not in Merchant Center or Google Ads, and neither reaches a custom label or a campaign-priority setting on its own. That is the class of work we build as paid media — reading a store’s own margin and velocity data, writing it into the feed as a real segmentation signal, and keeping the bid tiers and campaign priority aligned to it as the catalogue changes, rather than trusting one blended account-level ROAS to say whether the spend is working. The same distinction between what a platform reports and what a store’s own data says holds whether the catalogue sits on BigCommerce or on Shopify; BigCommerce’s free native Google sync and its own ownership of Feedonomics just make the mechanism reachable without buying a third-party feed relationship first.