Brands

You own brands. The parent has a name people recognise, the three subsidiaries you acquired have their own, and every one of them insists on its own look, its own tone and its own domain, while the ordering logic behind them is identical. The usual outcome is three separate builds by three local agencies, and then you pay for every platform change three times, in three different codebases, on three different release dates. Meanwhile the country organisations want Poland, the Czech Republic and the Netherlands live this year, without a local sales office in any of them.

On top of that sits the channel question, which is commercial rather than technical. You sell through specialist retail and wholesale, and you want a direct channel too. Your trade partners can see your direct storefront, and they will look at it the week it launches. Every price, every delivery promise and every exclusive product on that site is read as a statement about the relationship. A direct channel built without that conversation does not fail technically. It fails in the next annual negotiation with your largest partner.

What is different about your business

One product record has to serve many views at once. The same article is a trade line with a net price and a carton quantity, a D2C listing with a recommended retail price and lifestyle photography, and an export row in a partner's classification. These are views of one record. The moment they become copies, they diverge, and nobody can say which is right.

Your direct channel is visible to the partners who carry you. Price discipline, assortment separation and delivery times are the instruments you steer with. They need to be decided in a room with sales in it, then configured, rather than chosen by whoever sets up the storefront.

Brand identity is per storefront; ordering logic is shared. Each brand needs its own domain, typography, colour and content, running on the same catalog, the same customer model and the same checkout. If a brand's individuality requires a fork, the model is wrong.

A country launch is a data project, not a translation project. Language is the visible part. Underneath sit tax treatment, payment methods, units, legal texts, classification and the question of which assortment may be sold there at all. Translating the storefront while the product data stays German gets you a site nobody can search.

Your reporting only means something in three dimensions. Brand × country × channel. A single revenue line across all of them hides the two markets that are working and the one that is not, and it is the reason multi-brand groups keep funding the wrong storefront.

Governance becomes a real question. Who may publish a price in Poland, who may add a product to the D2C assortment, who signs off brand content for a subsidiary. With one storefront this is a conversation; with fifteen views it has to be roles.

Your path

Phase 1: One data core, cut per channel and locale

Do this before the second storefront exists. Retrofitting channel awareness onto a catalog built for one market is the most common reason these programmes stall.

1. Publish a digital product catalog: the goal page for this phase.
2. The catalog data model → Channels, locales and completeness: the core concept for your whole setup.
3. Plan your data model with Reference entities for brand, and Assets and asset families for the imagery that differs per brand and channel.
4. Tenants, apps and markets: how many tenants you need, which is usually fewer than proposed.
5. Completeness and readiness: a product can be ready for one channel and not another, and the report has to show that.

Phase 2: The second storefront, then the second country

The second one is the expensive one. Once brand two and country two are live from the same core, the rest are configuration.

1. Go multi-country: the goal page for this phase.
2. How storefronts work → Create a storefront → Themes and branding → Domains and going live
3. Languages and markets and Add a language → Translate the catalog → Translation quality
4. Currencies and tax and Payment methods: per market, decided with finance.
5. Classification standards → Classify products where partners or marketplaces require it.
6. Pre-launch checks: run the same list for every market, so market five is not an adventure.

Phase 3: Run the channels honestly

1. Sell through marketplaces and channels: the goal page for this phase.
2. Design your price lists per channel and market, with Rounding, defaults and resolution rules so a recommended retail price and a net trade price cannot collide.
3. Segments and Organizations and hierarchies: a retail group with country subsidiaries is one customer with a structure, not twelve accounts.
4. Promotions vs. contract prices: the rule that stops a D2C campaign undercutting a partner's agreed price.
5. Raise order value → Bundles and kits for cross-brand selling between parent and subsidiaries.
6. Decide on real numbers → Agree what counts as an order → Currency, time zones and periods → Build a custom dashboard per brand, country and channel.
7. Users, roles and permissions: publishing rights per market, once there is more than one team.

The mistakes we see most in your industry

• Cloning a tenant per brand or per country. It is the fastest path to storefront number two and the slowest to storefront number six. Every later change is done n times, and within a year the data has drifted far enough that no report reconciles.
• Launching a market before deciding who answers the phone in that language. A Czech storefront generates Czech questions, Czech returns and Czech invoices. The commercial readiness is harder than the technical readiness and is usually planned last.
• Setting the D2C price without the trade channel in the room. Once your partners have seen it, it is the reference point in every negotiation. Decide the discipline first (recommended retail, assortment split, delivery), then build.
• Translating the storefront but not the product data. The navigation is in Dutch and the attribute values are in German, so search returns nothing and the facets are unusable. This is the most common defect in a country roll-out.
• Reporting one combined revenue number. With several brands, markets and channels it is the number that lets a failing storefront hide behind a successful one for four quarters.

What to measure

