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.