by Trivas.aiMost brands can tell you their total revenue for last month within about ten seconds. Ask them which SKU actually made money after ad spend, and the room goes quiet. That gap is exactly what product performance analytics is supposed to close, and it's why so many dashboards, despite looking impressive, fail at the one job that matters.
Product performance analytics means tracking how individual products or SKUs perform, not how your store performs in aggregate. Revenue, margin, ad spend, return rate, inventory velocity: all of it broken down to the item level.
That's a different job than general ecommerce analytics. Store-level or channel-level reporting tells you Shopify did $80K last week. It doesn't tell you that one SKU drove half of it while three others lost money once you factor in ad spend and returns. Product performance analytics is the layer underneath that answers the actual question: which products are working, and which ones just look busy.
This gets harder the moment you sell on more than one channel. A brand running Shopify and Amazon side by side needs the same SKU's performance stitched across both platforms, not two separate spreadsheets that never talk to each other. Otherwise you're comparing a product's Amazon numbers against its Shopify numbers using different math, different attribution logic, and different definitions of "conversion," and drawing conclusions from noise.
Revenue per SKU is the easiest number to pull and the least useful one on its own. Here's what actually belongs on a product performance dashboard.
Contribution margin per SKU, after ad spend, COGS, and fulfillment cost. Not gross revenue. A product that does $50K a month can still be a net loser once you subtract what it cost to sell.
Sell-through rate and days of inventory remaining, tied to when you'd actually need to reorder. A SKU selling well but running low on stock is a different problem than one selling well with three months of inventory sitting in a warehouse.
Blended CAC and ROAS at the product level. Store-wide ROAS averages hide the fact that one hero SKU is usually subsidizing five underperformers. You won't see that unless you break it out.
Return and refund rate by SKU. A rising return rate on one product almost always means something specific: a sizing issue, a listing that oversells the product, a quality problem in a recent batch. It shows up here before it shows up anywhere else.
Conversion rate by product page or listing, separated from your site-wide average. A 2% site-wide conversion rate can be masking a product page converting at 0.5% and another at 6%.
The honest answer: from a mess of places that were never designed to talk to each other. Shopify order data. Amazon Seller Central or Vendor Central. Meta and Google ad platforms. GA4 funnel events. Each one has its own export format, its own refresh schedule, and its own definition of things like "order" or "conversion."
Most teams handle this by exporting CSVs into a spreadsheet once a week and manually stitching it together with VLOOKUPs. It works, sort of, when you have 40 SKUs. It falls apart once you cross a few hundred. Someone renames a column, a SKU gets listed differently on Amazon than on Shopify, and the whole model breaks quietly until someone notices the numbers don't add up.
This is where a proper warehouse layer earns its keep. Trivas runs on Amazon Redshift specifically so that joining Shopify, Amazon, ad platform, and GA4 data at the SKU level is a modeling problem solved once, not a manual reconciliation redone every Monday morning. If you're selling across both platforms, this is also where Amazon and Shopify data actually need to live in the same model instead of two disconnected views.
Even brands that collect the right data often misread it. A few patterns show up constantly.
Judging a product by revenue alone. A SKU can look like your best performer on a revenue chart while ad spend is quietly eating every dollar of margin. Revenue without cost context isn't a metric, it's a headline.
Comparing Amazon and Shopify performance without normalizing attribution windows. Amazon Ads typically attributes on a longer view-through window than most Shopify-side ad reporting. Stack them side by side without adjusting for that, and you'll conclude one channel is outperforming the other when really you're just comparing two different clocks.
Reacting to weekly noise instead of watching trends. A single bad week for a newly launched or seasonal SKU doesn't mean much. Watching a 4 to 6 week trend line tells you whether something's actually declining or whether last week was just a slow Tuesday.
Not separating new-customer from repeat-customer performance. This one hides the most value. A SKU with a middling ROAS on new-customer acquisition might be the product that drives the highest repeat purchase rate in your catalog. If you only look at blended numbers, you'll never see which products are actually building retention versus which ones just look good on a first-touch report.
Trivas pulls Shopify, Amazon, Meta and Google ads, and GA4 data into one Redshift-backed model, so SKU-level margin and ROAS sit in a single dashboard instead of four browser tabs and a spreadsheet. That's the foundation of the insights product: not another export tool, but a shared data layer everything else is built on top of.
Wingman, the AI insights layer, sits on top of that model and flags what actually needs attention. A SKU's ROAS dropping below breakeven. Inventory running out ahead of a demand spike you didn't see coming. That's the kind of thing that normally requires someone staring at a spreadsheet long enough to notice a pattern. Wingman surfaces it before that person has to go looking.
The forecasting module goes a step further and projects sell-through and reorder timing per SKU, based on that product's actual historical velocity rather than a flat store-wide average. A seasonal SKU and a steady year-round seller shouldn't be forecasted the same way, and forecasting built at the SKU level treats them differently instead of averaging them into the same reorder date. For teams building this into weekly reporting cadence, it's also worth pairing with proper BI reporting so the numbers reach the people who need to act on them, not just the person who built the dashboard.
Product performance analytics only does its job if someone actually looks at it weekly. A dashboard checked once a quarter is just a nicer-looking spreadsheet: technically accurate, functionally useless for catching a margin problem before it costs you a month of ad spend.
If you're still mapping out what this should look like for your own catalog, it's worth seeing what SKU-level dashboards actually look like in practice rather than picturing it in the abstract. Explore what a live view of this looks like, or start a trial and pull your own SKUs into it before you build another spreadsheet from scratch.
explore more insights
3 min read
3 min read
3 min read
.d53b12e5.png&w=3840&q=75 "Trivas.ai")