Custom labels for margin tiers: split PMax asset groups or keep one campaign?

Say a store sells phone accessories at 60% margin next to large appliances at 12%. One tROAS target across the whole feed either starves the appliances or overspends on accessory volume that doesn't pay. The usual fix is custom labels in the feed, something like margin_high, margin_mid and margin_low, then splitting by label so each group gets its own target.

Separate campaigns only make sense once each one has enough conversions to learn, and roughly 30 a month per campaign is the line I'd use. Below that, splitting just fragments the data. A safer middle step is asset groups inside one campaign, with the labels used as listing group filters.

How are you handling margin in your feeds right now: labels, a separate sheet, or ignoring it?

Set each tier's tROAS from break-even, not from what it already returns. Break-even ROAS is 1 divided by margin, so at 60% margin it's about 1.7 and at 12% it's about 8.3. That's a huge gap, which means one target number can't mean the same thing across tiers. Are your targets built on the margin math, or on what each tier happens to return today?

Setting the target at break-even is a mistake. 1 divided by margin is the floor, not the goal. At exactly 8.3 on appliances you're only covering product cost, and smart bidding will hit that number and call it a win.

Also, 12% is usually gross margin. Once you take out shipping, payment fees and returns, the real contribution on a big appliance can be a lot thinner, which pushes true break-even well above 8.3. I'd work out break-even on contribution margin first, then set each tier's target a bit above that so there's room for overhead.

Agreed on contribution margin. I'd add that the revenue you feed the bidder matters just as much. If conversion value is gross order value, a big appliance that comes back at a 15% return rate still counts as full revenue, so the tROAS looks healthy while the real return is lower. Microsoft Ads takes whatever you send it, imported conversions and UET values alike, so send net value after refunds and cancellations, or build an estimated return rate into the value. Otherwise your 8.3 target is measured against revenue you never actually keep.

Volume is a bigger problem on this side too. Appliances at a 12% margin often sell only a few times a month, so that tier may never hit a learning threshold. For a tier that thin, max conversion value with a sensible cap can be more honest than a tROAS that never settles. Depends on your order volume, obviously.

Net value is the right call, and timing matters too. Appliance returns usually land two to four weeks after the sale, so if you import the order at full value on day one, the bidder spends its whole learning window trusting revenue you'll hand back later. A flat return-rate discount fixes the average but not the lag.

If your setup supports conversion adjustments for uploaded or imported conversions, send the refund as a restatement against the same order ID once it posts, and the bidder corrects itself. If it doesn't, take the appliance tier's return rate from the last 90 days and discount the value at import by that amount. It's rougher, but it keeps tROAS from chasing revenue that never arrives.

I'm not sure "the bidder corrects itself" holds. A restatement fixes the reported number, but the model has already learned from the inflated values during the window. With only a few appliance orders a month, that early data is most of what it has, and the lag stays in the training set for weeks. So for a thin tier I'd import at the discounted value by default and keep restatements for real outliers, like a large order that came back whole. Getting the import value close to what you'll actually keep matters more than fixing it afterwards.

Agreed on importing near the value you'll actually keep. The trailing 90-day return rate reads low, though, because the last few weeks of orders haven't had their returns posted yet. A better rule of thumb is to use the return rate on orders older than 30 days, add a couple of points for the lag, and recheck it monthly.

The reason is asymmetry. If the import value is slightly conservative, tROAS just gets a bit stricter. If it's too generous, the model learns from revenue that never shows up, and with a thin tier that error sticks around for weeks.