# Events and event classes

> An event is one thing that happened in a session. Sequential gives each event one of nine classes, so a click means the same thing from every SDK.

> **In short**
>
> - An event is one thing that happened in one session, such as a page view, a click or `checkout_started`.
> - Sequential gives each event one of nine classes when it arrives. There is nothing to set up.
> - Sequential never rewrites the event name that your SDK sent.
> - Filters, replay annotations and judgments all use the class.
> - Event lists hide System events, but charts and tiles still count them.

## What an event is

An event is one thing that happened in one session. Sequential stores each event with its **class**, its **event name** exactly as your SDK sent it, and its **source**. The source is the SDK that sent the event.

On the **Events** page, each row shows the class badge and what the event acted on, such as `/pricing` or "Start trial". Hover the badge to see the source and the original name. To filter on them, use the **Event Name** and **Source** filters. See [Explore events](/docs/events-explorer).

## The nine classes

Sequential gives every event exactly one class.

| Class | Shown as | What it means |
|---|---|---|
| `pageview` | Page view | Your app showed a page or screen |
| `click` | Click | Someone clicked or tapped an element |
| `form_submit` | Form submit | Someone submitted a form |
| `identify` | Identify | Your app tied the visitor to your user id |
| `error` | Error | Your app reported an error |
| `rage_click` | Rage click | Repeated clicks on one spot, as the sending SDK detects them |
| `dead_click` | Dead click | A click that got no response, as the sending SDK detects it |
| `custom` | Custom | Any name not recognised as one of the above. Usually these are your own events |
| `system` | System | SDK housekeeping and telemetry, not something the user did |

- Sequential does not drop an event because of its name.
- The set of classes is fixed. You cannot add, rename or remap classes.

## What the class is for

Each SDK names the same action differently. The class gives these events one name.

| Feature | How it uses the class |
|---|---|
| **Event Type** filter | Filter with a class name, such as `rage_click`. See [Filters, date ranges and saved views](/docs/filters-and-saved-views). |
| Replay annotations | The replay's **Events** tab and timeline markers group events into chips by class. See [Find and replay sessions](/docs/sessions-and-replay). |
| Judgments | Sequential writes each line of the judge's session digest from the event's class. See [Judgments](/docs/judgments). |

## Autocaptured and custom events

- **Autocaptured** events are page views, clicks and form submits that an SDK sends without code from you. With the Sequential SDK, autocapture is on by default. It never records what a user types.
- **Custom** events are events that you send by name from your own code, such as `checkout_started`. See [Send custom events](/docs/custom-events).

## Hidden System events

Sequential gives SDK housekeeping events the System class. It stores them like any other event, but event lists and the judge's digest leave them out.

> **An empty list can still have counts**
>
> Event lists hide System rows, even when your filter asks for them. If you filter **Event Type** = `system`, the list stays empty.
>
> The chart and tiles still count the events. To list them, turn on the **All +N** chip.

## Limits

- **Event properties: choose a type.** **Event Property** matches one of the event's own properties by its name, with a type and an operator. **is** on **Text** matches the exact text of the whole value. To compare a number or a date, choose **Number** or **Date**. See [Property conditions](/docs/filters-and-saved-views#property-conditions).
- **Name collisions.** A custom event with a name that the sending SDK keeps for itself takes the class of that name. It can then be hidden: through Amplitude, `session_start` is System. See **Names, clicks and errors** below.
- **Rage and dead clicks.** Sequential stores them only if the sending SDK detects them.
  - The Sequential SDK does not detect them yet.
  - PostHog's dead-click detection is off with Sequential, unless your `posthog.init` sets `capture_dead_clicks`.
  - If Amplitude sends rage-click or dead-click events, Sequential stores them as Custom.
- **Replay marks are not events.** Rage clicks, dead clicks and bounces that the replay marks in a recording are not stored events. So filters, Watch and Ask do not see them.
- **Errors depend on the SDK.**
  - The Sequential SDK stores an Error event only for errors that you pass to `captureException`. Uncaught errors do not become events.
  - Sequential turns off PostHog's exception autocapture. So by default, only errors that you send with `posthog.captureException` arrive.
  - Mixpanel, Amplitude and Pendo send no error events.
