Sequential Docs
Sign in

Analyse behaviour › Basics

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.

View as Markdown 16 KB

On this page

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.

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.
Replay annotations The replay's Events tab and timeline markers group events into chips by class. See Find and replay sessions.
Judgments Sequential writes each line of the judge's session digest from the event's class. See 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.

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.

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.
  • 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, PostHog (web), Mobile apps, Mixpanel, Amplitude, Pendo or Moving from 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.
  • 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.
  • 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.