by Trivas.aiStandard ROAS treats every dollar of revenue the same. A $50 order is a $50 order, whether it came from a bundle you're basically giving away or a hero SKU with real margin baked in. That's the flaw. Ecommerce analytics with margin-aware ROAS exists because that flaw isn't small, it's the whole reporting layer built on a bad assumption.
Here's a concrete version of the problem. Say you run a campaign pushing a discounted bundle that nets 4x ROAS. Looks great in the ad account. Meanwhile a separate campaign on your bestselling, full-margin SKU is sitting at 2.5x ROAS. On paper, campaign one wins. Shift more budget to it, right?
Except the bundle might carry 15% margin after shipping and returns, while the hero SKU runs 55%. Run the math and the "worse" campaign is generating more actual profit per dollar spent. The 4x campaign might be barely break-even once you account for what it actually cost to fulfill those orders.
This is how teams end up chasing the wrong products and wondering why net profit refuses to move even as blended ROAS climbs quarter over quarter. You're optimizing a number that looks like performance but isn't tied to the thing that pays your bills.
Margin-aware ROAS is: (revenue minus COGS, fulfillment, and returns) divided by ad spend, calculated at the SKU or campaign level, not blended across the whole store.
It's not the same as contribution margin, and it's not a replacement for your P&L. Contribution margin tells you what's left after variable costs across the business. Margin-aware ROAS is narrower on purpose: it's a spend-efficiency metric, answering "is this specific ad dollar generating profitable revenue" rather than "is the business profitable overall." It's also not MER (media efficiency ratio), which stays at the total-spend, total-revenue level and still ignores margin entirely.
The distinction matters most once you're past a single hero product. A brand selling one SKU at one margin can get away with blended ROAS, the numbers roughly track reality. But once you've got multiple SKUs, bundles, wholesale-priced items mixed with DTC, or seasonal margin swings, blended ROAS starts hiding more than it reveals. You need the metric to be granular enough to catch the fact that "revenue" isn't a single flavor of dollar anymore.
Trivas pulls order-level cost data (COGS, shipping, fulfillment fees, returns) straight from Shopify or Amazon, and pulls ad spend from Meta, Google, and TikTok, all landing in Amazon Redshift. That's the pipeline. No CSV exports, no separate margin tab someone updates every other Friday.
From there, the dashboard recalculates ROAS per campaign, per ad set, and per SKU using actual margin, not a flat assumed percentage applied storewide. That last part matters. A lot of teams approximate margin with one blanket number (say, "we run 40% margin") and apply it everywhere. But a 40% average might mean one SKU at 65% and another at 12%. Averaging erases exactly the signal you need.
When supplier costs change, seasonal pricing shifts, or freight rates spike, those COGS updates flow through automatically. Margin ROAS recalculates without anyone touching a spreadsheet. That's the part that usually breaks in manual setups: someone builds a margin model in Q1, costs shift in Q3, and nobody updates the model until year-end reconciliation shows the numbers were wrong for six months. The BI reporting layer is built to close that gap by keeping cost data live instead of static.
This isn't just a reporting nuance, it changes what you actually do with budget.
Take the bundle-versus-bestseller scenario from earlier. If you reallocate spend away from the high-ROAS, low-margin bundle toward the lower-ROAS, high-margin bestseller, blended ROAS on paper might dip. But net profit goes up, because you're now spending against orders that keep more of their revenue after costs. That's the entire point: margin-aware ROAS optimizes for money kept, not money moved.
It also changes how you read creative testing. Two ad creatives can drive similar order volume, but if one is pulling in full-price hero SKU orders and the other is mostly driving discounted, bundled, or low-margin add-ons, they're not equally good creatives even if their click-through and blended ROAS look similar. Margin-aware reporting separates "this ad drives volume" from "this ad drives profit."
There's an inventory angle too. Sometimes margin ROAS drops and it has nothing to do with the campaign. Freight costs went up. A supplier raised prices. Returns spiked on a specific SKU. Without margin-level visibility, that shows up as "the campaign got worse" and someone pauses or restructures ads that were actually still performing fine. With margin-aware ROAS, you can see the COGS line moved, not the ad performance, and you leave the campaign alone while you go fix the cost problem instead.
The inputs are straightforward: product cost data, shipping and fulfillment cost per order, and ad spend feeds from whichever platforms you run. Connecting those typically takes under an hour once accounts are authorized, since Trivas is built to ingest this data natively rather than treating margin as a bolt-on.
The Wingman AI layer sits on top of that data and surfaces which campaigns or SKUs have the widest gap between blended ROAS and margin ROAS, so you're not building a pivot table every Monday to find the same answer. That gap is usually where the real budget mistakes are hiding. Instead of manually cross-referencing an ad export against a margin spreadsheet, Wingman-driven insights flag it directly.
This replaces the common workaround: exporting ad platform data into one spreadsheet, margin data into another, and reconciling them by hand every week. It works, sort of, until someone's on vacation, or the margin spreadsheet gets out of date, or a formula breaks silently and nobody notices for a month. If you're a marketing leader trying to defend budget decisions to finance, having this reconciled automatically instead of manually is the difference between a confident answer and a "let me check and get back to you."
Most attribution-first tools, Triple Whale, Northbeam, Polar among them, are built to answer "which channel or touchpoint drove this sale." That's a genuinely hard problem and they've put real engineering into solving it.
But it's a different question from "was this sale profitable." Bolting margin data onto an attribution-first platform usually means manually entering COGS assumptions or standing up a separate BI layer to combine the two data sets. That's not a knock on those tools specifically, it's a structural reality of how they were built: attribution first, margin as an add-on.
Metric
Attribution-first tools
Margin-aware ROAS in Trivas
Primary question answered
Which channel or touchpoint drove the sale
Was the sale profitable after real costs
Margin data
Often manual entry or separate BI layer
Native to data ingestion from order-level source
COGS updates
Typically require manual refresh
Flow through automatically as costs change
If you're weighing this directly, the comparison of Triple Whale, Polar, and Trivas breaks down the structural differences in more detail.
The core shift here isn't cosmetic. Optimizing toward margin-aware ROAS instead of blended ROAS changes which campaigns get budget, which creative gets scaled, and which SKUs you actually push. It's a decision-making change, not a dashboard redesign.
If you want a quick gut check before connecting full order and cost data, the ROAS calculator is a fast way to see how your current blended numbers stack up.
When you're ready to see what your margin-aware numbers actually look like, start a trial or grab time to talk it through directly. No need to overhaul your stack first, just connect the data and see where the gap is.
explore more insights
3 min read
3 min read
3 min read
.d53b12e5.png&w=3840&q=75 "Trivas.ai")