One record per product, and one place that can change it
One database doesn’t stop copies drifting. What stops it: one place that accepts writes, checks before a push, and a version of the record shaped for each channel.
On this page
Someone edits a product description in Shopify. Nobody tells the Amazon team. Both versions stay up for three weeks, until a shopper posts a screenshot of the difference in a review.
An image gets swapped in the ERP. The old one is still cached in the DAM, so the marketplace shows a colorway you discontinued. A price changes in the webshop but not in the Google Shopping feed, and the comparison engine flags a mismatch.
Many brands selling on several channels have lived some version of this. The usual answer is to put all the product data in one database.
Teams do that, and the copies drift again. Storage was never the problem. The problem is that several systems can still write to the same field.
One record per product is the starting point, not the answer. The work sits around that record. Who can change a field, what gets checked before a push, and what each channel receives from it.
The data splits, then splits again.
Bad tools aren’t the cause. The cause is that everyone keeps a working copy, and nothing stops them from editing it:
- The ERP team owns SKU masters, cost prices and warehouse attributes
- Marketing writes descriptions and brand copy in Google Docs or Notion
- The agency keeps Amazon content in its own tools
- The Shopify developer fixes wording in the theme, and the marketplace team edits listings in Seller Central to get past validation
- The creative team drops images in a shared drive or an S3 bucket, named however that person named them
- Compliance keeps regulatory data in PDFs and spreadsheets, emailed once a quarter
Each team works from the copy it holds. The copies diverge on the first edit. A data cleanup fixes the values and leaves the workflow alone, so the copies split again.
Note
The cause is write access
This isn’t a data problem. It’s a write problem. When two systems both accept edits to the same field, you don’t have one version, you have two opinions. The fix isn’t copying data into one place. The fix is that one system accepts writes and the rest only read.
Direct edits in channel tools undo the record.
This is where it usually falls over, even with the right tools in place.
Someone on the marketplace team clears a listing rejection in Seller Central. A Shopify developer adjusts a description in the theme. A social commerce coordinator edits a product card in the platform admin.
Each one leaves the channel holding a value the PIM doesn’t have. The next push from the PIM overwrites it, and the fix is gone. The person who made it learns that the PIM breaks their work.
So they stop opening the PIM. From then on, the record is one more copy.
Policy doesn’t hold this. What does:
- Set channel tools to read-only where the platform allows it, through staff permissions in Shopify admin or user permissions in Seller Central
- Where it doesn’t, check the channel for direct edits on a schedule and fix them in the PIM
- Make the PIM the quickest place to fix a typo, so the fix happens there and reaches the channels on their next update
- Give an urgent correction a short path, one approval for a typo or an emergency price change
- Reach the PIM from where people already work. Through MCP (Model Context Protocol), a merchandiser can update product data from Claude or ChatGPT, signed in with their own permissions, without opening the PIM UI
What actually breaks.
The cost isn’t abstract. It shows up as listings rejected, prices that don’t match, and agents writing from values nobody trusts:
Scroll sideways to see the whole table.
| What breaks | What it looks like | Why it happens |
|---|---|---|
| Two versions of the same product | The webshop says “100% organic cotton” and Amazon says “cotton blend.” A shopper who sees both stops trusting either one. | Two systems both accept description edits, and a change in one never reaches the other. |
| Listings rejected at the marketplace | A listing comes back for a missing EAN, the wrong category, or an attribute in the wrong format. | Nothing checks the record against the channel’s rules before it leaves. |
| Prices that don’t match | Google Shopping shows €49.99 and the webshop shows €54.99, and shoppers ask to be charged the lower one. | The price changes in one system and reaches the others late, or not at all. |
| Updates that arrive late | A product gets a new ingredient list. The website has it on day 1, Amazon in week 3, the print catalog never. | Each team updates its channel on its own schedule, from its own copy. |
| The wrong catalog in the wrong country | The German website lists products that aren’t sold in Germany, and the French marketplace is missing products that belong there. | Availability is set channel by channel, by whoever runs each one. |
| Agents working from stale values | An agent writes descriptions from an old export rather than the current record. | Each agent reads whichever source it was wired to, current or not. |
| The same product recorded more than once | One SKU sits in 3 systems with different attribute values, and reports built on them disagree. | Nothing decides which records are the same product. Someone merges them by hand, and the copies come back. |
| Nothing to hand the auditor | An audit asks for the current materials declaration for every product sold in the EU, and no single system can produce it. | Compliance data sits in supplier PDFs and in fields spread across systems, with no one place to query it. |
Changing tools doesn’t remove any of these. They come back because nothing decides which system owns the field, and nothing checks the record before it leaves.
Storage isn’t the hard part.
Teams buy a PIM, import everything, and call it done. Six months later the Amazon agency still keeps its own spreadsheet, and the PIM holds values nobody trusts.
Storage on its own is one more copy. What makes a record the one people actually use is everything around it, and none of it is a database feature:
Scroll sideways to see the whole table.
| What the system has to do | What that looks like day to day | What happens without it |
|---|---|---|
| One place accepts writes | The team edits product values in one system. Channel tools receive them and aren’t used to change them. | Every team keeps editing its own copy, and the copies drift again. |
| Changes get checked before they land | An agent’s suggestion waits for a person by default, edits are limited by role, and a product is checked against a channel’s field rules before it is pushed there. | Bad values go in unchecked, including values an agent invented. |
| Changes reach the channels | A change goes out with the next push or feed run, built from the one record, rather than whenever someone remembers. | An update happens when someone remembers to make it. Every gap in between is a stretch where a shopper can see two answers. |
| Each channel gets its own shape | One record produces what each destination expects, from Amazon’s required fields to a retailer’s file template. | Someone adapts the content by hand for every channel, and the versions drift. |
| A rule for when two sources disagree | Someone has written down which source owns each field, so a supplier file, an ERP export and a hand edit don’t take turns overwriting it. | Whatever was written last wins, so a stale import overwrites a value someone had just corrected. |
| Other systems can query it | An enrichment run, a recommendation engine or a compliance tool can ask for the current value, over the API or MCP. | Agents work from exports and snapshots that are out of date by the time they read them. |
An agent reads whatever it’s given.
A person who sees two different fiber compositions stops and asks which one is right. An agent doesn’t.
It reads the values it’s given, treats them as correct, and writes from them. That changes what a stale field costs:
- An enrichment agent writing from a stale field repeats the same error at scale: not one bad description, but thousands
- An AI shopping agent may cite whichever version of your data it finds first
- A recommendation engine built on inconsistent attributes suggests the wrong items, and irrelevant suggestions damage conversion
- A chatbot answering a specification question states the wrong number with no hedge, which erodes buyer trust
- A workflow that keys on the current product state can’t tell which of three systems holds it
- A compliance check needs one attribute set, not three partial ones from different systems
Split product data doesn’t only make the site look inconsistent. It makes every agent reading it unreliable, and it does that at scale: one stale value, repeated everywhere the agent writes. Inconsistency was annoying but survivable when a person could stop and use judgment. That is the part the agent doesn’t do. One maintained record isn’t a convenience for the data team, it is the condition for handing work to an agent at all.
Four steps, in order.
The model that holds up has four steps. Each one does a different job:
1. Bring the data in.
Supplier feeds, ERP exports and manual imports each come in through a saved mapping someone reviewed.
An import writes straight to the record and reports a result for each row, so decide which source fills which field before the first one runs. If you’re comparing vendors, ask what happens when an import disagrees with a value already there.
2. Decide who can change what.
Attributes are typed, and roles decide who can edit them. By default, an agent’s suggestions wait for a person before they apply. Every product keeps a version history of who changed what, and when.
An edit from a role without permission is rejected. That is what makes the record trusted rather than merely central.
3. Work out what each channel needs.
When the record changes, the system works out which channels carry that product, what shape each one needs, and, for a direct push to Amazon or Shopify, whether the product passes that channel’s field rules. Ask any vendor whether its system can also hold a product back until it clears a completeness threshold for that channel.
A change goes out when you run the push or on a schedule you set, and a push sends only products marked Approved.
4. Give each channel its own version.
Each output is built from the same record at publish time. Amazon gets its required fields, character limits and category mapping. Shopify gets its metafield format, and any other channel gets a file in its own template.
In CataZenta, one product holds per-channel titles and copy; Amazon and Shopify pushes are checked against each channel’s field rules first, and other channels get a CSV or Excel feed built from their template, run by your team.
An AI assistant connected through MCP reads that same record, within the permissions you grant it. One record, several shapes, and no two of them disagreeing.
Before and after.
Six situations, handled with copies and with one record:
Scroll sideways to see the whole table.
| Scenario | With copies | With one record |
|---|---|---|
| A product is reformulated | The ingredient list changes in the ERP. Marketing hears about it 2 weeks later. The website is updated in week 3, the marketplace in week 5, the print catalog never. | The change lands in the PIM on the ERP export, and channels are fed from that one record. |
| Selling through a new retailer | “What data does a new retailer need?” turns into a 4-week research project, then a manual export, then a column mapping in a spreadsheet that someone has to keep up. | The retailer’s template is uploaded and its columns mapped to existing attributes once. |
| Changing a price everywhere | The price changes in the webshop. The marketplace team hears about it on Slack. The Google Shopping feed catches up on the next weekly batch, 5 days later. | The price is updated once, in the system that owns it. Amazon and Shopify pick it up on their next push, and the next feed file your team runs carries it. |
| Writing content with an agent | The tool writes from webshop values that are already out of date. What it produces contradicts the marketplace listing, and someone squares the two up by hand. | AI enrichment works from the PIM record itself, so it starts from current attributes rather than a stale webshop copy. Drafts are reviewed by default before they reach any channel. |
| A regulatory audit | “Show me current product declarations for all EU products.” Weeks of pulling data out of several systems and working out which values agree. | If declarations are modeled as attributes, one filtered export returns them, with each product’s version history behind it. |
| Taking on an acquired brand | The new brand keeps its data in spreadsheets and Shopify. A long migration follows, with both sets maintained side by side for months. | The new brand is set up in its own workspace and imported through saved mappings; agent suggestions on it wait for review by default. Plan the cut-over from its current store. |
Start with a 4-week proof.
- Take your top 50 SKUs and open them on every channel. Count the ones where the title, description, price or image differs. That count is what the split is costing you.
- List every system and every person that can change product data today. That list is your write map. The goal is one entry.
- Import those 50 SKUs into the PIM and agree it is the only place your team edits product data. Set up the feed for each channel.
- Set the channels to read-only where the platform allows it. Where it doesn’t, check the channel for direct edits on a schedule.
- Measure again. How many products still differ, how long a change takes to reach every channel, and how often a channel rejects a listing.
The 50-SKU pilot is there to show you three things: whether the channels line up once one system owns the writes, whether anyone still reaches for the channel tool to make an urgent fix, and whether the setup looks like it holds as you add the rest of the catalog.
Tip
The question to ask in the room
The test isn’t whether all the product data sits in one place. It is whether a person or an agent can read any attribute’s current value from one place, and know it is the one that goes out. If your team checks two systems, compares the values, or wonders which one is current, you don’t have that yet. You have copies, and an agent can’t tell copies apart.