# What a PIM is and its role in an online store

> What a PIM (Product Information Management) is, how it organizes families, channels and completeness, and how to decide which system rules each field.

URL: https://clione.ai/glossary/pim/
Lang: en

If someone at your company says "that gets changed in the PIM", they mean the system where product information lives before it reaches the store. PIM stands for product information management, and it has nothing to do with the personal information managers of old electronic organizers, which share the acronym. For a store it matters for a practical reason: **when there is a PIM, the published [product page](/glossary/product-page/) is the last stop for a piece of data that was decided somewhere else**, and if nobody knows which system rules each field, the changes made in the store vanish at the next sync.

## How it works

Every PIM has its own vocabulary, but the pieces repeat. We explain them with Akeneo's documentation, a PIM whose public help defines each concept separately.

**Families.** A family is a set of [product attributes](/glossary/product-attributes/) shared by the products in that family, and a product that joins it automatically inherits all its attributes.[^akeneo-family] Sneakers have size, drop and sole type; backpacks, capacity and material. **The family is the data's template**, just as the theme template is the page's template.

**Channels.** A channel is a selection of products and information to export, and it can be a website, a printed catalog or a mobile app. Each channel has its own category tree, languages and currencies, and **its own completeness**: a website may require 50 attributes and an app, 30.[^akeneo-channel] It is the PIM's central idea: the same product is prepared differently for each destination.

**Completeness.** It is the percentage of required attributes that have a value, calculated by family, channel and active languages. A product is complete when it reaches 100%, that is, when all its required attributes have a value.[^akeneo-completeness] It is the metric a catalog team uses to know what is missing before publishing.

**Distribution.** The PIM does not sell: it sends. Its job ends when the data reaches each channel, whether the store platform, a marketplace or [Google Merchant Center](/glossary/google-merchant-center/). Merchant Center, for example, accepts products by file, by Google Sheets, by its API, from ecommerce platforms such as Shopify, or by reading the site's [structured data](/glossary/structured-data/).[^gmc-data-source] Each destination has its own rules: a product title in Merchant Center takes up to 150 characters and the description, up to 5,000.[^gmc-spec] That is why a PIM often keeps several versions of the same field, one per channel.

**The connections change.** Connectors that use each destination's API break when the destination changes. Google retired the Content API for Shopping on August 18, 2026, began returning progressive errors from September 1 and asks you to migrate integrations to the Merchant API.[^merchant-api-updates] If your PIM sends products to Google by API, **ask which API it uses today**.

## In a store

What a PIM forces you to decide is who rules each field. A **fictional example**: an outdoor gear store with an ERP for prices and stock, a PIM for product content and the store on Shopify:

| Field                                                                                   | Who writes it            | Who receives it                                 | What happens if it is edited in the store       |
| --------------------------------------------------------------------------------------- | ------------------------ | ----------------------------------------------- | ----------------------------------------------- |
| Price and stock                                                                         | ERP                      | PIM, store and [feeds](/glossary/product-feed/) | The next ERP sync overwrites it                 |
| Name and description                                                                    | PIM                      | Store and feeds                                 | The next PIM export overwrites it               |
| Attributes (size, material, capacity)                                                   | PIM                      | Store, feeds and markup                         | The next PIM export overwrites it               |
| Images                                                                                  | PIM or its image manager | Store and feeds                                 | Depends on whether the export includes images   |
| [Meta title](/glossary/meta-title/) and [meta description](/glossary/meta-description/) | The store                | Only the store                                  | It stays, if the PIM does not export that field |
| FAQs and [JSON-LD](/glossary/json-ld/)                                                  | An enrichment tool       | Only the store                                  | It stays, unless another system writes over it  |

The last column is the one that gives people a scare. When two systems write the same field, the last one to sync wins, and the platform does not have to warn you. If you use a tool that publishes to the store, ask what it does in that case. Clione, for example, flags the product at the next sync when the platform or a PIM overwrites a field it published, with the date and the exact fields, and republishing is your decision.


That a product at 100% completeness is ready. What completeness measures is how many required attributes have a value,[^akeneo-completeness] and **a value can be filled in and be false**: a capacity copied from another model counts the same as the right one. It also counts only the attributes someone marked as required for that family and that channel.[^akeneo-family][^akeneo-channel] Completeness says what is missing; whether what is there is correct is something only a review can say.


## How to check it

1. **List your channels.** Store, marketplaces, Google feeds and other destinations' feeds, printed catalog. With a single channel, a PIM has little to distribute; with several, it is where you decide what each one gets.
2. **Write the field map**: for each field, which system writes it and which ones receive it, as in the table above. A field with two systems writing it is a [field overwrite](/glossary/field-overwrite/) waiting to happen.
3. **Pick three products and compare them in three places**: the PIM, the published [product page](/glossary/product-page/) and the feed. Name, price, attributes and description have to match.
4. **Review completeness by channel**, not overall: a product can be complete for the website and incomplete for Google.[^akeneo-channel][^gmc-spec]
5. **Ask how the data reaches Google**: if it is by API, make sure the integration uses the Merchant API and not the Content API for Shopping.[^merchant-api-updates][^gmc-data-source]

## Related concept: product catalog

The [product catalog](/glossary/product-catalog/) is the set of products the store has set up on its platform, the one you see in the Shopify or BigCommerce admin and the one that gets published. The PIM comes before it: it is where the information that ends up in that catalog and in the other channels is prepared. A store without a PIM edits its catalog directly on the platform; a store with a PIM **edits in the PIM and lets the platform's catalog receive**. Mixing the two ways of working without a field map is what makes changes disappear. Improving that data, wherever it comes from, is [catalog enrichment](/glossary/catalog-enrichment/).

To keep going, the [catalog and entities reading path](/learn/catalog-and-entities/) lays out the rest of the terms.