Unified Customer Profile in 1C-Bitrix
Imagine a customer ordering a product on the site, then calling the call center from a different number, and later logging in through the app without authorization. The database holds three separate records, and the manager cannot see the full purchase history. On large projects, the duplication rate reaches 15–20% — for 100,000 records, that's up to 20,000 duplicates. This classic problem is solved by establishing a unified customer profile in 1C-Bitrix. We set up such a system turnkey: from table auditing to automatic merging. Over 80 projects integrating Bitrix and Bitrix24 have been completed. Our experienced team of certified 1C-Bitrix developers guarantees a smooth migration. Contact us for a database audit.
Why Is a Unified Profile Important?
Without a unified view, up to 20–30% of revenue is lost. For a client with 50,000 orders per month, duplication leads to 10,000 lost orders annually. Our bitrix deduplication service reduces this to near zero.
Causes of Duplication and User Data Structure
A typical scenario: a user places an anonymous order, then registers, but the guest session is not linked. The system creates a new record in b_user, while old orders remain with USER_ID = 0. If a lead with the same phone is registered simultaneously in the CRM, there are two duplicates. On databases with 500,000+ records, the duplicate percentage reaches 15–20%. We have seen this on projects with thousands of daily orders.
The core operates with two independent entities: user (b_user) and buyer (b_sale_person_type + b_sale_order_user). When an anonymous order is placed, a record is created in b_sale_order with USER_ID = 0 and contact data in the b_sale_order_props_value fields. Upon registration or authorization, orders are linked to a specific USER_ID, but the connection "guest orders → registered user" is not built automatically. Additionally: if the CRM module is installed, each order triggers the OnSaleOrderSaved event, which creates or updates CCrmContact and CCrmDeal entities. Duplication at the b_user level immediately causes duplicate contacts in the CRM. Without intervention, the number of duplicates grows exponentially. Our approach includes a thorough b_user audit to identify all duplicates. Proper CRM integration is essential to prevent future duplicates.
How Does Duplicate Detection Work?
We use deterministic fields and advanced matching. In one case, we reduced duplicate rate from 20% to 0.5%. Implementing bitrix user merge via CUser::Merge ensures consistent results. Our bitrix profile setup includes automated detection scripts.
Profile Merge Mechanism
A unified profile is built through three components:
-
Identification by deterministic fields. Email and phone are the primary merge keys. In the b_user table, the EMAIL and PERSONAL_PHONE fields should be unique (index UQ_USER_EMAIL). The problem is that Bitrix does not prohibit two users from having the same phone if it is stored in user-defined properties via b_user_field.
-
Merging via the user API. When a duplicate is detected, CUser::Merge() is called — this method transfers all orders, subscriptions, bonus points to the master account and deactivates the duplicate. It is important to check dependent tables first: b_sale_order, b_sale_fuser, b_rating_vote, b_forum_user, b_subscribe_subscriber. CUser::Merge documentation Source: Bitrix Developer API
Example merge code
// Merge: all duplicate data is transferred to the master user
$result = CUser::Merge($masterUserId, $duplicateUserId);
if (!$result) {
$GLOBALS['APPLICATION']->GetException();
}
- The b_sale_fuser table (fake user). This is the key table for anonymous sessions. Each guest gets a record in b_sale_fuser with USER_ID = NULL. Upon authorization, the CSaleUser::DoAutoLogin() method should link the FUSER_ID to the real USER_ID. If this step is missed, the cart and incomplete orders remain "suspended" and do not appear in the profile.
User-Defined Fields and Guest Session Linking
Additional customer attributes (date of birth, gender, preferences) are stored in b_uts_user — a table automatically created for user-defined fields (UserTypeEntity with ENTITY_ID = 'USER'). When merging with CUser::Merge(), these data are not automatically transferred — the method copies only the main b_user table fields. It is necessary to manually transfer values from b_uts_user before calling the merge. This order history transfer is critical for data integrity.
The standard handler OnAfterUserAuthorize fires on every login. It is convenient to implement the following:
AddEventHandler('main', 'OnAfterUserAuthorize', function($fields) {
if ($fields['USER_ID'] > 0) {
// Transfer the guest's cart to the authorized user
$fuserId = CSaleUser::GetAnonymousUserID();
CSaleBasket::TransferBasket($fuserId, $fields['USER_ID']);
}
});
Resolving Duplicates with CUser::Merge
On one project with a catalog of 150,000 products, we found 12,000 duplicate profiles. After configuring the merge via CUser::Merge, the entire queue was processed in 4 hours — automated deduplication is 3 times faster than manual methods. The client no longer lost orders; the number of anonymous carts decreased by 87%. CUser::Merge documentation Bitrix Developer API
Why Is a Unified Profile Critical in e-Commerce?
Without merging the customer database, up to 20–30% of revenue is lost — customers leave without seeing order history, managers waste time on manual merging. A configured mechanism provides a unified view, speeds up order processing by 2–4 times, and reduces delivery errors. Maintenance budget savings can reach 40%. For a typical project with 100,000 users, you can save over $5,000 annually. Order an audit of your database — evaluate the savings.
How Does Profile Merging Impact Performance?
Merging via CUser::Merge() is a fairly heavy operation: it overwrites several tables, updates the cache, and triggers agents. On databases with hundreds of thousands of users, the process can take up to 30 seconds per 100 duplicates. On a database of 200,000 users, the full merge completes in about 4 hours. To avoid hanging the user interface, we run the merge as an agent with asynchronous execution. For this, a queue of duplicates is created in a separate table, and the agent processes 100 duplicates per run.
CAgent::AddAgent(
"CMergeAgent::ProcessBatch(100);",
"main",
"N",
60
);
Step-by-Step Merge Algorithm
- Table audit — scan b_user, b_sale_fuser, b_uts_user for duplicates by email and phone.
- Index configuration — add unique indexes on key fields to prevent new duplicates.
- Deduplication script — determine the master account (by registration date or order count) and run CUser::Merge.
- Automation — attach a handler to OnAfterUserAuthorize and an agent for periodic cleanup.
What Is Included in the Work
| Stage | What We Do | Result |
|---|---|---|
| 1. Audit | Scan b_user, b_sale_fuser, b_uts_user for duplicates | Report with duplicate count |
| 2. Design | Determine merge strategy (email or phone) | Logic documentation |
| 3. Implementation | Write deduplication scripts and handler | Working merge mechanism |
| 4. Testing | Run on a database copy | Loss-free protocol |
| 5. Deployment | Launch agent, train staff | Database without duplicates |
Timeline: from 5 to 15 days. Cost is calculated individually, starting from $2,500 for standard setups. Budget savings up to 50%.
Deliverables
- Comprehensive documentation of merge logic and scripts
- Access credentials to all systems and repositories
- Staff training on unified profile management
- Post-launch support for 30 days
Our deliverables include thorough documentation, full access, training, and support. Contact us for integration consultation.
1C-Bitrix Development Expertise
With over 80 projects, our team brings deep 1C-Bitrix development experience, including bitrix profile setup, CRM integration, and custom deduplication solutions. We ensure seamless order history transfer and data consistency.