Size Estimation

Size estimation tells you how many entities match your audience definition, without saving the audience or running a sync. It is how you check that your filter conditions are targeting the segment you meant while you are still building it.

How Estimation Works

The audience builder shows an Estimated Size panel beside the filter. It updates on its own: after you stop editing the filter for about a second, Zeotap

1. Compiles the filter conditions into a COUNT(*) query — the same compilation a full evaluation performs
2. Executes it against your warehouse
3. Displays the count

You can also force a fresh run with Recalculate, and estimate a saved audience from its row in the Audiences list.

The count is computed by the warehouse over the whole model, so it reflects your data as it is right now — not a sample and not an extrapolation.

Caching

An estimate is cached for five minutes, keyed on the filter and the model behind it. Editing a condition and coming back to the previous one returns the cached number rather than re-querying, which is what keeps an iterative build from launching a warehouse query on every keystroke. A canvas republish invalidates the cache for the audiences it owns.

If you need a number that reflects a change made in the warehouse in the last few minutes, wait out the cache or change the filter and change it back.

Realtime Audiences

A realtime audience is counted differently, and the panel says which number you are looking at:

• An audience with both batch and realtime conditions shows Estimated Candidates — the profiles matching the batch half. The live event conditions are checked at request time and can only narrow that number, never widen it.
• An audience with only realtime conditions cannot be estimated at all. Membership is decided live, per request, so there is no batch snapshot to count.

When to Use Estimation

• During audience building — Watch the size change as you add or modify conditions
• Before saving — Confirm the audience is the size you expect before committing to it
• When iterating — Test different thresholds quickly (e.g. “what if lifetime_value goes from >500 to >1000?”)

Performance

An estimate is one aggregate query. It returns in seconds on most models, and the cost scales with:

• Your warehouse’s query processing speed
• The complexity of the filter (computed attribute joins, relationship traversals, nested groups)
• The size of the underlying tables

It is cheaper than a full evaluation because it counts rather than materializing the matching rows, but it is a real query against real data — a filter that would be slow to evaluate will be slow to estimate.

Next Steps

• Audience Preview — See the matching rows, not just the count
• Creating an Audience — Full audience creation guide
• Filter Builder — Build and refine filter conditions