# Your data in PostHog - Docs

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](/docs/data/events.md)**, single actions triggered at a specific point in time.

These are sent either from one of our [SDKs](/docs/libraries.md), or directly via our [API](/docs/api.md).

Events are flexible: they can be captured automatically via [autocapture](/docs/product-analytics/autocapture.md), or you can capture your own [custom events](/docs/getting-started/send-events.md), and attach additional metadata via [properties](/docs/data/events.md#event-properties).

## Properties

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

You might, for example, [create a custom event](/docs/getting-started/send-events.md#2-capture-custom-events) 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](/docs/data/sessions.md) 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](/docs/data.md), or by [using the toolbar](/docs/toolbar/create-toolbar-actions.md) 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](/tutorials/how-to-rename-events.md) 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](/docs/data/persons.md)**, 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](/docs/getting-started/identify-users.md), 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.

**Further reading**

-   [How data is stored in ClickHouse](/docs/how-posthog-works/clickhouse.md)
-   [How person properties are added to events](/docs/how-posthog-works/ingestion-pipeline.md#2-person-processing)

## 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](/docs/data/cohorts.md) 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](/docs/product-analytics/group-analytics.md)**, 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](/addons.md#group-analytics) and that you enable person profiles.

## Data model

Dig into the details of the [data model](/docs/how-posthog-works/data-model.md) to learn more about the fields on each data type.

### Community questions

Ask a question

### Was this page useful?

HelpfulCould be better