How to Set Up Product Analytics From Scratch
Product analytics answers the question: what are users actually doing? Without analytics, product decisions are based on intuition and anecdotes. With analytics, you can see which features are used, where users drop off, and what actions predict retention.
This guide covers setting up analytics from scratch, including the events to track, how to structure them, and how to avoid the common mistake of tracking everything and learning nothing.
Step-by-step guide
Step 1: Choose an analytics tool
For most teams: Amplitude (powerful, steep learning curve), Mixpanel (accessible, generous free tier), or PostHog (open-source, self-hosted option). Choose based on team size, technical sophistication, and budget. Start with one tool. Adding more later creates data fragmentation.
Step 2: Define your event taxonomy
Create a naming convention for events: [object].[action] format. Examples: "project.created", "prd.generated", "ticket.exported". Use consistent casing (snake_case or dot.notation) across the entire product. Document every event in a tracking plan spreadsheet.
Step 3: Start with activation and retention events
Do not track everything on day one. Start with: signup events (method, source), activation events (the key action that predicts retention), retention events (return visit, core action repeated), and conversion events (free to paid). These four categories answer the most important product questions.
Step 4: Add user and event properties
Each event should carry properties that enable segmentation: user role, plan type, team size, feature area, and session context. User properties are set once and persist. Event properties are specific to each occurrence. Properties make your data useful; events without properties are just counts.
Step 5: Implement identity stitching
Before login, users are anonymous (identified by device or cookie). After login, attach a user ID. The analytics tool should merge pre-login and post-login activity. This is critical for understanding the signup-to-activation funnel.
Step 6: Validate tracking before launch
Test every event in a staging environment. Verify: events fire when expected, properties are populated correctly, user identification works across sessions, and the analytics dashboard shows the expected data. Fix tracking bugs before launch; retroactive fixes leave data gaps.
Common mistakes
Tracking everything
Tracking every click and hover creates noise without signal. Start with 15-20 essential events and add more as specific questions arise. You can always add tracking later; you cannot retroactively un-track noise.
Inconsistent naming
If one event is "userSignedUp" and another is "project_created" and a third is "PRD Generated," your data is a mess. Define and enforce a naming convention from day one.
No tracking plan document
Without a tracking plan, events are added ad hoc by different engineers with inconsistent naming and properties. Maintain a single document that lists every event, its properties, where it fires, and who added it.
Ignoring identity stitching
If pre-login and post-login activity are not connected, your signup funnel is broken. You cannot measure the path from landing page to activation without identity stitching.
Tips
- Use a tracking plan spreadsheet with columns: event name, description, properties, trigger, and owner
- Set up a daily Slack digest of key metrics so the team builds awareness
- Add analytics review to sprint retros: what did we learn from the data this sprint?
- Create a "data quality" dashboard that monitors tracking completeness
How Vantage helps
Vantage connects to Amplitude and Google Analytics as context sources. When your product analytics data is connected, PRD generation is grounded in real user behavior: which features are used, where users drop off, and what patterns predict retention.