by Om RathodA brand doing $2M in gross revenue across Shopify and Amazon with a 28% return rate isn't running on $2M. It's running on roughly $1.44M net. Most dashboards never make that distinction. They call the gross number "revenue," and founders make budget decisions based on it.
This is the core reason so many teams start searching for ecommerce analytics for a brand with high return rates. Their current stack shows a healthy top line. The bank account tells a different story.
This bites hardest in apparel, footwear, and beauty, categories where sizing, color variance, and shade-match problems drive returns well above the ecommerce average. Anything sold with a "will this actually fit or work for me" question attached to it has this problem baked in.
The stakes here aren't academic. ROAS, CAC, and LTV calculated on gross revenue overstate profitability across the board. A campaign that looks like a 3x return might be closer to break-even once returns are factored in. Founders scale spend on the strength of the wrong number, then find out months later when cash flow doesn't match the dashboard.
If you're evaluating tools because your spreadsheet, Shopify's native reports, or a generic analytics dashboard doesn't separate gross from net, that gap is exactly what this page addresses.
Most ecommerce dashboard tools pull order revenue at the moment of purchase and stop there. They never reconcile that figure against returns processed weeks later. The sale gets logged as revenue on day one and stays that way in the reporting, whether or not the product comes back.
That creates a timing problem. A customer buys on day 1 and returns on day 34. Those two events often land in different reporting periods, sometimes different months entirely. Blended monthly ROAS looks stable on the surface because the return from last month's cohort is quietly dragging down this month's numbers, and nobody connects the two.
The lag problem, in practice
Most tools don't do that last step. SKU-level and campaign-level return rate is rarely broken out at all, which means a founder can't see that one specific ad creative, landing page, or discount code is attracting buyers who return at twice the normal rate.
The downstream effect: CAC and LTV models built on gross revenue systematically overvalue channels that convert impulse buyers. This shows up often in paid social, where a scroll-stopping creative drives a spike in orders that looks great in gross ROAS and terrible once the returns come back in.
An analytics setup that actually reflects reality needs a few specific things that generic dashboards skip.
Net revenue and net margin, calculated automatically. Returns, restocking costs, and reverse logistics fees get subtracted at the data layer, not manually reconciled in a spreadsheet at the end of the month.
Return rate broken out by SKU, variant, channel, and campaign. Not just "return rate: 22%" as a company-wide average, but return rate by size, by color, by Amazon vs. Shopify, and by the specific ad campaign that drove the order. That's the only way to find the actual source of the problem.
True CAC and LTV recalculated on net revenue. Not first-order gross value. A customer who orders three times and returns two of those orders looks very different from a customer who keeps everything they buy, even though both might show up as "3 orders" in a simpler system.
Cohort tracking that separates repeat high-return customers from one-off high-return purchases. A customer who returns almost everything they buy is a different problem than a single order with an unusually high return rate. Lumping them together hides both. Honestly, this is the split most tools skip entirely.
Forecasting that models return rate by SKU category. Not a flat return percentage slapped across the whole catalog. A sandal has a different return profile than a boot. A foundation shade has a different return profile than a lip product. Forecasting tools that ignore this consistently overestimate available margin.
Trivas is built on a Redshift-based data warehouse that pulls raw order and return data directly from Shopify and Amazon, not just pre-aggregated summary reports. That distinction matters here specifically: it's what allows a return to be matched back to the original order, the original SKU, and the original campaign, instead of showing up as an unattributed line item in a separate returns report.
The AI Wingman layer sits on top of that data and surfaces anomalies automatically. If a specific SKU's return rate jumps above its 90-day average, that gets flagged, no founder needing to notice it buried in a spreadsheet or catch it three weeks later when the return volume finally shows up in a monthly report.
The forecasting and simulation product incorporates historical return rate by category into revenue and inventory projections, rather than running a straight-line projection off gross sales trends. If footwear in a certain size range historically returns at 30%, that gets baked into next quarter's projected net revenue and inventory needs, not treated as a surprise after the fact.
Dashboards can also be set so net revenue and net margin are the default view, not gross. The number a founder sees first when they log in is the real one. No mental asterisk required.
For brands running both channels, Amazon and Shopify return data get treated as connected but distinct data sources, which matters because return policies and reconciliation timing differ meaningfully between the two.
Here's an illustrative scenario, not a real customer, to show how this plays out.
A footwear brand runs Meta and Google ads and sees a blended ROAS of 3.2x on gross revenue. On paper, that's a strong number, and the natural instinct is to keep scaling spend.
One shoe style in the catalog has a 30% return rate. Once that's factored in, net-of-returns ROAS on the exact same ad spend drops to 2.1x. Same campaigns, same budget. Very different picture of what's actually profitable.
Digging into SKU-level return data shows the returns aren't spread evenly across sizes. They're concentrated in one specific size run, size 10 and 10.5, for example. That's a meaningfully different problem than "this shoe doesn't work." It points to a sizing chart issue, a fit problem specific to that size, or a product page that isn't setting the right expectations, none of which require pausing the ad campaign entirely.
Once return rate is built into the forecasting model at the SKU level, next quarter's inventory and cash flow projections stop assuming the gross sales trend line is the real number. Inventory planning accounts for the actual expected return volume on that style, and cash flow projections stop overestimating available margin heading into the next reorder cycle.
Founders shopping for this kind of tool are usually also looking at Triple Whale, Northbeam, or Polar Analytics. All three are capable platforms for blended ROAS and attribution. Returns handling is where the differences tend to show up.
[VERIFY]: whether these tools reconcile returns back to the original order and campaign at the SKU level, or whether they only surface aggregate return totals at the account or product level. That distinction is the whole ballgame for a brand trying to figure out which specific campaign or size run is driving the return problem.
Trivas's Redshift-native data model was built with this kind of cross-platform reconciliation as a core requirement, not something layered on after the initial dashboard was already built. Raw order and return data from both Shopify and Amazon sit in the same warehouse, which is what makes SKU-level and campaign-level return attribution possible in the first place.
For founders who want a detailed side-by-side before deciding, the Triple Whale vs. Polar vs. Trivas comparison walks through the full feature set.
Onboarding starts by connecting Shopify and Amazon order and return feeds directly. There's no manual CSV export process to maintain, and no monthly spreadsheet reconciliation to keep current.
Because the data pipeline is pre-built for both platforms, most brands see their first accurate net revenue dashboard within days, not weeks.
Amazon return data, including A-to-z claims and refund-only returns, gets treated distinctly from Shopify return data, since the return policies, timing, and reconciliation rules differ meaningfully between the two platforms. Treating them identically is a common source of error in simpler tools.
The core value here is simple: net revenue and net margin visibility by SKU, channel, and campaign, not just a gross sales number that looks better than the business actually is.
If you're ready to see your own net-of-returns numbers, start a trial and connect your Shopify and Amazon data to get a real picture of what's profitable after returns, not just what sold.
If you'd rather talk through your specific return rate problem first, before connecting anything, the founder-led option is there for that conversation too.
explore more insights
3 min read
3 min read
3 min read
.d53b12e5.png&w=3840&q=75 "Trivas.ai")