Identity Resolution
Explaining Identity resolution and its key advantages.
Last updated
Explaining Identity resolution and its key advantages.
Last updated
Just imagine how many devices people switch in their daily routines, surrounded by the most advanced technology mankind has ever experienced. Do any of us keep a note on which device we recently viewed any of the products to purchase?
With the boom in digital space, the number of touchpoints through which a customer can interact with a brand has increased considerably in the last few decades. The customer is not confined to a particular channel, device, or platform anymore. While the number of devices and touchpoints has increased, so are the expectations of the customer. Traditional tools like CRM and DMP lack the functionality to track activity across devices.
Identity resolution is the process of attributing events performed by the customer across various touchpoints, platforms, or channels to a single, unified customer profile. This profile can then be accessed to create a more personalized experience to better serve customers.
When an anonymous user visits your website for the first time and performs certain events, CDP stores the Cookie ID or Device ID and creates an anonymous profile for the user, this cookie ID or device ID can then be used when the customer visits the website for the second time or moves another page to create a more personalized experience through banner personalization, web push notification, on-site notification, and notification bot.
If this anonymous user provides any identifiable information like an email address or phone number the identity resolution compares this with the existing data in the CDP.
Existing user - If CDP can map the information with the existing profile, it merges the event information and activities with the existing user to create one view for the customer so that the customer can be targeted even if these events are captured from a different source
New user - If CDP is not able to map the information with any profiles, it creates a new profile for the customer. When the customer performs any new activity in subsequent visits these would be tracked under this profile.
When the user visits from another device or source, say the mobile application, the application source (App SDK) initialises or captures the identifier (say device_ID) and identity resolution performs the same actions as mentioned above to create one unique profile for the customer.
A common source of historical/behavioural or next best offer based customer data is Offline Files. Lemnisk CDP has the capability to ingest huge amounts of customer data via Offline Files stored in SFTP/S3 or any data warehouse.
When user data is ingested from the offline source, the CDP captures each row as a distinct event of user data, where at least one column is marked as the user identifier. The CDP further create unique profiles or stitches profiles based on the other identifer that is ingested.
Lemnisk CDP is extremely versatile in capturing customer data from various sources. One of the commonly used sources by enterprises is the REST API, where the CDP captures user data via real-time, server-to-server API calls. Identity resolution works in a similar fashion here, where stitching takes place if the identifier received in the API call already exists in the CDP.
Provides a single source of truth for customer data, ensuring more accurate and unified customer profiles.
Offers a 360-degree view of the customer, linking interactions across different channels and data sources.
Helps businesses understand customer behavior across multiple touchpoints, both online and offline.
Enables better segmentation and personalization, ensuring more relevant and timely engagement.
Facilitates real-time profile matching and merging, reducing duplication and inconsistencies.
Identity Resolution is the cornerstone of Lemnisk — it's what enables businesses to stitch together fragmented customer data into a unified, single customer view.
Here are the best practices organizations must follow while setting up Identity Resolution during CDP onboarding:
Choosing the identifiers wisely: Clearly define what constitutes a "Unique Customer" based on your business needs. It could be:
Email ID
Phone Number
Customer ID (from CRM)
Loyalty Card Number
Device/Cookie ID (for anonymous users)
Changing identifiers after an account is onboarded and data has started flowing into the production account can be cumbersome and may lead to unnecessary data duplication and merges.
Add multiple data sources: Integrate multiple data sources with CDP and ensure at least one of the identifiers is present and configured with the CDP to maximize the effectiveness of building a golden record.
UAT setup: Before deploying directly to production, it is highly recommended to set up a UAT environment to validate event flows, identity resolution, and data merging. Our team will collaborate with you to create a UAT instance of Lemnisk, allowing you to experiment with new data sources and use cases.
If setting up UAT for all data sources isn't feasible, sending test events from the production system to the UAT account can serve as an alternative to verify data accuracy and stitching before going live.
When multiple user IDs are accessed on a single device during testing, several issues can arise, such as unintended profile merging, misrouted notifications, and missed communications. These problems can lead to inaccurate test results, data inconsistencies, and compromised user experiences.
If best practices are not followed, test accounts may interfere with live user data, resulting in:
Unintended Profile Merges: Persistent session data and cached identifiers can cause separate test accounts to be linked incorrectly.
Misrouted Notifications: Push notifications, emails, and SMS messages may be delivered to the wrong user, leading to confusion and security concerns.
Data Integrity Issues: Overlapping session tokens and push tokens can corrupt test results, making it difficult to validate functionality.
For effective testing, please use the following points as a guide:
Use UAT write keys (source IDs) for Testing
Always use User Acceptance Testing (UAT) account write keys instead of production keys for testing. This ensures that testing does not inadvertently affect live user profiles or production data. Please reach out to your account manager to get the UAT and production keys for your account.
Reset the App and Web Environment Before Testing
For Web Testing:
Use a Different Browser Profile: Creating a separate user profile in your browser helps isolate test sessions from production data.
Open Incognito/Private Mode: This prevents cookies, cache, and stored session data from interfering with testing.
Clear Browser Cache and Cookies: If using incognito mode is not an option, manually clear cache and cookies before starting a new test session.
For Mobile Apps:
Uninstall and Reinstall the App: This resets anonymous IDs and push tokens, preventing unintended profile merges.
Clear Cache and App Data: If a reinstall is not feasible, manually clearing app data may help avoid conflicts.
Use Separate Testing Environments: Conduct tests in a controlled environment to prevent production data contamination.
Implement Unique Test Devices or Simulators
If possible, use different physical devices or virtual test environments for different user IDs. This minimizes conflicts caused by persistent session data and push token overlaps.
As part of the onboarding process, our team will work with you to define the identifiers that are applicable to your business. The identifiers are customizable to suit your business needs.
