Your data in PostHog

To get the most from PostHog, it helps to build a picture of how your data in PostHog is structured, grouped, and related.

Events

Our data model starts with events, single actions triggered at a specific point in time.

These are sent either from one of our SDKs, or directly via our API.

Events are flexible: they can be captured automatically via autocapture, or you can capture your own custom events, and attach additional metadata via properties.

Properties

Properties are metadata that you can attach to many types of data in PostHog.

You might, for example, create a custom event to represent purchasing an upgrade with custom properties like price or renewal_period.

You could then break down your upgrade_purchased event by those properties.

We also automatically apply some properties to events, such as:

• the Browser used to trigger an event.
• the Current URL where an event occured.
• or the Device Type used.

Sessions

A session is a collection of events corresponding to a specific usage session of your product or website.

One unique user can have multiple sessions, and each session will contain numerous individual events.

Sessions can also have properties, such as Session duration, Entry URL, and Pageview count, which you can query.

Actions

Actions are a layer on top of events.

They let you combine several events and treat them as if they're a single event, which you can then analyze in insights and dashboards.

Unlike events, which are captured via code in your product, actions are created within PostHog via the data management tab, or by using the toolbar on your website or app.

You might create an action to combine a number of events that lead to the same outcome – e.g. all the buttons on your homepage that lead to the pricing page.

Actions are also useful for renaming events and giving them a more memorable name.

Unlike events or sessions, actions do not have properties attached to them, though you can filter actions using properties attached to events, sessions, and other types of data in PostHog.

Person profiles

Users of your product are given a person profile, which associates all their events, sessions, and actions to them.

Person profiles similarly contain properties. Some are set automatically, such as:

• Browser details
• Geo IP data
• Referrers
• UTM values

You can also set your own properties on person profiles, which will appear in reports and data tables.

If a user upgrades to a paid tier, for example, you could set a property called paid_tier with the details.

Person profiles need distinct identifiers, so PostHog can accurately track behavior.

You might see a few identifiers on each profile: anonymous IDs created before a user has been identified, an ID you set after they log in, and IDs that are created on the client and backend, later merged together into a single profile.

Cohorts and groups

There are two ways to analyze collections of users in PostHog:

• Cohorts – Dynamic or static lists of users based on shared properties
• Groups – An aggregate of events captured from a group of users (e.g. a company)

Cohorts

Cohorts enable you to easily create a list of users who have something in common, such as completing an action or having the same property.

For example, if you want to see a list of every user in your paid tier, you could query for all profiles where that paid_tier property has been set.

Your cohort would then show you a periodically-updated listing of your paid customers.

You could then use this cohort in other parts of PostHog, such as:

• In trends, funnels, retention, user paths, stickiness, and lifecycle insights
• As a filter on any product analytics dashboard
• To target feature flags, experiments, and user surveys
• To filter the session replay list and create playlists
• Filter live events on the Activity page

Groups

Alternatively, you might want to understand group behavior. By defining groups, you can see a cross-section of events across multiple person profiles.

This can be helpful if you're selling to companies with multiple individual users, and want to understand the overall behavior of the whole company that uses your product.

Groups are also useful if you want to analyze retention at an account-level – i.e. how long customers use your product before churning.

Groups require that you have the Group analytics add-on and that you enable person profiles.

Data model

Dig into the details of the data model to learn more about the fields on each data type.