E-commerce profit tracking: optimise for profit, not revenue

E-commerce profit tracking means one change: you stop sending revenue back to Google and Meta as the conversion value and start sending the real contribution margin per product. It sounds like a detail. It’s the biggest lever most shops leave lying on the table — because from that moment on, Smart Bidding optimises for profit rather than for high-revenue loss-makers.

The gap is brutal. A discounted bestseller on a 15 % margin can pull your account upwards because it “performs well” — while costing you money on every unit sold. Steer on POAS instead of ROAS and you invert that mechanism. Here’s why it pays, how the principle works technically, and which tools actually do it.

1. Why ROAS misleads you — and profit tracking tells the truth

ROAS (return on ad spend) measures revenue per advertising euro. 5x ROAS sounds like a dream number. But ROAS knows nothing about your margin, and that’s where the problem starts.

Run it through: you make €5 in revenue for every €1 of spend. On a product with a 20 % gross margin, only €1 of contribution margin survives from those €5 — your advertising euro is gone again, and shipping, returns and payment fees haven’t even been deducted yet. The same 5x ROAS on a product with a 60 % margin is highly profitable. Same metric, opposite outcome.

That’s the core of it: ROAS is a revenue metric, not a profit metric. It treats a euro of revenue on the cheap product as worth exactly as much as a euro on the margin champion. So Smart Bidding optimising towards ROAS targets does precisely the wrong thing — it scales whatever brings in the most revenue, not whatever leaves the most behind.

POAS (profit on ad spend) turns the question around. Instead of “how much revenue per advertising euro?” you ask “how much profit per advertising euro?”. And suddenly you can see which campaigns, products and search terms are really carrying your account — and which ones only look like they are.

The point isn’t that ROAS is a bad number. For a shop with a margin that’s constant across the whole range, a ROAS target is completely fine — ROAS and POAS run in parallel there. The problem starts the moment your margin diverges between products: 25 % on one SKU, 65 % on the next. That’s when a single uniform ROAS target steers your budget in the wrong direction, because it has no idea what the margin is. And very few shops have a flat margin across the entire catalogue.

Where ROAS typically lies:

• Discount campaigns. Revenue explodes, margin collapses. ROAS celebrates, your account bleeds.
• Low-margin bestsellers. High volume, thin margin. Exactly the products a ROAS target loves to scale up.
• Return-heavy categories. Fashion, shoes, furniture. The ROAS report counts the purchase, not the parcel coming back.
• Products with high shipping or payment costs. Bulky goods eat their margin in shipping — and none of that shows up in ROAS.

2. Sending profit instead of revenue: the profit-signal principle

Now the lever. Google and Meta optimise towards the conversion value you send back to them. By default that value is revenue — the basket value. This is where you intervene: instead of revenue, you hand over the contribution margin, the real profit per product.

That’s the heart of the profit-signal principle. Every SKU gets its true value attached. Not “this product cost €89”, but “this product produced €34 of contribution margin after all variable costs”. What you have to deduct per product:

• Cost of goods — the biggest item, and completely invisible inside revenue.
• Shipping — especially relevant for bulky or heavy goods.
• Return probability — priced in as an experience value per category.
• Transaction and payment fees — PayPal, Klarna and credit cards eat 1–3 %.

What happens next is the actual trick. Smart Bidding gets an honest value for every conversion. The discounted low-margin bestseller suddenly reports a pitiful contribution margin, and the algorithm stops scaling it. The high-margin product reports a fat one — and that is what now gets more budget and more aggressive bids. You steer your entire account towards profit without manually rebuilding a single campaign.

The nice part: the algorithm was never the problem. Smart Bidding and Advantage+ are extremely good at optimising towards a goal. They’ve just been optimising towards the wrong goal, because you were feeding them the wrong signal. Change the signal and the same AI works for your margin instead of against it. Garbage in, garbage out — that applies to the value just as much as to the event.

One term matters here. You don’t want to send the raw gross margin, you want the contribution margin — the amount left after all variable costs, the amount that covers your fixed costs and your profit. Gross margin only deducts cost of goods; contribution margin also accounts for shipping, returns and fees. The closer the value you send sits to the real contribution margin, the more precisely the bidding strategy optimises. And this works across platforms: on Meta the same value rides along through the Conversions API as value — the server-side channel you use to hand profit back cleanly — consent permitting.

