by Trivas.aiMost brands can tell you their top-selling product. Fewer can tell you if that product is actually profitable once you factor in returns, ad spend, and which channel is really driving the sales. That gap is what product performance evaluation is supposed to close, and it's where most reporting setups quietly fall apart.
Product performance evaluation is the practice of measuring how individual SKUs or product lines perform, not how your store performs overall. That means sales velocity, margin after fees, return rate, ad efficiency, and channel contribution, all at the SKU level.
This is a different exercise than general business reporting. A revenue dashboard tells you the month was good. It doesn't tell you which three SKUs carried the month while ten others lost money on returns. That's the distinction: business reporting is top-line, product performance evaluation is SKU-level and cohort-level.
For brands running Amazon and Shopify side by side, this matters more than most people admit upfront. A SKU can look like a hero on Amazon and a dud on Shopify, or vice versa, and if you're only looking at combined revenue you'll never see it. You need the evaluation happening at the product level across both channels, not just at the store level, or you'll keep making merchandising and ad spend decisions based on a number that's hiding the thing you actually needed to know.
Not every metric deserves a seat at this table. Here's what actually belongs.
Sales velocity and sell-through rate, tracked per SKU over a rolling 7, 30, and 90 day window. A single snapshot tells you almost nothing. A trend line tells you whether a product is accelerating, flat, or quietly dying.
Gross margin per unit, after Amazon or Shopify fees, shipping, and the ad spend actually allocated to that product. Revenue per SKU without margin attached is a vanity number. It looks great on a slide and tells you nothing about whether you should keep pushing that SKU.
Return and refund rate by SKU. This one gets ignored constantly, and it's the one that quietly wrecks margin while top-line revenue looks fine. A product with a 22% return rate can post strong gross sales and still be a net loser once refunds, restocking, and lost inventory value settle out.
Channel contribution. How much of a product's revenue is coming from Amazon organic, Amazon ads, Shopify direct, or Shopify traffic driven by Meta and Google. Two products can have identical total revenue and completely different risk profiles depending on how concentrated that revenue is in one channel.
Inventory turn rate, tied directly to the performance data. A "best seller" that turns over slowly isn't a best seller, it's a cash flow problem sitting in a warehouse. Turn rate is what keeps the other four metrics honest.
None of these metrics work in isolation. A SKU with great velocity and terrible margin is not a win. A SKU with great margin and a rising return rate is a warning, not a celebration.
Here's how this usually plays out on a spreadsheet. Someone pulls a Seller Central export, then a Shopify analytics report, then a Meta or Google ads report, and tries to line them up by SKU in a fourth tab. It works, technically. It also takes hours, and it has to be redone from scratch next week.
The errors show up fast. Amazon payouts land in a currency and fee structure that doesn't match Shopify order data one-to-one, so reconciling the two by hand introduces small mistakes that compound. A shipping fee gets missed. A return gets counted in one system but not the other. Nobody notices until margin numbers stop making sense three months later.
Then cadence slips. Weekly evaluation becomes monthly. Monthly becomes "whenever someone has a free afternoon," which in practice means never. The team stops asking "how is this SKU actually performing" and starts asking "what feels like it's selling," because the real, margin-adjusted answer is three tabs deep in a spreadsheet nobody wants to open again.
That's the actual cost of manual evaluation. It's not that the data doesn't exist, it's that getting to it is expensive enough in time that people stop trying, and decisions drift back to gut feel.
Fix the cadence first. Fast movers get reviewed weekly. Full catalog reviews happen monthly. Pick the schedule and don't let it slide, because a framework that only runs when someone remembers isn't a framework.
Next, segment the catalog into tiers: hero SKUs, steady sellers, and long tail. The questions you're asking differ by tier. For a hero SKU, you're watching margin compression and return rate creep. For long tail, you're mostly asking whether it's worth keeping in the catalog at all.
For each tier, define two or three metrics that actually trigger action. Margin drops below a set percentage, return rate climbs above a set threshold, velocity flattens for two consecutive weeks. Vague thresholds like "keep an eye on it" don't produce decisions. Specific ones do.
Document the baseline. Without a recorded starting point, every evaluation cycle turns into re-deriving the whole picture from scratch, which is exactly the manual-process trap you're trying to escape. A written baseline is what makes month-over-month comparisons mean something instead of feeling like a fresh guess every time.
The fix for the manual mess is centralizing the data before you try to analyze it, not after. Trivas pulls Amazon, Shopify, and ad platform data into one Redshift warehouse, so SKU-level performance is a query against joined data instead of a manual reconciliation exercise across three exports.
The time difference is real. A reporting pull that used to eat a few hours every week can run in minutes once the pipeline is built once and kept current. That's not a one-time savings, it's what makes weekly cadence actually sustainable instead of aspirational.
On top of the centralized data, an AI insight layer flags SKUs that have moved outside their normal performance range, rather than requiring someone to scan every row of every export looking for the one product that's drifting. That's the difference between reactive reporting and someone actually watching the catalog. For teams evaluating BI reporting tools or an insights layer built to sit on top of that data, this is the part that actually changes behavior, because people stop skipping the review when it takes minutes instead of hours.
Forecasting is the other half. Evaluation on its own is backward-looking, it tells you what happened last cycle. Layering forecasting and simulation on top turns the same data into a forward view: what's likely next cycle if current velocity, margin, and return trends hold. That's the shift from reporting on the past to actually planning around it.
Brands running both channels tend to feel this most acutely. If you're managing Amazon alongside Shopify, the manual version of this evaluation means reconciling two entirely different data structures by hand every single cycle. Centralizing it removes that step entirely.
Product performance evaluation only does its job if it's consistent, margin-aware, and covers every channel a product touches. A one-off deep dive on a slow afternoon isn't an evaluation framework, it's a snapshot that goes stale in a week.
If you want to see how the underlying metrics get defined and standardized, the data dictionary is a good place to see how terms like sell-through rate and contribution margin get applied consistently across a catalog.
If you're rebuilding how your team looks at product performance, it's worth exploring how the reporting and forecasting pieces fit together before you commit to another round of manual spreadsheet work. No pressure to jump straight to a demo, just have a look and see if the setup matches how your team actually needs to work.
explore more insights
3 min read
3 min read
3 min read
.d53b12e5.png&w=3840&q=75 "Trivas.ai")