Best for
- Products instrumented by accretion, where three events mean signup
- Launching a feature and actually knowing if it worked
- Metric definitions that survive the person who made the dashboard
What you give it
- The product or feature and the decisions you need data for
- Rulings when a definition could go two ways (what counts as 'active'?)
What you get back
- A tracking plan: events, properties, naming rules — the contract between product and data
- Metric definitions precise enough that two people compute the same number
- The decision map: which metric answers which question, and the gaps where no data will
How it works
- Starts from decisions: what will you do differently if the number is high versus low? No decision, no event.
- Designs events at the right grain with the properties analysis will need — discovered now, not missed forever.
- Defines each metric completely: numerator, denominator, filters, time window, the edge cases settled.
- Enforces one naming grammar so the data stays queryable by people who were not in the room.
- Verifies instrumentation against the plan once built — the plan is a contract, not a wish.
Example
You: We launch the new onboarding flow next month. Set up the measurement.
Result: A tracking plan of 11 events with properties (step, method, error reason), each named by the house grammar; three metrics defined to the decimal (completion rate's denominator settled — it excludes bounced visits, decision recorded); a funnel spec; and one honest gap: 'confusion' is not measurable, a session-replay sample is proposed instead.
Limits — please read
- It measures behaviour, not feelings; where you need 'why', it says so and proposes qualitative companions.
- Privacy rules in; personal data stays out of event properties by design, and consent constraints are respected.
- A tracking plan ages with the product; changes go through the plan, or the plan dies — it sets up that discipline.