Instrument for questions, not for completeness
Lesson 15 of 24, level 01Index
Launch day is the worst possible time to discover you cannot answer “did anyone use it”.
Write the question first, then the event
From question to an event
- Question: Did they connect?
- Event: bank_connected
- Property: Connection method
- Decision: Fix failed methods
For every event you plan to track, name the question it answers. If you cannot name one, delete the event. Over instrumented products are as unanalysable as under instrumented ones, and they cost more to store.
The five questions you will be asked in week one are almost always the same: did anyone use it, who, did they come back, did it break, and did it move the number we said it would.
Instrumentation should make a decision answerable. Start with the question, then capture the smallest reliable set of events and properties needed to answer it.
Use your chosen course project throughout. The additional examples below are fictional practice cases; transfer the method to your own evidence.
Work backwards from the decision
Write the decision and the comparison you need. “Why does connection fail?” may require a start event, a confirmed result, provider, and a non-sensitive error category. It does not require storing every click or raw customer content. A tracking plan should explain why each property exists.
Define when events fire
Distinguish intent from confirmed outcome. A button click says the user tried; a server-confirmed success says the operation completed. Assign ownership, a schema, and an identifier that can deduplicate retries. Document how client and server events relate so the same action does not appear twice in a funnel.
Test the awkward paths
Exercise success, failure, retry, refresh, and delayed response. Inspect actual payloads in a development environment and compare them with the specification. Check missing properties and time handling. An event name that looks right in a dashboard can still be emitted at the wrong moment.
A question becomes a contract
- Question: Decision to support
- Event: Confirmed occurrence
- Property: Needed context
Doing it with AI, and where it breaks
Generate the event schema from your spec, then delete every event you cannot attach a question to.
It produces an exhaustive taxonomy, every click and hover. That is noise you pay to store and never query.
Your AI workbench
Start with your own notes or clearly labelled practice data. Remove private details before sharing. Replace the placeholders, run the prompt in your chosen AI tool, and keep the output beside its source.
Turn this decision question and flow [paste] into a minimal tracking plan. Include event name, firing condition, source, required properties, deduplication key, and owner. Add acceptance tests for retry, duplicate delivery, and late success. Exclude personal content and mark unknown implementation details.
Before you use the output
- Success reflects confirmed completion
- Retries and duplicate delivery differ
- Every property answers a stated question
Stuck? Try this next
Ask AI to generate sample payloads and test assertions, then have the implementing engineer review the firing conditions. Plausible JSON alone does not prove the system records the right event.
Keep a brief AI log: input used, useful output, what you checked, and what you rejected. The decision remains yours.
Build it
A tracking plan where every event is tied to a written question.
Plausible, PostHog or GA4
Checkpoint
If you did the build, these take two minutes. If you cannot answer one of them, that is the part to go back to.
Moving on marks this lesson complete. Finish the build first, it is the part that counts.