- **Mixpanel profiles.** Sequential does not accept Mixpanel's `people.set` from the browser today.
- **Long sessions.** The judge reads at most 255 events per session. When a session has more, it leaves out plain clicks first.
- Event lists also hide some low-information names, such as `scroll`, `hover` and `heartbeat`, whatever their class. Do not use them for custom events.
- With the Sequential SDK, `capture()` throws on any event name that starts with `$`.
- Sequential SDK super properties last only as long as the page. To keep them, call `register()` on every page load.
- PostHog `$set`, `$set_once` and Sequential SDK `identify` properties stay on that one event. They do not become user properties.
- Sequential stores `pendo.track` properties as user properties, not event properties.
- The replay's **Info** tab shows only the user properties on the session's first event. So they are often missing there.

### What Sequential stores for each event

- Examples of events: your app showed a page or screen, someone clicked a button, someone submitted a form, or your app recorded `checkout_started`.
- The class: one of the nine classes above.
- The event name, exactly as your SDK sent it.
- The source: the SDK that sent the event.
- The time.
- The page URL and the referrer.
- The operating system, browser, country and IP address.
- The user and the session that the event belongs to.
- The event properties.

### Which SDK events get each class

Sequential takes the class from the event name and from the SDK that sent it.

| Class | Produced by, for example |
|---|---|
| `pageview` | PostHog `$pageview` and `$screen`, Mixpanel `$mp_web_page_view`, `[Amplitude] Page Viewed`, Pendo `load`, Sequential `$pageview` |
| `click` | PostHog `$autocapture` clicks and taps, Mixpanel `$mp_click`, `[Amplitude] Element Clicked`, Pendo `click`, Sequential `$click` |
| `form_submit` | PostHog `$autocapture` submits, Mixpanel `$mp_submit`, `[Amplitude] Form Submitted`, Sequential `$form_submit` |
| `identify` | `$identify` from PostHog, Mixpanel, Amplitude or Sequential; Pendo `meta` |
| `error` | PostHog and Sequential `$exception`, Smartlook `error` |
| `rage_click` | PostHog `$rageclick`, Mixpanel `$mp_rage_click` |
| `dead_click` | PostHog `$dead_click`, Mixpanel `$mp_dead_click` |
| `custom` | `checkout_started` sent with `sequential.capture`, `posthog.capture`, `mixpanel.track`, `amplitude.track` or `pendo.track`; mobile `Application Opened` |
| `system` | `$pageleave`, `$web_vitals`, `$set`, PostHog mobile `Application Backgrounded`, Amplitude `session_start`, Pendo `focus` |

The same name can get different classes from different SDKs. For example, `click` from Pendo is a Click, but `click` from PostHog is Custom. For PostHog autocapture, the kind of interaction also counts.

To see which of these events each SDK sends, read the **What is supported** section of its install page: [Sequential SDK](/docs/sequential), [PostHog (web)](/docs/posthog), [Mobile apps](/docs/mobile), [Mixpanel](/docs/mixpanel), [Amplitude](/docs/amplitude), [Pendo](/docs/pendo) or [Moving from Smartlook](/docs/smartlook).

### How each feature uses the class

- For example, a page view is `$pageview` in PostHog, `[Amplitude] Page Viewed` in Amplitude and `load` in Pendo.
- A Rage click filter on **Event Type** means the same thing for every SDK.
- Sessions, Users, Funnels, Flows and Retention share these filter fields.
- The replay groups events with the chips **Pages**, **Clicks**, **Forms**, **Custom**, **Identify** and **Frustration**.
- **Frustration** holds rage clicks, dead clicks, errors and "Bounced from …" rows. The replay adds a "Bounced from …" row when someone opens a page and returns to the previous page within 5 seconds.
- The judge reads a short digest of each session.
- In the judge's digest, the line for a page view is the path. For a click, it is the element text. For an error, it is the message. For a custom event, it is the name and a few properties.
- From 14 October 2026, a page that the visitor reached with their own Back button or swipe reads "went back (u-turn)" with the page. This needs a Sequential SDK that sends how the page was reached. It changes only the judgments made after that date.

### Event rows, Event Name and Source

- On an Events row, the source and the original name are in the title of the class badge. Hover the badge to see them.
- Examples of rows: the badge **Page view** with `/pricing`, or the badge **Click** with "Start trial".
- On the **Events** page and on the other pages, they are in the list of filter fields.

### Why custom events help

- Use custom events for moments that only your app knows about.
- Autocapture can show that someone clicked "Continue". A custom event shows that they started checkout.
- A funnel or flow step can use the exact name of a custom event.
- The judge answers the default rubric's **Intent** and **Outcome** questions from the session's events. A custom event gives the judge a named milestone. Without one, the judge has mostly page paths and click text.

