This article walks through the most common ways a BlueConic segment can surprise you: showing zero (or fewer) profiles than expected, showing a count that seems delayed or stale, applying AND/OR logic differently than you intended, returning the wrong window of profiles for a relative date filter, or producing an export/connection count that doesn’t match the segment. Each section is a checklist — work through it top to bottom before escalating to Support.
Why is my segment empty (or showing fewer profiles than expected)?
Most zero-profile segments are caused by something not writing to the property, an incomplete or overly strict filter, or a silent mismatch between the stored filter value and the data on the profile.
Indexing hasn't caught up yet
BlueConic uses Apache Solr to calculate segment counts. Whenever a profile is created or updated, it has to be re-indexed before it shows up in a segment filter — this can take up to 10 minutes. If you just triggered the activity you're testing, wait and recheck before troubleshooting further.
Use the Simulator to confirm a property is being written in real time — it loads automatically when you're logged into BlueConic in the same browser. A property can be present on the live profile (Simulator) while the Segments tab still shows 0 until the Solr catches up.
The listener isn't on, or isn't running where you think it is
New listeners are off by default. Confirm the listener toggle is On, then check its channel/page rules. By default a listener runs on all pages of all channels; if it was narrowed to a limited set, test traffic on a URL that actually matches those rules.
Consent / Objectives are blocking the write
This is about whether the listener (or Global Listener) is allowed to persist data — not about putting the segment itself in an Objective. Placing a segment in an Objective does not change who belongs to the segment.
If a listener has no Objective attached, it still runs (subject to your tenant's privacy settings).
If a listener is added to one or more Objectives: in opt-in legislation zones it only applies when the visitor has consented to at least one of those Objectives; in opt-out zones it applies unless the Objective was refused. If multiple Objectives are linked, meeting any one of them is enough.
The Global Listener always executes, but values are only persisted to the profile when the visitor has consented to a linked Objective. In-memory values can still be used for on-page targeting even when they are not stored.
Objectives only evaluate correctly when the profile has a Privacy legislation zone. Imported profiles that have never visited a channel often lack this property, which can make consent look “missing” even when you mapped other fields.
If the listener is configured correctly but the property stays empty for real traffic, check consent on a test profile (consented vs refused Objectives) before assuming the segment filter is wrong.
Write access isn't enabled on the profile property
Newly created profile properties have Visitor access off by default. For a browser listener (or dialogue/client-side connection) to store a value, Write must be enabled on that property.
Visitor access applies only to browser-based interactions. It does not apply to batch or server-side connections, server-side listeners, or the REST API — so if the property is populated by an import, skip this check.
If a listener is configured correctly and other properties are populating fine, but one specific property stays empty, check Write access on that property first.
A segment rule is incomplete
A blank segment (and a blank segment export) usually means one or more conditions were never finished: a property was added with no values selected, a range was left unset, or a date filter was added without a complete “in range / within last” configuration. Incomplete rules match no profiles.
In order to fix, open the segment, hover each condition, and confirm every filter has an operator and at least one value (or a complete range). Then save and recheck the count at the top of the segment editor.
The operator or AND/OR combination is stricter than you intended
Text filters default to contains any of (match at least one selected value). Switching to contains all, is empty, or does not contain any of can drop the count to zero — or explode it — without looking like a misconfiguration.
Between conditions, + AND requires every condition to be true. A property-value filter ANDed with a date window, an Objective filter, and membership in another segment is a common way to accidentally build an empty set. Rebuild condition-by-condition and watch the count at the top of the editor after each one.
The property isn't available for segmentation (or is hidden from the Segments tab)
A profile property can only be used as a segment condition if Available for segmentation is enabled. If Don't show on Segments tab (Hide from UI) is also on, the property will not appear in the Segments UI even when it is still usable from server-side plugins. If you can't find the property when adding a condition, check those two settings before creating a duplicate property.
The segment's stored values don't exactly match the profile data (silent mismatch)
BlueConic text segmentation does not support substring / “contains this keyword” matching. Each selected value is an exact stored value. BlueConic will not automatically group similar values together.
If you add a value by typing or pasting it (Add value) rather than selecting it from the live list of already-indexed values, it is stored as literal text. The UI accepts lowercase only for newly typed values. Trailing spaces, extra characters, or a near-duplicate variant (for example Home vs Home vs homepage) will not match, even when they look identical on screen — and the segment can return 0 for that value.
Indexed values also load in blocks of 40 (up to 1,000 unique values). If the value you want is not in the first page of the list, scroll or search rather than typing a lookalike.
Fix: Remove the value and re-add it by selecting it from BlueConic's autocomplete/value list. If in doubt, rebuild the filter from scratch as a test copy and compare counts. To catch near-duplicates, inspect the full value list for variants and include each one, or normalize the property upstream (for example with a Casing data processor on import).
The listener rule type doesn't match how you're filtering
If you're filtering a segment on Title, confirm the listener itself is configured to capture and match on Title (not URL) — and that the rule capturing the activity is the type you think it is (a content rule vs. a click rule can capture different things even when pointed at the same page).
Why is my segment count delayed, or not matching what I expect it to be right now?
A “10-minute indexing lag” is the baseline for a profile property that was just written. It is not the whole story if the segment depends on imported timeline data, a rollup, or a scheduled connection.
Understand the full pipeline, not just indexing
Before a profile is reflected in a segment used by a downstream export or connection, several steps have to complete in sequence:
Data is imported into BlueConic
Timeline events are processed
Timeline Event Rollups run and update the relevant profile properties
The target segment reindexes based on the updated properties (Solr, up to ~10 minutes after the property change)
Only then does an export/connection run and pick up qualifying profiles
Each step takes variable time depending on data volume, the number of rollups configured, and how busy the shared processing cluster is at that moment — which means the same import volume can finish faster or slower from one run to the next. If a scheduled connection runs too soon after import, some profiles simply will not have made it through the pipeline yet.
Fix: Build in buffer time between import and any downstream export/connection that depends on segment membership. A gap of 1–2 hours is often not enough at higher volume; several hours may be needed. If missed sends happen on a recurring schedule, talk with your Customer Success Manager about timing and capacity.
Rollups with “last N days” do not refresh continuously
If the segment is based on a property written by a timeline event rollup (for example “number of orders in the last 7 days”), that property is not recalculated on every page load. After a qualifying event, BlueConic schedules the next re-evaluation when the sliding window would change — typically at midnight UTC, not at the same hour of day the event occurred.
So a profile can drop out of (or stay in) a “last 7 days” segment later than you expect, even though Solr indexing is already up to date. That delay is the rollup window, not a broken segment.
The number at the top of the segment is current; the graph is not
The count at the top of the segment editor is the figure to trust after Solr has indexed. The “number of profiles” widget in the sidebar is a time-series graph of historical membership, not a live count refreshed on every page load. Don’t read “right now” off the graph.
While you are still editing conditions, OR-blocks and the on-screen count update after about two seconds of inactivity. Unchecking View profile counts hides per-value counts to speed up the UI — it does not mean those values have no profiles.
A dialogue can match before the Segments tab does
Dialogues evaluate Who rules (and current profile values) during the page view. Segment counts in the Segments tab wait on Solr. It is expected that Simulator / a live dialogue can show a visitor in the audience while the segment still shows 0 (or an old count) for up to ~10 minutes. BlueConic also reads a profile’s segment memberships at the start of each page view — a brand-new segment, or a property that just changed, is not available to a dialogue until the visitor refreshes or navigates.
Why isn't my rule logic working as expected?
"Extend existing segment" only supports AND
The Extend existing segment feature creates a new segment containing only profiles that are members of all selected segments plus any added conditions — it does not support OR. If you need "Segment A OR Segment B," Extend is the wrong tool.
Workaround: Build the segment directly in the segment editor instead of using Extend: add Segment A as a condition, then use the + OR connector to add Segment B as a second condition.
Filter operators among values vs. connectors among conditions
These are two different layers of logic, and mixing them up is the usual “OR that acted like AND” report:
Among values on one property: default is contains any of (OR). Use contains all only when the profile must have every selected value.
Among conditions: you choose + AND or + OR for each additional condition. Do not assume the default matches the previous connector.
Multidimensional segments support both AND and OR at the condition level. If the result is wrong, rebuild condition-by-condition and check the connector between each one.
There is no partial-text / keyword operator. Selecting shoe will not pick up red shoes.
Near-duplicate values are separate values
When a property has many unique or near-duplicate values, each distinct stored value has to be selected individually, or normalized upstream before it reaches BlueConic. If you're missing profiles you expect to see, check the indexed value list for variants (spacing, punctuation, different tokens) that also need to be included.
Why isn't my dynamic (relative) date filter working as expected?
To build a segment on a rolling window (e.g., "profiles created in the last 30 days"), use a date/time filter on the relevant profile property set to In range > Within last, with the number of units you want. The part people miss is the time unit, because each produces a genuinely different window. All calculations use UTC under the hood; the preview shows the range in your local time zone.
Days (24 hours) is the default option — that is usually the rolling window people mean. Calendar days (UTC) is the other common choice, and it is not the same thing.
Time unit | What it actually measures |
Calendar days (UTC) | Full calendar days in UTC (midnight to midnight), then through the end of the current hour. Not a rolling 24-hour count. |
Days (24 hours) (default) | Rolling 24-hour periods counted from the start of the current hour. |
Hours | Full-hour increments from the start of the current hour. |
BlueConic always rounds down to the start of the current hour for these filters. A segment checked at 10:55 AM using "Within last 2 calendar days (UTC)" and one using "Within last 2 days (24 hours)" can return meaningfully different ranges even though both say "2 days." Official example (local time 10:55 AM on November 4):
Within last 2 calendar days (UTC): November 2, 12:00 AM → November 4, 10:59 AM
Within last 2 days (24 hours): November 2, 10:00 AM → November 4, 10:59 AM
“Within last 1 hour” at 11:01 includes the entire previous hour and the current hour (10:00:00 through 11:59:59), not “the last 60 minutes.”
Before publishing a date-based segment to a live campaign: click outside the date/time input field. A preview immediately appears next to the time-unit dropdown showing the exact date/time range (in your local time zone) that will actually be used. Confirm that matches your intent before saving.
Fixed dates follow the viewer's time zone
Fixed-date filters (Between / After / Before) are configured in the browser’s local time zone and stored in UTC. Another user opening the same segment will see the same instant converted to their time zone (for example 5:30 AM CET on 1 December appears as 11:30 PM EST on 30 November). If you leave the time blank after picking a date, it defaults to 12:00 AM.
If this segment is actually driven by a rollup property rather than a date property on the profile, see Rollups with “last N days” above — the rollup’s relative window and the segment filter’s relative window are configured separately and do not stay in lockstep.
Why doesn't my export or connection count match the segment count?
A smaller (or empty) run compared with the segment is often not a segment problem. Connections apply extra filters on top of membership:
Connection Objectives: only profiles that satisfy the connection’s consent rules are processed. Example from product docs: a segment of 11.18K can yield 5.66K exported if only those have both the required identifier and consent.
Matching identifier: profiles with no value for the unique identifier you mapped are skipped.
Mapped properties: many export goals only include profiles that have a value for at least one of the selected export properties.
Incremental export (default): only profiles in the segment whose profile last-modified time is after the last successful run are sent. Adding a timeline event does not by itself bump last-modified, so those profiles can be omitted until something else updates the profile. Uncheck “only export profiles that have changed” (wording varies by connection) if you need a full dump.
Pipeline timing: if the connection ran before rollups and Solr finished, membership was still incomplete at run time — see delayed counts.
The number shown on the connection goal (“profiles available for export”) is already this filtered set, not the raw segment size.
Things that look like problems but aren't
All Visitors and Known Visitors appear greyed out in the segment list because they are system-managed and can’t be edited that way — not because of a permissions error, and not because the segment is inactive. Segments do not have an on/off toggle the way listeners and dialogues do.
Greyed-out overlaps in the Segment Overlap insight usually mean that overlap (especially OR-based segments) can’t be saved as a new segment from the insight. Build the combination in the segment editor instead.
Dialogue view counts will not equal segment size. Views only count profiles that actually visited a matching page while the dialogue was active.
If you've worked through the relevant checklist above and the segment still isn't behaving as expected, include the relevant details and reach out to support via in-platform chat or email.