POAS vs ROAS: which metric tells you if your ads are profitable?

You hit your ROAS target. Revenue looks fine. Then finance asks why the store still feels tight on cash.

That gap shows up a lot in e-commerce. Return on ad spend became the default scoreboard for paid media, but it only answers one question: how much revenue came back for each dollar of ad spend. Margin never enters the picture. Two products can post the same ROAS and leave you with opposite outcomes for the business.

The two metrics look identical in structure. ROAS = revenue ÷ ad spend. POAS = gross profit ÷ ad spend. The only change is the numerator, but that swap is the difference between measuring how much came back and measuring whether any of it was profit.

Profit on ad spend (POAS) makes that swap concrete. And it only starts to matter inside the ad accounts once profit data can reach the platforms reliably, which is where most setups stall.

What return on ad spend (ROAS) is and why it became the default

ROAS is revenue divided by ad spend.

Spend $1,000 on ads and generate $4,000 in revenue, and your ROAS is 4.0 (or 400%, depending on how your team writes it). Every major ad platform reports some version of this. Bid strategies chase it. Agencies still put it near the top of almost every performance deck.

It became the default for boring, practical reasons. Revenue is easy to capture at checkout. Your store already knows the order total. Platforms already accept a conversion value. Teams can set a target ROAS without rebuilding their data stack. For catalogs where every SKU has a similar margin, ROAS is often good enough as a directional signal.

The trouble starts when margins vary. Fashion with heavy discounting. Bundles with different COGS. Free shipping on some SKUs and not others. "Strong ROAS" and "healthy business" stop meaning the same thing pretty quickly.

The problem with ROAS: all revenue looks equal

ROAS treats a dollar of revenue from a high-margin product the same as a dollar from a thin-margin one. The bidding algorithm only sees the value you send it. If that value is the order total, the platform has no idea which sale actually paid for the ads.

Take a store running shopping ads across two categories. Both show a 4x ROAS. One category carries about 65% gross margin. The other sits closer to 20% after COGS, shipping, and payment fees. Scale the second category and you can grow reported revenue while shrinking contribution. The ROAS chart still looks like a win.

Mixed catalogs make this worse. Merchants scale what the platform pushes. The platform pushes what looks valuable in the conversion feed. Feed it revenue alone, and high-ticket or easy-to-convert items get favored even when the margin is weak. Reporting stays green while cash gets tighter. Anyone who has watched a discounted product soak up most of the ad budget for a month, while the margin barely covers the spend, knows that feeling.

For a closer look at how conversion value choices distort ROAS in analytics and ads, see how to fix GA4 ROAS inaccuracies.

What profit on ad spend (POAS) is

POAS stands for profit on ad spend. The common formula is:

POAS = gross profit ÷ ad spend

Gross profit here usually means revenue minus cost of goods sold. Some teams go further and subtract shipping, payment fees, and expected returns before they divide. That stricter version – contribution profit – is often closer to cash reality. Either way, profit goes in the numerator. Revenue does not.

A POAS of 2.0 means you kept $2 of gross profit for every $1 of ad spend.

POAS break-even is always 1.0. ROAS has no fixed break-even. Below 1.0, ad spend is eating more than the order contributed after product cost. Above it, ads are adding contribution before fixed overhead.

A 3x ROAS can be fine for a 50% margin product and disastrous for a 20% margin one. POAS removes that translation step. You still need enough POAS to cover overhead and growth goals, but the floor is easier to read.

Industry guides such as Polar Analytics' POAS overview frame the same split: ROAS measures revenue efficiency, POAS measures whether the spend made money.

Worked example: same ROAS, opposite profitability

Two products. Same ad spend and same reported ROAS. But a very different POAS.

	Product A (premium)	Product B (promo)
Revenue from ads	$2,000	$2,000
Ad spend	$500	$500
ROAS	4.0	4.0
Gross margin	60%	18%
Gross profit	$1,200	$360
POAS	2.4	0.72

Product A returns $2.40 of gross profit per ad dollar. Product B returns $0.72. Relative to product cost, B is underwater, even though both campaigns look identical on a ROAS report.

If the ad platform only receives $2,000 as conversion value for both, it has no reason to prefer A. B might even get more budget when it converts faster or wins more auctions. That is how a healthy-looking ROAS account can still feel unprofitable at month end.

Why POAS is harder in practice

ROAS only needs order revenue. POAS needs margin data that most tracking setups never touch.

That data usually lives in your ERP, inventory system, or a spreadsheet finance updates weekly. It rarely sits in the browser data layer at purchase time, and for good reason: visitors should not see your margins. So the profit number has to be added later, on the server, using product IDs from the order.

A few things make this messy:

• Margin changes. Supplier costs move and promotions change contribution overnight. Stale profit tables send the wrong signal.

• Variable costs. Shipping, payment fees, and returns differ by order. A flat margin percentage is a start that doesn’t represent the full picture.

• Multi-item carts. One order can mix high-margin and low-margin SKUs. Item-level profit has to be summed into one conversion value.

• Platform targets. Once conversion value switches from revenue to profit, old ROAS targets stop mapping 1:1. A 400% target on revenue is not the same as a 400% target on profit. Teams forget that more often than you'd expect.

Offline POAS in a BI tool helps with diagnosis. It does not change what the ad platforms optimize toward. For that, profit has to become the conversion value in the feed the algorithms train on.

The tracking dependency: platforms chase the value you send

Ad platforms optimize toward the conversion value you give them. Google's own docs say you define that value when you set up conversion tracking, including options such as sales revenue or profit margins. Meta, Microsoft Ads, and others behave the same way in practice: the number in the purchase event is what value-based bidding learns from.

