---
title: Event-based tracking explained
description: Events, event properties, and user properties (the three primitives every analytics platform is built on).
readingTime: 8 min
---

# Event-based tracking explained

> **Chapter 1 of the Concepts section.** No prerequisites. This page covers the building blocks every other chapter assumes you understand.

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.