What Is Bloomreach Identity Resolution?
Bloomreach Identity Resolution is the foundational pillar of enterprise customer data platform (CDP) strategy, enabling organizations to unify fragmented customer identities across all touchpoints and devices. This technical deep-dive explores the precise data architecture that allows businesses to eliminate duplicate profiles, achieve real-time identity stitching, and build a true 360-degree customer view that powers personalization at scale.
Understanding the Dual-Identifier Architecture: Hard IDs vs. Soft IDs
The core of Bloomreach’s identity resolution engine rests on a sophisticated dual-identifier system that distinguishes between persistent, authenticated customer identifiers and ephemeral, device-based tracking identifiers. This architectural approach enables the platform to track customers across their entire lifecycle, from anonymous first-touch through registered customer transactions and beyond. Hard IDs represent persistent, authenticated identifiers such as email addresses, customer account numbers, or loyalty program IDs that uniquely identify a known customer in your system. Soft IDs, conversely, represent device-level or session-level identifiers such as browser cookies or mobile advertising IDs that track anonymous or partially-known visitors. The relationship between these two identifier types creates the foundation for real-time identity stitching.
Hard IDs are case-sensitive and immutable identifiers that serve as the primary key for customer profile unification. Every customer can possess multiple hard IDs—for example, both an email address and a customer ID from your backend system—but each hard ID value can only belong to a single customer profile at any given time. This constraint is intentional and critical: it prevents the system from creating duplicate customer records when the same authenticated identifier appears multiple times in your data pipeline. Bloomreach enforces strict validation rules on hard IDs, requiring at least one alphanumeric character and prohibiting null or undefined values. Organizations must implement automatic case normalization (converting all IDs to lowercase) during data import to prevent accidental duplicate profiles caused by case sensitivity variations.
Soft IDs, by contrast, operate under a different constraint model designed to accommodate the multi-device reality of modern customer behavior. A single customer can possess up to 64 soft IDs of the same type—for instance, 64 different browser cookies representing 64 different devices or browsers used by that customer. When a customer exceeds the 64-soft-ID limit, Bloomreach automatically purges the oldest unused soft ID and assigns the new one, ensuring that the system continues to track current device activity while maintaining historical context. This capacity ceiling reflects a pragmatic balance between tracking comprehensiveness and system performance optimization.
The Real-Time Identity Stitching Process: From Anonymous to Known
Real-time identity stitching is the operational mechanism that transforms fragmented behavioral data into unified customer profiles. The process begins the moment a new visitor arrives at your digital property. Bloomreach automatically generates a unique soft ID (cookie) for that visitor, creating an initial customer record in the Single Customer View (SCV) database. This anonymous profile captures all behavioral events—page views, product interactions, cart activities—attributed solely to that soft ID. The profile remains in this anonymous state until the customer performs an authentication action such as logging in, registering an account, or completing a purchase.
When authentication occurs, the system receives a hard ID value (typically an email address or customer ID) through one of three integration pathways: the JavaScript SDK tracking implementation, batch data imports, or API calls. At this critical moment, Bloomreach executes the identity stitching logic. The system searches the customer database for any existing profile already associated with that hard ID. If no profile exists, the hard ID is simply assigned to the current anonymous profile, effectively promoting it from anonymous to known status. If a profile already exists with that hard ID, Bloomreach initiates a customer merge operation, consolidating all behavioral events, properties, and engagement history from the anonymous profile into the existing known profile.
This merge operation follows strict conflict resolution rules. When two profiles merge, properties are resolved hierarchically: newer property values override older ones, but missing properties are never deleted—they are preserved from both profiles to create the most complete customer record possible. Event histories are concatenated, ensuring that all behavioral touchpoints remain intact. A/B test assignments are carefully handled to prevent test contamination, with rules ensuring that merged customers maintain consistent test bucket assignment throughout their journey.
Preventing Duplicate Profiles: Data Architecture Best Practices
Duplicate customer profiles represent one of the most insidious threats to CDP data quality, and they emerge not from platform limitations but from implementation errors in data ingestion pipelines. The most common source of duplicates is incorrect SDK function usage: developers who invoke exponea.update() instead of exponea.identify() inadvertently track customer identifiers into customer properties rather than into hard IDs, preventing the system from recognizing the customer as already known and creating a new profile instead. This seemingly small implementation detail cascades into serious data integrity issues.
Import processes present a second major source of duplicates. When batch importing customer data from external sources, administrators must meticulously verify that identifiers are mapped to the correct ID type (hard vs. soft) and that case normalization is applied consistently. A single email address imported as “John.Doe@example.com” in one batch and “john.doe@example.com” in another batch creates two separate customer profiles, since Bloomreach hard IDs are case-sensitive by design.
Double opt-in workflows create a third, more subtle duplicate scenario. In a typical double opt-in flow, an email address is first tracked as a soft ID (in customer properties) when a user submits a subscription form, creating an initial profile. After the user clicks the confirmation link in the verification email, the system should track that same email as a hard ID (in customer_ids), triggering an automatic merge with the initial profile. If the double opt-in configuration is incorrect, the confirmation step fails to execute the merge, leaving two separate profiles in the system.
Remediation of duplicate profiles requires a multi-step approach. First, identify the root cause by examining where the duplicate data originates: JavaScript SDK tracking, imports, or API calls. Second, correct the source to prevent future duplicates. Third, fix existing duplicates by using the API to track the duplicate identifier into the hard_ids field of the profiles you wish to consolidate, triggering a merge operation. This process is irreversible, so Bloomreach strongly recommends consulting with business consultants before executing large-scale merge operations.
External ID Configuration: Building Your Identity Taxonomy
Bloomreach distinguishes between internal IDs—automatically assigned system identifiers that appear in the URL when viewing customer profiles—and external IDs, which are the identifiers you configure and control. External IDs form the complete identity taxonomy for your project and determine how customers are recognized and unified across your data ecosystem.
A minimal external ID configuration includes two identifier groups: registered (a hard ID typically containing email addresses or customer IDs) and cookie (a soft ID for anonymous tracking). However, advanced implementations may configure unlimited external identifiers to accommodate complex business requirements. A retail organization might configure registered for email addresses, customer_id for backend system identifiers, facebook_id for social media integration, and loyalty_number for offline program integration—all as separate external IDs within the same project.
The external ID configuration determines behavior across multiple critical operations. When creating a new customer, you specify which external ID to use for lookup and creation. When identifying an anonymous customer, you provide both the soft ID (cookie) and the hard ID (registered), triggering the merge operation. When handling multiple devices, the system allows a single customer to accumulate multiple soft IDs under the same hard ID, preserving the complete multi-device journey.
| Scenario | External IDs | Identification Call | Result |
|---|---|---|---|
| Create new customer by hard ID | registered (hard), cookie (soft) | {registered: "user@example.com"} | New customer with external IDs: {'registered': 'user@example.com'} |
| Create new customer by soft ID | registered (hard), cookie (soft) | {'cookie': '123e4567-e89b-12d3-a456-426655440000'} | New customer with external IDs: {'cookie': '123e4567-e89b-12d3-a456-426655440000'} |
| Identify anonymous customer | registered (hard), cookie (soft) | {'registered': 'user@example.com', 'cookie': '123e4567...'} | Customer (previously anonymous) is updated with hard ID and merged |
| Handle multiple cookies | registered (hard), cookie (soft) | {'registered': 'user@example.com', 'cookie': '234e5678...'} | Customer gains second cookie: {'registered': 'user@example.com', 'cookie': ['123e4567...', '234e5678...']} |
| Anonymize customer | registered (hard), cookie (soft) | Anonymization request | All private properties removed, IDs replaced, anonymization event logged |
| Multi-source customer | registered, customer_id, facebook_id | {'registered': 'user@example.com', 'facebook_id': '9876543210'} | Single unified profile with multiple identity anchors across systems |
ID Transformations and Data Normalization
Bloomreach provides automatic transformation capabilities for both hard and soft IDs during data import, addressing the most common data quality issues that lead to duplicate profiles. The trim transformation automatically removes leading and trailing whitespace from identifier values, preventing duplicates caused by inconsistent data formatting in source systems. The lowercase transformation converts all characters to lowercase, solving the case-sensitivity problem that plagues email-based identifiers in particular.
These transformations must be explicitly enabled during import configuration, and they are applied consistently across all imported records. Best practice dictates always enabling lowercase transformation for email-based hard IDs, as email addresses are inherently case-insensitive in real-world usage, yet Bloomreach’s case-sensitive architecture treats “John@example.com” and “john@example.com” as distinct identifiers. Organizations that skip this step inevitably discover duplicate profiles only after significant data accumulation, making remediation exponentially more difficult.
ID Limitations and Architectural Constraints
Understanding Bloomreach’s architectural constraints is essential for designing scalable identity resolution implementations. Hard IDs cannot be deleted or renamed once configured—this is a permanent project-level decision. Soft IDs similarly cannot be converted to hard IDs after initial configuration, though additional soft IDs can be added throughout the project lifecycle. Any identifier must contain at least one alphanumeric character and must never contain the literal strings “null” or “undefined,” as these are reserved system values.
The 64-soft-ID limit per customer represents a deliberate architectural choice optimized for the typical multi-device customer behavior pattern while preventing resource exhaustion from edge cases. Organizations with highly fragmented device ecosystems (such as digital marketing agencies testing across dozens of browsers and devices) may approach this limit, but genuine customer use cases almost never exceed it.
Advanced Identity Resolution Scenarios
Cross-Device Journey Mapping: A customer browses products on desktop (soft ID: cookie_123), later continues on mobile (soft ID: cookie_456), and finally completes purchase after logging in (hard ID: john@example.com). Real-time stitching immediately associates all three touchpoints with the unified profile, enabling attribution models that accurately credit the desktop research and mobile browsing phases that preceded the purchase conversion.
Offline-to-Online Unification: A customer makes an in-store purchase using a loyalty card (hard ID: loyalty_number_789), then later visits the website (soft ID: cookie_234). When they log in with their email (hard ID: john@example.com), the system merges the loyalty card identity with the email identity, creating a complete omnichannel view that includes offline purchase history alongside digital engagement.
Multi-Account Customer Handling: A business customer uses different email addresses for different departments (procurement_dept@company.com, marketing_dept@company.com). Bloomreach supports multiple hard IDs per customer, allowing the system to recognize all departmental email addresses as belonging to the same organizational customer while maintaining separate engagement histories by email if desired.
Identity Resolution and Privacy Compliance
Bloomreach’s identity resolution architecture includes built-in support for privacy regulations including GDPR, CCPA, and emerging global privacy frameworks. Customers can request anonymization, which triggers a comprehensive process: all private customer properties are removed, external IDs are replaced with random UUIDs, private properties of associated events are deleted, and an anonymization event is logged for audit purposes. The system maintains the ability to prevent future identification of that customer while preserving historical data integrity for analytics and compliance purposes.
Why Enterprise Leaders Choose Bloomreach for Identity Resolution
Bloomreach’s identity resolution engine powers 1-to-1 personalization at enterprise scale because it is the only platform that combines real-time stitching accuracy with sophisticated conflict resolution logic. The dual-identifier architecture elegantly handles the complete customer lifecycle from anonymous first-touch through authenticated transactions and ongoing engagement. The automatic merge capabilities eliminate manual identity consolidation workflows, while the built-in duplicate prevention mechanisms ensure data quality without requiring constant remediation.
Organizations implementing Bloomreach Identity Resolution gain immediate competitive advantages: accurate attribution modeling across all touchpoints, elimination of wasted marketing spend from duplicate profile targeting, and the technical foundation for advanced AI-driven personalization through Loomi AI’s predictive capabilities. The platform’s ability to maintain identity consistency across unlimited external data sources—from owned channels like email and mobile apps to third-party integrations like Facebook, Salesforce, and Google Analytics—creates the unified foundation that modern customer experience strategies require.
Getting Started with Identity Resolution Implementation
Successful identity resolution implementation begins with architecture planning: defining your external ID taxonomy, determining which identifiers are hard vs. soft, and establishing data normalization rules. Next, implement proper tracking through the JavaScript SDK using the correct functions (exponea.identify() for hard IDs, exponea.update() for properties), configure your data import pipelines with appropriate case normalization and trimming, and design double opt-in workflows that correctly trigger customer merges.
Finally, establish ongoing data quality monitoring through Bloomreach’s profile usage dashboard and duplicate detection reports. Regular audits of your identity resolution configuration catch implementation errors before they cascade into significant data quality issues. Partner with Bloomreach’s professional services team or certified implementation partners like Voxwise to ensure your identity architecture is optimized for your specific business requirements.
Ready to Master Bloomreach Identity Resolution?
Voxwise is the leading Bloomreach implementation partner, specializing in identity resolution architecture that eliminates duplicate profiles and enables true 360-degree customer views. Our technical experts design and implement identity taxonomies that scale from startups to enterprise organizations with millions of customer records.
Discover how Voxwise can optimize your Bloomreach identity resolution implementation, eliminate duplicate profiles, and unlock the full potential of your customer data platform.