These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Operational Analytics
- Features
- Metrics and results
Metrics and results
Keep a metric definition, its observation and its result in the same trail.
OverviewResult exceptions×
Operational Analytics · Metrics and results
New
Result exceptions
Metric results
| Id | Metric | Source | Period start | Period end | Status | |
|---|---|---|---|---|---|---|
| IDD-288 | MD-9232 | PS-34128 | 03 Oct | 09 Oct | Suppressed | |
| IDD-574 | MD-6291 | PS-86193 | 22 Oct | 28 Oct | Invalid | |
| IDD-256 | MD-9651 | PS-93752 | 22 Oct | 27 Oct | Suppressed | |
| IDD-463 | MD-3897 | PS-90777 | 08 Oct | 10 Oct | Invalid | |
| IDD-898 | MD-9333 | PS-58584 | 10 Oct | 14 Oct | Suppressed |
6 of 6 records
IDD-288Metric results · MR-45643
SuppressedMetricMD-9232
SourcePS-34128
Period start03 Oct
Period end09 Oct
ReasonSuppressed mr-515
What you can do
Start with the source record
A metric steward describes grain, numerator, denominator, unit, aggregation method and version in a metric definition. Observations record values against source snapshots and periods. Results retain their period, dimension, numerator, denominator, status and originating operation run. Reviewers can inspect invalid or suppressed results with their reason before using them in a decision. The team keeps the source record open during discussion so a status or result does not lose its context. A named owner can answer where a number came from, when it was observed and which revision was under review.
A practical pilot uses one property and one reporting window. The owner checks its definition, a small set of observations and the first decision before expanding collection. This keeps disagreements about timing, outcome or responsibility visible while they are still easy to resolve.
How the work is organized
- Definition authority. Agree who reviews a metric definition and which version applies to a process.
- Window alignment. Match observation and result windows to the relevant source coverage.
- Result status. Keep calculated, suppressed and invalid results distinct in reports.
The source snapshot connects operational records to the organization and the person responsible for the result. A record changes state through the defined lifecycle, while its revision and state history keep previous decisions understandable. If the team needs to revisit a result, it can inspect the run and evidence attached to that source rather than relying on a copied chart.
What to agree during setup
Agree which team can create the source record, who can review it and when a result is ready to share. Decide how dates, time zones and source identifiers are written so two people can find the same observation. If a source revision changes, require a fresh review decision and keep the earlier decision visible in the history. Use a small real case to check that the person assigned as owner can reach the related records.
The setup conversation should include the source system owner. An external event stream supplies the facts, while the team working here owns interpretation and review. The source reference and consent basis need to be meaningful to the people checking the result. Agree what evidence a reviewer expects before moving a snapshot forward.
Check the handoff on an actual case
Open a snapshot for a measured web property. Have the analyst trace one observation to its source and reporting period. Ask the reviewer to identify the exact revision and explain the decision with its evidence reference. Then have the owner open the resulting action or report. A successful handoff lets each person reach the same source record and understand why its current state is justified.
Repeat the check when an observation is rejected, a source capture is stale or a run fails. The team should see the exception in the appropriate record and avoid presenting an incomplete result as confirmed. Keep the owner responsible for the next action and the reviewer responsible for the decision they made.
What your team sees
- Result exceptions — Suppressed and invalid results with their recorded reason.
- Source freshness exceptions — Source captures that are stale or failed.
Follow the work through
Follow collection, review and analysis from the same source record. Use implementation to rehearse ownership and evidence before the first operating cycle.
What it keeps track of
Data model- Metric definitions
- Approved metric definitions with grain, expressions and aggregation method.
- Metric observations
- Observation-level metric readings tied to a snapshot and source.
- Metric results
- Calculated metric results persisted once per approved definition and window.
- Source mappings
- Reviewed field mappings between source and target definitions.
- Source snapshots
- Sourced snapshot captures with coverage window and freshness status.
- Operation runs
- Workflow execution runs with frozen revision, input hash and result identity.
Who uses it
Permissions- Metric Steward
- , Independent Reviewer, Process Owner
Set up Operational Analytics your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.