<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Instrumentation Spec

An instrumentation spec defines what analytics events to track, when to fire them, and what properties to include. It serves as a contract between product and engineering, ensuring consistent data collection that enables accurate measurement. Good instrumentation specs prevent the "we can't answer that question because we didn't track it" problem.

When to Use

• Before engineering implements a new feature
• When defining analytics requirements for experiments
• When auditing existing tracking for gaps or inconsistencies
• When onboarding a new analytics tool
• Before launch to ensure measurement is in place

When NOT to Use

• You are specifying the dashboard built on top of the events -> use measure-dashboard-requirements
• You need experiment-specific metrics and variants, not product-wide tracking -> use measure-experiment-design
• The feature itself is not yet specified (no flows to instrument) -> use deliver-prd first
• You are analyzing data you already collect -> use measure-experiment-results or measure-survey-analysis

Instructions

When asked to create an instrumentation spec, follow these steps:

1. Define Analytics Goals

Start with the questions you need to answer. What will you measure? What decisions will this data inform? This prevents over-instrumentation while ensuring nothing important is missed.

1. Identify Events to Track

List each user action or system event that should be tracked. Follow consistent naming conventions (typically noun_verb or verb_noun in snake_case). Each event should represent a distinct, meaningful action.

1. Specify Event Triggers

For each event, describe exactly when it fires. Be precise: "When user clicks Submit button" vs. "When form is submitted successfully." These are different events with different meanings.

1. Define Event Properties

List the properties (attributes) attached to each event. Include property name, data type, description, and example values. Properties provide context that makes events useful.

1. Document User Properties

Identify persistent user-level attributes that should be associated with all events (e.g., subscription tier, account creation date). These enable segmentation in analysis.

1. Address PII and Privacy

Flag any properties that contain personally identifiable information. Document how PII should be handled - hashing, encryption, or exclusion.

When the feature sends user input to a model and the exchange is captured, extend this section to cover the trace as well. A trace is not an event: an event carries properties you chose in advance, while a trace carries what the user typed and what the model wrote back, which is free text that can contain anything the user decided to put in it. Decide and record four things: what is captured, what redaction runs before storage and whether it runs before the trace leaves the process, how long traces are retained and what deletes them, and what fraction of requests is sampled and how that sample is chosen. A uniform sample is the wrong instrument for finding rare failures; if the traces exist to diagnose bad output, oversample the flagged cases and say so.

1. Create Testing Checklist

Define how QA should verify that tracking is implemented correctly. Include steps to validate events fire at the right times with correct properties.

Output Format

Use the template in references/TEMPLATE.md to structure the output. A complete spec fills every template section: Overview; Event Inventory; User Properties; PII & Privacy Considerations; Implementation Notes; and Testing Checklist.

Quality Checklist

Before finalizing, verify:

• ] Event names follow consistent naming convention
• ] Each event has a clear, unambiguous trigger
• ] Properties include data types and example values
• ] PII is identified and handling is documented
• ] Events map to the analytics questions you need to answer
• ] Testing checklist enables QA verification
• ] If model traces are captured: redaction, retention, sampling, and who can read a trace are all decided, not deferred

Examples

See references/EXAMPLE.md for a completed example.