End-to-end customer identification in 1C-Bitrix: where the link breaks
A customer submits a request from the website under one email, then messages from their phone, and the manager manually creates a card in the CRM using the name from the chat.
A month later, the same person places an order in their account under a third set of data — and three unlinked profiles appear in the system.
End-to-end customer identification in 1C-Bitrix is needed precisely so that these records converge into a single profile rather than existing in parallel.
Profile fragmentation begins at the junction of channels. A feedback form, online chat, a call via telephony, an order from the catalog, and a conversation in Bitrix24 write data into different entities: lead, contact, company, user.
Each has its own set of fields and its own deduplication logic, so automatic merging rarely triggers — there is a match by email, but no longer by phone.
Duplicate customers hit the sales department directly. A manager calls back someone who has already purchased, doesn't see the history of inquiries, and doesn't know about an open deal held by a colleague.
In reports, one customer is counted as three, conversion and average order value are distorted, and repeat sales are missed because no one tracks returns.
A unified customer profile is built on a bundle of keys: phone, email, order number, account identifier, and external tags from ad platforms.
The task is not just to merge cards, but to establish a rule by which new inquiries are attached to an existing profile rather than spawning a fourth one. Let's break down how this works at the level of exchange between the website, Bitrix24, and the accounting system.
What a unified customer profile across the website and CRM provides
Speed of request processing
A unified customer profile is assembled from website events, forms, calls, and correspondence, rather than from a single form.
When a visitor identifier is linked to a CRM card, the manager sees the history of interactions before the first contact: which pages were viewed, what was requested, whether they were already a customer.
A request stops being a "cold" email — it takes less time to review because there is no need to clarify the context.
Share of lost requests
The main cause of losses is not customer rejection, but the gap between channels: a website request, a call, and an email live in different places and are not linked to each other.
End-to-end identification closes this gap — an interaction from any channel lands in a single profile, and none remains without an owner.
The share of lost requests falls not because of "manager discipline," but because the system physically does not allow a request to remain unassigned.
Class of errors during data merging
Merging profiles is the riskiest part: with incorrect matching, two customers turn into one, and one customer's history goes to the other.
That is why merging rules are built on confirmed attributes (phone, email, contract number), while questionable matches go to manual review rather than being merged automatically.
This approach eliminates the class of errors that is most costly in support — confusion in the service history and repeat sales to existing customers.
Ways to link a visit, a lead, and a deal: comparison of approaches
When it comes to linking profiles, the "way" is primarily the choice of the key by which we merge records. It determines where the chain of touchpoints breaks and how much manual work falls on operators. Below are working alternatives that are actually chosen between on projects.
The key as the basis for merging
A phone number gives the best match rate for B2C: it is almost always present in the lead and in the CRM. The limitation is normalization: different recording formats, extensions, calls from landline numbers.
Without bringing them to a unified form, linking profiles produces false merges. Email is more resistant to format, but is filled in less often in calls and at offline points.
An internal customer identifier is the most reliable option if it has already been assigned at the entry point: in the form, at registration, in the order. Then the visit, the lead, and the deal reference a single record without heuristics.
The chain of touchpoints as a key works differently — it links events by time and context when there is no explicit identifier.
| Approach | When it fits | Limitations |
|---|---|---|
| By phone number | B2C, many calls, leads with a phone | Normalization needed, false merges with shared numbers |
| By email | Online leads, B2B correspondence | Rarely filled in during calls and offline |
| By internal identifier | There is registration or an end-to-end order number | Requires assignment at the first touchpoint |
| By chain of touchpoints | No explicit key, long deal cycle | Lower accuracy, rule configuration needed |
In practice, they are most often combined: phone as the primary key, email and internal identifier as clarifying ones, and the chain of touchpoints fills the gaps. Such a hybrid reduces the share of unlinked leads and does not require rewriting accounting systems.
How we build identification: stages of work
We start with an inventory: which systems already store customer data and by which attributes they can be matched. Without this step, any linking scheme is built on guesses and falls apart at the first identifier conflict.
- Audit of sources. We compile a list of systems — website, CRM, accounting system, forms, call tracking, mailings — and for each one record which identifier it provides: phone number, email, order number, internal ID. Separately, we note where an attribute is normalized and where it is stored "as entered."
- Linking scheme. We design a graph: nodes are customers, edges are matching attributes with a confidence weight. We define the profile merge rule and the split rule in case a match turns out to be false.
- Normalization and matching rules. We bring phone numbers to a single format, clean emails, and set source priority. Here we also decide which attributes we consider strong and which are auxiliary.
- Implementation of linking. We embed the logic into the data exchange between the website and the accounting system: an event on the website creates or updates a profile rather than spawning a duplicate. We make processing idempotent — a repeated run must not break the links.
- Scenario testing. We run end-to-end paths: a form submission, a call, a repeat inquiry, a purchase from another device. We check that the history is assembled into a single profile and is not lost during an exchange failure.
- Handover of regulations. We provide documentation on merge rules, integration points, and the procedure for resolving conflicts so that support can work without us.
Each stage ends with a verifiable result, not a report. If the audit shows that a source provides garbage attributes, we say so honestly before the start — otherwise end-to-end customer identification in 1C-Bitrix will turn into a graph of duplicates.
What the client receives upon delivery after implementation
Implementing end-to-end identification is not a "set it and forget it" affair, but a set of artifacts by which the system lives and evolves without its author.
Below is what exactly remains with your team after handover, so that support can be carried out on your own or handed off to another contractor without archaeology through the code.
- Matching configurations — profile merge rules: which attributes link records (phone, email, order number, CRM identifier), which source has priority in a conflict, what to do with incomplete data. Exposed in an editable form rather than hardcoded.
- Identity graph — a map of entities and edges: customer, deal, order, ticket, visit. It shows where the merge point is, where the master record is stored, and how updates propagate.
- Access policies — which roles see the merged profile, which see only a segment, which fields are masked. Segregation at the level of Bitrix roles and 1C accounts.
- Merge and split procedures — the sequence of actions for an erroneous merge: how to roll back a merge without losing history, who makes the decision, and within what timeframe.
- Integration documentation — the exchange points between the website, Bitrix24, and 1C, the formats of transmitted data, the synchronization schedule, and behavior when one of the parties is unavailable.
- Guide for marketing and support — how to read the merged profile, where to view the source of an attribute, how to verify that a customer was merged correctly.
- Link quality monitoring — a set of checks: the share of unlinked records, duplicates, discrepancies between systems. With a report that reveals degradation before it reaches analytics.
Each artifact is handed over in working order and with an owner assigned to it. Describe your task — we will come back with an estimate and a plan for what from this list can be covered immediately and what in stages.
Case study: how a unified profile reduced the share of lost requests
The project is a network of service centers with booking via the website, a personal account, and request processing in 1С.
Before the introduction of end-to-end identification, a request from the website, a call, and a repeat inquiry from the personal account existed as three different clients: the manager saw three cards, and there was nothing to pull up the history with.
What the analysis showed
Records were linked by normalized phone number, email, and contract number; conflicts were resolved by a priority rule — contract over phone, phone over email. Each client was assigned a stable internal identifier, which is set on any touchpoint: form, call, email, order in 1С.
Duplicates were not deleted blindly — disputed matches were placed in a queue for manual review so as not to merge two different people sharing a corporate number.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Share of duplicates in the database | about 18% | 3-4% |
| Response time to a repeat inquiry | 40-60 minutes | 5-10 minutes |
| Requests without client history | every third | isolated cases |
A separate class of errors also disappeared, the one that cost the most: a manager would call a client with an offer that the client had already declined in a previous inquiry.
After profiles were linked, such calls stopped — the history is pulled into the card before the first contact.
The merging was done on the 1C-Bitrix side with synchronization to 1С, so the data does not diverge between the website and the accounting system.
How does end-to-end identity resolution differ from simple contact synchronization?
Contact synchronization transfers fields from one system to another: name, phone, email, deal. End-to-end identity resolution solves a different problem — it establishes that the same person stands behind these records and preserves that connection even when the data diverges.
The difference between the approaches shows up not at the moment of exchange, but at the moment when a customer arrives with a new contact or under a different name.
Simple synchronization works by key matching: a match is found — the record is updated, no match — a new one is created. This is how duplicates appear, and the history breaks apart into several cards.
End-to-end identity resolution builds stable links between profiles: it matches records by a combination of attributes, merges them into a single profile, and stores match weights.
The phone may have changed, the email may have stayed the same, but the connection between a website visit, a call, and a purchase is not lost.
The practical consequence lies in analytics and in working with the customer. With synchronization, a report will show three inquiries as three different people, and the manager will not see that the customer has already purchased.
With end-to-end identity resolution, all touchpoints are consolidated into a single profile: you can see which channel the first interest came from, how much time passed before the deal, and what happened in between. This is the difference between the approaches — exchanging data versus establishing connections.
Another difference is resilience to change. Synchronization breaks when the export format changes, a field is renamed, or a new source appears: the connection has to be set up again.
End-to-end identity resolution relies on matching rules and accumulated connection history, so a new source is connected as just another node, not as a separate integration. The customer profile remains intact when channels, employees, and the structure of reference data change.
Common technical concerns when implementing
End-to-end customer identification in 1C-Bitrix almost always lands on an already running project: with an accumulated database, legacy integrations, and custom modules.
That's why the customer's concerns are usually not about the idea itself, but about how it will coexist with what already exists. Below is a breakdown of typical technical questions that come up before the start.
Will this break the current site and the exchange with 1C?
Profile merging happens in a separate layer: matching is performed based on events, not by rewriting existing entities. Users, orders, and documents stay in place; only the linking logic changes.
The exchange with 1C continues to work according to the same rules — the new layer merely supplements it with a customer identifier.
Will it handle the load under high traffic?
Matching is moved to a queue and processed in batches, rather than at the moment of a user request. Hot operations — lookup by identifier — go through indexes, so response time doesn't grow along with the database. During peak loads, the queue is drained asynchronously, and the site doesn't wait.
How is the issue of security and data access resolved?
Personal data is stored in the same perimeter as before — without moving it to third-party services. Access is delimited by roles, and all matching operations are logged: you can see which records were merged and on what basis. This simplifies audits and the investigation of disputed cases.
What should be done with legacy systems and old databases?
Legacy sources are connected via adapters: some data is migrated once, some — on a schedule. Duplicates and "dead" profiles are cleaned up gradually, without stopping operations.
If a source is disconnected, the others continue matching — the system doesn't depend on a single channel.
If your case isn't on the list — describe your current architecture, and we'll come back with an estimate and a plan tailored to it.
Let's discuss your task and come back with a plan
To offer a solution without generic words, we need the context of your system: how your data sources are currently structured, where your customer base is stored, and which channels are already collecting contacts.
Describe the task in free form — we will analyze the current identification scheme, find the gaps between systems, and come back with an estimate and a work plan.
The more specific the input, the more precise the proposal: there are no universal templates here, and every configuration has its own bottlenecks.
What to include in the description:
- which systems are involved in customer accounting — website, CRM, 1С, warehouse, support service;
- how records of the same person from different sources are currently linked: by phone, email, order number, or manually;
- which channels bring in inquiries — website forms, calls, messengers, offline locations;
- whether there are duplicates and how you currently find and merge them;
- which reports are needed as output — by customer revenue, by repeat purchases, by funnel;
- which access and personal data restrictions apply in your company;
- what you have already tried and why the result was unsatisfactory.
Based on this input, we will determine the scope: where matching rule configuration is sufficient, and where improvements to data exchange between systems are needed.
In response, you will receive a diagram of connections between sources, a list of stages in order, and an understanding of which data will need to be exported at the start.
Describe the task — we will come back with an estimate and a plan showing what we do and in what sequence.