Setting Up Audience Segments in Bitrix24 CRM Marketing

Why audience segments in Bitrix24 become outdated in a month

A segment in Bitrix24 CRM marketing is not a mailing list but a selection rule: which contact and deal card fields cause an entry to fall into a group. As long as the rule is the same and fields are filled in consistently, everything works.

The breakdown begins when Bitrix24 audience segments are assembled manually: a marketer exports contacts using one filter, tags some of them, and leaves the set static.

Then data discrepancies in cards come into play: a contact comes from a form, then the same person is created from a call, then a manager adds more details — and one field contains “Минск,” another “Minsk,” and a third is empty.

Duplicates are not merged, the deal is linked to a company rather than a person, so a rule based on contacts simply does not see it.

The campaign goes to those who have already purchased or unsubscribed; outdated contact groups continue to receive emails for months. And some recipients do not fall into any segment — lost deals surface a quarter later, when the client has already chosen another.

Manual database reconciliation is a week of work: consolidate exports, find duplicates, determine which field value is correct, update tags. By the time it is complete, it is already outdated: in a month the database changes again, and no segmentation rule has appeared.

We break down how this is solved: rule-based selection instead of static lists, required fields at deal entry, regular regrouping and duplicate control — so that mailings go out based on current data, not an old export.

What managed segmentation delivers: 4 measurable effects

A segment in Bitrix24 is not a list of contacts but a selection rule: a field in the card, deal stage, purchase history, and website action are combined into a single query, and the campaign is addressed exactly to it.

While the rule lives in the marketer’s head, the audience is assembled manually and becomes outdated by send time. When the rule is described in the CRM, the database recalculates itself, and empty and invalid addresses are filtered out at entry.

Below are four effects that are visible in reports, not just claimed.

Targeting accuracy

Filtering by fields and stages eliminates manual exports: only cards with filled attributes go into the mailing. The hit rate rises from “about half” to 90% and above — manual assembly errors go away along with the process.

Unsubscribe rate

The subject and frequency of an email depend on the segment: a welcome chain for new contacts, an upsell for active ones. Relevance reduces the unsubscribe rate by two to three times compared with a blanket mailing to the entire database.

Campaign preparation time

A segment is saved as a template and reused: a new mailing is assembled by selecting a rule rather than exporting and cleaning tables. Preparation takes hours instead of days, and the result is reproducible from launch to launch.

Repeat purchases

Automated scenarios catch up with the client based on an event: abandoned cart, subscription expiration, a month after purchase. The touchpoint arrives on time, so the share of repeat purchases grows without additional pressure on the database.

Filters, lists, and rules: how the approaches differ

A segment in CRM is not a saved search but an object with a lifecycle: it has selection conditions, a population moment, and a rule by which the composition changes further.

Therefore, the approaches differ not by interface but by who owns the composition — a person or a trigger rule. Below are the options that are actually chosen between on a project, together with their limitations.

In practice, the choice is dictated by two questions: how often the attribute changes and who owns the data. If the attribute lives in deal fields and managers update it, dynamic filters provide an up-to-date picture with each mailing.

If data comes from outside, it is more stable to keep a static group and populate it on a schedule — you see exactly the composition you have verified.

The options are not mutually exclusive.

A workable combination: a dynamic filter collects candidates, and before the campaign the selection is fixed into a static group — the mailing goes out to a verified list, and updating the group’s composition does not break an already launched series.

Order of work: from data inventory to policy

Segmentation in CRM marketing breaks not on rules but on data: duplicate contacts, empty industry fields, deals in different pipelines, part of the history remains in the manager’s email.

Therefore, we start not with mailing setup but with an inventory of sources — which systems write to the card, how often, and who is responsible for the field. Then the work proceeds in steps with a fixed result at each.

1. Source inventory. We reconcile the CRM, website forms, mailboxes, telephony, and accounting system: which events actually reach the card and which are lost along the way. The output is a list of sources with owners and exchange frequency.
2. Field map. We mark up which fields participate in rules, who fills them in and how, and where empty values are allowed. A field without a filling policy cannot be used in a segment — the selection will “drift.”
3. Schema design. We assemble a tree: static lists for targeted mailings, dynamic rules by deals and activity, exclusions. We check that segments do not overlap where that is not intended.
4. Setup. We create rules, robots, and triggers, link them to mailings, and set the touch frequency and exit procedure from a segment.
5. Testing on a database copy. We run the schema on a test copy of the portal with anonymized data: we look at inclusion, false positives, duplicates, and behavior when a deal status changes.
6. Training and handover of the policy. We provide a document: how to add a segment, who changes a field, and what to do when the pipeline is restructured.

Field maps, trigger rules, and support policy

After segment setup, the client is left not with a set of screenshots but with working documentation that the marketer and administrator use without us. We record everything that changes in the system: custom fields, entity relationships, and group inclusion conditions.

Without this description, editing a field silently breaks the selection — the segment stops being populated, and this is noticed only from a failed mailing.

