Recommendations for working with segments

Segments are a key tool for working with data in a CDP platform. The quality of selections, analytics, and marketing mailing launches depends on how they are configured. However, in practice, there are situations when a segment does not work as expected: it is not recalculated, not updated, or returns unexpected results.

To simplify troubleshooting, this article provides recommendations for working with segments.

Too many "NOT" conditions

Excessive use of negations, especially the NOT IN SEGMENT operator, complicates logic and reduces performance.

Special attention – the "NOT IN SEGMENT" operator.
It is the most performance‑heavy operator. When used, the system dumps the entire profile database to intersect with the excluded segment. This is very slow.

Example of a problematic construct:

NOT IN (segment A)
AND NOT IN (segment B)
AND NOT IN (segment C)
...

Recommendations:

• Avoid using "NOT IN SEGMENT" whenever possible. Instead, duplicate the negative conditions from the selected segment. For example, if the segment has a single condition "not in Global Control Group", use a direct condition "is in GCG".

• Do not use more than 2–3 "NOT" conditions (of any kind) in a row without a good reason.

• Replace a set of "NOT" conditions with a single positive rule. Instead of listing where an object should not be, describe where it should be.

• Document segmentation rules: state why each negation is added. This helps avoid situations where one condition becomes irrelevant but the logic remains unnecessarily complex.

• Use "NOT IN SEGMENT" only when it is really unavoidable (e.g., the excluded segment is dynamically updated by another team).

Using the "NOT" condition with "OR"

When building a segment, a condition like the following is often set:

NOT (has active contract) OR NOT (verified)

At first glance, it may seem that this condition excludes all customers without a contract and without verification. In practice, it works differently: the segment will include all customers except those who simultaneously have both an active contract and verification completed.

This means that the condition excludes only those for whom both conditions are true at the same time, and not everyone who has at least one of them.

Recommendations:

• Avoid long expressions that alternate NOT and OR.

• If you need to select only customers who have neither a contract nor verification, use:

NOT (has active contract) AND NOT (verified)

Indexes and segment performance

Indexes are internal database structures that speed up searching for profiles by field values. Without an index, the system has to iterate through all customers — the segment builds slowly, especially on large databases.

Some indexes are created automatically when the platform starts. These are system indexes necessary for platform operation. You cannot manage them, and their set may differ between installations. Queries on such fields are usually fast, but you shouldn’t rely on this for any field.

Recommendations

Analyze which segments you build most often and which fields you use in them. Pass this list to your administrator. The administrator will check which indexes already exist and, if necessary, create additional ones within the limits.

caution

No more than 64 indexes can be created per account. For more details on database indexes, see the administrator documentation.

Storing lists of values

If you need to select profiles by a specific value from a list (e.g., interests, categories, tags), it is better to store such lists in a “tags” field type rather than in a string.

For example, the interests field contains tennis, football, chess. If you need to select everyone interested in tennis, the segmentation process will take longer when stored in a string than when stored in a “tags” field.

Date range

If a segment condition uses a date (registration date, order date, goal reached, email opened, etc.), the recalculation will be faster when the date range is limited. The fewer dates need checking, the less time segmentation takes.

Recommendations:

• Specify a concrete period whenever possible. Instead of “goal reached”, use “goal reached in the last 7 days”.

• Instead of checking events for all time, use profile attributes that don’t require scanning history (e.g., “last order date” instead of “had at least one order”).

• For recurring segments, use relative dates (“last N days”), but don’t make N too large — usually 30–90 days are enough.