Products, channels & reporting (seams)
A product is the hub of the catalog, but most of what makes a product useful happens in systems that sit next to it: it gets listed on sales channels, its channel counterparts get synced, its performance is rolled up into dashboards and scorecards, it feeds what-if profitability models, it shows up as a row in the report builder, and it gets indexed so search can find it.
This page maps those seams — the connection points from the product out to each neighbouring system — so you understand what crosses each boundary and why. It deliberately doesn't teach you how to operate those systems. Each one has its own home in the docs, and this page links you there. Think of it as the wiring diagram behind the product, not the manual for any single appliance.
For the inventory seam (stock levels, opening balance, FIFO valuation), see the Inventory guides instead — that facet is documented under View a product's stock and Browse FIFO layers, and isn't repeated here.
The product as a hub
At a high level, a single product record radiates out to six adjacent systems. Each arrow is a seam this page describes.
None of these systems own the product; the product owns a reference to each of them (or is referenced by them). Understanding the direction of ownership at each seam is the useful thing — it tells you what happens when a product is created, edited, merged, or deleted.
Sales-channel listings
A product has many listings — one per place the product is published or linked on a sales channel. The product's Listings tab surfaces those listings, counted by integration, with the controls to publish and link. The relationship runs one way: the product is the source of truth, and each listing is a downstream projection onto a channel.
A few product-facing facts leak back across this seam and are worth knowing:
- The FBA flag is derived from listings, not set by you. A product counts as an FBA product when any of its listings belongs to an FBA channel. You never toggle this yourself — publish or unpublish an FBA listing and the flag follows.
- Listings are cleaned up with the product. When a product is deleted, its listings are deleted alongside it (see Archive, unarchive & delete a product). When two products are merged, the listings move to the surviving product rather than being orphaned (see Merge duplicate products).
- Channel orders can create products. An inbound channel listing can spawn a SKU.io product through the "create products from listing" flow — but that flow lives on the listing side, not the product side.
- Data health counts channel coverage. The product data-health check inspects channel mappings as one of its signals, so a product with no listing where you'd expect one shows up there (see Review product data health).
Everything about publishing, mapping, and managing listings — including how kits and bundles are published to a channel and how a bundle expands into component lines on an inbound channel order — is the Listings area, coming in the Listings guide. From the product docs, cross-link there; don't operate listings from here.
Channel product sync
Distinct from your listings is the channel's own representation of a product. Each integration (Shopify, Amazon, WooCommerce, and more) keeps its own product records, and SKU.io mirrors them into a common shape it calls a channel product — so an Amazon product and a Shopify product look the same to the rest of SKU.io, with the channel recorded on each one.
- One list, many channels. Every connected channel contributes its products to the same list, tagged with the channel they came from. That's what lets you review and map channel products from one place instead of one screen per integration.
- Mapping is what makes a channel product useful. Once a channel product is mapped to a SKU.io product, that mapping is what pushes inventory out to the channel and what resolves inbound order lines back to the right SKU.io product. Order lines are matched to channel products in the background, so a new mapping applies to orders shortly after you save it rather than instantly.
- Some 3PL stock is matched on the SKU string. A few third-party-logistics stock feeds (ShipMyOrders and ShipFusion inventory, for example) match to your product on the SKU text itself, not on a stored link. That match is brittle: rename or mistype a SKU and the stock silently stops matching. Keep SKUs stable and consistent (see Edit a product's details for SKU-change caveats).
The mechanics of each integration's sync — auth, polling, field mapping, conflict resolution — belong to that integration's area, not here. This page only marks the seam so you know channel products and your products are two different things joined by a mapping.
Metric snapshots & scorecards
The product carries a lot of performance data, but almost none of it's entered by hand — it's computed and owned by the demand-planning and reporting area and stored either as pre-aggregated snapshot tables or as cached fields on the product itself.
There are two layers to keep straight:
Monthly snapshots (macro dashboards). These are pre-aggregated monthly buckets the macro dashboards read from:
| Snapshot | Covers | Holds |
|---|---|---|
| Product | one row per product per month | sales volume, units sold, COGS, profit, purchase volume, units received/returned, ending on-hand units, ending inventory cost |
| Product × channel | one row per product per sales channel per month | the sales-side split of the above per channel — no purchasing figures |
| Brand | one row per brand per month | brand-level sales and purchasing rollups, plus PO on-time and received counts |
Purchasing figures exist at the product and brand level, never per channel, because a purchase order isn't attributable to a sales channel. Snapshots are rebuilt in bulk by a background Tracked Job (you can watch its progress in the job tray), and are refreshed automatically when the data behind them changes.
Cached velocity figures (demand planning). Separately from the monthly snapshots, a handful of demand-planning figures are stored on the product itself so they're fast to read: units sold over the last 30, 60, 90, and 180 days, daily average consumption, ABC and XYZ classification, demand trend percentage, and the time the velocity figures were last computed. These sit alongside the fields you fill in, but you never edit them — they're refreshed by the velocity calculation, and that last-computed timestamp tells you how fresh they are.
Scorecards. On top of the metrics, each product gets a composite scorecard score. The weighting is account-wide rather than per product: one set of weights, thresholds, and a minimum sales-order gate applies to every product. The score is a weighted blend of six dimensions:
| Dimension | What it measures |
|---|---|
| Gross margin | margin on sales |
| GMROI | gross-margin return on inventory investment |
| Sales growth | period-over-period sales change |
| Sell-through | how fast stock converts to sales |
| Stock cover | days of cover on hand |
| Return rate | share of units returned |
Two rules matter: the weights must sum to 100, and a product is only scored once it has at least the minimum number of sales orders in the period — below that gate it's left unscored rather than scored misleadingly on thin data.
All of this — the dashboards, the scorecard configuration, the velocity model — is documented in the demand-planning and reporting area, not in product CRUD. This page only tells you which fields on a product are computed rather than entered, so you don't try to edit them.
Pro Forma analyzer
Three fields on the product exist purely to feed the Pro Forma Analyzer, a profitability what-if surface: a Pro Forma shipping cost, landed-cost percentage, and marketplace-cost percentage.
The analyzer combines these with channel and rate-card assumptions to model a product's profitability under different scenarios. A saved scenario is your own what-if snapshot: it stores the inputs you entered, the results they produced, and the version of the rate card used — so when a rate card is superseded, the analyzer can tell you a saved scenario is stale and offer to recalculate it. A scenario doesn't have to point at a real product either; you can model a purely hypothetical one by entering a product profile by hand.
The analyzer itself is a separate surface with its own documentation. Here, just know that those three Pro Forma fields on the product are its inputs (you can set them alongside other financials on the product — see Set a product's accounting & financial line type).
Reporting & the report builder
The product participates in reporting in two ways.
As a source of daily financial rows. Each product contributes daily financial rows to the reporting layer — its share of the numbers the financial reports are built from. Those rows belong to the product, so deleting a product deletes its reporting rows along with the rest of its cleanup; nothing is left stranded.
As a report-builder entity. The custom report builder exposes the product as a first-class entity, publishing its columns — identity (SKU, name, barcode, MPN), classification (ABC/XYZ, primary category), supplier, velocity, cost, accounting, and the Pro Forma fields — as dimensions and measures you can pivot on. Archived products carry their archive date, so a report can include or exclude them.
The report builder and the financial reporting layer are documented in the reporting area. This seam only notes that a product is both a reportable and a first-class report-builder entity, and that its reporting rows are cleaned up with it.
Search indexing
Products are added to a search index so the search box stays fast on large catalogs. Indexing is automatic: create, edit, or delete a product and the index keeps up on its own — there's no re-index step for you to run.
What gets indexed is deliberately narrow. A product is searchable on:
| Field | Indexed |
|---|---|
| SKU | always |
| Name | always |
| Barcode | only when it has a value |
| MPN | only when it has a value |
Barcode and MPN are left out when blank, so an empty barcode never dilutes a match.
Relevance is tuned so identity beats description: a SKU match outranks an MPN match, which outranks a name match, by a wide margin — and an exact SKU match is pushed to the very top. Type a full SKU and you get that product first, even when the same string appears inside other products' names. The products list's general search box uses this index, which is why it ranks results rather than listing every partial text match.
For how the general search box, columns, and filters behave, see Browse, search & filter the products list and the Products list columns, search & filters reference.
Next steps
- How a product flows through the system — the end-to-end lifecycle these seams hang off.
- Products — overview — the map of every product-catalog capability.
- Merge duplicate products — how listings, reporting rows, and mappings are re-homed when products merge.
- Archive, unarchive & delete a product — what's cascaded when a product is removed.
- View a product's stock — the stock/FIFO seam, documented in the Inventory area.