Most founders start with the same analytics setup: drop in Google Analytics, set up a dashboard, watch the numbers go up, and feel like they're doing analytics. A year later, they're making the same product decisions they would have made without it. The data was there — they just never had a clear question it was supposed to answer, so it answered nothing. The problem isn't too little data. It's a lack of clarity about what the data is for.
This guide is about building an analytics system that actually informs decisions — not just collects numbers. It covers the two distinct jobs analytics needs to do (website traffic vs. product behavior), the tools that do each job best, and the specific metrics and workflows that separate teams that use data from teams that just have data.
The analytics instrumentation trap
The instrumentation trap is what happens when you track everything you can, not everything you should. It starts innocently: you instrument page views, then clicks, then form completions, then scroll depth, then video plays. Two months later you have 200 events in your schema, a dashboard with 40 charts, and no clearer understanding of why users churn. The volume of data becomes an excuse not to act on it — 'we need more data before we decide' is often a rationalization for decision paralysis.
The alternative is starting with questions. Before adding a single tracking event, write down the three decisions you need analytics to help you make in the next 90 days. 'Are users completing onboarding?' 'Which pricing page variant converts better?' 'What does the drop-off in trial-to-paid conversion look like?' Those questions define your measurement plan — and your measurement plan defines what you track. Everything else is noise.
The three-question exercise
Before your next sprint, write down exactly three analytics questions that would materially change a product decision. Then instrument only what's needed to answer those questions. Delete events you're not using — they add noise and slow query performance.
Two jobs, two tools
Web analytics and product analytics are different tools solving different problems, and conflating them leads to either over-complexity (trying to use a heavyweight product analytics platform for simple traffic questions) or under-insight (using a traffic tool to answer product behavior questions it wasn't designed for).
Website analytics answers: How many people visited my site? Where did they come from? Which pages get the most traffic? What's the bounce rate on my landing page? These questions are about acquisition — understanding how people find you and whether your marketing is working. They don't require user identification or behavioral tracking beyond pageview and referrer data.
Product analytics answers: What do users do after they sign up? Where do they drop off in the onboarding flow? Which features are actually used? What behaviors correlate with paying customers versus churned users? These questions require tracking identified users across sessions, capturing feature-level events, and computing cohort-level metrics over time.
Plausible: the simple traffic dashboard
Plausible's design philosophy is deliberate simplicity. The script is under 1KB (vs. Google Analytics' 73KB), loads asynchronously, and doesn't use cookies — which means it works without a cookie consent banner in most jurisdictions, doesn't get blocked by Safari's Intelligent Tracking Prevention, and doesn't show up as a privacy violation in security audits. For marketing sites and landing pages, this matters practically: a smaller percentage of your visitors are invisible to your analytics.
The dashboard is one screen. Traffic trends, top pages, referrer sources, countries, devices, and conversion goals — all visible without navigating menus or building reports. For founders who check analytics once or twice a week to answer 'is traffic growing and where is it coming from,' Plausible answers those questions faster than any alternative. The absence of complexity is a feature, not a limitation.
PostHog: product analytics and beyond
PostHog's strength is breadth without the typical breadth penalty of complexity. Product analytics (funnels, retention, user paths, cohorts), session replay (watch actual user sessions to see what they clicked, scrolled, and struggled with), feature flags (gradual rollouts, A/B tests, permissions gates), and in-app surveys — all accessible from the same interface, using the same user identity. When you're debugging why users drop off in your onboarding funnel, you can click from the funnel chart directly into session replays of users who dropped off. That level of integration between tools is the real differentiator.
The first 1 million events per month are free, permanently — not a trial, not a limited feature set. For an early-stage product under 10,000 active users, you'll likely stay on the free tier for months. When you do hit scale, the pricing is event-based and predictable: you know exactly what you'll pay before you commit.
What to actually track (and what to ignore)
The events worth tracking are those that represent meaningful user actions in your product, particularly actions that sit at critical moments in your funnel. For a SaaS product, this typically means: account created, onboarding step completed (broken into individual steps), first key action performed (the moment that correlates with retention — for a project management tool, this might be 'first project created with two or more tasks'), paid plan activated, and account churned.
- Track the key user journey, not every click — events should represent meaningful decisions, not page noise
- Name events as past-tense verbs: 'project_created', 'payment_completed', 'feature_used' — not 'project_page_view'
- Include relevant properties on each event: plan type, user segment, feature name — you'll want to filter by these later
- Don't track PII (names, emails) as event properties — use PostHog's person profiles for that
- Audit your event schema quarterly — unused events degrade query performance and confuse the team
Funnel analysis that drives decisions
Funnels are where product analytics starts paying for itself. A funnel analysis shows you the conversion rate between each step of a key user journey — signup → onboarding step 1 → onboarding step 2 → first value moment → subscription. The drop-off between steps is your roadmap. If 60% of users complete step 1 but only 15% complete step 2, you have a clear optimization target — and you have the session replays of step-2 dropoffs to diagnose why.
The most common mistake in funnel analysis is optimizing the wrong step. Teams often focus on the step with the lowest absolute conversion rate, but the highest-leverage optimization is the step where small improvements have the biggest downstream impact. A funnel with steps at 80% → 20% → 70% → 60% should prioritize the 20% step, not the 60% step — even though both look like they have room for improvement.
When session replay changes everything
Session replay is where user behavior becomes intuitive. Watching five sessions of users who dropped off at a specific funnel step is often more diagnostic than reading a hundred rows of event data. You'll see the confusion that doesn't show up in your events: the button that users can't find, the error message that's technically displaying but nobody notices, the form field that causes people to pause for 30 seconds before abandoning. These insights don't come from quantitative data — they come from watching actual people use your product.
PostHog automatically captures session replays and associates them with your analytics events. When you identify a problematic funnel step, you can filter replays to users who hit that step and dropped off, then watch a sample. This workflow — quantitative identification, qualitative diagnosis — is the most efficient debugging loop for product UX problems.
Feature flags and controlled rollouts
PostHog's feature flags integrate with its analytics in a way that standalone flag tools don't. When you roll out a feature to 10% of users via a PostHog feature flag, the analytics events those users generate automatically include which variant they're seeing. You can then compare funnel performance between the control and test groups without any additional instrumentation. This closes the loop between shipping and learning — not just 'did we ship it' but 'did it work.'
Privacy-first analytics in a post-GDPR world
Both Plausible and PostHog are privacy-forward by design, which has become a practical requirement rather than a nice-to-have. Plausible collects no personal data and requires no cookie consent banner in most GDPR jurisdictions. PostHog provides robust anonymization controls, data residency options (EU hosting available), and person deletion APIs for GDPR right-to-erasure requests. For products targeting European users or operating in regulated industries, these aren't compliance checkbox items — they're requirements that influence your tool choice before anything else.
Making analytics a team habit
The highest-leverage analytics investment isn't a better tool — it's a team ritual that regularly reviews the data. Weekly product meetings that start with three metrics (activation rate this week, day-7 retention this cohort, trial-to-paid conversion this month) create accountability and catch regressions before they compound. The meeting shouldn't take more than ten minutes to open the dashboards, review the numbers, and identify one thing to investigate or act on.
“Analytics tools don't make you data-driven. The questions you ask and the decisions you're willing to change make you data-driven. The tools just make the answers faster.”
— Tama
