PostHog Event Schema Builder

PostHog is an open-source product analytics platform. Event tracking means recording user actions — like button clicks, form submissions, or page views — as discrete named events with properties describing the context. These events let you understand how users interact with your product, funnel through flows, and what drives retention or churn.

Event properties describe the specific action that happened — like which button was clicked, the plan selected, or the page visited. They're passed in the properties object of posthog.capture(). Person properties describe the user themselves — like their email, subscription plan, or signup date — and are set via posthog.identify(). Person properties persist across events and let you segment users.

PostHog recommends snake_case for event names (e.g. user_signed_up, checkout_started, feature_used). Use consistent noun-verb or verb-noun patterns across your codebase. Avoid spaces and special characters. Prefix events by area if you have many (e.g. auth_login_clicked, billing_plan_upgraded). Good naming makes autocomplete and search much faster as your event library grows.

Install posthog-js: npm install posthog-js. In your _app.tsx or layout.tsx, call posthog.init('YOUR_API_KEY', { api_host: 'https://app.posthog.com' }). Then anywhere in your components, import posthog and call posthog.capture('event_name', { ...properties }). Use the generated code from this tool directly — just replace the example values with real variables.

The distinctId uniquely identifies the user or session. For logged-in users, use your internal user ID (e.g. user.id from your database). For anonymous users, PostHog auto-generates a UUID on init and stores it in localStorage. After a user logs in, call posthog.identify(userId) to link the anonymous events to the identified user — this is called alias merging.

Client-side tracking (browser JS) is easiest and captures the most detail, but ad blockers can interfere. Server-side tracking (Node.js or Python SDK) is more reliable and can't be blocked — it's better for critical events like purchases or sign-ups. Many teams use both: client-side for UI interactions, server-side for transactional events. The generated code covers both approaches.