How to Build an Event Tracking Plan in Notion

Create a Notion database called Event Tracking Plan with these properties: Event Name (title, using your naming convention like object.action), Description (text explaining what this event represents), Trigger (text describing exactly when the event fires), Category (select: engagement, conversion, error, system), Platform (multi-select: web, mobile, backend), Status (select: planned, implemented, verified, deprecated), and Owner (person responsible for implementation).

• Enforce a naming convention in the description field: object.action format like signup.completed or feature.used
• Add a 'Feature Area' select property to group events by product area
• Include a 'Sprint/Release' property linking to when the event was or will be instrumented

Create a second database called Event Properties and link it to the Events database with a relation field. Each property entry has: Property Name (title, using snake_case), Type (select: string, number, boolean, array, object), Required (checkbox), Description (text explaining the value), and Example Value (text). This structure ensures every event's payload is documented before instrumentation begins.

• Define common properties that appear on many events: user_id, session_id, page_url, timestamp
• Create a 'Global Properties' view showing properties that should be sent with every event
• Add an 'Allowed Values' text field for enum-type properties listing all valid options

Create a 'Naming Convention' page at the top of your tracking plan that documents the rules every event and property must follow. Define the event name format (object.action), allowed objects (signup, feature, page, subscription), allowed actions (started, completed, failed, viewed), and the property name format (snake_case, no abbreviations). This page is the law — any event that does not follow it gets rejected during review.

• Define the object.action naming pattern with examples for each object category
• List banned patterns: no camelCase event names, no spaces, no version numbers in event names
• Include a decision tree: 'Is this a user action? Use object.action. Is this a system event? Use system.event_type.'

Walk through each critical user flow in your product and identify every point where you need data. For the signup flow, events might include: signup.started (form rendered), signup.completed (account created), signup.failed (validation error or API failure). For each event, fill in the trigger description with the exact condition: 'Fires when the signup API returns 200 and the user account is persisted to the database.'

• Map events to your signup, activation, core usage, and payment flows
• Add events for error states and failure conditions, not just happy paths
• Include page.viewed events for key pages with route and referrer properties

For each event, add an Implementation Notes text field describing any technical considerations: should the event fire client-side or server-side? Does it require waiting for an API response? Are there race conditions to handle? Add a QA Criteria text field listing how to verify the event is firing correctly — 'Submit the signup form with valid credentials and verify the event appears in the analytics debug panel with all required properties.'

• Specify whether each event is client-side (JavaScript SDK) or server-side (API call) instrumented
• Note any dependencies: 'This event requires the user to be identified before it fires'
• Write a QA test step for each event so the implementer knows how to verify correctness

Define the process for adding new events: the PM creates a draft entry, an engineer reviews the technical feasibility and implementation approach, and an analyst verifies the event is queryable and consistent with existing data. No event goes into production without all three reviews. Schedule a quarterly audit where the team reviews all events for usage — deprecate events that are not being queried and add missing ones that have been requested.

• Create a 'Needs Review' status that new events must pass through before implementation
• Assign each new event a PM reviewer, an engineering reviewer, and an analyst reviewer
• Schedule a quarterly tracking plan audit to deprecate unused events and add newly needed ones