> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hightouch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

## Before you begin

* Familiarity with [how Events works](https://docs.hightouch.com/events/overview.md)

## What you'll decide

* [Event model](#design-your-event-model) — what to track and how to name and structure events
* [Identity](#plan-identity) — how to recognize people and connect their activity over time
* [Contract strategy](#decide-your-contract-strategy) — what to validate and how strictly
* [Coverage](#plan-for-coverage) — how reliable client-side collection needs to be
* [Delivery](#choose-how-events-reach-destinations) — 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](https://docs.hightouch.com/events/event-spec.md), [warehouse schema](https://docs.hightouch.com/events/warehouses/schema.md).

## 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](https://docs.hightouch.com/customer-studio/overview.md) 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](https://docs.hightouch.com/events/contracts/management.md) 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](https://docs.hightouch.com/events/contracts/management.md), [handling violations](https://docs.hightouch.com/events/contracts/violations.md), [Events CLI](https://docs.hightouch.com/events/contracts/cli.md).

## 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](https://docs.hightouch.com/events/first-party-tracking.md). Send business-critical events, such as purchases and signups, through [server-side collection](https://docs.hightouch.com/events/sdks/http.md) 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](https://docs.hightouch.com/events/first-party-tracking.md).

## 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](https://docs.hightouch.com/events/warehouses/warehouse.md), [event streaming](https://docs.hightouch.com/events/event-streaming.md).

## 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](https://docs.hightouch.com/events/migration-guide/overview.md) 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](https://docs.hightouch.com/events/sources/overview.md).
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](https://docs.hightouch.com/events/warehouses/warehouse.md).
3. **Govern your events with contracts.** Define [data contracts](https://docs.hightouch.com/events/contracts/management.md) 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](https://docs.hightouch.com/events/sources/overview.md#debugger) and the [event catalog](https://docs.hightouch.com/events/sources/overview.md#event-catalog), and check that your warehouse tables and columns match what you sent (see [Warehouse schema](https://docs.hightouch.com/events/warehouses/schema.md)). If you're migrating, validate parity against your previous tool instead — see [Validate your migration](https://docs.hightouch.com/events/migration-guide/validating-your-migration.md).
5. **Set up monitoring.** Add volume, violation, and sync alerts so you catch issues early. See [Monitor events](https://docs.hightouch.com/events/monitoring.md).

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](https://docs.hightouch.com/events/event-streaming.md).
* **Transform events** in flight to rename properties, filter, or enrich them. See [Transform events with functions](https://docs.hightouch.com/events/functions/overview.md).
* **Improve coverage** for browser events by [proxying through your own domain](https://docs.hightouch.com/events/first-party-tracking.md) and moving critical events to [server-side collection](https://docs.hightouch.com/events/sdks/http.md).

## Next steps

* **Migrating** from another tool? Follow the [Migration guide](https://docs.hightouch.com/events/migration-guide/overview.md).
* Once events are flowing, [build audiences in Customer Studio](https://docs.hightouch.com/customer-studio/overview.md) from your event data.