Event Tracking Plan Template: implementation to decision
Treat the prompt as an implementation brief. The useful artifact is not copied code alone, but a reviewed event contract that produces a trustworthy answer.
- 1
Select the boundary
Instrument the point where tracking_plan_reviewed becomes final.
- 2
Create the contract
Start with tracking_plan_reviewed, event_contract_changed, instrumentation_verified and keep every field typed, bounded, and privacy-reviewed.
- 3
Run a fixture
Exercise known success, failure, retry, and empty-result cases before relying on aggregate results.
- 4
Answer the question
What does one row represent, and which decision does it support?
Template
Paste this into your coding agent
Replace YOUR_API_KEY, run the flow locally, then verify the generated events and dashboards.
Event Tracking Plan Template
Create an event tracking plan for this codebase before adding Telemetry.
Use /skill.md and inspect the production workflow, existing analytics calls, tests, deployment configuration, privacy controls, and downstream reports.
For each proposed event, document:
event_name, event grain, business or operational decision, owner, exact trigger, required fields, optional fields, types and units, controlled values, prohibited content, privacy classification, retention expectation, schema_version, downstream SQL or dashboards, and synthetic validation cases.
Identify ambiguous retries, duplicate deliveries, raw URLs, unbounded strings, personal data, secrets, and fields whose source of truth is unclear. Do not add instrumentation until those boundaries are resolved.
Then implement the smallest approved event set, add contract and failure-path tests, verify ingestion in a non-production environment, and create SQL that keeps counts beside rates.
Return the tracking plan as a committed Markdown document and summarize any review decisions still required. Do not invent consent, retention, security, or compliance policy.Events to capture
Verification checklist
What a complete instrumentation pass leaves behind
Events
Synthetic events reach the intended table with stable names and field types.
Queries
The first SQL queries return plausible rows with an explicit time window.
Views
A dashboard uses the real fields and includes enough context to explain a change.
Safety
Prompts, bodies, credentials, signatures, and private content were checked for redaction.
Related product capability
Continue this workflow in Structured events
Capture stable event names, typed fields, and privacy-reviewed operational context.
Related SQL recipes
Answer the next question with SQL
Run the query against the structured fields from this workflow, inspect the example result, and turn a useful answer into a dashboard or alert.
Track Event Schema-Version Adoption
Which producers still emit old versions of a critical event?
Open recipeMeasure Required-Field Null Rate
Which event names have an unacceptable missing account identifier rate?
Open recipeFind Duplicate Event IDs
Which event IDs were received more than once?
Open recipeMeasure Event Ingestion Freshness
Which production event sources are stale or delayed right now?
Open recipeMeasure Late-Arriving Events
Which event producers deliver data late enough to distort analysis?
Open recipeMeasure Telemetry Volume by Event Name
Which event contracts create the most ingestion volume?
Open recipeMore templates