### How to name custom events

- Examples of custom event names: `checkout_started`, `invoice_sent` or `plan_changed`.
- Keep names stable and few.
- Put what changes, such as plan, amount or item count, in properties.
- Do not use names such as `scroll`, `change`, `idle` or `heartbeat`. These events stay Custom, but event lists hide them the same as System events.

### Show hidden events

- SDKs send many housekeeping events.
- Event lists that hide System events: the Events page, a user's event list and the replay's **Events** tab.
- The judge's digest leaves System events out completely.
- The **Events over time** chart, the **Activity overview** tiles and breakdowns include System events.
- Examples of System events: page-leave and web-vitals events, feature-flag calls, profile updates such as `$set`, app backgrounding, and session start and end.
- The **All +N** chip shows hidden events. Its number counts only the rows that the list has loaded.
- In a replay, **Show all** also shows them.
- To list only System events, filter **Event Type** = `system`. Then turn on the **All +N** chip.
- Event lists also hide a few names that carry little information, such as `scroll`, `hover` and `heartbeat`. They hide these names whatever their class is.

### Where each kind of property comes from

Events carry three kinds of properties:

- **Event properties** describe one event, such as `plan` on `checkout_started`.
- **Super properties** apply to every later event from the page. You set them with `sequential.register()`.
- **User properties** describe the user. They come from profile calls.

| Kind | Describes | Comes from | Where you see it |
|---|---|---|---|
| Event properties | One event | The properties on a capture or track call, such as `plan` on `checkout_started` | **Event details** (the icon at the end of an Events row), under **Properties**, or expand a row with **›** in the replay's **Events** tab |
| Super properties | Every later event from the page | `sequential.register()`. They arrive as event properties on each event | As event properties |
| User properties | The user | Profile calls: Pendo visitor metadata, Amplitude `Identify` with `set`/`setOnce`, Smartlook `identify` properties and `smartlook('properties', …)` | **User properties** in the replay's **Info** tab, and the **Visitor Property** filter |

- The replay's **Info** tab shows only the user properties on the session's first event. So they are often missing there.
- Sequential SDK super properties last only as long as the page. To keep them, call `register()` on every page load.
- If a call passes a property with the same key as a super property, Sequential uses the value from the call.
- Not every SDK's "user" data becomes user properties. PostHog `$set` and `$set_once` stay as event properties on that one event. The properties that you pass to the Sequential SDK's `identify` also stay as event properties on that one event.
- Pendo works the other way. Sequential stores `pendo.track` properties as user properties.
- Only Pendo and the Sequential SDK's `sequential.account()` fill account properties. See [What each SDK supports](/docs/support-matrix).
- Pass `identify` the same identifier for a user every time. Sequential takes the value as given. It does not merge two different values for one user. See [Identify your users](/docs/identify-users).
- Sequential stores values as text. It stores a value that looks like a date and time, such as `2026-10-01T09:00`, as a date.
- If a text value or a key has half of a character pair, for example half of an emoji (an unpaired UTF-16 surrogate), Sequential stores "�" (U+FFFD) in place of that half. It stores the rest of the event. A complete pair, such as a full emoji, does not change.
- To filter on a date and time value, choose the type **Date** in a property condition.

### Names, clicks and errors

- Examples of name collisions: through Amplitude, `session_start` is System and hidden. Through Pendo, `focus` is System and `click` is Click.
- When a session has more than 255 events, the judge leaves out plain clicks first, then custom events. It keeps errors, rage clicks and dead clicks longest.
- The Sequential SDK guards its own names: `capture()` throws on any name that starts with `$`.
- The replay also marks rage clicks, dead clicks and quick bounces that it finds in the recording, such as "Bounced from /pricing after 3 s". Sequential does not store these as events. So filters, Watch and Ask do not see them. The replay's **Insights** tab judges them.
- With the Sequential SDK, uncaught errors do not become events. If replay is on, the recording's DevTools still captures them. The **JavaScript errors** setting is on by default. See [DevTools in replays](/docs/devtools).

## Related

- [How Sequential works](/docs/how-it-works)
- [Send custom events](/docs/custom-events)
- [Users and identity](/docs/users-and-identity)
- [Sessions](/docs/sessions)
- [Explore events](/docs/events-explorer)
- [DevTools in replays](/docs/devtools)
- [What each SDK supports](/docs/support-matrix)
- [Glossary](/docs/glossary)