• Description of fields and relationships. Types, default values, and a note on which fields participate in segmentation conditions; separately — relationships between deal, contact, and company, so that a new pipeline does not remain outside the selection.
• Schemas of groups and trigger rules. Static and dynamic segments, recalculation event, application order, and priority of competing rules.
• Access rights matrix. Which roles view and edit segments, who changes fields and rules, who works only with ready-made selections — the marketer does not rewrite logic, the administrator does not become a single point of failure.
• Instruction for the marketer. Assemble a selection, test on a test group, launch a mailing, collect the result — with examples of typical tasks and an explicit list of actions that break segmentation.
• Update policy. What is reviewed when the pipeline changes, a product group or channel is added, who is responsible, and how often rules are reconciled with the actual data structure.
• Escalation procedure. Where a request goes when figures diverge, what data set to attach (deal number, trigger time, expected and actual value), and within what timeframe we return with an analysis.

We hand over documents in your environment: descriptions — in a knowledge base or repository, schemas — in editable form, not as images. Before handover, we review them with your team — the instruction should be readable by someone who did not participate in the setup.

Case study: open rate increased, unsubscribes decreased by half

The client came with a database of several tens of thousands of contacts, which received one common mailing. There were three segments, they were filled in manually and updated once a quarter — by send time, some attributes no longer reflected the person’s behavior.

The open rate held at around 11–12%, and a noticeable share of unsubscribes came from those who had not opened emails for months.

What was reworked in the rules

Segments were assembled not by profile fields but by actions: opened an email, clicked a link, submitted a request, silent for more than 60 days.

The rules became event-based — a contact changes segment at the moment of action, not during a quarterly review; they live in Bitrix24 CRM marketing.

• inactive contacts are moved to a separate track and receive one win-back email, after which they do not enter the main mailings;
• unsubscribed contacts and spam complainers are excluded from all selections at the rule level, not “manually before sending”;
• frequency is limited to two emails per week per contact, and time overlaps are merged;
• the template is inserted by segment, and manual list export is removed entirely.

Metrics before and after

The team’s workload fell along with the metrics: the marketer stopped being an export operator and started testing hypotheses, while support focused on handling “why did I receive this” requests.

Inactive contacts no longer dilute the main mailings, and repeat sends do not go to those who have already unsubscribed.

How does a dynamic group differ from a static one?

A static group is a saved list of contacts: it changes only manually, and at the moment of fixing you can see how many people are in it.

A dynamic group does not store the composition — it stores a selection rule based on card fields and events, and the list of participants is calculated anew on each access.

In Bitrix24, both tools live side by side but behave differently: in a dynamic one, you cannot add a person outside the condition; in a static one, you cannot get a fresh snapshot without an export.

The composition is recalculated not on a schedule but at the moment the selection is computed: opening a list, launching a mailing, changing a participant’s fields.

If the client changed deal status or the last activity period expired, they drop out of the group automatically, without manual cleanup.

The flip side: if fields are updated rarely, the selection inherits this delay, and some recipients receive a message that is already irrelevant.

The intersection of conditions works as a filter: an “AND” combination narrows the selection to those who meet all conditions at once, while changing the order of “AND”/“OR” branches changes the result.

Traps include an empty value instead of an explicit “not set” and inconsistent input (city, company name): the group silently loses some of the needed participants, and this is noticeable only when reconciling with an export.

A fixation moment is needed where immutability matters: a mailing to an agreed list, manual exclusions, consent to data processing, control measurements of “database as of date.” A workable scheme is to assemble the composition with a dynamic group, fix a snapshot, and then conduct communication using the static one: the rule remains verifiable, and sending is predictable.

Technical concerns: duplicates, load, limitations

A segment is not a ready-made list but a rule by which the selection is recalculated on live data. Therefore, technical concerns come down to duplicates, load, and condition limits — we address each.

Does segment recalculation load the system?

Recalculation runs in the background on a schedule and does not block user work. Time grows with nested conditions and segment intersections — we limit nesting depth and spread heavy selections across a schedule.

Is there a limit to condition complexity?

The limit is set not by the interface but by recalculation time and rule readability. With dozens of conditions, a logic error is no longer visible to the eye — we break it down into several segments with clear names.

Is change history preserved?

The segment composition is versioned: you can see who changed the conditions and when. If a mailing went to the wrong place, we use the history to restore the rule’s state at the needed moment and roll back to the previous version.

Can segment data be exported?

The selection can be exported to a table or transferred to an external system for reporting. We fix the list of fields so that the export does not pull unnecessary personal data.

Let’s discuss the task and come back with an estimate and work plan

To make the review substantive, send a description of the task: which segments are needed, by what attributes the audience is divided, and from which sources data comes — deals, emails, calls, web forms, records from 1C.

On the system side, access will be needed: a portal with rights to CRM marketing and the mailing module, and for segmentation by accounting data — exchange credentials with 1C.

We transmit secrets through a secure channel, grant minimally necessary rights, and revoke them after handover.

Then comes a business conversation: we clarify the logic of conditions, look at how fields are filled in practice, and fix the boundaries — what is included in segment setup and what requires integration improvements. The output is an estimate and work plan with stages and a verification procedure.

• Segment map: which groups are assembled, by which fields, and how often they are recalculated.
• Set of rules: combinations of conditions by deals, stages, activity, and client source.
• Access and role schema: which employees can view and change segments.
• Test environment: we run the rules on real data without affecting production mailings.
• Support instruction: how to add a new segment without breaking neighboring ones.
• Procedure for handing over the result: demonstration on data and transfer of documentation to the responsible employee.

Describe the task — we will come back with an estimate and work plan.