Conversion value as gross profit or revenue for a mixed-margin Shopping store?

Has anyone pushed gross profit into conversion value instead of revenue? Take a store selling phone accessories at 20% margin next to branded cases at 60%. With revenue as the value, the cheap, high-volume SKUs look just as good as everything else, so Smart Bidding keeps pouring budget into them. Feeding margin as the value fixes that on paper, but then the numbers in Google Ads no longer match the revenue in the shop system, and finance people hate that.

Some people keep revenue as the value and split campaigns by margin tier with custom labels instead. That's easier to read, but it splits the learning data. I lean toward profit value once there's enough volume for the bidding to learn from it. I'm not sure that holds for stores under about 50 conversions a month, though.

Agreed on the threshold. At 30 or 40 sales a month, a margin-based value doesn't give Smart Bidding enough signal to separate the 20% accessories from the 60% cases, so it mostly adds noise.

The finance problem has a cleaner fix than people think. Keep revenue as the primary conversion value so the numbers match the shop system, and add profit as a secondary conversion action with its own value. Secondary actions get reported but don't drive bidding, so finance gets its profit view in the same account. You can also see whether the low-margin SKUs earn their place before you change anything.

Same on Microsoft Ads, it has primary and secondary goals too. The catch is that profit usually can't come from the page itself, so the secondary goal needs cost data from your shop system, typically through an offline import. Without that it just duplicates revenue.

Returns are the piece I'd add. A profit value calculated at checkout overstates every order that's later refunded or cancelled, and the offline import won't reverse it unless you send the adjustment as well. So export net profit after returns, not order total minus cost at the time of sale. Otherwise the secondary goal drifts upward every month and finance spots it before you do.

Discounts matter too. Margin is set per order, so a 15% coupon on a 60% margin product leaves a much thinner number than the sticker price suggests. If the shop system doesn't carry the discount into the cost data, the profit figure will look healthier than the business actually is.

Agreed on returns, but how you handle them comes down to how your return window compares with the conversion window in Google Ads. If most returns land within a week or two, sending net profit as a conversion adjustment works and the numbers stay honest. If your policy allows 30 or 60 days and the conversion window is 30, a refund on day 45 has no click to attach to. The adjustment does nothing and the secondary goal keeps climbing. In that case I'd either widen the window as far as the import allows, or have finance trim the profit figure each month by your observed refund rate rather than trusting the import to catch everything.

Yes, and one thing nobody's brought up: a refund adjustment only attaches to the original click if the conversion action still exists in the same form. If you rename the action or change its value settings mid-year, that link can break and the refunds land nowhere. So keep the profit action fixed and log every change you make to it.

The adjustment matches on the order ID you sent with the original upload, not on the click. So a refund on day 45 can still attach, as long as the order ID matches and the adjustment lands inside the window, which I believe is 55 days from the conversion. Past that, you're stuck with the trim-by-refund-rate approach Kai described.

Agreed on the order ID, but the timestamp is where this usually breaks. The adjustment has to carry the original conversion time, not the refund date, and most shop exports only give you the refund date. If you don't have both, the match can fail without any error telling you so.

Timezone is the other silent failure. Google needs the original conversion time with an explicit offset, so if the first upload used the shop's local time and the refund export is in UTC, orders placed near midnight won't match and nothing in the interface tells you. Pick one timezone for both files and write the offset into the timestamp string.

Before sending a full batch, push one known order through as a test adjustment and check that it lands in the conversion action's adjusted numbers. It takes about ten minutes and shows whether the order ID survived the export. Shop systems often add a prefix or store code to order numbers, and that alone can make every refund miss.

Rule of thumb: take the secondary action's monthly profit and compare it against finance's net figure for the same orders. If the gap is bigger than your refund rate explains, the matching is failing somewhere, and you'll catch it before finance does.