How POAS works
ROAS rewards revenue, and revenue is a poor proxy for what a business keeps. A store selling a 20 percent margin product and an 80 percent margin product at the same 4.0 ROAS is not earning the same money on each. POAS fixes this by putting profit in the numerator, so the metric finally reflects the number that pays the business. The cost is that POAS needs accurate cost of goods per product, which is exactly the data most feeds are missing.
POAS vs ROAS on a real catalogue
Consider two products, each at a 4.0 ROAS. Product A carries an 80 percent margin, so its POAS is 3.2. Product B carries a 20 percent margin, so its POAS is 0.8, meaning it loses money after cost of goods at the same headline ROAS. A ROAS-based bidding strategy treats them as equals and happily scales the loser. A POAS view scales the winner and starves the loser. On a wide feed, that difference compounds into the entire profitability of the account.
Getting POAS into your bidding
Google does not bid to POAS natively, so the standard technique is to send margin into the conversion value instead of revenue. When the value passed back is gross profit rather than order value, a target ROAS strategy is effectively optimising to profit, and the platform learns to favour high-margin products on its own. This requires a clean cost-of-goods field in the feed and a value rule or server-side adjustment to convert revenue into profit at the point of conversion.
How iClick uses POAS
On any account with meaningful margin spread across the catalogue, iClick moves the bidding signal from revenue to profit by feeding margin-adjusted conversion values, so Smart Bidding optimises to what the business keeps rather than what it books. The prerequisite is honest cost-of-goods data per SKU, and getting that in place is often the single highest-leverage change on an ecommerce account, because it silently reweights every automated bid toward profit.
