How to set up event tracking for product analytics in PostHog

So you want to know what users are actually doing in your product—not just what they say they do. Good call. Event tracking is the backbone of any real product analytics engine, and PostHog is a solid choice if you want control, transparency, and real data you can trust.

But here’s the thing: getting event tracking right takes more than just tossing in a JavaScript snippet and hoping for the best. If you just follow the happy path in the docs, you’ll probably end up with a mess of inconsistent events and questionable data. Let’s walk through how to get reliable event tracking set up in PostHog—without drowning in overkill or skipping the stuff that actually matters.

1. Get Clear on What You Actually Need to Track

Before you even sign up for PostHog or touch any code, stop and think about what questions you want to answer. If you track everything, you’ll end up with noise. If you track nothing, well—good luck.

Start with these basics:

  • What are your main user flows? (Sign up, onboarding, main feature use, upgrade, etc.)
  • What are your product’s “aha!” moments? (Is there a specific action that separates casual users from power users?)
  • Where do you lose people? (Churn points, drop-offs, confusing UX.)

Pro tip: Don’t try to track every click and scroll. Focus on business-critical actions and a few key behaviors. You can always add more later.

2. Set Up Your PostHog Project

Assuming you’ve landed on PostHog as your tool, you need a place to send data.

A. Create a PostHog Account

  • Go to PostHog.
  • Sign up—cloud or self-hosted both work, but cloud is easier to get started.
  • Create a new project (you might see this called a “team” in the UI).

B. Get Your Project API Key

  • Once your project is set up, head to Project Settings.
  • Copy your API key (sometimes called the “Project API Key” or “Team API Key”). You’ll need this for installing the tracking library.

3. Install the PostHog Tracking Library

Now for the technical bit. How you do this depends on your stack:

A. For Web Apps (JavaScript/React)

  • Basic Website:
    Add the snippet from PostHog’s “Getting Started” guide to your <head>. It’ll look something like:

html

sh npm install posthog-js

Then in your app:

js import posthog from 'posthog-js';

posthog.init('YOUR_PROJECT_API_KEY', { api_host: 'https://app.posthog.com' });

If you’re self-hosting, swap out the api_host URL for your instance.

B. For Mobile Apps

  • React Native: Use @posthog/react-native.
  • iOS/Android: There are native SDKs, but be honest: unless you’re doing something fancy, web tracking covers a lot. Still, check the official docs for the right SDK.

C. For Back-End Event Tracking

If you need to track server-side events (like purchases or sign-ups that happen via API), use the PostHog Python, Node.js, or Ruby libraries. The setup is similar—just pass your API key and fire events from your backend.

4. Define a Consistent Event Naming Scheme

Here’s where most teams trip up: they start tracking events with random names like ClickedButton, button_click, and UserPressedTheShinyRedThing. Three months later, nobody knows what’s what.

Pick a naming convention and stick to it:

  • Use clear, action-based names: user_signed_up, item_purchased, feature_used
  • Keep it lowercase, use underscores
  • Be consistent with verbs first: clicked_signup, viewed_dashboard, invited_teammate

Write these down somewhere. If you have a team, agree on the list before you start firing events.

5. Instrument Your Key Events

Time to track the stuff that matters.

A. Identify Users (Don’t Skip This!)

If you don’t attach a unique ID to your users, you’ll just see a swarm of anonymous blobs. You want to tie events to real users (even if you don’t know their name yet).

As soon as you know who a user is (sign up, login, etc.), call:

js posthog.identify('USER_ID_OR_EMAIL');

  • Do this once per session, right after login or registration.
  • If you have guest users, assign them a random ID and then “merge” later when they sign up.

B. Track Events

For every important action, fire a named event:

js posthog.capture('user_signed_up', { plan: 'pro', referral: 'landing_page' });

  • The first argument is your event name (stick to your naming convention).
  • The second is an object of properties (optional, but super useful).
  • Only add properties you’ll actually use for analysis. Don’t bloat every event with every possible context.

C. Don’t Overdo It

Resist the urge to track every UI flicker or mouse movement. Measuring everything slows down your app, makes your analytics a mess, and doesn’t actually help. Less is more.

6. Track Properties That Actually Matter

Event properties (sometimes called “event metadata”) are where you add detail—like which plan a user chose, or which feature they used.

What’s useful?

  • For sign-ups: source, plan, device
  • For purchases: product ID, value, currency
  • For feature use: feature name, version, context

What’s not?

  • User agent strings
  • Session IDs (PostHog tracks these by default)
  • Anything you’ll never segment or filter by

Pro tip: Never send personally identifiable info (like emails) as event properties unless you’re 100% sure it’s OK. Use unique IDs instead.

7. Test Your Events—Properly

Don’t just hope it works. PostHog has a handy “Live Events” section where you can see events streaming in real time.

How to check:

  • Open your product in a private window.
  • Trigger your tracked actions (sign up, use a feature, etc.).
  • Watch PostHog’s Live Events to confirm your event names and properties are showing up as expected.

If you see weird stuff:

  • Double-check your event names and properties for typos.
  • Make sure identify is being called after login or sign-up.
  • If you see duplicate events, you might be firing events in the wrong place (like both on click and on submit).

8. Ignore the Hype—What to Skip (For Now)

There’s a lot of noise about “autocapture” (tracking every click automatically) and “session recording.”

  • Autocapture: Sounds great, but the data is usually too messy to be useful. You end up with a firehose of clicks without context. For early-stage products, skip it. When you’re more mature, you can turn it on temporarily for exploratory research.

  • Session recording: Can be helpful for debugging tricky UX bugs, but don’t mistake it for solid product analytics. Also, be careful with privacy.

Stick to manual, intentional event tracking for the stuff that matters. It’s more effort upfront, but your future self will thank you.

9. Use PostHog’s Built-In Tools—But Don’t Overcomplicate

You now have events flowing in. What’s next?

  • Funnels: Set up a funnel to see where users drop off in critical flows (like sign-up or checkout).
  • Retention: See how many users come back after using a feature.
  • Dashboards: Pin your key metrics for quick checks.

Don’t get lost in endless charts. Pick 2–3 numbers that actually matter to your team and watch those. Nobody cares about “events per user per day” unless it moves your business.

10. Keep Things Tidy: Review and Iterate

Tracking isn’t a one-and-done thing.

  • Review your events every month or so. Kill off ones you’re not using.
  • If you add new features, add tracking as part of the rollout.
  • Keep your event names and properties consistent—future you (and your teammates) will have fewer headaches.

Wrapping Up

If you’ve made it this far, you’re already ahead of most teams. Remember: start simple, track only what matters, and check your work. It’s better to have ten solid, well-named events than a hundred random ones you never use.

Tweak and expand your setup as your product grows—but don’t chase the analytics rabbit hole. Keep it lean, keep it useful, and you’ll actually get answers you can trust.