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.

Segmentation is one of the most resource-intensive processes in the platform. Not all segments will work quickly, and this largely depends on how they are designed: what conditions are used, what fields are involved, and how external data sources are configured.

This article provides recommendations for building efficient segments — from choosing a segment type to configuring indexes and external queries.

Segment types and calculation speed

Different segment types affect performance differently:

• Static segments — calculated once at creation or manual update. After calculation, the profile list is fixed, and subsequent use of the segment does not require recalculation.
• Dynamic segments — recalculated every time they are used (when launching a mailing, campaign, etc.). Complex dynamic segments can slow down mailing launches.
• Updatable segments — recalculated on a schedule. The load is distributed over time, but with a large number of updatable segments and frequent schedules, the overall load can be significant.

Segmentation by events (profile history)

When segmenting by events — email opens, clicks, goals reached, link clicks — the platform scans the action history of each profile.

Always specify a date range. Without a date limit, the system will check the entire profile history, which significantly slows down calculation.

The larger the period, the longer the segment takes to calculate:

• Segment "opened email in the last 7 days" — calculates quickly.
• Segment "opened email in the last year" — takes significantly more time.
• Segment "opened email" without a date limit — scans the entire history, which can take a very long time.

Recommendations:

• Always limit the date range. Use relative periods whenever possible ("last N days").
• For recurring segments, a range of 30–90 days is usually sufficient.
• Instead of checking events for all time, use profile attributes that do not require scanning history. For example, "last order date" instead of "had at least one order".

Segmentation by profile data

Indexes and custom fields

Indexes are internal database structures that speed up searching for profiles by field values. Without an index, the system has to iterate through all profiles sequentially — 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 — the user cannot manage them.

For fast segmentation by custom fields, you must create an index on that field in the database. On large databases, the absence of an index can increase segment calculation time several times.

caution

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

Recommendations:

• Analyze which fields you most often build segments by.
• Pass the list of these fields to the administrator for index creation.
• Take into account the 64-index limit and prioritize the most important fields.

Composite indexes for large databases

For databases containing one million profiles or more, segmentation performance depends even more on condition complexity and the presence of indexes.

MongoDB supports composite indexes, which speed up segmentation by multiple fields simultaneously. For example, if you often build segments by the combination "city + customer status", a composite index on these two fields will significantly speed up calculation.

caution

The number of indexes on a single profile database is limited by MongoDB limits. Before creating composite indexes, you need to assess which field combinations are used most often and prioritize them. Each additional index increases the time for writing and updating data in the database.

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.

Segmentation by external data

Segmentation by external sources (SQL queries, APIs, files) has its own performance characteristics. Detailed recommendations are in a separate article:

Recommendations for segmentation by external data

Key points:

• Design queries so that they return the minimum amount of data.
• Combine conditions from one external database into a single SQL query.
• Conditions with "NOT" on external data lead to scanning the entire profile database — minimize their number.
• The platform can automatically combine queries to one external database into a single SQL query (via intersection and union of results), but only if the queries use the same connector and are bound to the same profile field.

The "NOT" operator

Too many "NOT" conditions

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

The "NOT IN SEGMENT" operator.
This 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 the "NOT IN SEGMENT" operator whenever possible. Instead, duplicate the conditions from the excluded segment with the opposite sign.

For example, you need to select profiles that are not in the segment "Not in GCG". Instead of NOT IN (segment "Not in GCG") use the condition Is in GCG. The result will be the same, and performance will be higher.

• Do not use more than 2–3 conditions with "NOT" (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 truly unavoidable (e.g., the excluded segment is dynamically updated by another team).

Using "NOT" 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 completed verification.

This means that the condition excludes only those for whom both conditions are true at the same time, 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)