Why Bitrix24 audience segments fail in mailings
Bitrix24 audience segments are not saved lists but rules that are recalculated against the database.
Until the rule runs, the mailing goes out based on the previous composition: the client has already changed status, yet the email for the next stage arrives to them — or does not arrive to anyone.
Even a small delay on a live database results in emails to the wrong people and distorted open statistics.
More often the filter itself breaks. Conditions are assembled into nested groups with AND/OR logic, and one incorrect combination expands the sample many times over.
An empty field is interpreted either as "not filled" or as "value does not match" — depending on how the field is set up; an extra space, different case, or a phone number in another format removes the client from the segment.
This is how an incorrect contact sample appears: the rule is formally correct, but the right people are not in it.
The second cause is duplicates in the customer database. One person is created from a web form, from correspondence, and from exchange with 1C; one card has no email, while another has a differently spelled name.
The segment includes one and skips the other — the client receives two identical emails or receives none. Errors in trigger conditions add their own: the trigger fires on an outdated deal status and goes out before the manager has recorded the agreement.
In the sales funnel, this is not immediately visible. The manager considers a lead cold, although the mailing simply did not arrive, while marketing sees opens but does not see that part of the database fell out of the sample.
We break down how this is closed: from auditing fields and deduplication rules to checking the segment on a test group before sending.
What changes in the sales department after database setup
A segment in CRM marketing Bitrix24 is a selection rule based on card fields: deal stage, date and amount of the last purchase, industry, source, website activity, email open history.
The condition is recalculated on the system side, so a contact matching the rule enters the sample automatically — no manual export and merging of tables is needed.
Manual contact tagging goes away with it: the manager does not assign tags like "wholesaler" or "repeat purchase"; they are calculated by logic from data already accumulated in the cards.
The accuracy of hitting the client's interests is visible by the share of irrelevant emails — the mailing stops going to the entire list, where some addresses are not targeted.
Next, unsubscribes from mailings decrease: an offer about consumables does not go to someone who bought equipment once and will not return.
The speed of preparing a sample is measured in minutes.
The marketer changes one condition and immediately sees the current slice, while a segment configured once is reused in subsequent campaigns without reassembly — managers do not spend hours filtering the database before each launch.
Separately, there is domain reputation: spam complaints from a non-target audience worsen deliverability, and emails stop reaching those who actually need them.
Static and dynamic segments: comparison of approaches
In CRM marketing, the contact grouping mode determines who receives the email and how predictable the recipient composition is.
A manually fixed list and a segment built by condition solve different tasks — choose based on the frequency of database changes and the requirement for send reproducibility.
| Option | When it fits | Limitations |
|---|---|---|
| Static mailing list | One-off events, manual samples, participants of a specific deal | New contacts do not enter it; the composition is maintained manually; as the database grows, addresses become outdated |
| Dynamic segments | Regular scenarios: deal stage, source, activity, tags | Recalculation runs on a schedule, so between launches the composition is outdated; compound conditions across several fields make the calculation heavier |
| Segment snapshot for a campaign | Reproducibility is needed: composition frozen on the send date | The snapshot does not update itself, and it has to be reassembled for each new wave |
The main limitation of segmentation is noticeable precisely as the database grows: the more contacts and the more compound the filter, the greater the discrepancy between scheduled launches.
Recalculation across several fields with activity history may take longer than the campaign itself, so we keep conditions simple and move heavy samples into a snapshot.
We separately monitor overlaps: one contact often falls into several conditions at once, and without priorities and exclusions they receive extra emails.
Setup stages: from database audit to scenario verification
Segmentation in CRM marketing starts not with the interface but with data.
If cards contain different spellings of the same city, empty required fields, and duplicates by phone, any selection condition will assemble a junk sample — the mailing will go to the wrong people, and the report will show false conversion.
Therefore, the order of work is fixed: first we look at what is in the database, then we design attributes, and only then we assemble rules.
- Customer database audit — export a slice of contacts, companies, and deals, calculate the share of filled fields, look for duplicates by phone and email, check whether sources are labeled. The output is a map: which attributes are missing and where data contradicts each other.
- Field and attribute schema — decide where each attribute lives: a standard field, a custom field, or a calculated value from a related entity. We immediately fix filling rules; otherwise the segment will "drift" in a month.
- Attribute autofill — some data comes from forms, some is set by robots and rules when the stage changes. Without this, new leads have empty fields, and the segment does not see them.
- Assembling selection conditions — the rule builder: set of fields, operators, nested AND/OR groups, mandatory exclusions for unsubscribes, duplicates, and inactive companies.
- Test contact sample — we check each segment on 20–50 records: manually verify inclusion and exclusion, and achieve the counter matching expectations.
- Mailing scenario verification — a run on test addresses: launch conditions, touch frequency, email chain, correctness of the opt-out link and repeat triggers.
- Handover and training — we hand over the segment map, attribute update regulations, and a memo on edits; we go through with the marketer how to create a new segment without a developer.
The order matters: a skipped data audit almost always returns as reworking conditions after launch, when the database has already been mailed.
Trigger rules, filters, and regulations for working with the database
A segment lives not by the setup itself but by the agreement on who changes it and when. If an employee renames a field, the sample changes silently, and the mailing goes to the wrong people.
Therefore, the handover package includes a segment description: what remains in the system and by which document the logic can be reassembled.
- Rule trigger conditions — a list of events by which a contact enters or falls out of the segment: deal stage change, field completion, absence of activity over a period. With priorities so that when overlapping, one predictable rule fires.
- Customer card filters — saved sets of conditions by source, stage, deal amount, tags, and activity. With a note on which fields are required: an empty value cuts the contact out of the sample.
- Employee access separation — a rights matrix: who sees the segment database, who exports contacts, who changes rule conditions, who works only with reports.
- Database maintenance regulations — frequency of segment reassembly, duplicate merging, processing of unsubscribes and inactive contacts, record retention period.
- Instructions and relationship map — how to add a condition, check it for conflict with existing ones, and roll back a change; which mailings rely on the rule and will stop if it is disabled.
Each item is a saved setting in Bitrix24 or a file next to it: a list of rules with priorities, filters, rights matrix, regulations, and instructions. Segmentation logic is reproduced from them without waiting for the setup author.
Implementation breakdown: fewer irrelevant emails and blocks
Before: mailing to the entire database
The client — a retail chain with a database of several tens of thousands of contacts — sent campaigns to the entire export: there were no segments, and the list before each mailing was assembled manually in a spreadsheet.
The manager spent 3-4 hours verifying, some addresses got into the email twice, and buyers of one category received offers for completely different ones.
The share of erroneous recipients reached 27%, 30-40 complaints about mailings arrived monthly, and mail services increasingly classified the emails as bulk unwanted.
After: segments that reassemble themselves
The database was labeled in Bitrix24 by rules: purchase history, activity in the deal card, consent to mailing, and recency of the last order.
The segment is reassembled automatically before campaign launch, and an unsubscribe or complaint removes the address from the sample within a day — manual list verification is no longer needed. Sample preparation takes 10-15 minutes instead of the previous hours.
The share of erroneous recipients fell to 3%, and the number of complaints to 2-3 per month, so emails again reach the main part of the database. Repeat sales grew by about a third: the offer lands in the segment where this category has already purchased.
How contact groups differ from mailing lists
A contact group is not a storage of people but a saved selection rule. Inside is a condition: a set of card fields, values, and logical links.
The composition is recalculated every time the group is accessed or according to regulations, so a client whose status or industry changed falls out of the segment automatically.
The attribute itself remains in the card — in standard or custom fields that you created for your data model.
A mailing list is structured differently: it is a static set of addresses fixed at the moment of assembly. The attribute "is in the list" is stored not in the card but in the link between the contact and the list itself.
You can get there manually or by an automation rule action, and you can leave only if the record is deleted.
Hence the difference in condition recalculation. A group reflects the current state of the database: change the filter — the composition changes.
A list reflects the state at the moment of assembly and then lives its own life, accumulating those who have already unsubscribed or changed address.
Sample overlap behaves differently in the same way. A contact can be in several groups at once, and the overlap is calculated on the fly by fields, without duplicates.
Two lists can contain the same address, and duplicates will have to be cut off with a separate filter at send time.
Practical conclusion: keep the client attribute in a card field and build the group by that field — then the segment updates itself. Leave the list where strict volume control is needed, for example manual confirmation of campaign participation.
Technical doubts before starting setup
Before launching segmented mailings, the same questions come up — they concern not the interface but the logic of samples. Below are short answers; if the database was assembled from several sources, start with the last block.
A contact fell into two segments at once — which email will they receive?
Sample overlap is a normal situation; segments do not exclude each other. The order is set at the campaign level: either conditions are applied sequentially and the last segment overrides the previous one, or an exclusion for already processed contacts is added to the filter. Without an explicit rule, the contact receives two emails minutes apart.
Does a contact without a deal participate in the sample?
Yes — if the segment is built by the "Contact" entity and not "Deal". Conditions by stage, amount, and responsible person work only where there is a link to a deal, so such records fall out of the sample.
A working technique: assemble a broad segment by contacts, and identify groups by deal history inside it with separate conditions.
What to do with a fragmented contact database?
Merging sources is done before setting up segments: records are consolidated by a normalized key — phone or email — and duplicates are removed. Otherwise one person passes through two cards, receives two mailings, and statistics are split in half.
Import after setup requires reassembling conditions — therefore the order of work is: first merging, then logic.
Let's discuss the task: how to start setup in your case
To make the estimate substantive rather than "by eye", at the start a short set of input data is enough. Collect it in advance — then the first conversation is about the segmentation schema, not about clarifying the inputs.
- which fields and reference books are already filled in contact, company, and deal cards;
- by which attributes you currently divide clients: purchase amount, date of last deal, source, industry;
- which mailings and scenarios are already launched and what data they rely on;
- database volume: how many contacts in total and what share of them are active;
- which channels are involved and whether there are consents for communication on each;
- who on the customer side is responsible for marketing and approves texts;
- access: a test portal or a role with a limited set of rights instead of full administrator.
The first conversation takes about an hour: we break down the current database structure, look at which segmentation rules are already working and where data is incomplete.
As a result, we return with a segmentation work plan — which rules we set up first, how we check contacts entering each segment, and how not to break existing scenarios.
Access handover happens after the plan is approved: first a test portal or a separate role, then the production environment with change logging. Describe the task and attach what already exists — we will return with an estimate and order of work.