Running many brands on one platform without mixing their data
Two setups are common: a PIM instance per brand, or every brand in one shared system. One multiplies infrastructure, the other mixes brand data. What a third option has to do.
On this page
Both setups fail, in different ways. A separate PIM instance per brand means more infrastructure, the same integrations built again, and no view across the group. One shared system mixes brand data, forces a single attribute definition on every brand, and turns permissions into a knot.
The question isn’t where the catalogs sit. It’s which rules the whole group sets, which decisions each brand keeps, and whether that line holds in the data or only in a policy document.
What breaks as the portfolio grows.
As the number of brands grows, structural problems start to show, and they compound.
Scroll sideways to see the whole table.
| Challenge | What it looks like at scale | What it breaks |
|---|---|---|
| Every brand has its own taxonomy | Brand A calls it “Outerwear > Jackets > Rain.” Brand B calls it “Clothing > Weatherproof > Jackets.” Brand C uses flat categories. | No reporting across the group. An AI system tuned on one taxonomy fails on the next. Search across brands doesn’t work. |
| The same attribute means different things | Brand A’s “material” is a free-text field. Brand B uses a structured select. Brand C keeps “fabric_type” and “material_composition” as separate fields. | An enrichment agent needs the same field types everywhere. Marketplace templates break brand by brand. One automation rule doesn’t carry to the next brand. |
| The same setup, built again per brand | Each brand writes its own import mapping, its own AI prompt templates, its own review steps. What one team works out stays with that team. | Nothing spreads. A new brand starts from nothing. The group pays the same setup cost again for every brand. |
| One product, different names by region | The same parent product sells under a different brand name in each market. Price, description and compliance fields differ by region. | Nobody can see “this product everywhere” in one place. A compliance audit means matching brand-and-region combinations by hand. |
| Marketplace rules learned again per brand | Each brand sells on Amazon, Zalando and Otto — each with different seller accounts, different requirements, different approval workflows. | Channel work multiplies with every brand. Each team works out the same marketplace requirements again instead of sharing what it found. |
| Approvals work differently in each brand | Brand A needs CMO sign-off on descriptions. Brand B publishes automatically. Brand C sends every claim to legal. No shared set of rules. | The group has no way to hold one quality standard. Compliance risk piles up in the brands with the loosest rules. |
| Adding a brand | New brand acquired. Its data sits in Shopify, 3 spreadsheets, and an agency’s Google Drive. It has to be running inside the group within 90 days. | If the architecture can’t take a brand on quickly, that brand runs in parallel systems for months. Integration debt builds up. |
None of this is an administrative inconvenience. The import can’t be reused, the check can’t be written once, and the group can’t compare two brands on the same measure. Every brand you add pays for all of it again.
Where the two common setups break.
The safe-looking choice is one PIM per brand. Nothing mixes, each brand runs itself, and the separation is clean. The costs arrive later.
- Infrastructure grows in a straight line. N brands means N instances to maintain, upgrade, secure and audit.
- Each instance needs its own ERP connector, marketplace connector, channel sync and AI integration. The same thing gets built N times.
- A view across the group needs a data warehouse project on top, with its own lag and mapping work.
- Group standards don’t hold, because each instance validates what it likes.
- Prompts and enrichment steps get rebuilt per instance. What Brand A’s team works out, Brand B’s team works out again without knowing it.
- Onboarding a new brand can be a long infrastructure project.
The other answer is every brand in one shared PIM instance. It trades infrastructure cost for risk that doesn’t show up on an invoice.
- Brand A’s content team can end up seeing Brand B’s unpublished products unless permissions are scoped carefully. Isolation depends on configuration, not architecture.
- Permissions turn into a long list of roles trying to scope access by brand, inside a system that wasn’t built to scope anything by brand.
- The attribute model becomes a negotiation. “Material” means something different to each brand, and the shared system takes one definition.
- AI enrichment context bleeds across brands. An assistant tuned on Brand A’s tone writes Brand B’s copy in the wrong voice.
- Reporting can’t tell the brands apart without manual tagging, which teams forget or set up wrong.
- One brand’s data quality problem reaches the others. A bulk import error in Brand C corrupts a taxonomy every brand uses.
- An acquisition pours a new brand’s data into the same crowded space, where only permissions keep it separate.
What the architecture has to do.
What works is real multi-tenancy. One platform, one isolated workspace per brand, one set of infrastructure underneath, and each brand still deciding for itself inside that. But isolation on its own is not the whole job. A platform that carries several brands has to hold all of this:
Scroll sideways to see the whole table.
| Requirement | What it enforces | Why it matters |
|---|---|---|
| Workspace isolation | Brand A’s data is invisible to Brand B at the query, not only on the screen. Nothing reads across workspaces. | An agent working in Brand A’s workspace has no Brand B data to invent from. MCP (Model Context Protocol) tools are scoped to one workspace. |
| One set of group rules | The same quality standards apply to every brand: minimum completeness, required attribute types, what the change history has to record. | An agent run can cover the whole group, because the input looks the same in every brand. |
| What each brand decides | Each brand sets its own taxonomy, attributes, channels and agent settings, inside the group rules. | Enrichment works from that brand’s own products. Channel settings fit the brand without the group having to settle on one shape. |
| Comparison across brands | Every brand measures completeness and quality the same way, so group leaders can compare brands without opening individual records. | Where the group puts its money rests on what it can see across the portfolio. Ask whether the platform does this or leaves it to exports. |
| A standard way to add a brand | A new brand should start from a template, not a fresh implementation: open the workspace, apply the group rules, set up saved mappings, connect the channels. | A brand you buy should join the group’s standards from the start, without a long stretch of parallel systems. |
| Shared AI, scoped per brand | Enrichment, MCP tools and model access should be shared across brands, while the context an agent reads stays inside one workspace. | An improvement should land once for every brand, while each brand’s data stays in its own workspace. |
CataZenta keeps each company’s catalog separate from every other company’s, and assistants connected over MCP can only do what the signed-in user is allowed to do. It doesn’t separate brands inside one workspace, share rules, templates or channel connections across workspaces, or report across them. Ask any vendor, including us, which of these it really does.
Note
Where the line sits
Running several brands on one platform isn’t “run every brand from one place.” Standardize what pays off across brands. Quality standards, data people trust, one set of infrastructure. Leave each brand what makes it a brand. Its voice, its channels, the depth of its own taxonomy. The boundary holds because the architecture draws it, not because a policy asks.
Where AI runs depend on it.
When people did this work by hand, each brand could keep its own standards. An agent run is less forgiving. It reads the fields as they are.
- An enrichment agent needs the same attribute types across products. If Brand A’s fields differ from Brand B’s, you configure the agent per brand, or the output is unreliable.
- A multi-step run (import, validation, enrichment, a channel feed) depends on predictable fields. Where brands differ, that run gets rebuilt per brand instead of configured once and applied broadly.
- MCP tools exposed to outside AI systems have to scope to one brand’s workspace. Without isolation in the data, an outside agent reading your catalog over MCP could surface the wrong brand’s products.
- Group-level work like analytics, demand forecasting and cross-brand recommendations needs one classification scheme. With a different scheme per brand, you pay to map them together before you can compare anything.
- Compliance checks for Digital Product Passports (DPP) and the General Product Safety Regulation (GPSR) need one attribute definition. If “materials_composition” means something different in each brand, each brand needs its own check.
The more agent runs you put across a portfolio, the more the shared standard matters. Without it, each brand pays the setup cost again, and AI multiplies cost instead of value.
Group sets the floor, brands work above it.
The split is the design. One layer is shared and enforced for every brand. The other belongs to the brand alone.
The group layer, shared and enforced.
- Minimum data quality standards. Completeness thresholds, required attribute types, validation rule templates.
- Policies. What an approval has to include, what the change history has to record, what an agent may write.
- Shared infrastructure. The platform, security controls, AI model access, MCP connections.
- Cross-brand reporting (often built outside the platform today). Portfolio completeness, brand-by-brand launch comparison, group-level regulatory readiness.
- The onboarding framework. Workspace provisioning, saved mappings, the standard templates a new brand starts from.
The brand layer, its own and isolated.
- Its taxonomy and attribute schema. Depth, naming, how it classifies.
- Its workflow. Who approves what, how many review stages, which attributes an agent drafts and which a person writes.
- Its channels and marketplace settings. Which channels, which format, how often it sends.
- Its AI templates. Tone of voice, description length, keyword strategy, locale-specific guidelines.
- Its users and roles. Who sees what, who edits what, who publishes.
The group layer holds the standard, and the trust that comes with it. The brand layer keeps what makes the brand a brand, and the pace it wants to move at. Neither can override the other without an explicit escalation, as long as the split lives in the architecture and not in a document. When you look at a platform, ask whether the next brand adds a workspace and an import, or another stack.
Where the difference shows.
Five situations, first in a separate or shared setup, then in what the architecture should allow.
Scroll sideways to see the whole table.
| Scenario | Separate or shared setup | What the architecture should allow |
|---|---|---|
| Buying a brand | A long infrastructure project; systems running side by side for months. Integration debt long after that. | The brand gets its own workspace. Data imported through saved mappings. Group standards applied from the start. |
| An audit across the group | A long job matching records by hand across several systems. Consultants hired. Tracking in a spreadsheet. | Every brand runs the same GPSR check against the same attribute standard, so the results compare like for like. Gaps listed per brand, per product. |
| Rolling out AI enrichment | Built for Brand A. Rebuilt for Brand B. Rebuilt again for Brand C. Different prompts, different validation, different quality. | The enrichment setup is shared. Each brand’s templates sit in its own workspace. Build it once and every brand has it. |
| Questions about the portfolio | “How does completeness compare across brands? Which brand is launching fastest? Where are quality gaps concentrated?” — nobody can answer. | Every brand measures the same way; putting brands side by side without mixing data still usually takes exports and a BI tool. |
| Opening a new marketplace | Each brand researches the requirements on its own, hits the same constraints, and builds the same integration: the same work several times. | Ask whether a connector set up once is available to every brand, and whether channel requirements can be shared as a template. |
If adding a brand takes a fresh infrastructure build, the architecture doesn’t fit how the group grows. If it is configuration rather than a new build, each brand should cost less than a fresh implementation.