Campaign, ad group and product group structure
How Standard Shopping campaigns are organised, campaigns, ad groups, product groups and how you subdivide them, plus campaign priority and how it all contrasts with Performance Max listing groups.
A Standard Shopping campaign is a nested container: campaign holds ad groups, ad groups hold product groups, and product groups are how you slice your catalogue up to bid each slice differently. You start with one product group covering everything, then subdivide it by attributes like category, brand or custom label. Performance Max uses a similar idea called listing groups, but with far fewer levers on top.
The four levels, from outside in
A Standard Shopping campaign is a set of nested containers. Understanding the nesting is most of the battle, because bids and filters live at specific levels and it's easy to look for a control in the wrong place.
| Level | What it is | What it controls |
|---|---|---|
| Campaign | The top container | Budget, bidding strategy, priority, inventory filter, locations, schedule |
| Ad group | A container inside the campaign | Mostly organisational in Shopping; holds the product-group tree |
| Product group | A slice of your catalogue | The bid (or the group a Smart Bidding target applies to) |
| The product itself | An individual item from your feed | Nothing set here directly: it inherits from the product group it falls into |
The key insight: the product group is where bidding happens, and product groups are defined entirely by attributes that come from your feed. You never list products by hand: you carve the catalogue up by category, brand, item ID, condition, product type or custom label, and each carved-out slice gets its bid.
You start with "All products" and subdivide
Every new Shopping ad group begins with a single product group (All products) that contains your whole catalogue on one bid. That's rarely what you want, because a £9 accessory and a £600 hero product shouldn't share a bid. So you subdivide.
Subdividing splits one product group into children based on one attribute at a time. Split All products by brand, and you get one child per brand plus an Everything else catch-all. Then you can split any of those children again (say, by custom label) and so on, building a tree:
All products
├── Brand = Acme
│ ├── custom_label_0 = margin-high → tROAS 550%
│ ├── custom_label_0 = margin-low → tROAS 280%
│ └── Everything else (Acme) → tROAS 400%
├── Brand = Contoso → tROAS 400%
└── Everything else → tROAS 350%
Two rules that save a lot of pain:
- You split by one attribute per level. You can't split a group by "brand AND margin" in a single move: you split by brand, then split each brand-child by margin. This is exactly why custom labels live in separate slots: different dimensions in different slots let you cross-cut cleanly down the tree.
- Every subdivision creates an "Everything else". This catch-all holds every product that didn't match a named branch. It always carries a bid, and it's where unlabelled or newly-added products quietly land. Always check what bid your "Everything else" branches hold: it's the single most common place accounts leak spend.
Deep dive How deep should the tree go, and campaign priority
Depth: subdivide only where you'll bid differently. A product group tree exists to hold distinct bids. Every subdivision you create but bid identically to its parent is pure reporting overhead: it adds rows to manage without adding control. The discipline is to split only when two slices have genuinely different economics: different margin, different price band, different lifecycle stage. In practice most well-run accounts subdivide two or three levels deep (often product type → margin band → lifecycle) and stop. If you find yourself with hundreds of product groups you never touch, you've built a report, not a bidding structure.
Campaign priority: the classic multi-campaign lever. When the same product is eligible in more than one of your Standard Shopping campaigns, priority (High / Medium / Low) breaks the tie: the higher-priority campaign enters the auction, regardless of bids. This powers the old three-tier query-sculpting structure: a High-priority campaign with low bids and broad negatives catches generic queries, pushing valuable specific queries down into a Low-priority campaign with higher bids. It's a genuinely useful pattern for controlling which budget answers which kind of search.
Two caveats. First, priority only arbitrates between Standard Shopping campaigns: it does nothing across ad groups within a campaign. Second, priority does not outrank Performance Max: for any product PMax also serves, PMax wins regardless of your Standard Shopping priority. So if you run both, the only reliable separation is at the product level (each product in exactly one campaign's serving set) not the priority level. The standard-vs-PMax comparison covers that split in full.
Performance Max: listing groups, fewer levers
Performance Max organises its catalogue with listing groups, which subdivide by the same feed attributes you'd use in Standard Shopping: category, brand, item ID, custom label. The structural idea is identical: carve the catalogue into slices.
The difference is what you can do with the slices. In PMax:
- You can subdivide listing groups and you can exclude slices from serving.
- You can't set a separate bid per listing group: one asset group runs on one Smart Bidding goal.
- You don't get campaign priority, negative keywords, or full search-term reporting.
So listing groups are for inclusion/exclusion and organisation, not for the per-slice bidding that product groups give you in Standard Shopping. This is the core control trade-off between the two campaign types: PMax hands the per-slice bid decisions to Google, Standard Shopping keeps them in your hands.
The through-line: structure is only as good as your feed
Every product group and listing group is defined by feed attributes. If your product_type is missing, you can't subdivide by it. If your custom labels are inconsistent, your tree catches the wrong products and the rest fall into "Everything else". Campaign structure is the scaffolding; the feed is what flows through it. Get the attributes clean and consistent first (the Shopping auction rewards the same data) and design your labels deliberately with custom labels before you build the tree on top.
Frequently asked questions
What's the difference between an ad group and a product group?
An ad group is an organisational container inside a campaign; a product group is a slice of your inventory inside that ad group that carries its own bid. Most Standard Shopping accounts use one ad group per campaign and do all their real work in the product-group tree.
How many product groups should I create?
Only as many as you'll actually bid differently. Every subdivision you're not going to set a distinct bid or target for is just reporting clutter. Split where the economics differ, margin, price band, lifecycle, not for its own sake.
Does Performance Max have product groups?
It has listing groups, which subdivide your catalogue the same way, but you can't set per-group bids on them and you don't get the priority and negative-keyword controls Standard Shopping gives you. See the standard-vs-PMax comparison for the full trade-off.