Plan your Events implementation

Plan these decisions before you instrument Hightouch Events. They are harder to change after events start flowing because your warehouse tables, contracts, and destinations depend on them.

What you'll decide

• Event model — what to track and how to name and structure events
• Identity — how to recognize people and connect their activity over time
• Contract strategy — what to validate and how strictly
• Coverage — how reliable client-side collection needs to be
• Delivery — where events go and how each destination should receive them

Design your event model

Decide which actions to track and how each event should be named and structured. These choices affect your warehouse tables, contracts, audiences, reports, and destinations.

• Track what you'll use. Tie each event to a real use case, such as an audience, journey, report, or destination workflow. Tracking everything "just in case" creates noise and tables no one uses.
• Name events consistently. Pick one convention, such as Object Action (Order Completed), and use it everywhere. Event names become warehouse table names, and contracts match them exactly. Inconsistent names can create duplicate tables or break validation.
• Separate properties from traits. Properties describe the action, such as cart total. Traits describe the person, such as email or plan type. Adding person attributes to every event can make tables harder to manage.
• Decide required and optional properties. Define which fields each event must include so contracts can validate them later.
• Keep field types consistent. A price should always be a number. A flag should always be a boolean. Hightouch infers each column's type from the values it receives, so mixed types can cause rejected or changed data.

Go deeper: event types and payload structure, warehouse schema.

Plan identity

Decide how to recognize people before and after they are known, and how their activity should connect to one profile.

• Choose a stable userId. Use an identifier that does not change over a person's lifetime, such as your internal database ID. Avoid email addresses, phone numbers, and session IDs because they can change or rotate. Send email and phone as traits instead.
• Connect anonymous and known activity. A visitor starts with an anonymousId. Call identify when they sign in so their pre-login and post-login activity can be connected.
• Decide how profiles unify. Joining one person's anonymous and known activity can happen in a warehouse model. Unifying many identifiers across devices, sessions, and sources into one profile is the job of Identity Resolution. Customer Studio can then use that identity layer for traits and audiences.
• If you're migrating, preserve identity behavior. Recreate your current tool's identity priority logic with identifier rules so people resolve consistently while both systems run in parallel.

Decide your contract strategy

Decide which event rules to enforce and how strict those rules should be. A data contract validates the event name, field names, and field types exactly as written, including capitalization and whitespace.

• Choose an enforcement level for each violation type. Hightouch can allow the event and flag the violation, block the event, or filter out the invalid fields. The default is to allow.
• Start permissive, then tighten. Use a permissive setup first so you can see violations without dropping data. Tighten enforcement once event names and field types are stable.
• Prioritize important events. Add contracts for your core, high-value events before covering edge cases.

Go deeper: managing contracts, handling violations.

Plan for coverage

Decide how complete your client-side event collection needs to be and which events need a more reliable path. Installing the SDK does not guarantee that every browser event will be captured.

• Expect some client-side loss. Browser events can be blocked by ad blockers, privacy settings such as Safari ITP, and cookie limits. This is part of client-side tracking, not necessarily a setup issue.
• Use first-party and server-side collection where needed. Proxy SDK traffic through your own domain with first-party tracking. Send business-critical events, such as purchases and signups, through server-side collection so they do not depend on the browser.
• Choose which events must be reliable. Route those server-side from the start.

Go deeper: first-party tracking.

Choose how events reach destinations

Decide where each event should go and how each destination should receive it.

• Warehouse, streaming, or both. Write events to your warehouse for analytics, modeling, audience building, and long-term reuse. Stream events directly to a tool only when the workflow is time-sensitive, such as triggering a message as soon as an action happens. Many teams warehouse all events and stream only the events that need to be immediate.
• Event-shaped or profile-shaped data. A destination can receive data as events, which represent actions over time, or as profile properties, which update attributes on a person. Choose based on what the destination should do with the data. Sending events when you meant to update profiles, or the reverse, is a common setup mistake.

Go deeper: write events to your warehouse, event streaming.

Build your implementation

Once you've made the decisions above, follow these steps to set up Events. If you're migrating from another tool, follow the Migration guide instead — it adds the work of running both systems in parallel, proving your data matches, and cutting over without downtime.

1. Connect your sources. Instrument your app, site, or backend to send events to Hightouch using an SDK, the HTTP API, or a streaming source. See Collect events.
2. Send events to your warehouse. Configure a warehouse destination so events land in a consistent schema you can query and model. See Send events to your warehouse.
3. Govern your events with contracts. Define data contracts for your core events so bad data is caught before it reaches your warehouse. Start permissive and tighten as your event names and types stabilize.
4. Validate the data. For a fresh build, confirm events arrive as expected: inspect live events in the debugger and the event catalog, and check that your warehouse tables and columns match what you sent (see Warehouse schema). If you're migrating, validate parity against your previous tool instead — see Validate your migration.
5. Set up monitoring. Add volume, violation, and sync alerts so you catch issues early. See Monitor events.

Depending on your use cases, you may also:

• Stream events to destinations for time-sensitive workflows, alongside or instead of the warehouse. See Stream events to destinations.
• Transform events in flight to rename properties, filter, or enrich them. See Transform events with functions.
• Improve coverage for browser events by proxying through your own domain and moving critical events to server-side collection.

What's next

• Migrating from another tool? Follow the Migration guide.
• Once events are flowing, build audiences in Customer Studio from your event data.