Skip to main content

Overview

Hightouch Events uses a standard event structure for identifying users, tracking actions, and recording page and screen views, while letting your team control event structure and identity behavior. This article defines the event tracking specification used by Hightouch:
  • Supported event types
  • Required and optional fields
  • Identity behavior across anonymous and known users
  • Shared payload structure
  • Example JSON payloads
Use this guide when implementing SDKs, reviewing event data, or validating incoming events.

Supported event types

Hightouch supports the following event types: Each event type builds on a shared base structure and adds its own required fields.

Shared event structure

All event types share a common base structure, so Hightouch can validate, govern, and activate events consistently across destinations.

Required fields

  • type — The event type (identify, track, page, screen, group)
  • messageId — A unique identifier for the event
  • At least one identifier: anonymousId or userId
  • originalTimestamp — When the event occurred
  • sentAt — When the event was sent by the SDK or API

Optional fields

  • context — Automatically collected metadata (device, OS, SDK version, etc.)
  • integrations — Destination-specific flags
  • traits or properties — Metadata attached to the event:
    • Traits describe the user (for example, email or plan)
    • Properties describe the action or context (for example, price or product ID)

Identify events

Identify events capture data about who a user is. They are used to:
  • Associate anonymous activity with a known user
  • Set or update user-level traits
  • Link events across devices and sessions
For example, you might use Identify events to power follow-up email campaigns, segment users by location or plan, or link anonymous activity to authenticated behavior. Users often generate events before they log in or sign up. During this time, events are associated with an anonymousId. When you later send an Identify event that includes both a userId and the same anonymousId, subsequent events from that device include both identifiers. You can then join earlier anonymous-only events to the known user in your warehouse models using the shared anonymousId.

Components of Identify events

  • anonymousId
    A device- or browser-level identifier generated by the SDK to associate events from the same user before they are identified. This value is included automatically in other event types (e.g., Track events).
    An anonymousId typically persists across multiple sessions on the same device or browser.
  • userId
    A stable, persistent identifier for a known user (for example, it’s common to use an ID generated by your database). Avoid using mutable values such as email addresses.
  • traits
    Optional user attributes, such as email, name, or age.

Example identify event payload

Track events

Track events capture data about what a user did, such as completing a purchase or clicking a button. Additional details about the action are included in the properties object. For example, for a Purchase Complete event, you may want to include the product ids of the purchased products. When events are stored in the warehouse, the event field is used to generate table names in the warehouse. Additionally, the properties field is autoconverted into columns in the warehouse.

Example track event payload

Page events

Page events track the webpages users interact with. In most situations, you should automatically call the page load event when a page is loaded. For single-page applications, trigger page events on route changes.

Example page event payload

Screen events

Screen events are the equivalent of page views for mobile apps. Like page events, you should automatically call the screen event when a mobile screen view is loaded.

Example screen event payload

Group events

Group events let you associate users with a larger group. For example, a user may be part of an organization, or family. The traits field is optional, and can include information on traits on the group. For example, if linking a user to a company, you may include traits on the company such as the company size or location.

Example group event payload

Automatically captured fields

Hightouch SDKs automatically populate common context fields about the device, environment, and session. The table below shows which fields are captured by each SDK.
  • IP Addresses are captured by Hightouch’s servers when a message is received for client-side events and is not captured by Hightouch’s libraries.
  • userAgentData is only collected if the Client Hints API is available on the browser.
  • The Flutter and React Native SDKs capture the same session fields as iOS and Android. Session tracking is enabled by default. See iOS, Android, Flutter, and React Native for timeout configuration.
Last modified on September 15, 2026