Segments

A segment is a saved set of conditions, such as "iOS users who bought pro_yearly in the last 90 days". Grovs evaluates it on demand, so members change as people act. Use a segment as the audience of a push campaign, an in-app message or a journey.

Segments live under Audience → Segments.

Requirements

• Segments need the Enterprise edition and ClickHouse with reads and writes enabled. Grovs Cloud has both.
• Purchase conditions need revenue tracking.

People and devices

Every count has two numbers: people and devices.

• A person is the user identifier your app sets through the SDK, exactly as sent. Matching is case- and whitespace-sensitive, so UserA and usera are two people.
• A visitor with no identifier counts as its own person.
• A matching person brings in all of their devices.
• An identifier shared by more than 50 devices is treated as not set. This stops a shared or guest ID from merging unrelated people.

Without a user identifier in the SDK, people and devices are close to the same number.

Groups and conditions

A definition has two levels:

• Conditions sit inside a group. The group's operator, and or or, decides whether a person must match every condition or at least one.
• Groups are combined by a top-level and or or.

Groups cannot be nested. A definition holds 1 to 5 groups of 1 to 10 conditions each.

"Did not" conditions

A negative condition matches people who did not do something. Negative conditions are:

• event or purchase conditions set to "did not"
• is not, is not set and is not in the uploaded list operators

A negative condition must sit in an and group with at least one positive condition, which says who to start from. Example: "opened the app in the last 30 days" and "did not buy in the last 30 days".

Exception: a device condition in "current device" mode with is not counts as positive. It needs a known current value that differs, so it skips people with no device data.

Time windows

Event, device ("any device used" mode), acquisition and purchase conditions take a time window:

• Rolling: the last N days.
• Fixed: a date range from one day to another. It cannot start in the future.

Windows are in UTC and aligned to whole days. "Last 7 days" starts at 00:00 UTC seven days ago.

On self-hosted deployments, SEGMENT_EVENT_LOOKBACK_DAYS, SEGMENT_ACQUISITION_LOOKBACK_DAYS and SEGMENT_PURCHASE_LOOKBACK_DAYS set these caps.

Data retention

Segments only read data your plan still keeps.

• Saving a fixed window that starts before your retention cutoff is refused.
• A saved fixed window that later ages past the cutoff keeps working. Counts carry an incomplete flag, and the dashboard shows "A condition looks further back than your data retention; counts exclude deleted data."
• A "did not" window that reaches past retention is refused. Deleted data could otherwise turn a past buyer into a "did not buy" match.

Freshness

Counts are exact, not sampled.

• Unfiltered conditions on a built-in event or on any activity read daily totals. These lag up to about 10 minutes for the current month and the two before it, and up to a day for older months. Today is always included.
• Every other condition reads live events.
• Opening a segment computes a result once and reuses it for about 5 minutes. Counts, members and breakdown on that page read the same result, so they agree.

Who can use segments

Anyone on the project's team, admin or member, can create, edit, archive, count and export segments.

Archiving stops evaluation and hides the segment from pickers. Restore it from the Archived filter on the segments list.

Automate it

Create, estimate, count and archive segments and upload identifier lists from your server with the Segments API.