Operations

Multi-Store Management

The structure and process a seller uses to run several marketplace stores without mixing data, access or compliance evidence.

Aliases: Multi-account management, 多店铺管理, 多店运营, 店群管理

The organisational problem

Selling from more than one store is normal for brands with several product lines, for agencies managing client accounts, and for sellers operating in multiple markets. The difficulty is not opening accounts; it is keeping them distinguishable in a way that survives a platform review and a tax inspection.

Three layers have to be separated: legal identity, commercial data and technical environment. Most multi-store incidents come from a failure in one layer while the other two are handled correctly.

The three layers

Legal. Each store needs a defined operating entity, or a documented relationship to one. A store run under another company's identity without an agreement is both a platform and a tax problem. Payout accounts, tax registrations and invoices should follow the entity.

Commercial. Catalogues, pricing and customer communication should not be cloned across stores without reason. Platforms read identical image sets and copy as a signal, and buyers compare offers across stores.

Technical. Each store needs its own environment: its own browser profile, its own network exit, its own credentials. Environment isolation describes the mechanics; the management layer decides who gets which profile.

What the management layer contains

A register of stores: entity, marketplace, category, responsible operator, environment assignment
Role definitions: who can view, who can publish, who can change payout data
Approval steps for catalogue changes that affect several stores
A compliance evidence pack per store, not per company
A suspension playbook, because a finding can arrive at any store in the group

Tooling

Multi-account browsers provide the technical layer: one isolated profile per store, proxy assignment per profile, and operator-level permissions with an activity log. Products in this category include Feikua Browser, which bundles proxy access with profile isolation and team permissions, and Ziniao, which offers a comparable model. Selection comes down to the number of stores, the market coverage of the proxy pool, and how granular the permission model needs to be.

What no tool fixes

Tooling does not resolve identity overlap. If two stores share a tax number, a bank account or a beneficial owner, they are linked at the identity layer regardless of browser configuration. It also does not replace account health discipline or the evidence required for seller verification.

A workable rhythm

Review the store register monthly, confirm that every active store has a current environment assignment and a current compliance pack, and reconcile users against the role list. Association findings usually surface weeks later, which is why account association reviews rely on the register to reconstruct what was running at the time. Team access control decisions are recorded in the same document.

Primary source: Platform multi-account policies; vendor documentation for multi-account browsers.

FAQ

How many stores can one seller manage?

It depends on platform policy and on the justification approved for each account. There is no technical limit in most tools, but platform rules define what is permitted.

Are separate browser profiles enough to keep stores independent?

They address the technical layer. Identity data, catalogues and payouts still link stores if they overlap, so separation has to be managed on all three layers.

Should each store have its own entity?

Not necessarily, but the relationship must be documented. A single entity with several stores is legitimate where the platform permits it and the accounts are authorised.

How do I keep compliance evidence organised?

Per store, not per company: registration, certificates, product documentation and correspondence, with a named owner and a review date.

What happens if one store is suspended?

The group should assume a possible association review and prepare entity and environment documentation for the other stores before responding, rather than after.