Measurement plan

When this is useful

You are about to run this process and need one reusable working document.

What the workbook covers

1. Decision brief

2. Event dictionary

3. Fictional completed event record

4. Identity and eligibility

5. Metric contract

6. Quality checklist

Use with real evidence

Download the full Markdown resource, replace placeholders with your situation and retain sources beside claims. Keep unanswered questions visible rather than filling them with plausible guesses.

Put it to work

1. Read the full worksheet and define the decision it supports.
2. Fill the relevant tables using dated observations and explicit assumptions.
3. Review the output with its owner and record the next decision.

Limits and tradeoffs

The worksheet structures work; it does not supply missing customer evidence or guarantee a business result. Adapt examples and assign a responsible owner.

Worksheet preview

# SaaS measurement plan and event dictionary

Create one plan for one decision. Examples are fictional. Store sensitive identifiers and customer records in the appropriate restricted systems, not in a public worksheet.

## 1. Decision brief

- Decision owner:
- Decision to make:
- Options being considered:
- Questions the evidence should answer:
- Useful customer result:
- Observation window and review date:
- Evidence that would support each option:
- Qualitative evidence needed alongside counts:

## 2. Event dictionary

Copy one record for each event.

| Field | Definition |
|---|---|
| Event name and version | Fill in |
| Exact successful operation that triggers it | Fill in |
| Entity measured | Account, user, integration, action, or another defined entity |
| Authoritative source | Fill in |
| Required properties and allowed values | Fill in |
| Occurrence timestamp and timezone | Fill in |
| Unique event or operation identifier | Fill in |
| Retry and duplicate handling | Fill in |
| Repeated valid action handling | Fill in |
| Situations when it must not fire | Fill in |
| Implementation and definition owners | Fill in |
| Known gaps | Fill in |

Avoid recording free-text customer material or sensitive payloads when a categorical property answers the question.

## 3. Fictional completed event record

Event: `test_failure_investigated`, version 1. Trigger: an investigation outcome is successfully saved for a failure. Unit: investigation, associated with its account. Source: the application's saved investigation record. Required properties: account identifier, investigation identifier, outcome category, occurrence timestamp, and definition version. A retry of the same save operation must not create a second completed investigation. Opening the failure screen and a failed save do not trigger the event. Editing an already saved outcome does not count as another first completion. This event indicates a recorded investigation, not proof that its conclusion helped the customer.

## 4. Identity and eligibility

- Account and user relationship:
- Handling of users in several accounts:
- Anonymous-to-authenticated connection, if needed:
- Internal/test exclusions:
- Other eligibility rules:
- Merged and deleted entity handling:
- Access owner and retention decision:
- Identity gaps that affect interpretation:

## 5. Metric contract

| Field | Definition |
|---|---|
| Metric name | Fill in |
| Numerator | Exact qualifying behavior and counting unit |
| Denominator | Exact eligible population and counting unit |
| Cohort entry rule | Fill in |
| Outcome observation window | Fill in |
| Timezone | Fill in |
| Fully observed cohort cutoff | Fill in |
| Source and query/report owner | Fill in |
| Missing-data treatment | Fill in |
| Definition changes affecting comparison | Fill in |

Illustrative contract: eligible accounts created during a stated week that save an investigation outcome within seven days of creation, divided by eligible accounts created during that week. Only report the final seven-day rate after every included account has had that window. Seven days is a planning example, not a universal activation standard.

## 6. Quality checklist

- Successful operation creates the expected event.
- Failed operation does not create a completion event.
- Retry and duplicate delivery follow the documented rule.
- Repeated valid actions follow the documented rule.
- Events belong to the correct account or other entity.
- Internal test activity is identifiable and excluded as specified.
- A sample reconciles with authoritative application records.
- Known capture gaps and definition version are documented.

For each check, record tester, date, expected outcome, actual outcome, and unresolved issue.

## 7. Decision report

- Decision and owner:
- Period, cohort, window, and definition version:
- Numerator and denominator counts:
- Rate, if appropriate:
- Known gaps and uncertainty:
- Customer or support evidence:
- Proposed action and reasoning:
- Next review condition:

Illustrative reporting sentence: “12 of 30 eligible accounts reached the defined result within the completed observation window.” These numbers are fictional. Add limitations before using any real report to choose an action.

## Aggregation and operation checks

- Raw event counting unit:
- Stable operation/deduplication key:
- Metric counting unit:
- First qualifying event rule:
- Later valid events and effect on the metric:

Fictional first-result check: a