A US brand running 180 SKUs across three TikTok Shop stores has a specific problem that looks like a data problem and is actually a decision problem. The dashboard says GMV is up. The bank account says otherwise. Every weekly meeting ends with someone proposing new products, because adding SKUs is the one lever that feels like progress when nobody can say which existing SKU is worth defending.
Sales detail does not solve that on its own. It answers a narrower and more useful question: which SKU is moving units, in which category, over which period. That is the input. The decision about which SKU earns still requires a second number that lives somewhere else, and teams that skip that step end up promoting their busiest product instead of their most profitable one.
This is written for the brand or multi-store operator in the US running 50 to 200 SKUs with a team of 10 to 50, where the catalogue is large enough that no one holds it in their head and small enough that a wrong call is survivable if you catch it in a month.
Why fifty SKUs makes the answer harder, not easier
With five SKUs, ranking is trivial and intuition is reliable. With fifty, three failures appear that never show up in small catalogues.
The first is that aggregate GMV hides concentration. A store can grow 20% while its top three SKUs do all the work and the bottom thirty decline, and the dashboard will show one green line. The second is that slow movers do not announce themselves: a SKU selling two units a week looks acceptable in a monthly total and is actively losing money once returns and shipping are counted. The third is that platform-level metrics average across your own variants, so a strong colour variant can carry a weak size range for a year without anyone noticing.
None of those are visible from a single GMV figure. All of them are visible from a per-SKU table read in the right order.
What the sales detail table contains, and what it does not
Being precise about scope saves a lot of wasted analysis. Sales detail is a per-SKU view: GMV, total orders, and units sold, for each product variant, filterable by period, product category, and listing status. That is the whole table.
What it does not contain is the deduction layer. Refunds, platform fees, tax, and shipping are not in the SKU row. Those live in store-level performance reporting, which is where the money actually gets adjusted.
This matters because the most common analytical mistake in this workflow is treating per-SKU GMV as per-SKU profit. It is not, and the gap is not small: on a category with a 12% return rate and free shipping thresholds, a SKU’s contribution can be halved between the two numbers. Anyone who ranks by SKU GMV and then wonders why the best sellers do not pay for the team has skipped step one.
Two steps, in this order: store net, then SKU ranking
Start at the store, not the SKU. Pull the period you care about from store performance, where refund counts, tax, and shipping are already deducted, and note the net figure. That number is the ceiling: no combination of SKU-level totals can exceed it, and the difference between gross and net is your entire cost of selling. DAMI’s store performance view carries those four deduction lines in the same table, so the net figure is available before anyone opens a SKU row.
Then note two ratios, because they set the filter for step two. Refund rate as a share of GMV, and shipping cost as a share of GMV. A brand with an 8% refund rate and 14% shipping cost is in a different business from one at 3% and 6%, even if both show the same GMV. The first brand needs SKUs with high unit margin and low return propensity. The second can afford volume plays on cheap accessories.
Only after those two ratios are written down does the SKU ranking mean anything, because they tell you what a good SKU looks like in your specific store rather than in general.
Step two: rank by units, then check the top five against margin. Sort sales detail by units sold for the same period. Take the top five and the bottom ten. That is the whole exercise: everything between the top five and the bottom ten is noise at this catalogue size, and analysing forty mid-rank SKUs produces a report nobody acts on.
For the top five, answer one question each: does this SKU survive its own return rate? A unit that sells 900 times and comes back 200 times is a marketing asset and a margin liability at the same time. Check the returned units against the reason codes where your store provides them; size-related returns and defect returns need completely different responses.
For the bottom ten, answer a different question: is this SKU unsellable, or is it unsold? Those are not the same. An unsellable SKU has views and no conversions — the product is wrong, or the listing misrepresents it. An unsold SKU has almost no views — the product may be fine and simply never got traffic, which is a creator or content problem rather than a product problem.
The distinction is the difference between delisting twenty products and getting twenty products in front of creators. Most teams do the first because it is easier and because the data does not distinguish the two cases for them; someone has to make that call by looking at views, not just orders.
The four SKU types that show up in every roster
Across catalogues of this size, the same four shapes recur. Naming them makes the monthly conversation faster, because the action per type is different and does not need to be re-argued every time.
| Type | What the data looks like | What it means | Action |
|---|---|---|---|
| Anchor | Top 10% of units, low return rate, stable week over week | Carries the store; creators accept it because it sells | Protect it. Sample budget goes here first. |
| Traffic trap | High units, high return rate, high review volume | Sells on the video, disappoints on arrival | Fix the listing claim or the variant, not the creative |
| Quiet earner | Low units, high unit price, near-zero returns | Small but clean margin; under-promoted | Get it in front of three creators before delisting |
| Dead weight | Low units, low views, non-zero returns | Nobody sees it and the few who buy return it | Delist; it is costing attention and stock space |
The traffic trap is the type teams defend longest, because the unit number is impressive and the return rate is blamed on customers. That argument usually collapses once returns are matched to specific claims in the video.
Filtering a 200-SKU catalogue down to the twelve that matter
Filtering is where a large catalogue becomes manageable. Two filters do most of the work: listing status and category.
Filter to active listings only before ranking. Delisted and out-of-stock SKUs distort every average and, more importantly, hide the fact that a product you think is selling has actually been unavailable for three weeks. A SKU with zero units because it went out of stock looks identical to a SKU with zero units because nobody wants it, unless status is part of the query.
Then filter by category and rank inside each one rather than across the whole store. A beauty brand’s skincare SKUs and its accessory SKUs do not compete for the same creator or the same margin, and ranking them together always produces the same useless result: the cheapest high-volume item wins, and the high-margin item looks like a failure.
Do this once per category and the twelve SKUs that matter fall out on their own — typically three anchors, a couple of quiet earners worth a test, and a handful of obvious dead weight. DAMI’s SKU sales detail view runs on period, category, and listing status together, which is what makes the per-category pass practical instead of a spreadsheet exercise; sorting the same table by units gives the top-five list without a manual pivot.
Why the same SKU can look good on one store and bad on another
Multi-store operators hit a specific trap here. The same SKU, same price, same creative, performs differently by store because the audience, the creator mix, and the shipping origin differ. Ranking SKUs inside one store and then applying that ranking across all three produces decisions that are wrong in two of them.
Two practices fix it. First, keep the ranking per store, and only compare at the category level. Second, when a SKU is a top-five performer in one store and bottom-ten in another, treat that gap as a question about the store rather than the product: usually the creator roster in the weaker store never picked it up, or the shipping time from that warehouse is long enough to suppress conversion.
Rolling the numbers up across stores is the reporting step, not the analysis step. It is useful for spotting that store B’s SKU set is drifting away from store A’s, and useless for deciding what to do about it. DAMI’s multi-store rollup keeps the per-store SKU view intact while showing the combined figure, so the category comparison does not require exporting three files and reconciling names by hand — the same rollout logic described in the multi-store creator data piece applies here, just on the sales side.
A monthly twenty-minute review that actually holds
The review does not need to be sophisticated; it needs to be short enough to survive a busy month. Twenty minutes, four steps, same order every time.
| Step | What you pull | Decision it forces |
|---|---|---|
| 1. Store net | Store performance for the period, with refunds, tax and shipping deducted | Is the month profitable at all |
| 2. Refund and shipping share | Both as a percentage of GMV | What a good SKU looks like this month |
| 3. Top five and bottom ten | Sales detail sorted by units, active listings only | Which SKUs get samples, which get delisted |
| 4. One creator action per quiet earner | Three creators per SKU from your roster | Two hours of work that is not more product research |
The one thing to resist is expanding the review. Add return-reason analysis only for the traffic traps, add traffic data only for the bottom ten. A review that touches every SKU every month gets skipped in month two, and a skipped review is worse than a narrow one.
Where this workflow stops being useful. Sales detail is a rear-view instrument. It tells you what sold, which is the right input for next month’s sample budget and the wrong input for a launch decision. A new SKU has no units, so it ranks at the bottom by definition, and running this analysis on a three-week-old product will tell you to delist it.
There is a second limit worth stating: per-SKU attribution gets fuzzy when one video promotes several products. The units land on whichever SKU was attached to the listing, not necessarily on the product the viewer wanted, and no amount of table reading resolves that. If your creators routinely bundle three items in one video, trust the category ranking more than the individual SKU ranking.
The workflow is also blind to why a SKU moves. It cannot tell you whether the anchor sells because of the product or because one creator made a video that happens to work. That answer lives in the creator and video data, which is why the dashboard metrics worth tracking include creator-level figures alongside product ones.
FAQ
Does the SKU table include refunds and fees?
No. SKU rows carry GMV, order count, and units. Refunds, tax, and shipping are deducted at store level, so the per-SKU number is gross and must be read against the store’s net figure.
How many SKUs should I analyse each month?
Top five and bottom ten per category. Everything in between changes too slowly to justify the reading time at this catalogue size.
Should I delist a SKU with zero sales?
Only after checking views. Zero views means it was never seen and the problem is traffic. Views with no orders means the product or the listing is wrong.
How do I compare stores fairly?
Rank inside each store and compare at category level. Cross-store rank comparisons mostly measure warehouse distance and creator roster quality, not product strength.
What if my best seller has the highest return rate?
That is a traffic trap. Fix the claim in the creative or the variant that gets returned, and keep selling it, because the demand is real and the loss is operational.
The decision this data is actually for
Every number in this article exists to answer one question you will face next week: where do the next fifty samples go? Not which product is best in the abstract. Which twelve SKUs deserve the sample budget, the creator slots, and the listing work this month.
Teams that answer that question monthly, with a narrow review and a clear ranking, usually find their margin improves without a single new product. Teams that skip it keep adding SKUs, keep watching GMV rise, and keep wondering why the account does not grow in step.
Start in the DAMI workspace with the store-level net for last month, then filter SKU sales detail to active beauty or apparel listings for the same period. The top five and bottom ten will take ten minutes to produce, and they set the sample budget for the month.
