Event-based analytics

Amplitude, Mixpanel, and PostHog look different on the surface. Underneath, they run on the same model. A user does something, that action becomes an event, and the event carries enough context to answer questions about it later. Learn the model once and the tools stop feeling like separate skills.

You can skip this chapter if you've worked with one of these platforms before. If you're new, the next ten 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.

The event is the unit everything else hangs off. Most analyses start as a count of them. How many orders this week, how many sign-ups, how many songs the average user plays. 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. Include the properties you'll actually analyze, not every column in your database.

#Users

Every event belongs to a user. Before someone signs up they're anonymous, and the tool still tracks their events against a temporary identity tied to their browser. When they authenticate, you hand the tool your internal user ID, and the anonymous history stitches onto the real person.

How that stitching works, and why browser cookies make it harder than it sounds, is a chapter of its own: Identifying users. For now, hold two facts. Every event has a user behind it, identified or not. And each user accumulates a profile over time, which is where the next piece lives.

#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 versus free, US versus EU, organic versus marketing-acquired. 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.

It sounds like a footnote. 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.

Set user properties first, then track the event. That order comes up again and again through 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.

#Groups

In B2B, the customer isn't a person. It's an account. Five people from one company are one customer paying one bill. If your model only knows users, you can't answer the questions a B2B business runs on. How many accounts are active this week? Which ones are expanding, and which are about to churn?

A group is that account. Tools call it groups (Mixpanel, PostHog) or accounts (Amplitude). You tell the tool which group a user belongs to, and their events roll up to the account as well as to them.

Groups carry properties too, describing the account rather than the person:

• plan: enterprise
• seats: 45
• mrr: 1200
• industry: logistics

With groups in place, your analysis can work at the account level. Weekly active accounts, feature adoption per account, retention measured by account instead of by user. One power user who logs in every day can make a forty-seat account look healthy while the other thirty-nine have gone silent. Only account-level metrics catch that.

If you sell to individuals, where one user is the whole customer, you can skip groups. If you sell to companies, set them up early. Retrofitting group membership onto months of historical events is painful, and some account-level reports can't be rebuilt after the fact.

#Sessions

A session is a single sitting, a run of events from one user with no long gap between them. The tool opens a session on the first event and closes it after a stretch of inactivity, usually 30 minutes. Come back an hour later and that counts as a new session.

Sessions are how you measure engagement inside a visit. Session length, events per session, sessions per user per week. You don't manage them yourself. The SDK stamps each event with a session ID and rolls it over after the timeout. The identifier mechanics, and how sessions behave across anonymous and identified users, live in Identifying users.