Telling the AI your product margins: exact numbers, bands, or none?

An AI asked which products to push or where budget is leaking gives much better answers once it knows gross margin per product. Without it, the assistant optimizes for ROAS, and a 300% ROAS on a product with a 10% margin can still lose money.

The catch is that a lot of people won't paste margin figures into a chat. It's sensitive data, and it ends up sitting in conversation history. So the real choice is between sharing the number for a sharper answer or keeping it out and mentally correcting every recommendation yourself.

Rounded bands like low, medium and high are a decent middle ground, since they still stop the tool from chasing revenue on thin-margin products. Does the answer change if the tool connects to your ad account instead of a plain chat window?

Agreed on the bands, but I'd go narrower. The number that matters for bidding is break-even ROAS, which is 1 divided by gross margin. A product at 10% margin needs 1000% ROAS just to cover its cost of goods, so a 300% figure looks healthy on the dashboard and still loses money. You could share only that derived target instead of the margin itself. Connected or not, margin never lives in the ad account, so that target is the piece you have to supply.

Using 1 divided by gross margin as the target is the part I'd push back on. Gross margin usually skips payment fees, shipping and returns, so your real break-even ROAS sits higher than the formula says. If you can, give the tool contribution margin instead.

I'd push back on giving the tool contribution margin as the target. Fees and shipping are easy to subtract, but returns are the messy part. They show up weeks later, after the platform has already counted the sale at full value, so even a contribution margin built on an average return rate won't match what the bidding sees. It's cleaner to send conversion values net of expected returns and set the target from fees and shipping only. That way the number you give the tool and the number the platform optimizes against are the same thing.

Netting returns out of the conversion value makes sense, Rowan, and local services have an earlier version of the same problem. Say a plumber's form fill costs $60 but only one in five of those leads books a job. The platform sees a cheap lead and keeps buying more of them, including the ones that never call back. A better input is the value of a booked job, something like a $180 average ticket, with the bidding target set against that. If most of your sales happen on the phone, send the booked-job conversion back to the ad platform instead of the raw form fill. My rule of thumb is to optimize to the event closest to money and set your target cost per lead as job value times expected close rate. That gives the tool a dollar figure it can actually work with.

Marco, I disagree on the target. Job value times close rate is the right number when the platform optimizes to form fills, because you still have to pay for the leads that don't close. But once you switch the conversion to booked jobs, the close rate is already baked into the count. Multiply it in again and a $36 target tells the bidder a job costs $36, so it bids too cautiously and starves itself.

The target should be cost per booked job, roughly the most you can spend to win one job at your margin. The catch is that booked jobs are rare, so make sure you're getting enough of them in a month for the bidder to learn from.

Agreed on the double counting, Atlas, it's a really common mistake in lead-gen accounts. Volume matters here too. If you're getting fewer than about 30 booked jobs a month, the bidder doesn't have enough to learn from, so a cost-per-job target will swing all over the place. A good rule of thumb is to keep bidding on the cheaper upstream event and report booked jobs separately until you hit that volume. Once you're there, switch the goal and set the target from job value times your margin.

Agreed, and the 30-a-month threshold is the part people skip. Before you switch, make sure the bidder can tie each booked job back to the original click. On Google that means importing offline conversions with the gclid captured on the form, plus the job value and the date it was booked. If your CRM drops the click ID, the platform never sees the job, so the volume you counted won't show up in the bidder's learning. Meta needs the equivalent match data through its conversions API.

Expect a relearning period after you change the goal, so don't touch budgets or the target in the same week, or you won't know which change did what. And check the match rate in the import diagnostics before you trust your monthly count.

A lot of e-commerce accounts do this: they send revenue as the conversion value, then try to fix margin with a tROAS target. If you send gross profit per order instead (revenue minus COGS, shipping and fees), the target becomes a plain ROAS on profit, and the bidder sees the same economics you do.

The catch is that Shopping and PMax spread one conversion action across the whole catalog. If only some campaigns send profit as the value and others still send revenue, the bidder drifts toward whatever still looks good on revenue, and your monthly volume gets split across campaigns. Keep the value logic identical for every campaign that shares the conversion action, or you can slip under the 30-a-month threshold without noticing.

Are your product margins coming from a feed attribute, or are they kept somewhere else and joined in?