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

# Product events

> What your customers actually do in your product, flowing into Zudo as events — and becoming traits, indicators, activity and health signal.

Product events are the usage side of an account. Everything else in Zudo is what customers *said* — emails, meetings, requests. Events are what they *did*, and the gap between the two is usually where churn hides: an account whose CSM calls go well and whose logins stopped is a different account from one where both are healthy.

## Getting events in

Events arrive from your product through a CDP or analytics tool:

* **[Segment](/integrations/segment)** — `track`, `identify` and `group` calls forwarded to Zudo
* **[PostHog](/integrations/posthog)** — the same, from your PostHog project

Both are configured as connections with a webhook endpoint and a signing secret. See the integration pages for the setup, and [event auto-create](/integrations/event-auto-create) for having Zudo create accounts from events for customers it has not seen before.

## What an event becomes

A single inbound event feeds several things at once.

### Account matching

Events carry a group identifier — your own id for the customer. Zudo matches it against the account's `externalId`, then `psId`, then `vitallyId`. An event that matches nothing is held rather than dropped, so it lands correctly once the account exists.

### Traits

A `group` call's properties become **product traits** on the account, and an `identify` call's become traits on the contact. These are first-class Zudo traits: they work in segments, smart-trait formulas and custom reports exactly like traits synced from Vitally or typed by a person. See [trait name precedence](/settings/trait-name-precedence) for what happens when two sources claim the same name.

### Indicators

[Indicators](/accounts/indicators) are predicates over the event stream — "active in the last 7 days", "has ever exported", "logins last 30 days". They are the main reason to send events at all.

### Activity and health

Product activity counts as contact with the account. A customer using the product daily is engaged even if nobody has emailed; an account with no events and no email is quiet in a way that shows up in its [health score](/accounts/health-scoring).

## Retention

Raw events are kept for **7 days** and rolled up into daily per-account, per-event-name counts that are kept indefinitely. Recent debugging works against the raw stream; long-range questions work against the rollups.

That split matters when you query: ask for raw events to see exactly what arrived this morning, and rollups for anything older than a week.

## Reading events over the API

| What                                                           | Endpoint                        |
| -------------------------------------------------------------- | ------------------------------- |
| Raw events, newest first, filterable by account, name and date | `GET /product-events`           |
| Daily rollups — the long-range view                            | `GET /product-events/rollups`   |
| An account's indicator values                                  | `GET /accounts/{id}/indicators` |
| An account's traits, including product traits                  | `GET /accounts/{id}/traits`     |

Identity calls (`$identify`, `$group`, `$alias` and their PostHog equivalents) are excluded from the raw feed unless you ask for them by name or pass `includeIdentity=true` — they describe who someone is rather than what they did, and they would otherwise drown the feed.

Full reference at [zudo.so/api/v1/docs](https://zudo.so/api/v1/docs).

<Note>
  Events are ingested asynchronously. An event sent now appears in the raw feed within a minute or two; indicators and
  rollups are recomputed on a nightly job, so a brand-new event does not immediately move an indicator.
</Note>