GPC (GS1 Global Product Classification)
GPC (GS1 Global Product Classification) is GS1's standard scheme for sorting products into a four-level hierarchy: segment, family, class, and brick. The brick is the working level — an eight-digit code that says what a product fundamentally is, independent of brand, packaging, or supplier. In GDSN, the brick you assign is what tells a data pool and its recipients which attributes and validation rules apply to that item.
The four levels, and the one you actually publish
GPC is maintained by GS1 and republished on a set cycle, so codes get added, renamed, and deprecated over time. It has four nested levels.
| Level | What it answers | For a 3/8-16 Grade 8 hex bolt |
|---|---|---|
| Segment | The broad industry sector | Hardware |
| Family | A group within that sector | Fasteners |
| Class | A narrower grouping | Bolts and screws |
| Brick | What the thing fundamentally is | Hex bolt |
Each brick also carries its own attribute set: the properties that distinguish items within one brick. For the hex bolt, that is drive type, thread type, and material grade. Those attributes hang off the brick rather than forming a fifth level of the hierarchy.
Every brick has both a name and a code. Hex bolt is the name. The code is eight digits beginning with 1000, and you take it from the current GPC publication rather than deriving it yourself. Brick codes occupy their own number space, so a class code tells you nothing about which bricks sit beneath it, and a brick can be re-parented in a later publication while its code stays the same.
One distinction worth nailing down. A GTIN identifies a specific trade item. A GPC brick classifies what kind of thing it is. Two different manufacturers' 600V wire connectors carry different GTINs and different MPNs while belonging to the same brick, which is the whole point.
Why the brick decides your attribute workload
GDSN requires a GPC brick on every trade item you publish. The brick is the key that selects a rule set.
The chain runs like this:
- You assign a brick to the item.
- Your data pool applies the validation rules attached to that brick, plus any market-specific profile (US, EU, and so on).
- Those rules decide which attributes are mandatory, which are optional, and which values are legal.
- The recipient, a retailer or distributor, receives the item already sorted into a category their own systems understand.
So the brick is upstream of the work. Move a UL listed 600V wire connector from a generic "electrical accessory" brick to the correct connector brick and the required attribute list changes underneath you. Fields you never populated become mandatory. Values you had as free text now have to come from a code list.
Brick assignment is therefore a standing job with a review cadence. It sets how much enrichment each item needs before it can be published at all.
GPC vs the other classifications on the same SKU
A single SKU in a distributor's catalog often carries four or five classification codes at once, each answering a different question for a different audience.
| Scheme | Who asks for it | What it's for |
|---|---|---|
| GPC brick | GDSN data pools, GS1 trading partners | Selects required attributes and validation rules for the item |
| UNSPSC | Procurement, ERP spend analysis | Categorizes spend and purchasing, not product specs |
| ETIM / ECLASS | Electrical, HVAC, MRO channels in Europe | Deep technical attribute models per class |
| Google Product Category | Shopping feeds | Ad and search placement |
| HS code | Customs | Duty and tariff treatment |
| Your internal taxonomy | Your site's navigation and facets | How your buyers browse |
The practical consequence: each of these schemes maps to the others only loosely. A brick may span several UNSPSC codes. Your internal category for "fasteners" may split across a dozen bricks. Treat every mapping as its own maintained artifact with an owner, reviewed whenever either scheme publishes a new version.
How brick assignment goes wrong
The failure modes are consistent across catalogs, and none of them throw an error at the moment they happen:
- Defaulting to a broad brick. Someone picks the least specific brick that validates. The item publishes, the required attribute list stays short, and the recipient gets an item that lands in the wrong place on their shelf.
- Copying the brick from a similar item. Fine until the similar item was wrong too. Errors propagate down a product line.
- Ignoring publication changes. GPC gets updated. A deprecated brick sitting on thousands of live items surfaces as a bulk rejection months later.
- No evidence trail. Nobody recorded why this bolt got this brick, so the next person re-litigates it.
- Brick assigned before the attributes exist. The classification is correct but the item cannot publish, because the brick's mandatory attributes were never captured from the spec sheet.
That last one is the common case, and it is where the labor sits. A PIM stores the brick and the attributes; something else has to read the manufacturer's datasheet, pull the thread pitch and material grade, and normalize them to the brick's code list. Anglera does that work alongside Akeneo, Salsify, Syndigo, inriver, or Pimberly.
The brick tells you what's required. Something still has to fill it.
Frequently asked questions
What is a GS1 GPC brick code?
A GPC brick code is an eight-digit identifier, beginning with 1000, that names what a product fundamentally is — a hex bolt, a UL listed 600V wire connector, a pipe fitting. It sits at the lowest level of the GPC hierarchy, below segment, family, and class. Each brick carries its own set of attributes and permitted values, which is what makes the brick the operative code in GDSN rather than the levels above it.
Is GPC the same as UNSPSC?
No. Both classify products, but they answer different questions for different audiences. GPC is GS1's scheme and is what GDSN uses to decide which attributes an item must carry. UNSPSC is a procurement and spend-analysis taxonomy used mainly in ERP and purchasing. A single brick can span several UNSPSC codes and vice versa. Most catalogs carry both, mapped separately and maintained separately.
Do I need a GPC brick for every item I publish to GDSN?
Yes. Every trade item published through GDSN carries a GPC brick code, and it drives the validation rules your data pool applies. Assign it before you start collecting attributes, since the brick is what tells you which attributes you need. In practice the brick is one of the first fields you have to get right, because everything downstream keys off it.
What happens if I assign the wrong GPC brick?
Usually nothing visible at first, which is the problem. The item validates against the wrong brick's rules, so mandatory attributes you actually needed are never requested and never populated. The recipient receives the item classified as something it isn't, and it surfaces on their side as a miscategorized product, a failed onboarding, or a support ticket weeks later. Correcting it means republishing with a new required attribute set.
How often does GPC change, and who maintains it?
GS1 maintains GPC and publishes updated versions on a regular cycle, adding new bricks and retiring old ones as categories evolve. So brick assignment needs a standing review, scheduled against the GPC release cycle. If nobody checks, deprecated bricks sit quietly on live items until a data pool rejects them in bulk. Treat the GPC version you validate against as a tracked dependency.