measure-instrumentation-spec

Name: measure-instrumentation-spec
Author: product-on-purpose

486stars64forks

How to install measure-instrumentation-spec?

product-on-purpose/pm-skills/measure-instrumentation-spec

$npx -y skills add product-on-purpose/pm-skills --skill measure-instrumentation-spec

Installs into the current project.

Summary

Specifies what analytics events to track, when they fire, and what properties to include, as a contract between product and engineering that prevents undertracked features. Use before engineering builds a feature or when auditing existing tracking for gaps. For the dashboard buil

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Instrumentation Spec
3
4	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.
5
6	## When to Use
7
8	- Before engineering implements a new feature
9	- When defining analytics requirements for experiments
10	- When auditing existing tracking for gaps or inconsistencies
11	- When onboarding a new analytics tool
12	- Before launch to ensure measurement is in place
13
14	## When NOT to Use
15
16	- You are specifying the dashboard built on top of the events -> use `measure-dashboard-requirements`
17	- You need experiment-specific metrics and variants, not product-wide tracking -> use `measure-experiment-design`
18	- The feature itself is not yet specified (no flows to instrument) -> use `deliver-prd` first
19	- You are analyzing data you already collect -> use `measure-experiment-results` or `measure-survey-analysis`
20
21	## Instructions
22
23	When asked to create an instrumentation spec, follow these steps:
24
25	1. Define Analytics Goals
26	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.
27
28	2. Identify Events to Track
29	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.
30
31	3. Specify Event Triggers
32	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.
33
34	4. Define Event Properties
35	List the properties (attributes) attached to each event. Include property name, data type, description, and example values. Properties provide context that makes events useful.
36
37	5. Document User Properties
38	Identify persistent user-level attributes that should be associated with all events (e.g., subscription tier, account creation date). These enable segmentation in analysis.
39
40	6. Address PII and Privacy
41	Flag any properties that contain personally identifiable information. Document how PII should be handled - hashing, encryption, or exclusion.
42
43	7. Create Testing Checklist
44	Define how QA should verify that tracking is implemented correctly. Include steps to validate events fire at the right times with correct properties.
45
46	## Output Format
47
48	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.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] Event names follow consistent naming convention
55	- [ ] Each event has a clear, unambiguous trigger
56	- [ ] Properties include data types and example values
57	- [ ] PII is identified and handling is documented
58	- [ ] Events map to the analytics questions you need to answer
59	- [ ] Testing checklist enables QA verification
60
61	## Examples
62
63	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type

measure-instrumentation-spec

486stars64forks

View on GitHub

How to install measure-instrumentation-spec?

product-on-purpose/pm-skills/measure-instrumentation-spec

$npx -y skills add product-on-purpose/pm-skills --skill measure-instrumentation-spec

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Instrumentation Spec
3
4	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.
5
6	## When to Use
7
8	- Before engineering implements a new feature
9	- When defining analytics requirements for experiments
10	- When auditing existing tracking for gaps or inconsistencies
11	- When onboarding a new analytics tool
12	- Before launch to ensure measurement is in place
13
14	## When NOT to Use
15
16	- You are specifying the dashboard built on top of the events -> use `measure-dashboard-requirements`
17	- You need experiment-specific metrics and variants, not product-wide tracking -> use `measure-experiment-design`
18	- The feature itself is not yet specified (no flows to instrument) -> use `deliver-prd` first
19	- You are analyzing data you already collect -> use `measure-experiment-results` or `measure-survey-analysis`
20
21	## Instructions
22
23	When asked to create an instrumentation spec, follow these steps:
24
25	1. Define Analytics Goals
26	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.
27
28	2. Identify Events to Track
29	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.
30
31	3. Specify Event Triggers
32	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.
33
34	4. Define Event Properties
35	List the properties (attributes) attached to each event. Include property name, data type, description, and example values. Properties provide context that makes events useful.
36
37	5. Document User Properties
38	Identify persistent user-level attributes that should be associated with all events (e.g., subscription tier, account creation date). These enable segmentation in analysis.
39
40	6. Address PII and Privacy
41	Flag any properties that contain personally identifiable information. Document how PII should be handled - hashing, encryption, or exclusion.
42
43	7. Create Testing Checklist
44	Define how QA should verify that tracking is implemented correctly. Include steps to validate events fire at the right times with correct properties.
45
46	## Output Format
47
48	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.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] Event names follow consistent naming convention
55	- [ ] Each event has a clear, unambiguous trigger
56	- [ ] Properties include data types and example values
57	- [ ] PII is identified and handling is documented
58	- [ ] Events map to the analytics questions you need to answer
59	- [ ] Testing checklist enables QA verification
60
61	## Examples
62
63	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type