Feed the system revenue and it scales revenue. Swap that number for profit and the budget starts competing on contribution instead. It may sound simple but, in a live stack, it usually is not.

Client-side tags mostly see what the browser sees. Profit lives in backend systems. Joining item IDs to a margin table, summing profit for the cart, and forwarding a clean purchase event is a server-side job. Browser restrictions and ad blockers already cut into conversion completeness. Incomplete events make profit-based bidding noisier, because every missing purchase is also a missing margin signal.

The bridge between ROAS and POAS is not a new KPI slide. It is reliable server-side value signals: purchase events that fire when the order is real, product IDs that match your margin source, and a conversion value that reflects profit before the hit reaches the ad platform. 

Read more about enrichment and recovery of lost conversions in the guide to Google Ads Server-side Tracking and calculating Server-side Tracking ROI.

How to start moving toward POAS

A perfect contribution model on day one is rare. Most teams get further with a staged path.

• Start with offline POAS. Pull ad spend by campaign or product group, join orders to COGS, and sit ROAS next to POAS for a few weeks. The places where high ROAS hides weak margin usually jump out fast. That alone changes budget conversations.

• Agree what "profit" means for bidding. Gross profit after COGS is the common starting point. Shipping and fees get added when those costs swing widely by SKU or region. Media and finance need the same definition, or the meeting turns into an argument about whose spreadsheet is right.

• Build a product-level profit source. A table keyed by item ID (SKU), with an updatable profit or margin field and clear ownership. Stale margins are worse than no POAS. The algorithm will confidently optimize to the wrong thing.

• Send profit as conversion value on a server-side path. At purchase, resolve each line item to profit, sum the cart, and pass that sum as the event value. A parallel revenue conversion can stay for reporting. Bidding should move to the profit-based action once the data looks stable.

• Recalibrate targets after the switch. Old ROAS targets mislead once the value definition changes. New efficiency targets belong on the profit-based conversion, with enough time for the algorithms to relearn before anyone calls the test.

• Watch the ugly data issues. Missing item IDs, fallback values of zero, delayed margin updates. Those show up fast in bidding. Preview a few purchases end to end before flipping primary conversion actions.

If your catalog has near-uniform margins, staying on ROAS may still be rational. POAS pays off when margin spread is wide enough that revenue optimization and profit optimization diverge.

Where TAGGRS fits

Once you decide to bid on profit, you need a place to join order data to margin data without exposing that margin in the browser. That is where server-side Google Tag Manager earns its keep.

TAGGRS Profit Tracking is built for this pattern. Product profit values sit in a Firestore collection keyed by item ID. A server container variable looks those values up at conversion time and sets the Google Ads / GA4 conversion value to profit instead of order revenue. The docs are clear on one constraint: this needs a server container, because the browser cannot safely fetch your margin table.

TAGGRS hosts that server-side GTM setup and connects the Google Service Account integration so the Firestore lookup can run in the container. You still own the margin data and the definition of profit. The platform side is the plumbing: reliable purchase events, enrichment at the server, and a conversion value the ad platforms can train on.

For stores already on Shopify or similar stacks, the same server-side path also helps with conversion completeness, which matters once every purchase event carries a more precise value. See Shopify Server-side Tracking if that is your storefront.

Conclusion

ROAS told a generation of e-commerce teams whether ads "worked." For mixed-margin catalogs, that answer is incomplete. 

POAS asks the better question: did the spend leave profit after product cost?

Getting there is less about renaming a column and more about sending the right conversion value into the platforms that spend your budget. Offline POAS reports help you see the problem. Server-side profit signals let bidding systems act on it.

Ready to set it up? Create a free TAGGRS account or book a demo to talk through your specific setup.

FAQ

What does POAS stand for?

POAS stands for profit on ad spend and it measures gross profit (or contribution) generated per unit of advertising spend.

What is the difference between POAS and ROAS?

ROAS divides revenue by ad spend while POAS divides profit by ad spend. Same structure, different numerator. Two campaigns can share a ROAS figure and disagree completely on POAS when margins differ.

How do you calculate POAS?

The formula to calculate it is POAS = gross profit ÷ ad spend. Example: $1,200 gross profit from $500 ad spend = POAS 2.4. Some teams use contribution profit (after shipping, fees, and returns) instead of gross profit. Pick one definition and keep it consistent in reporting and bidding.

What is a good POAS?

Break-even on the metric is 1.0 (profit equals ad spend at the gross or contribution level you chose). A useful target depends on overhead, growth goals, and how complete your profit definition is. Compare POAS across your own products before chasing a universal benchmark from someone else's catalog.

Can I optimize ad platforms for POAS?

In practice, yes: send profit as the conversion value and use value-based bidding. Platforms optimize to the value in the conversion feed. Revenue produces revenue-seeking spend. Profit produces profit-aware spend. Google documents conversion value as something you define, including profit margins, for strategies such as Maximize conversion value.

Why do I need Server-side Tracking for POAS?

Margin data should not live in the browser. Joining item IDs to a private profit table, summing the cart, and forwarding a purchase event is a server-side workflow. Client-side tags alone rarely have a clean, secure path to that data, and they already lose part of the conversion stream to blockers and browser limits.

Should every store switch from ROAS to POAS?

No. If every product has a similar margin, ROAS and POAS will rank campaigns in roughly the same order. POAS matters when margin spread is large enough that scaling revenue and scaling profit pull in different directions.

Does TAGGRS support profit-based conversion values?

Yes. TAGGRS documents a Profit Tracking setup that pulls product profit from Firestore in the server container and passes it as conversion value. It requires Server-side Tracking.