Telemetry
Copy-paste instrumentation template

Event Tracking Plan Template

Create a reviewable event catalog covering grain, ownership, fields, privacy, retention, validation, and downstream SQL dependencies.

Reviewed by the Telemetry product team on . Event names, recommended fields, analysis questions, and privacy boundaries. Review standards and ownership

Questions this unlocks
  • What does one row represent, and which decision does it support?
  • Which fields are required, sensitive, bounded, or prohibited?
  • Which queries, dashboards, alerts, and owners depend on this contract?
Template evidence path

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. 1

    Select the boundary

    Instrument the point where tracking_plan_reviewed becomes final.

  2. 2

    Create the contract

    Start with tracking_plan_reviewed, event_contract_changed, instrumentation_verified and keep every field typed, bounded, and privacy-reviewed.

  3. 3

    Run a fixture

    Exercise known success, failure, retry, and empty-result cases before relying on aggregate results.

  4. 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

Event Tracking Plan Template

text
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

tracking_plan_reviewedevent_contract_changedinstrumentation_verifiedschema_drift_detectedevent_contract_retired

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.

Browse all recipes
Complete collectionsData quality SQL

More templates