> ## Documentation Index
> Fetch the complete documentation index at: https://docs.retailgrid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Product and SKU-Store grid views

> Work at the right granularity - one row per product, or one row per product-store combination with store-scoped prices, costs, and metrics.

With store-level data loaded, a grid can display rows at two levels of granularity:

* **Product view** - one row per product, with aggregated fields where applicable. The right level for catalog-wide work.
* **SKU-Store view** - one row per product-store combination. The right level when prices, costs, or competitors differ per store.

<Note>
  Not to be confused with [Views](/grids/views), which save and restore grid *layouts* (columns, filters, sorting). This page is about row granularity.
</Note>

## Switch between views

Use the grid-level **Product / SKU - Store** toggle to switch modes. Switching changes the row granularity in place - no page reload.

Your selection is persisted per workbook and session, so a grid you work in SKU-Store view stays that way when you come back.

The SKU-Store toggle is available once store-level data is loaded - see [Product store data](/data-requirements/product-store-data) and [Manage stores](/stores/manage-stores).

## What changes in SKU-Store view

Every row is one product in one store. Alongside the product columns you get the store columns:

* **Store** (identifier)
* **Country**, **Currency**, **Channel**, **Pricing zone**
* **Store price** - the price in that store, plus store-scoped cost and stock when loaded

A product active in 12 stores shows as 12 rows, each carrying that store's own values.

## Filters and sorting

Filters and sorts work in both views and respect the current mode:

* Store-scoped filters (by country, channel, pricing zone, store) apply in SKU-Store view.
* Switching views preserves applied filters where they still make sense. When a filter can't be carried across (e.g. a store filter going back to Product view), the grid warns you instead of silently dropping it.

## Metrics per store

In SKU-Store view, [metrics](/reference/metrics) are computed at the SKU-Store grain: each row's margin, price index, and competitor gap use that store's own price, cost, and competitor set. In Product view you see the product-level rollup of the same metrics.

This matters wherever stores genuinely differ - a SKU can be comfortably profitable in one market and underwater in another, and only the SKU-Store view shows that split.

## Pricing agents at the SKU-Store level

[Dynamic Pricing](/agents/dynamic-pricing) runs at the SKU-Store level when your grid carries store-level data: one recommended price per product-store combination, computed against each store's own competitor prices and costs. Rules can target store attributes (country, channel, pricing zone) so different stores get different guardrails.

## Performance

SKU-Store view multiplies row counts (products × stores), and the grid is built to stay responsive on typical catalogs - tens of thousands of product-store rows. If you work with very large combinations, filter to the stores you're actively pricing.

## Related

* [Manage stores](/stores/manage-stores)
* [Product store data](/data-requirements/product-store-data)
* [Dynamic Pricing](/agents/dynamic-pricing)
* [Metrics glossary](/reference/metrics)
* [Views (saved layouts)](/grids/views)