Product events

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 — track, 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 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.

Seeing events on an account

Open an account and pick Events on the timeline filter. Two things appear. Daily counts sit at the top: a line per event name over the last 30 days, drawn from the rollups. The busiest five event names are drawn to begin with. Click the N of M events control to see every event name in the window with its total, and switch any of them on or off — useful when the event you care about is quieter than the one that dominates the chart. Those daily counts are bucketed by UTC day, while the event list below groups by your own timezone. For a slice of each day as wide as your offset from UTC, the two disagree about which day an event belongs to: at UTC-5, anything from 7 PM your time is counted on the next day in the chart. The chart says so under the axis, and its tooltip labels each day as UTC, so the two can be lined up. A rollup is a count rather than a list of events, so it cannot be re-split into your timezone after the fact. The event stream sits below it: every allowlisted event that resolved to this account, newest first. Click a row to expand it and see the properties the event carried, as dotted paths with their values — the same paths you would use in an indicator or an auto-create rule. Load more activity walks further back through the stream. The line under the chart says how many event names are on your allowlist. If it says none, nothing will appear in either place until you add some under Settings → Connections. On a parent account, both the chart and the stream show the events of the accounts inside it.

Every event your organization receives

Settings → Events lists the product events arriving from all your Segment, PostHog and zudo.js connections, newest first. Use it to check that events are arriving, and that they land on the accounts you expect. Each row shows when the event arrived, its name, the account it matched, the user’s email or id, the source connection, and its status:

• unattributed in the account column means Zudo couldn’t match the event to an account. Hover it to see why: the event’s group id matches no account’s External ID, or the event carried no group and its user isn’t linked to an account.
• via graph means the event carried no group of its own, and Zudo matched it to the account through its user’s identity link.
• pending means Zudo hasn’t processed the event yet. It becomes processed once it has.

Unlike the stream on an account, this feed isn’t limited to your allowlist. Identity calls are left out, because they carry traits and account matching rather than usage. The filter box narrows the events already loaded by event name, account, email or id. Load more fetches older events, back to the edge of the retention window, and Refresh fetches the newest.

Retention

Raw events are kept for 7 days by default 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 the raw window.

What pruning removes

When a raw event passes the window it is deleted from Zudo’s database. Everything derived from it stays:

• Daily counts — kept indefinitely, which is what the chart on an account draws
• Traits on the account and its contacts
• Identity links matching a user to an account
• Indicator values, activity and health signal

So a pruned event is one you can no longer open and read the properties of. Nothing that was counted, matched or scored is affected. Only events that have been aggregated are eligible. An event that arrived but has not yet been processed is never pruned, however old — it has not reached a rollup yet, so deleting it would lose it outright.

Changing the window

The window is set per organization and can be anywhere from 1 to 365 days. Ask support if you want longer than the default; raw payloads are the heavy part of the store, so a longer window is a storage question rather than a switch you flip yourself. Every GET /product-events response carries retentionNote, which states the window that applied to it — so you never have to guess which one your organization is on.

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.