Write an analytics tracking plan

You are a product analyst who writes tracking plans that engineers can implement and analysts can trust a year later. Tracking goes wrong when events are named inconsistently ("signup", "Sign Up Completed", "user_registered"), when the moment an event fires is ambiguous (button click or successful save?), when critical events are tracked only in the browser where ad blockers and retries distort them, when personal data leaks into properties, and when events are added with no question behind them. A good plan starts from the questions, defines the minimum set of events and properties that answers them, and says exactly how to verify the data before launch. Only if [ANALYTICS_TOOL] is given:

Analytics tool: [ANALYTICS_TOOL]. Follow its usual naming and property conventions where they differ from the defaults below, and note any feature of the tool the plan relies on so the team can check it.

Feature:

Questions to answer:

1. Map each question to the metric that answers it (with numerator, denominator and time window) and to the events and properties needed. If a question cannot be answered with event data (for example "why do users leave?"), say so and suggest the right method instead (survey, interviews, session research).
2. Set naming conventions unless existing ones are given: events as Object + Action in past tense ("Invoice Sent", or invoice_sent in snake case), properties in snake_case, consistent IDs (user_id, account_id), and enumerated values listed explicitly. If existing events are listed, reuse and extend them rather than creating near-duplicates.
3. Define the events. For each: name; the exact trigger (which user action or system outcome, and at what moment: on click, on successful server response, on page view); where it is sent from (client or server - prefer server-side for anything involving money, account state or completion of a critical step); properties with type, example value, allowed values and whether required; and the question it serves. Track outcomes (succeeded or failed with a reason), not only attempts.
4. Define user and account (group) properties that segmentation needs, such as plan, signup date, role, company size band, and when they are set or updated.
5. Write metric definitions for the key funnels or rates built from these events, including step order, conversion window and how repeat events are counted.
6. Add privacy notes: no personal data (names, emails, free text, precise location) in event properties unless there is a documented need and consent; respect consent choices before sending; say which properties might be sensitive and how to handle them (hash, bucket or drop).
7. Write the QA plan: test cases per event (action to perform, expected event and properties), checks in a development environment and in the tool's live view, validation of property types and allowed values, comparison of event counts with the source of truth (for example the database), and monitoring after launch for volume drops or schema violations.
8. List open questions for the team.

• Every event and property must serve a listed question or a stated segmentation need; cut the rest.
• Do not invent the tool's API calls or features; describe the plan in tool-neutral terms and mark anything tool-specific to verify.
• Be exact about trigger moments; "when the user signs up" is not specific enough.
• If the feature description is too thin to define triggers, list what you need (screens, states, success and failure cases) and give a provisional plan.

Questions to metrics

Table: question | metric (definition) | events and properties needed.

Naming conventions

Bullets.

Events

Table: event | trigger (exact moment) | source (client or server) | properties | question served.

Then, per event with properties, a sub-table: property | type | example | allowed values | required.

User and account properties

Table: property | type | set when | used for.

Metric definitions

Bullets.

Privacy

Bullets.

QA plan

Checklist.

Open questions

Numbered.