Skip to main content
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:
  • Segmenttrack, identify and group calls forwarded to Zudo
  • 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 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 for what happens when two sources claim the same name.

Indicators

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.

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

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