• Revenue by brand × country × channel. Build this before launch, not after the first board question. Everything else here is a detail of it.
• Time to launch market n+1, from decision to live. If it is not falling with each market, the core is not shared and Phase 1 is unfinished.
• Catalog completeness per channel and locale, not overall. A 96 % complete catalog can still be unsellable in one market.
• Share of D2C revenue per country, next to trade revenue in the same region. The channel-conflict conversation needs both numbers side by side, per region, or it becomes an argument about anecdotes.
• Price deviation between the direct channel and the recommended retail price you publish to partners. Any drift here is a partner escalation waiting to happen.
• Content parity across brands: how many products carry brand-specific imagery and copy where the brand requires it, against how many fall back to the parent.
• Cross-brand order share: orders containing lines from more than one of your brands. It is the only measure that shows whether the group is worth more than the sum of its storefronts.

Where to start reading

1. Channels, locales and completeness: the concept the whole multi-brand setup rests on.
2. Tenants, apps and markets: decide the structure before anyone builds a second storefront.
3. Go multi-country: the roll-out sequence, with the obstacles named.

What you're building

One catalog, one customer model, one checkout, and as many storefronts on top as you have brands and countries. Every article is a single record whose values differ per channel and locale; every market carries its own currency, tax classes and price lists; every storefront is a theme, a domain and a navigation over the same data. The trade channel and the direct channel are two price lists and two segments, which is what makes the channel rules enforceable rather than hoped for.

flowchart TB
  ERP["Your ERP / PIM"]
  subgraph IS["Integration Studio"]
    WF["Workflows and export profiles"]
  end
  subgraph CS["Commerce Studio"]
    P["Products: one record, values per channel and locale"]
    M["Markets: currency, tax, locales"]
    PR["Price lists: trade net, recommended retail, per market"]
    CH["Channels: trade, D2C, marketplace"]
    C["Organizations and segments: retail groups, D2C buyers"]
    O["Orders, tagged by channel"]
  end
  subgraph XS["Experience Studio"]
    SF1["Storefront: parent brand"]
    SF2["Storefront: subsidiary brand"]
    SF3["Storefront: D2C, per country"]
  end
  MP["Marketplace or partner catalog"]
  ERP -- "articles, prices, stock" --> WF
  WF --> P
  WF --> PR
  P --> SF1
  P --> SF2
  P --> SF3
  M --> SF3
  CH --> SF1
  CH --> SF3
  SF1 --> O
  SF2 --> O
  SF3 --> O
  O --> WF
  WF --> ERP
  P -- "classified export" --> WF
  WF --> MP
  PROMO["Promotions (planned)"]:::planned
  PROMO -.-> SF3
  classDef planned stroke-dasharray: 5 5

What you need

• A decision on tenants: one tenant with several storefronts, unless a subsidiary is legally and operationally separate — Tenants, apps and markets
• Channels and locales defined before the second storefront, with brand as a reference entity — Channels, locales and completeness
• Asset families for the imagery that differs per brand and channel — Assets and asset families
• Markets with currency, tax classes and locales, confirmed with finance — Currencies and tax
• A price list per channel and market, and a written rule for how D2C relates to the recommended retail price — Design your price lists
• Trade partners as organizations with hierarchies and segments, D2C buyers in their own segment — Organizations and hierarchies
• A translation workflow with an owner per language, for the assortment that earns — Translate the catalog
• Roles that say who may publish what, per brand and market — Users, roles and permissions

Build it

1. Decide the tenant structure and write down why — Tenants, apps and markets
2. Define channels (trade, D2C, marketplace) and locales, and mark which attributes vary by each — Channels, locales and completeness
3. Model brand as a reference entity and set up asset families for brand-specific imagery — Reference entities
4. Load the parent brand's catalog and take it to complete for the trade channel — Publish a digital product catalog
5. Create the first market with its currency, tax classes and price list — Languages and markets
6. Build the parent brand storefront: theme, domain, navigation, over the trade channel — Create a storefront
7. Add the second brand as a second storefront on the same catalog, with its own theme and domain — Themes and branding
8. Settle the D2C rules with sales, then add the D2C channel, its segment and its price list — Design your price lists
9. Open the second country: market, tax, payment methods, and a translated top assortment — Go multi-country
10. Run the pre-launch checklist for every further brand and market, unchanged — Pre-launch checks
11. Classify and export the catalog for partners and marketplaces that require it — Sell through marketplaces and channels
12. Build the brand × country × channel report and put an owner on each cell — Decide on real numbers
13. Assign publishing roles per brand and market once a second team edits content — Users, roles and permissions

Decisions you'll need to make

Related product areas

• Commerce Studio — Products · Channel values · Locale values · References · Asset families · Markets · Tax classes · Channels · Price lists · Organizations · Segments
• Experience Studio — Sites · Themes · Domains · Languages and markets
• Integration Studio — Workflows · Import export · Field mapping