Cohorts

A cohort is a saved audience. Instead of re-typing “users who ran a query at least three times last week” into every explorer view, you define it once, AZ-Five materializes the membership, and the cohort becomes a one-click filter. Cohorts are built on the event stream — see Product analytics for how events get there.

Create a cohort

Cohorts come in two kinds:

• Behavioral — “performed event at least N times in the last D days”. The definition takes an event name, a count threshold (count_gte, at least 1), and a window (days, 1–365). Membership is computed by evaluating that predicate over the events table.
• Static — an explicit list of distinct_ids you supply, for audiences that come from somewhere else (a CSV export, a support list, a beta signup form).

Both kinds are created in the app: name the cohort, pick the kind, and either define the behavioral predicate or paste the id list. Membership is evaluated on save and shows an exact member count. If evaluation fails on create, the cohort still saves with membership shown as pending until a refresh.

Use as a filter

Every explorer view — search, histogram, top values, paths — accepts a cohort as a filter, and the events explorer exposes cohorts in its filter bar. The filter matches events whose distinct_id is in the cohort; an empty cohort matches nobody.

One honest boundary: membership matches raw distinct_ids, before identity merging. If a person triggered the qualifying events anonymously and later identified, their anonymous and identified ids are separate entries from the cohort’s point of view. Canonical-person cohorts are a stated later refinement, not a current behavior.

Limits and freshness

Membership is materialized in Redis — filtering reads a set, it doesn’t re-scan your events on every request. The set is rebuilt when you save a definition change, when you call refresh, and transparently on a filter-time cache miss. Behavioral membership is therefore a snapshot, not a live query: each cohort shows when its membership was last computed, and a refresh recomputes it on demand.

Evaluation counts members exactly up to 100,000. Separately, a cohort larger than 10,000 members cannot be used as an explorer filter — the resulting id list would dominate query planning — and the filter is rejected outright rather than silently truncating the audience. Big cohorts remain useful for counting and preview; they just can’t be an interactive filter.

Reference

Limits

Limit	Value
Behavioral window	1–365 days
Behavioral count threshold	count_gte ≥ 1
Evaluation cap	100,000 members; member_count exact up to this
Static id list	at least 1, at most 100,000 ids
Explorer filter bound	10,000 members — larger cohorts rejected outright, never truncated
Members preview	up to 500 ids at a time (the total is always exact)