In practice, “send profit instead of revenue” means one of two things:

1. You overwrite the conversion value with the contribution margin directly when the purchase event fires, instead of with revenue.
2. You leave revenue in place and adjust the value downstream — via rules or a server-side adjustment (more on that in a moment).

Both land in the same place: the value your bidding strategy optimises towards is your profit. The prerequisite is clean, complete e-commerce tracking. If revenue is already measured wrongly or with gaps, the prettiest margin value in the world won’t save you. So before you send margin values, the basics have to hold: check whether your shop reports purchase values back correctly and completely at all — my tracking check at visnakovs.de/tools/tracking-check (in German) walks through it.

3. The tools for profit tracking — and what they actually do

Now the question you’re probably asking: what do I build this with? There isn’t one tool, there are four mechanics that combine. I’ll name real examples — but treat them as categories, not buying advice. The principle is what counts, not the name on the invoice.

1. Dedicated profit analytics platforms. Tools like ProfitMetrics, TripleWhale or Polar Analytics pull your costs together (cost of goods, shipping, fees, sometimes returns) and calculate the contribution margin per order. The decisive part: the good ones send that profit value back to Google and Meta as the conversion value over a server-side connection. That gives you POAS reporting and profit bidding from one source. The price: a monthly bill and one more dependency in your stack.

2. Google Ads conversion value rules. Inside Google Ads you can adjust the conversion value with rules — by location, device or audience. That isn’t real product-level profit tracking, but it’s a pragmatic entry point if your margin swings a lot by country or customer segment. Useful as a supplement, no replacement for margin-accurate values per SKU.

3. Server-side value adjustment through GTM server-side. This is where it gets clean. You route the purchase event through a server-side GTM container, pull the margin per product in real time (from a data source or your shop), and overwrite the value before it goes out to Google and Meta. Advantages: robust against ad blockers and browser restrictions (ITP), one central place for the logic, and no SaaS lock-in. More work — but the mechanism belongs to you. The same principle applies in lead gen, by the way: if you send offline conversions back with a real value, Google optimises for closed deals instead of raw form fills — the “value” there is the deal value, here it’s the contribution margin.

4. A margin feed out of the shop system. For anyone to know the margin per product at all, you need it as a reliable data source. In Shopify you store purchase prices and margins as metafields; in Google Merchant Center you attach a supplemental feed to your product feed that gives every SKU its contribution margin or a margin label. That feed is the source of truth every other mechanic feeds from. Without it, every kind of profit tracking stays an estimate.

In practice you combine: margin feed as the data base, server-side adjustment or a profit platform as the engine, value rules as fine-tuning. Which route is right for you comes down to three things:

• How clean is your margin data? Without a reliable purchase price per product, everything else is cosmetics.
• How deep is your tracking setup? Server-side gives you the most robust values — but needs building, plus consent management that steers the server-side sending correctly.
• Do you want to build or rent? A profit platform is live faster; GTM server-side gives you full control and no running licence on the core mechanism.

Whichever route you take, the ground conditions are always the same: reliable margin per product, clean e-commerce tracking, correct consent handling, and ideally server-side delivery of the values.

The bottom line

ROAS optimises for revenue. Your bank account lives on profit. As long as you send revenue back as the conversion value, Smart Bidding will reliably scale your low-margin bestsellers and leave the profitable products sitting there.

Three take-aways:

• Steer on POAS, not ROAS. 5x ROAS on a 20 % margin can be a loss — only contribution margin tells you the truth.
• Send the real profit per product. Deduct cost of goods, shipping, returns and fees, then hand that value back to Google and Meta. From there the AI optimises for profit.
• Build the chain properly: margin feed as the data base, GTM server-side or a profit platform as the engine, value rules as fine-tuning. Without reliable margin data and clean tracking it all stays guesswork.

It’s work — but it’s the lever almost no competitor pulls. Optimise for profit while everyone else bids on revenue and you buy the same clicks more profitably.

If you want a second pair of eyes on whether your shop’s margin data and tracking are good enough to run this, write to me at visnakovs@clickspire.de.