Bidding To POAS Inside Meta When The Platform Only Sees Revenue
Meta's auction only understands revenue. Here's how to send a margin-adjusted purchase value through the Conversions API so value-based bidding effectively optimises toward POAS.
Quick answer
Send Meta a profit-weighted purchase value instead of the gross order total. Compute contribution margin per order at the moment of purchase, multiply by the order's revenue (or just send the margin amount directly), and pass that as the `value` field via the Conversions API. Meta's value-based bidding then maximises the sum of those values — which now equals profit, not revenue — and the auction optimises toward POAS without Meta knowing what POAS is.
Bidding to POAS on Meta with revenue-only signals
Feeding Meta's value-based bidding a margin-adjusted purchase value so the auction optimises toward profit even though the platform only models revenue.
Meta Ads Manager has no native concept of POAS (Profit on Ad Spend). Its value-based bidding (Highest Value, Minimum ROAS) maximises a single numeric field — the `value` you send with the Purchase event — under the assumption that it represents revenue. The workaround used by margin-sensitive performance teams is to overwrite that field at the source: instead of sending gross order value, you send a contribution-margin-adjusted value through the Conversions API. Meta keeps optimising toward the sum of `value`, but that sum is now profit. The pixel sees revenue, your CAPI payload carries the margin signal, and the bidder behaves as if it understood POAS.
This isn't a feature toggle — it's an operational pattern. You're trading the simplicity of revenue reporting for an auction that stops scaling your worst-margin SKUs. For stores where contribution margin swings 20-70% across the catalog, it's usually the single highest-leverage change a Performance Manager can ship in a quarter.
The relationship to POAS (Profit on Ad Spend) is direct: POAS is the metric you report on; margin-weighted CAPI is how you get Meta's bidder to act on it. Without the value transformation, you can measure POAS but only steer it through manual budget shifts and exclusions.
Why Meta only sees revenue
Meta's Purchase event has one numeric slot for monetary value. The platform's machine-learning models treat that number as revenue and assume higher = better. There is no `cogs`, no `margin`, no `profit` field in the schema — and no roadmap item to add one.
That single-slot constraint is the entire reason this workaround exists. If you let the Shopify or WooCommerce pixel auto-fire with the cart total, the auction will happily spend more to acquire a customer who bought a 12% margin discounted bundle than one who bought a 65% margin full-price hero SKU. Same revenue, very different P&L.
Pixel and CAPI must agree
If your Shopify pixel still fires the gross order value while CAPI sends margin-adjusted value, Meta will deduplicate by event_id and one of them wins — usually the first received. Either disable the pixel's Purchase event and rely on CAPI alone, or override the pixel value with the same margin-adjusted number client-side. Mismatched values cause silent attribution drift.
Computing the margin-adjusted value
At order confirmation, compute contribution margin per line item: selling price minus COGS minus variable fulfilment (pick-pack, payment fees, average return cost for that SKU). Sum across the order. That number — not revenue — is what you send as `value`.
Three implementation patterns are common. Pattern A: send raw contribution margin as `value` (cleanest, but breaks revenue-based ROAS in Ads Manager). Pattern B: send `revenue × blended_margin_rate` using a daily or weekly rate (preserves revenue scale, less SKU-precise). Pattern C: send a custom event (`PurchaseProfit`) alongside Purchase and optimise toward the custom one — gives you both numbers but needs ~50 events/week per ad set to exit learning.
For an apparel store with steady margin bands, Pattern B is usually enough. For a beauty or electronics catalog where SKU margins range from 8% to 70%, Pattern A or C earns its complexity. Decide before you ship — switching the meaning of `value` mid-campaign resets learning.
What changes once Meta optimises on margin
Typical 60-day shifts after switching Meta value-based bidding from revenue to margin-weighted CAPI (DTC stores, €1M-€15M revenue band)
| Vertical | ROAS change | POAS change | Spend reallocation | AOV change |
|---|---|---|---|---|
| Apparel (mixed margin) | -8% to -15% | +18% to +28% | Away from sale/clearance SKUs | +4% to +9% |
| Beauty (high-margin hero SKUs) | -12% to -20% | +25% to +40% | Toward full-price hero products | +6% to +12% |
| Electronics / accessories | -5% to -10% | +15% to +22% | Away from low-margin attach items | +10% to +18% |
| Home & lifestyle (bundles) | -10% to -18% | +12% to +25% | Away from discounted bundles | Flat to +5% |
The pattern is consistent: reported ROAS drops because the optimisation target shrank, but POAS climbs because Meta stops chasing revenue that doesn't convert into profit. Brief your CFO and your CMO on the ROAS dip before launch — otherwise the first weekly review derails the test.
Where this breaks
Learning-phase volume is the first failure mode. If margin-weighted values are small (think €4-€12 per order on low-AOV stores), Meta's bidder needs more events to find signal. Plan for a 10-21 day learning window and don't make catalog or audience changes during it.
Returns are the second. If you don't subtract a return-rate provision in the margin calculation, a high-return SKU will look profitable to Meta and the auction will scale it. Use a 30- or 60-day rolling return rate per category, not a global average.
How to test it without betting the account
Run a campaign-level A/B: duplicate your top-spending value-based campaign, swap the value source to margin-adjusted, and split budget 50/50 for at least 14 days. Compare on POAS and absolute profit — not ROAS. Use Meta's built-in A/B test tool so the auction doesn't cannibalise.
If profit is up and total spend is stable or down, roll out. If profit is flat, your margin variance across SKUs is probably too narrow to matter — keep revenue-based bidding and save the engineering hours. Either answer is a win because you got it cheaply.
Frequently asked questions
No. Meta has no way to know what the 'actual' order value is — it only knows what your pixel and CAPI send. As long as the value is consistent and event_id deduplication is clean, the auction treats the number you send as truth.
It works with Advantage+ Shopping, but the impact is smaller because ASC already does aggressive cross-SKU optimisation. The lift is largest on standard value-based campaigns with manual audience structures. Test on ASC last, after you've validated the value transformation elsewhere.
Shopify's native pixel sends gross order value and you can't override it from the standard channel app. You either disable Shopify's Meta pixel and run CAPI through a server-side tag (Stape, GTM server, or a custom endpoint), or use a margin-aware app that injects an override. Disabling the native pixel is the cleanest path.
Value rules adjust bids for predefined audience segments, not per-order margin. They're useful for 'bid 20% more on returning customers' but can't express 'bid in proportion to this specific order's contribution margin'. CAPI value transformation is strictly more powerful for POAS bidding.
Directionally accurate is enough. If your hero SKU has 60% margin and your clearance SKU has 15%, Meta only needs to see that 4x difference — not the third decimal. Use SKU-level cost data if you have it, category-level blended margins if you don't.
Klaviyo reads the Shopify order, not the Meta event, so its revenue and profit reporting are untouched. The transformation only changes what Meta optimises on. Your Klaviyo flows, segments, and revenue dashboards continue to see real order values.
Floor the value at €0.01 (Meta rejects non-positive values for Purchase events). Negative-margin orders being treated as zero is the correct signal — you don't want the bidder finding more of them. If a whole SKU is consistently negative-margin, exclude it from catalog feeds entirely.
Aggregated Event Measurement caps you at 8 events per domain and prioritises them in order. Make sure 'Purchase' (now carrying margin value) stays in your top priority slot. Otherwise iOS attribution is unaffected — CAPI is in fact more resilient than the pixel under ATT.
Learning phase exit needs ~50 optimisation events per ad set per week. Most accounts see a clear shift in spend distribution within 7-10 days and stable performance by day 14-21. Don't judge results before two full weeks of learning have closed.
It's within ToS — you're sending values you've calculated, which is exactly what the API expects. There's no need to flag it. If a rep asks why your ROAS dropped, explain you switched the optimisation target to contribution margin and POAS improved; most reps now recognise the pattern.
Track CAC, channels, and funnel conversion in one place
Metricuno connects ad spend, funnel events, and revenue so you can see CAC by channel, cohort, and campaign — without stitching together five tools.