Event-based tracking explained

Analytics platforms like Amplitude, Mixpanel, and PostHog all use the same underlying model: events. Every user action is an event, every event has context, and every event belongs to a user (anonymous or identified).

You can skip this chapter if you've worked with one of these platforms before. If you're new, the next 10 minutes will save you hours of confusion later.

#Events

An event is a discrete action a user performs in your product. When someone starts a song in a music app, that's a Song started event. When they complete a purchase, that's an Order completed event. When they sign up, that's Sign-up completed.

Most analyses are about counting events: how many orders, how many sign-ups, how many songs played per user. Events also unlock funnels, retention curves, and most of the analyses you'll build later in the guide.

#Event properties

Event properties add context to an individual event. A Song started event might carry:

• genre: jazz
• duration_s: 180
• source: playlist

Event properties answer questions about the circumstances of a specific action. Later you'll segment by genre to find your most-played categories, or by source to see whether playlists or search drive more engagement. The key is including properties that will actually be useful for analysis — not every field in your database.

#User properties

While event properties describe the action, user properties describe the person. User properties persist across events and stay attached to the user's profile.

Common examples:

• subscription_status: premium
• city: Chicago
• referral_source: facebook
• account_type: business

User properties are how you segment people: paying vs. free, US vs. EU, marketing-acquired vs. organic. They're how you slice every chart you'll build.

#The thing that trips everyone up

User properties get captured on every event as the value existed at the time the event fired. Not at the time you analyze it.

If a user has city: Chicago on their profile and performs 50 events, all 50 events are tagged with city: Chicago. If the user later updates their city to Denver, past events still show Chicago. Only events from that point forward will carry city: Denver.

This sounds like a detail. It's not. It changes how you implement events and how you read charts.

#Implementation consequence

When a user converts to a paid plan, you want their subscription_status user property set to active before you track the conversion event. Otherwise the conversion event carries the old trialing value, and your "Subscription started" funnel won't show what you'd expect.

This pattern — set user properties first, then track the event — comes up repeatedly throughout the guide.

#Analysis consequence

Imagine a user who first visits from Facebook (referral_source: facebook). They add items to their cart but don't check out. Days later, they return via direct traffic (referral_source: direct) and complete the order.

You might expect their Order completed event to attribute to Facebook. It doesn't. It attributes to direct, because that's what their referral_source was when the order fired.

If you want to attribute revenue to first-touch source, you have to track first-touch separately (a first_referral_source user property using setOnce, which only takes the first value). The guide covers these patterns as they come up.

#The mental model to take away

Three layers:

1. Events are things that happened. They're immutable — once fired, they're a permanent record of "this user did this thing at this time with these properties."
2. Event properties describe what happened.
3. User properties describe who it happened to, frozen at the moment it happened.

Internalize this and the rest of the guide makes intuitive sense. Skip it and you'll be debugging "why does my chart show the wrong value" for weeks.