Managing your tracking plan
The Tracking Plan page is a full analytics event manager. It reconciles what your code actually tracks against what SHOULD be tracked, and creates Linear tickets to close the gaps.
How it works
Every scan extracts analytics events from your code — analytics.track(), posthog.capture(), amplitude.track(), etc. — with their provider, properties, trigger, and category. The tracking plan compares these code-discovered events against your curated plan.
Event statuses
| Status | Meaning |
|---|---|
| Implemented | In the plan AND in the code, aligned |
| Suggested | Kanon recommends adding (uncovered user interaction) |
| Approved | User accepted a suggestion, not yet in code |
| Missing | In the plan but not found in code (was removed?) |
| Misaligned | In code but differs from the plan (wrong properties, provider) |
Working with the plan
Reviewing suggestions
After a scan, the plan shows suggested events for mutation endpoints (POST/PUT/PATCH/DELETE) that have no analytics tracking. For each suggestion:
- Approve → moves to "approved" (a ticket can be created for implementation)
- Reject → removes from the plan
Adding events manually
Click "Add event" to define an event that SHOULD exist:
- Event name, provider, trigger, properties, category, feature, description
- Status starts as "approved" (meaning: implement this)
Creating tickets
The "Create ticket" button generates a Linear ticket for the diff between the plan and the code:
- Events to implement (approved but not in code)
- Events to fix (misaligned between plan and code)
- Events to investigate (in plan but missing from code)
Choose "One ticket for all" (batch) or "One per route" (individual).
Best practices
- Start with what the code already tracks. After the first scan, all existing events appear as "implemented." Review them — are they named consistently? Do they have the right properties?
- Define your naming convention. Before approving suggestions, establish a pattern:
noun_verb(user_signed_up) orverb_noun(signed_up_user)? - Prioritize mutation coverage. The suggestions target POST/PUT/PATCH/DELETE endpoints because those are user actions. Read-only endpoints are lower priority.
- Review misalignments. If an event has different properties in the plan vs the code, decide which is correct and update accordingly.