Skip to main content
When you have a Segment or PostHog connection sending product-usage events into Zudo, every inbound event is a potential trigger for one of three things:
  1. Identity resolution — match the event to an existing Account / Contact.
  2. Auto-create (optional) — create the Account / Contact when no match is found.
  3. Timeline display — show the event on the matching account’s Events tab.
All three are configured per connection on the connection card (Settings → Connections → expand a product-event connection). The connection card surfaces three collapsible sections:
  • Auto-create from events — on/off toggles plus naming defaults.
  • Filter which events qualify — predicate rule sets that gate which events trigger creation.
  • Hide events from account timelines — patterns to drop from the account-view UI.
This page is a reference for the rule vocabulary, payload paths, and behavior you can configure across all three. For walk-through setup, see Segment or PostHog.

​
How the layers compose

Auto-create has two gates that must both agree before a record is created:
  1. Auto-create toggle for each record type (Contacts / Accounts). The on/off switch.
  2. Predicate rules in the Filter which events qualify section. Optional payload + identity rule sets — both sets must pass before a record is created.
Records that pass both gates are created with source: "product_event" so you can filter or audit them later. Events that don’t pass auto-create still flow through identity resolution normally — they just attach to existing records or land with no account, never create. The timeline exclusion list is independent: it hides noisy event types from the account Events tab and the daily-counts chart. Excluded events are still ingested, archived, and used for identity resolution and auto-create — they just don’t surface in the UI.

​
Account creation rules

Two predicate sets — both must pass before an Account is created.

​
Payload conditions

Match against the raw event payload. Use dot-paths into the JSON:
  • properties.tier
  • context.environment
  • properties.$set.signup_completed
  • traits.plan
Each rule is {field, operator, value}. Combined with AND.

​
Identity conditions

Match against the resolved identifiers from the event. Available flat fields:
  • email — resolved from traits.email, context.traits.email, properties.email, $set.email, or person.properties.email depending on source.
  • userId — Segment’s userId / anonymousId or PostHog’s distinct_id.
  • groupId — Segment’s groupId / context.groupId or PostHog’s $groups.<groupKey> / $group_key.
  • payload.<dot-path> — anywhere in the event JSON if you need something outside the three flat fields.

​
Common patterns

  • Block freemail signups from creating accounts Identity rule: email not_contains @gmail.com. Add similar rules for the freemail domains you want to exclude.
  • Only create from production events Payload rule: context.environment eq production (or properties.environment depending on your client).
  • Only create paid customers as accounts Payload rule: properties.plan neq trial.
  • Skip test groups Identity rule: groupId not_starts_with test_.
  • Only create when the group really exists Identity rule: groupId is_set. Required if your events sometimes lack a group binding.

​
Contact creation rules

Same structure as account rules — payload conditions + identity conditions — but applied to Contact creation independently of accounts. Contacts and accounts are created on independent gates: an event with an unknown email can auto-create a Contact even if the account is unresolved. Useful contact-side rules:
  • Block test users by email pattern — Identity rule: email not_contains @example.com.
  • Only create when user has been “identified” by your client — Payload rule: properties.$set.email is_set.

​
Hide events from account timelines

Some events are critical for identity resolution and auto-create but noisy on the timeline — Segment’s identify / group calls, PostHog’s $identify / $groupidentify / $set, system pageleave events, internal telemetry, etc. On the connection card, expand Hide events from account timelines and list the event name patterns to hide. Matching events:
  • ✅ Still ingested
  • ✅ Still archived to S3 (replayable later)
  • ✅ Still rolled up into Postgres
  • ✅ Still used for identity resolution and auto-create
  • ❌ Hidden from the account Events tab and the daily-counts chart
Patterns support exact match and * wildcards. Examples: One pattern per line. Max 200 patterns. Each pattern is case-sensitive (event names usually are). Segment:
PostHog:

​
Browse recent payloads

Configuring rules against an event payload requires knowing the exact dot-path to the property you want to match. Rather than digging through PostHog or Segment documentation:
  1. On the connection card, expand the Auto-create from events or Filter which events qualify section, then click Browse recent payloads → Show.
  2. Zudo shows the 5 most recent events from your connection, deduplicated by event name.
  3. Each event lists every available dot-path with its sample value.
  4. Click a rule’s field input first to focus it, then click any path in the browser to insert it into that input. Without an active focus, the click just copies the path to your clipboard.

​
How creation actually works

The aggregation job runs every 10 minutes. For each inbound event that didn’t match an existing record:
  1. Checks the connection’s auto-create toggles. Skipped if off.
  2. Evaluates the org-level payload + identity rules for the record type (account vs. contact). Both must pass.
  3. For accounts: confirms the minimum events threshold has been met. The connection setting accountMinEvents defaults to 1 (create on first event); 5–10 is a common spam guard.
  4. Creates the record:
    • Account: organizationId, connectionId, externalId = the inbound groupId, source: "product_event". Name comes from the configured payload path or falls back to Account <id>.
    • Contact: connectionId, email, productExternalUserId, source: "product_event". Name from payload path or the email’s local part. Linked to the resolved account when there is one; otherwise unlinked (Reconcile back-fills later).
  5. Subsequent events for the same group / user resolve normally via the identity chain without re-creating.
If creation collides with another process (rare race), Zudo gracefully falls back to attaching the event to the existing record.

​
Operators

Rule operators across both payload and identity sets: Unknown operators are treated as “pass” with a server-side warning — so a UI regression can’t accidentally block all creation.

​
Provenance and cleanup

Auto-created records carry source: "product_event". This shows up as a source value on the Account / Contact (indexed for fast filter). Use it to:
  • Filter the Accounts list to “Auto-created” for spot-checks.
  • Bulk-delete records that auto-created in error.
  • Distinguish from manually-imported records (which carry source: "manual", "vitally", "csv_import", or "api" depending on origin).

​
What auto-create does NOT do

  • Doesn’t merge existing duplicate accounts/contacts. Two records with overlapping emails stay separate; auto-create never deletes.
  • Doesn’t enrich created records with data from third-party services. Records are bare — you can enrich with Vitally sync, a CSV import, or the Zudo API.
  • Doesn’t back-fill historic events. Once events have been aggregated as accountId: null, creating the account later won’t retroactively attach them. Use Reconcile past events on the connection card for that.
  • Doesn’t cross-stitch identity. If the same human fires events with two different anonymousIds and no shared email, you get two contacts.