Materialized Segments

A materialized segment is a segment that loads its list of units from your BigQuery instance. You write SQL, Confidence executes it as the service account you have configured, and you can then use this list of units as targeting for A/B tests, rollouts, or flag rules.

​

When to Use Materialized Segments

Use materialized segments when you need to target a specific list of users defined by complex queries in your data warehouse. Common use cases include:

• Beta testers: Target users who have opted into beta programs
• High-value customers: Target users based on purchase history or engagement metrics
• Cohort analysis: Target users who signed up during a specific period
• Custom segments: Any segment that’s easier to define in SQL than with attribute criteria

​

How Materialized Segments Work

1. You define a SQL query that returns a list of entity IDs
2. Confidence runs this query against your BigQuery instance
3. Confidence loads the resulting IDs into a segment and builds a bloom filter
4. You can use this segment for targeting in rules, experiments, and rollouts

At resolve time, how Confidence checks segment membership depends on the segment size:

• Up to ~100,000 entities: The local resolve providers checks membership locally via a bloom filter in the resolver state. No network call needed.
• Larger segments or exactness-critical: When the bloom filter exceeds 512 KB, Confidence excludes it from the resolver state. The online resolver (Confidence backend) queries a key-value store for an exact membership check.

​

Bloom Filters and Local Resolution

When a load job completes, Confidence automatically builds a bloom filter, a compact, probabilistic data structure that can answer “is this entity in the segment?” locally.

​

How Bloom Filters Work

A bloom filter provides:

• Definitive no: If the filter says “not in set,” the entity is definitely not in the segment.
• Probable yes: If the filter says “in set,” there’s a negligible chance it’s a false positive (typically 1×10⁻⁸).

The local resolve providers receive the bloom filter as part of the resolver state. When a flag rule references a materialized segment, the provider checks the bloom filter locally instead of making a network call.

​

False Positives

A bloom filter never produces false negatives. It can produce false positives—a negligible fraction of non-members may match as segment members. For experiments, this introduces no systematic bias since these users still receive randomly assigned variants. For feature rollouts, a negligible number of extra users see the feature early. The Confidence UI shows the false positive rate on the materialized segment page.

​

Privacy

Bloom filters use a one-way, non-reversible data structure. You can check whether a key is in the filter, but you can’t extract the keys. This means Confidence delivers segment membership information to resolvers without exposing the underlying entity identifiers.

​

Automatic Delivery

Confidence builds and delivers bloom filters automatically—no configuration required. Every completed load job produces a bloom filter. The resolver state that local resolve providers fetch includes the filter. Confidence excludes individual bloom filters exceeding 512 KB from the resolver state. These segments fall back to require a key-value store lookup. There’s no cap on the number of bloom filters in a state.

​

Backward Compatibility

Older SDK versions that don’t support bloom filters silently ignore them and continue requiring a key-value store lookup. Newer SDK versions that don’t find a bloom filter for a segment fall back to the same behavior.

​

Related Resources