MSO Cloud · Documentation

Measurement in MSO Cloud

Source: docs/architecture/measurement.md Updated 2026-09-21
On this page

MSO Cloud validates a marketing decision by measuring what it produced against the organization's own first-party business data. Capability grades for the whole platform live on the Maturity Model page.

What "Measure Spine" means in the product#

In MSO Cloud, the Measure Spine is decision-outcome reconciliation: it takes a decision the platform recommended and measures the result against first-party orders or another conversion the organization chose. (YouNet's internal marketing framework uses the same name for a broader measurement doctrine; no module in MSO Cloud computes that doctrine.)

The definable-conversion registry#

Every organization points at exactly one measurable conversion. The registry defines six conversion slugs and a switch between counting events and summing their value:

Conversion What it measures
orders Count of first-party orders
gmv_vnd Value of first-party orders
aov Average order value
leads Count of marketing-qualified leads
deals Count of won deals
deal_value Value of won deals

A commerce organization measures on orders or GMV. A lead-generation organization measures on leads. A deal-driven organization measures on won deals or their value. One organization, one conversion the whole system reconciles against. This registry ships (its definition and the count-versus-value switch are documented in the platform's conversion ADR).

Reconciling a decision against first-party data#

When a recommended decision has been activated, a resolver measures its actual outcome. The path depends on the chosen conversion:

flowchart TD
  D["Activated decision"] --> C{"Org's chosen conversion"}
  C -->|"orders / gmv_vnd / aov"| O["First-party orders<br/>(the same SQL the dashboard reads)"]
  C -->|"leads"| L["Marketing-qualified leads<br/>(one CRM definition)"]
  C -->|"deals / deal_value"| W["Won CRM deals"]
  O --> M["Measured outcome"]
  L --> M
  W --> M
  L -.->|"feed thin or absent"| AB["Resolver returns null<br/>(never reads absence as zero)"]
  W -.->|"feed thin or absent"| AB
  M --> V["Expected vs measured<br/>incremental difference + verdict"]
  V --> LG["Recorded with the decision<br/>feeds the next cycle"]
  • Commerce conversions read the same first-party orders query the rest of the platform uses. The measurement SQL is identical to the reporting SQL, so a decision's measured result cannot disagree with the dashboard.
  • Leads resolve through the CRM's marketing-qualified-lead definition.
  • Deals resolve through won CRM deals.

When the required feed is thin or absent, the resolver returns null. It does not read a missing lead feed as zero leads. The measurement surface then presents expected versus measured, the incremental difference, and a verdict, alongside a system-health block whose fields each declare whether the number is real, an abstention, or insufficient data. This reconciliation ships.

Data validation: upload against ingest#

Separate from decision reconciliation, the platform runs a data-quality check that compares an uploaded export against the data the connectors ingested. This catches ingestion gaps and mapping errors before a number is trusted. It is data quality assurance, confirming the pipeline read the source correctly, and it ships. It is not the brand-health validation chain from the framework doctrine; keep the two separate.

Why commerce is the ground truth, not the product#

MSO Cloud is decision infrastructure for marketing. It is not a commerce analytics product. Commerce data has one role here: it is the final verification mechanism.

The reasoning is direct. Signals are not ground truth. A diagnosis is not ground truth. Stored memory is not ground truth. A marketing hypothesis has to be checked against something the organization did not narrate, and the closest available truth is real purchase behavior recorded with real money: orders, revenue, conversion. That is why the platform reconciles decisions against first-party commerce or the chosen conversion, and why the name Unified Commerce Intelligence Platform keeps "Commerce": it names the verification mechanism, not the subject. The subject is the marketing decision; commerce is how the decision is checked.

Third-party e-commerce estimates#

Third-party e-commerce market estimates describe a category or a competitor set from outside the organization's own systems. In the measurement model they are the thing being validated against first-party orders, never the anchor that validates. An experimental parser for third-party e-commerce sheets exists in the codebase and is not part of the production path; it is not wired to any live ingest. Third-party estimates are not presented as measured first-party truth.

What the platform does not measure here#

  • It does not compute the CPF to SBHI to ECI cascade from YouNet's marketing framework. That chain is doctrine, not a shipped feature.
  • It does not compute an SBHI composite. SBHI is YouNet's brand-health framework; what MSO Cloud computes today from social data is net sentiment, as one audience metric.
  • CRM structures exist, but lead and deal feeds are commonly thin. When a feed is thin, the conversion resolver abstains rather than reporting a number it cannot support.