The Two Ways Analytics Setup Goes Wrong
Over-instrumentation: A PM reads "track everything" and instruments 400 events on day one. The result: a data warehouse full of noise, dashboards nobody trusts, and engineers who resent the tracking code scattered throughout the codebase. Three months later, the PM still cannot answer basic questions because the signal is buried in noise.
Under-instrumentation: A PM ships the product and adds analytics "later." Later becomes six months. When they finally need data to make a decision — which onboarding step has the highest drop-off? — they realize they have been flying blind. They instrument retroactively, but now they have no historical baseline.
Both paths lead to the same outcome: bad decisions due to missing or unreliable data.
Here is the middle path. A focused instrumentation approach that gives you useful data within two weeks and scales as your product grows.
Start With Five Questions, Not Five Hundred Events
Before you instrument a single event, write down the five most important questions you need analytics to answer. Not 50. Five.
For a typical SaaS product, these might be:
These five questions drive the first wave of instrumentation. Everything else can wait.
The Event Taxonomy
An event taxonomy is a naming convention for your analytics events. Get this right on day one and you avoid a painful migration later.
The Object-Action pattern
Name every event as Object Action. Object is the thing the user is interacting with. Action is what they did.
Good examples:
Account CreatedReport ExportedDashboard ViewedInvite SentPlan UpgradedBad examples:
click_button_export (what was exported? which button?)user_action_12 (meaningless)onboardingStep3Complete (what is step 3? this will break when you reorder steps)Properties, not events
A common mistake is creating separate events for every variant of an action. Do not do this.
Bad:
PDF Report ExportedCSV Report ExportedExcel Report ExportedGood:
Report Exported with property format: "pdf" | "csv" | "excel"This gives you one event to query, with the ability to filter by format. It keeps your event count manageable and your taxonomy clean.
The core event set
For most SaaS products, you need 15-25 events on day one, not 200. Here is a starting template:
Identity events (2-3):
Account Created (with properties: source, plan, referrer)User Invited (with: role, team_size)User Logged In (with: method — email, SSO, social)Activation events (3-5):
These are specific to your product's activation flow. For a project management tool:
Project Created (with: template_used, team_size)Task Created (with: project_id, has_assignee, has_due_date)First Collaboration (with: type — comment, mention, share)Core action events (5-10):
The primary actions users take in your product:
Dashboard Viewed (with: dashboard_type)Report Generated (with: report_type, date_range)Integration Connected (with: integration_name)Search Performed (with: query_length, results_count)Settings Changed (with: setting_name, previous_value, new_value)Conversion events (2-3):
Plan Upgraded (with: from_plan, to_plan, trigger)Trial Started (with: plan, source)Subscription Cancelled (with: plan, reason, tenure_days)Error events (1-2):
Error Encountered (with: error_type, page, action_attempted)That is 15-20 events. Enough to answer your five questions and build a solid foundation.
Choosing Your Tool Stack
The analytics tool market is crowded. Here is a practical decision framework:
For teams under 50 users: start free
For teams with 50-1,000 users: choose based on your primary use case
| Primary use case | Best tool | Why |
|---|---|---|
| Funnel analysis | Mixpanel | Best funnel builder in the category |
| Session replay + analytics | PostHog, FullStory | See what users do, not just that they did it |
| Self-serve analytics for non-technical teams | Amplitude | Most intuitive UI for business users (see the PM's guide to Amplitude) |
| Data warehouse-first approach | Segment + BigQuery + Metabase | Maximum flexibility, higher setup cost |
For teams over 1,000 users: invest in a data stack
At scale, you need a Customer Data Platform (Segment, RudderStack) feeding a data warehouse (BigQuery, Snowflake) with a BI layer on top (Looker, Metabase, Mode). This separates data collection from analysis and gives you flexibility as your needs evolve.
The Two-Week Implementation Plan
Week 1: Foundation
Day 1-2: Define and document your event taxonomy.
Write it in a spreadsheet: event name, description, properties, data type for each property, and which of your five questions it helps answer. Share it with engineering for review.
Day 3-4: Implement identity and activation events.
Start with the events that answer your first question (activation rate). These are typically 5-8 events covering sign-up through the "aha moment."
Day 5: Validate the data.
Trigger each event yourself. Check that it appears in your analytics tool with the correct properties. Fix any issues immediately — data quality degrades fast when bugs are left unfixed.
Week 2: Core flows
Day 6-8: Implement core action and conversion events.
Add the remaining 10-15 events. Prioritize the events that answer questions 2-4 (retention, drop-off, feature usage).
Day 9: Build your first dashboards.
Create three dashboards:
Day 10: Team review.
Walk the team through the dashboards. Ask: "Can you answer your most pressing product question with this data?" If not, identify the gap and instrument it.
Common Mistakes to Avoid
Tracking pageviews as your primary metric
Pageviews tell you where users go. They do not tell you what users do. A user who visits the dashboard page 10 times might be a power user or might be confused about where to find something. The action events (what they do on the page) are the useful signal.
Not tracking time-based properties
When a user creates a report, track how long it took. When a user completes onboarding, track the duration. These time properties surface UX problems that action counts alone cannot reveal.
A user who creates a report in 30 seconds is having a good experience. A user who creates a report in 8 minutes is struggling. Both show up identically in an event count.
Ignoring event volume costs
Analytics tools charge by event volume. If you track a Button Hovered event that fires 50 times per session, you will blow through your event budget quickly. Reserve tracking for meaningful actions — actions that indicate intent or completion, not interaction noise.
Not setting up user identification
Anonymous event tracking is nearly useless for product analytics. You need to associate events with identified users so you can build funnels, cohorts, and retention curves at the user level.
Set up user identification on sign-up (or as early as possible in the user journey) and call identify() before tracking events. Most analytics SDKs handle this with a single method call.
Skipping the event governance process
As the product grows, multiple teams will want to add events. Without governance, your taxonomy devolves into chaos within 6 months.
Establish a simple process:
This takes 5 minutes per event and prevents months of cleanup later.
Leveling Up: What to Add After the First Month
Once your foundation is solid, add these in order of value:
1. Funnel analysis by segment. Break your activation funnel by acquisition source, company size, or plan tier. You will almost certainly find that some segments activate at 2x the rate of others. That insight changes your marketing and product strategy.
2. Feature adoption tracking. For each major feature, track: first use (adoption), weekly use (engagement), and last use (abandonment). This gives you a clear picture of which features earn their keep and which are dead weight.
3. Session replay on key flows. Do not replay every session. Replay sessions where users dropped off at a specific funnel step. Watch 10 sessions and you will understand why the drop-off happens. This is faster and more insightful than A/B testing.
4. Alerting. Set up alerts for meaningful changes: activation rate drops below X%, daily active users drop more than 20% week-over-week, error rate exceeds threshold. Do not alert on noise — only on signals that require action.
Getting analytics right from the start is one of the highest-leverage things a PM can do. Two weeks of focused instrumentation work gives you a data foundation that serves the team for years. The alternative — guessing — is expensive and unnecessary.