On this page
What MSO Cloud is, which shapes of organization it composes itself into, who works in it, how its three data planes stay apart, and how far its decision engine has actually gone.
What it is#
MSO Cloud is a multi-tenant commerce and marketing intelligence platform for Vietnamese retailers and marketing teams. It ingests first-party marketplace and marketing data plus third-party market estimates, keeps those planes separate, materializes them into a layered warehouse, and serves them through composable dashboards, a data assistant, and a decision engine.
Nothing about an organization is per-customer code. What a tenant runs is composed from a starter blueprint and the plugins enabled for it, and the same product binary serves every tenant.
Organization types#
A blueprint is the starting shape: it names the verticals the organization runs, the plugins it installs, the dashboard templates it ships with, and the menu items each role starts with. An administrator can change any of it afterwards.
| Blueprint | What it starts as |
|---|---|
| Standard commerce | Marketplace connectors and core analytics on the eCom vertical |
| Standard dashboard pack | The same eCom base plus a fixed report pack, with the standard dashboards granted to editor and viewer |
| Marketing analytics | Marketing, CRM and market verticals: ads, web analytics, search console, sheet-fed sources, and the off-take loop, with marketplace connectors turned off |
| Market data only | The market vertical alone, with marketplace connectors turned off and commerce navigation hidden |
| Customer conversations | The audience vertical: a social-listening corpus delivered as a presentation deck rather than an operational dashboard |
| Organization datasets | A vertical-free base: the organization brings its own datasets through a spreadsheet connector and asks the data assistant about them |
Two historical keys stay valid as aliases: an HR workspace and a finance workspace are both the organization-datasets base plus a domain layer, not separate products. A warehouse domain layer exists as a registry row with its own dataset pack and no blueprint key of its own yet.
Most production tenants combine several verticals at once — marketplace orders plus marketing spend, say. Each vertical resolves independently. See Organization Types.
Who uses it#
An organization has four roles.
- Owner and admin are the admin tier and hold the same capability set; rank, not capability, separates them. Rank decides who may act on whom.
- Editor works the operational surfaces — dashboards, reports, exploration, inventory, creators, finance, the data pipeline, audiences and cases — and holds nothing that administers the organization: no members, settings, connectors, AI, playbooks or decisions.
- Viewer is deliberately narrow: reports and exploration only. It does not carry the dashboard capability, because that capability opens a data catalog surface classified as containing personal data.
A super admin is platform staff, not an organization role: it holds no membership row anywhere, and it resolves to every capability in whichever organization it is acting in. Capabilities are enforced server-side on every procedure, not only hidden in the UI.
See User Guide, Administration Guide and Hướng dẫn Super Admin.
The three data planes#
Connector family is the data plane, and the planes never mix.
- First-party marketplace. Orders, creators and inventory from TikTok Shop, Shopee and Lazada, by API or by seller export. This plane is the only ground truth for order money.
- First-party marketing. Spend, conversions, web analytics, search and CRM from ad and analytics accounts. Each platform's numbers stay attributed to that platform.
- Third-party market intelligence. Competitor, category and creator estimates from a market-data vendor. They land in their own store, carry an estimate label wherever they appear, and are barred from becoming a first-party KPI or a decision lever.
Organization datasets are a first-party plane of their own: the tenant's own operational records, read from a spreadsheet tab and rolled up the same way every other plane is.
Full detail: System context, Ingest pipeline.
Tenancy and security#
Tenancy is two levels: an organization owns brands, and a brand is a workspace partition inside an organization rather than a separate tenant. Every fact or asset table carries both an organization id and a brand id.
- Row-level security is load-bearing, not a convention: every organization-scoped table carries a database policy, brand-partitioned tables carry a second policy leg, and both are enforced so even the table owner is not exempt. A database-backed inventory check fails when any table is missing its policy.
- Runtime database roles cannot bypass row-level security — even arbitrary SQL from a compromised application process stays inside the tenant boundary.
- Money is a signed 64-bit integer in VND, never a float, formatted through one shared helper.
- Sample data is flagged on every fact row so seeded demo data can never mix into a real KPI.
- Credentials are envelope-encrypted and never returned to a client; a key rotation keeps prior keys available until every row referencing them is rewrapped.
- Authentication supports password, single-use magic link, WebAuthn passkeys and TOTP two-factor, plus a per-organization Đăng nhập LDAP/AD.
- Rate limiting applies to every mutating and auth endpoint.
Full detail: System Architecture, Security.
Product surface#
- Trợ lý dữ liệu (Chat with your data) — natural-language questions answered through the same typed metric catalog every dashboard reads, never a separate number.
- Customizable Dashboards — pages, panels and cards composed from a shared widget registry.
- Trình sửa bố cục — the twelve-column grid grammar and the presentation document that keeps a deck's layout out of code.
- Đa thương hiệu — several brands in one workspace, separated at ingest and in every rollup key.
- Thông báo — channel registry, domain-declared notification types, and the three tiers a message passes before it is sent.
- Sao lưu và phục hồi — a tenant's own archive and restore, with a mandatory safety snapshot before any overwrite.
- Export pipeline — CSV / Excel / PDF — the same export path behind every report.
- Data Validation (Đối soát dữ liệu) — automated reconciliation against external ground truth, not a manual spot-check.
- Shopper Segments — cách tính (commerce-performance report)
- Comparison period — GA-style period-over-period
- Creator directory — affiliate creator profiles, revenue and commission by creator and content.
- Marketing intelligence — the measurement model for a Marketing-axis org
- MCP server — plug UCIP data into Claude / Codex / Cursor
Decision engine, at the level it has actually reached#
A closed sense, decide, act and learn loop runs over the metric catalog: a morning brief flags what needs attention against named signal rules, and an action queue and playbook library let an operator act on it. Every decision is recorded on an append-only ledger, where a correction is a new row rather than a rewrite.
The evidence ladder is graded honestly, and the grade is what the product claims:
| Rung | Where it stands |
|---|---|
| L0 reproducible playbook and decision kernel | Passed |
| L1 declarative rules with a per-predicate receipt | Shipped |
| L2 signal schema, version and provenance, snapshotted per decision | Shipped |
| L3 intervention impact estimate with a valid control | Observational prototype |
| L4 learned policy with off-policy evaluation | Prototype, substrate only |
| L5 immutable replay, drift and calibration, champion and challenger | Foundation, replay half |
Autonomy is a separate ladder. Recommendation with a human decision is present; scheduled execution inside an approval policy is in progress; anything further is closed by policy, not merely unbuilt.
Abstaining is the default rather than the exception: below the evidence bar the engine answers that it is still learning or has no reliable signal, and never fabricates a lift.
Language models are configured per organization as an ordered list of provider connections with automatic failover; the provider and model name never reach an end-user surface. A generated sentence carrying a number not traceable to a supplied fact is dropped rather than published.
Full detail: The Decision Engine, Maturity Model, Morning Brief.
Metrics governance#
Every number resolves through one metric catalog rather than ad hoc SQL per surface — the dashboard, the data assistant, alerts and reconciliation all read the same definition. Changing a definition is a versioned change, not a silent edit. Reconciliation assertions check every metric-bearing surface against external ground truth, never against a second in-code derivation of the same formula.
Full detail: Governance and Honest Numbers, Measurement in MSO Cloud.