To set up event tracking in PostHog, start with posthog.init, which switches on autocapture for pageviews, clicks, input changes and form submissions. Then add custom events with posthog.capture and a clear event name such as user_signed_up, with a properties object for context. Backend events use your SDK's capture call with a distinct ID.
Start with autocapture
PostHog recommends autocapture as the starting point for a web app, because it's the quickest setup and saves you adding events by hand. Once you call posthog.init with your project token, the browser JavaScript library starts capturing pageviews and pageleaves, including the URL, referrer, UTMs and scroll depth.
Autocapture also records clicks, input changes and submissions on a, button, form, input, select, textarea and label tags. That's a lot of useful data from one line of setup. To keep an element out of it, add the ph-no-capture class. That excludes it from capture and from session recordings, which is handy for anything sensitive.
Six moves from install to custom events
- Add the PostHog SDK for your platform and call posthog.init with your project token.
- Check that pageviews and autocaptured clicks are arriving, and add ph-no-capture to anything you want left out.
- Add a custom event with posthog.capture('user_signed_up') at the moment the action succeeds.
- Name events in an [object] [verb] format, such as project created or invite sent.
- Pass a properties object, for example login_type, to give each event context.
- For server-side events, call your SDK's capture with a distinct ID, using identified events for logged-in users and anonymous events where you don't need a person profile.
The events autocapture won't get right
PostHog's own docs say autocapture won't give you a reliable user_signed_up event, so track signups explicitly. The same goes for any event that marks real progress: a purchase, an upgrade, an invite sent. Fire these with posthog.capture in your code at the point the action succeeds, not when the button is clicked, so failed attempts don't count.
Custom events take the event name as the first argument. You can add a properties object, such as login_type set to email, so you can later split signups by method.
Naming events so your reports stay readable
| Format | Good examples | Why it helps |
|---|---|---|
| [object] [verb] | project created, user signed up, invite sent | Events group naturally by the thing they're about |
Pick the format on day one and stick to it. Mixed naming, such as signup in one place and user signed up in another, is the main reason product reports end up untrustworthy.
Anonymous and identified events
Identified events create a person profile and anonymous events don't. The JavaScript Web SDK captures anonymous events by default, depending on your person_profiles setting. Backend SDKs work the other way: they capture identified events by default.
PostHog Docs flag the trap here. To send an anonymous event from the backend, you set the process_person_profile property to false and use a non-person distinct ID such as a random UUID. Skip the random ID and you can end up sharing one ID across everyone, which merges their activity into a single person. Backend-only setups can also send pageview events with a current_url property if you need page data without the browser library.
Getting the balance right
PostHog recommends combining autocapture with custom events, and tuning autocapture if you're sending too many events. Autocapture gives you breadth, custom events give you the moments that matter. If your event volume climbs faster than you expected, trim autocapture first rather than your custom events.
How Mixpanel and Segment do it
Mixpanel's JavaScript SDK uses mixpanel.track() to send an event with a name and properties, a similar pattern to posthog.capture. Segment's Connections product collects first-party event data and sends it on to 550+ destinations, which suits teams feeding several tools at once. My roundup of product analytics tools compares more options.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
My advice for your first week of tracking
Switch on autocapture, then add no more than five custom events for the actions that define success in your product, starting with signup. Agree the naming format with your team before anyone writes a capture call. Once the data is clean, you can start grouping users by behaviour, and my guide to customer segmentation tools shows where that leads.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
Does PostHog track events automatically?
Yes. After posthog.init, pageviews, pageleaves, clicks, input changes and form submissions are autocaptured.
How do I send a custom event?
Call posthog.capture with an event name, optionally with a properties object.
How should I name events?
Use an [object] [verb] format such as user signed up.
How do I keep an element out of tracking?
Add the ph-no-capture class.
What is the difference between anonymous and identified events?
Identified events create a person profile; anonymous events don't.
