A Klaviyo segment that silently drops to zero is almost never a bug in Klaviyo. It is a change in the underlying data that quietly invalidates one condition in the definition. The short answer: clone the segment, remove conditions one at a time until the count returns, and the last condition you removed is the culprit. The three causes that produce this without any error are negative conditions that stopped including profiles with a missing property, a property whose data type drifted from number to text, and a renamed or deleted metric that the definition still points at.
Key takeaways
- The fastest way to find the failing condition is to clone the segment and strip conditions one at a time until the profile count recovers.
- Since April 2023, a "does not equal" or "does not contain" condition excludes profiles where the property is not set, so renaming or stopping a property can empty the segment with no error.
- Segments built on relative time conditions like "in the last 30 days" only remove profiles once every 24 hours, so a segment can look broken when it is simply mid-cycle.
- A property that starts arriving as text ("5") instead of a number (5) breaks numeric operators such as "greater than", and no error is raised.
- Confirm the real membership with the Get Segment API and the
additional-fields[segment]=profile_countparameter rather than trusting the cached count in the UI.
What you need
- Owner, Admin, or Manager access to the Klaviyo account so you can clone and edit segment definitions.
- A private API key with the
segments:readscope if you want to confirm counts programmatically. - Knowledge of which integration feeds the property or metric in the definition (Shopify, a custom catalog feed, a server-side event).
- One example profile that you are certain should be in the segment, to test conditions against real data.
Diagnose which condition emptied the segment
- Confirm the segment is genuinely empty and not mid-refresh. Open the segment and read the growth chart under the definition. If the count fell to near zero on a specific day, that date is your anchor. If the segment uses a relative time window, wait past one 24-hour cycle first, because Klaviyo documents that profiles who no longer qualify on a relative time condition are removed once every 24 hours, not in real time.
- Read the definition and count the conditions. Note every condition group and whether each is positive ("has placed order") or negative ("does not equal", "has not opened email"). Negative conditions are the most common silent failure and you will test them first.
- Clone the segment and binary-search the conditions. Duplicate the segment, then remove or disable conditions one at a time, saving after each removal and reading the new count. When the count jumps back to a sane number, the last condition you removed is the offender. This isolates the cause without touching the live segment that flows or campaigns depend on.
- Check the negative-condition trap on the offending condition. If the culprit is a "does not equal", "does not contain", or "is False" condition, the profiles you expect are being excluded because their property is not set. Klaviyo changed this behavior so that properties that do not exist on a profile are excluded from evaluation. Restore the intended behavior by adding an OR branch:
OR Properties about someone > [property] > is not set. - Verify the property data type on a real profile. Open your known-good profile and read the property value. If a numeric condition ("greater than 100") stopped matching, confirm the value is stored as a number and not text. Klaviyo only treats a value as a number when it is imported without surrounding characters; a feed that starts sending
"100"as a string will fail every numeric operator silently. - Check for a renamed or deleted metric or property. If the condition references a metric ("has placed order at least once") or a custom property, confirm that metric still exists with the same name under Analytics, Metrics. A re-installed integration or a changed event name creates a new metric and leaves the old one frozen, so the definition points at a metric that no longer receives events.
- Confirm the true count through the API. The UI count can lag. Query the segment directly and request the live count.
Readcurl -s "https://a.klaviyo.com/api/segments/SEGMENT_ID/?additional-fields[segment]=profile_count" \ -H "Authorization: Klaviyo-API-Key YOUR_PRIVATE_KEY" \ -H "revision: 2025-07-15" \ -H "accept: application/vnd.api+json"data.attributes.profile_countin the response. If it matches the empty UI count, the definition is the problem, not a display lag.
The three silent causes, side by side
| Cause | Symptom | Where to confirm | Fix |
|---|---|---|---|
| Negative condition excludes missing property | Segment drops to near zero right after a property rename or a feed change | The offending condition is "does not equal", "does not contain", or "is False" | Add OR [property] is not set to the condition group |
| Property type drift (number to text) | A numeric operator matches nobody, but the value looks correct on the profile | Profile page shows the value; a new import sends it quoted as text | Fix the source feed to send an unquoted number, or re-import with the correct type |
| Renamed or deleted metric | An event-based condition ("placed order zero times") flips the whole population | Analytics, Metrics shows a new metric receiving events and the old one flatlined | Point the condition at the current metric and archive the dead one |
Why negative conditions are the usual offender
Positive conditions fail loudly: if the metric stops firing, you notice the flow stops sending. Negative conditions fail quietly because their population is defined by absence. When Klaviyo stopped counting profiles with an unset property as passing a "does not equal" test, any segment that relied on that older behavior lost every profile where the property was blank. This is why a segment can survive for a year and then empty overnight when an integration change blanks a property for new profiles. The segment conditions reference lists which operators apply to each data type, which is worth reading when a condition behaves in a way the definition text does not suggest.
Relative time windows and the 24-hour cycle
Before you conclude a segment is broken, rule out the update cycle. Segments driven by "in the last 30 days" add qualifying profiles immediately but remove disqualified ones on a daily batch. If you are sizing these windows against a real repurchase interval, the method in sizing a Klaviyo engagement window by repurchase keeps the window wide enough that normal churn does not read as a failure. A segment that looks half-empty at 9am may simply be waiting for the nightly removal pass to finish.
Troubleshooting
- The count recovers when you remove a condition, then empties again after saving. You are editing the live segment, not the clone. Always test on a duplicate so flow membership is not disturbed.
- The property looks right on the profile but numeric comparisons still fail. The profile page renders both text and numbers the same way. Export the profile through the API and inspect whether the raw value is quoted.
- The segment is correct but a flow tied to it stopped sending. Flow filters evaluate separately from segment membership. Check the flow filter for the same negative-condition and type issues before assuming the segment is at fault.
- Custom properties fed from Shopify tags or metafields keep drifting. Decide where that attribute should actually live so it stops changing type or name between syncs. The tradeoffs are laid out in where segmentation data belongs across tags, metafields, and a warehouse.
How to verify it worked
Do not trust the definition editor alone. Confirm the fix with three signals:
- Profile count via API. Re-run the Get Segment call with
additional-fields[segment]=profile_countand confirmprofile_countreturned to the expected order of magnitude. Note that this field drops your rate limit to a burst of 1 request per second, so poll it sparingly, as documented in the Get Segment API reference. - Known-good profile membership. Open the example profile you chose in step 5 and confirm it now appears in the segment. One correct profile proves the condition logic, where a raw count does not.
- Growth chart recovery. Watch the segment growth chart over the next 24 hours. A real fix shows the line climbing back toward its historical baseline, not a flat plateau. If it stays flat, a second condition is still failing and you repeat the binary search.