| Audience | How you’ll use this article |
|---|---|
| Marketing teams | Understand the end-to-end event workflow and how event data powers real-time activation, personalization, and experimentation. |
| Data teams | Learn how events are planned, validated, stored in the warehouse, governed, and made available for downstream use. |
| Engineering teams | Follow the recommended implementation path, from instrumentation and validation to streaming and migration. |
Get started with Hightouch Events
This guide walks you through the end-to-end process of implementing Hightouch Events: from planning what to track to validating live event data and activating it in downstream tools. The steps below reflect the natural order most teams follow and link out to deeper documentation where needed.
Use this page as your starting point, then dive into each linked section as you implement.
Implementation overview
The table below outlines the recommended order for implementing Hightouch Events. Each step maps directly to a section in the Events documentation and reflects the structure you’ll see in the left navigation.
| Step | What you’ll do | Docs |
|---|---|---|
| Define events to track | Define the events you want to collect, including event names, types, and required properties. Align on naming conventions and identity strategy before writing code. | 📋 Event tracking spec |
| Connect event sources | Install SDKs or connect supported sources to start sending events to Hightouch. Use the debugger to confirm events are received with the expected payloads. | 📋 Connect event sources |
| Load to your warehouse | Persist event data to your warehouse so it’s queryable for analytics, modeling, and downstream use cases. | 📋 Schema |
| Stream events to destinations | Forward events in real time to downstream tools for activation, personalization, and operational workflows. | 📋 Event streaming |
| (Optional) Set up data contracts | Define and enforce rules for event structure, naming, and formats to keep data consistent as your implementation scales. | 📋 Managing contracts |
| (Optional) Transform events | Transform or enrich events in-flight before they’re written to your warehouse or streamed to destinations. | 📋 Functions overview |
| (Optional) Set up first-party tracking | Proxy events through your own domain to improve reliability and mitigate browser restrictions like Safari ITP. | 📋 First-party tracking |
| Validate your events | Review end-to-end event flow, inspect live data, and (if migrating) compare results against your previous system. | 📋 Migrate to Hightouch Events |
If you are migrating to Hightouch Events see Migrate to Hightouch Events.
Step-by-step guidance
1. Plan events to track
Start by deciding which user actions and events you want to capture and how they should be represented. This step often involves collaboration between marketing, data/analytics teams, and platform admins.
You should define:
- Event names and when each event fires
- Which fields are user traits vs event properties
- Required vs optional properties
- How users are identified across devices and sessions
This planning work becomes the foundation for every step that follows.
→ See Event tracking spec
2. Connect event sources to start collecting events
Once you’ve defined your event spec, instrument your applications and services to send events to Hightouch.
Hightouch supports multiple ingestion methods, including browser and mobile SDKs, server-side SDKs, HTTP APIs, and streaming platforms like Kafka.
At this stage, you should:
- Install and initialize the appropriate SDKs or sources
- Start sending
identifyandtrackcalls - Use the debugger to confirm events are arriving as expected
Supported SDKs
Hightouch provides several SDKs (software development kits) that you can deploy to your app or site in order to start collecting events. There are separate SDKs for:
Additionally, you can collect events directly from Kafka, PubSub, and Webhooks and inspect events in a web-based debugger to ensure you're capturing events from these different sources (including from SDKs) correctly.
Please note that there is a 96 kilobytes size limit for each event that's collected.
Recommended regions
aws-us-east-1(US East)aws-ap-south-1(Asia Pacific – Mumbai)aws-eu-west-1(Europe – Ireland)
For setup in other regions, please and we’ll help you get started.
3. Set up event storage
After events are collected, you can store them to your data warehouse. This makes event data available for querying, analytics, and downstream modeling.
In this step, you’ll:
- Connect your warehouse destination
- Review how event tables and schemas are structured
- Configure error handling and schema behavior
→ See Store events to your warehouse
4. Stream events to destinations
Once events are flowing reliably, you can stream selected events to downstream tools such as marketing platforms, analytics systems, or internal services.
This is useful when you want to:
- Trigger actions immediately after a user event
- Send conversion or interaction events to external platforms
- Power same-session or near–real-time workflows
Event forwarding applies filters, mappings, and governance rules before events are delivered.
→ See Event streaming
5. (Advanced) Govern event data
As your event implementation grows, data contracts help you maintain consistency and prevent breaking changes.
Contracts let you:
- Enforce required fields and types
- Validate naming conventions
- Detect and respond to violations automatically
→ See Managing contracts and Handling violations
6. (Advanced) Transform events
Event functions allow you to transform event data in-flight without re-instrumenting your sources.
Common use cases include:
- Renaming events or properties
- Enriching events with derived values
- Filtering or normalizing payloads
→ See Functions
7. (Advanced) Set up first-party tracking
First-party tracking routes events through your own domain, improving delivery reliability and helping mitigate browser limitations such as Safari ITP.
This step is optional, but recommended for teams with strict reliability or privacy requirements.
→ See First-party tracking
8. Validate your events
Before fully relying on your implementation, validate the entire event pipeline.
You should:
- Inspect live events in the debugger and event catalog
- Confirm data matches your tracking spec
Migrate to Hightouch Events
If you’re migrating from another event tracking solution, migration typically happens in parallel with the steps above:
- You’ll define events and instrument sources while still running your existing system
- You’ll validate data side-by-side before switching downstream tools
The migration guide walks through this process in detail: