# Identity Resolution Basics ### About this export | Field | Value | | --- | --- | | **content_type** | lesson | | **platform** | contentstack-academy | | **source_url** | https://www.contentstack.com/academy/courses/lytics-essentials/identity-resolution-basics | | **course_slug** | lytics-essentials | | **lesson_slug** | identity-resolution-basics | | **markdown_file_url** | /academy/md/courses/lytics-essentials/identity-resolution-basics.md | | **generated_at** | 2026-04-28T06:55:47.719Z | > Part of **[Lytics Essentials](https://www.contentstack.com/academy/courses/lytics-essentials)** on Contentstack Academy. **Academy MD v3** — structured for retrieval; no quiz or assessment keys. #### Video details #### At a glance - **Title:** Advanced Identity Resolution-Overview - **Duration:** 6m 46s - **Media link:** https://cdn.jwplayer.com/previews/11mVV7bx - **Publish date (unix):** 1751360800 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113474 kbps - video/mp4 · 180p · 248p · 151566 kbps - video/mp4 · 270p · 372p · 175242 kbps - video/mp4 · 360p · 496p · 201927 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/11mVV7bx-120.vtt` #### Transcript Today, we're going to cover ID resolution and LQL. At a high level, what we're going to do is we're going to explain what ID resolution means and then how we can create good ID resolution using LQL as a vehicle for that. Just as a reminder, LQL stands for Lytics Query Language. This is something you're going to hear throughout the videos. It's going to be a very important term to remember. What LQL is responsible for is transforming and mapping the data onto user profiles. What it's also responsible for is instructing us how to stitch information to a user profile by using identifiers. What an identifier is, is a unique field that we can find in the streams that's going to instruct us about that person, whether that be an email, an account ID, a customer ID, etc. Right? Our high level goal that we're really trying to accomplish is that we want to be able to merge data that comes in from multiple sources onto the same user profile. What this means is if a user lives in each one of these systems that lives upstream from Lytics, we want to be able to merge all of this data onto the same profile. The more information we're able to merge onto a profile, the more enriched that profile becomes, the more educated that profile becomes for activation. If we have an enriched profile that has had information from multiple sources, we have a bigger, a more fuller picture of what that user is doing and how they are interacting with the current ecosystem. The first place that we're going to start when we talk about ID resolution is we're going to talk about LQL and how it plays a part in our ID resolution strategy. In the LQL file, we have what are called by fields. You might hear this term throughout the video, so just get yourself familiar with it. What a by field is, is a unique identifier per source. We need all of our by fields, or at least some of them, in each file to be found in another source. If we do not have some sort of overlap between the sources' unique identifiers, there will be no way for us to instruct them on how to merge together. Essentially, if we have a siloed source come in, we'll only be able to create profiles off of the identifiers we see in that source. We will be unable to merge that information across the different profiles. A really good example of this is going to be our anonymous to known use case, a really strong use case that can be very, very valuable when activating on the web for users. We're going to go through a high level example of how we can handle an anonymous to known profile merging through the LQL by fields, as well as through making sure that we are well aware and scoped out the ecosystem that's coming into Linux and how to activate on that. The first place we're going to start is at example number one. Example number one is going to show us the two different kinds of events that we're going to receive from two different sources. Event one here, event one is going to be a web event that we receive that's a page view. In that page view, we will receive a cookie and we will receive a URL. That information is going to come into Linux and hit our LQL. What our LQL by field says that the cookie is actually a unique identifier for a person or a user on the site. What this then instructs Linux to do is create a graph node in our graph database for that user itself, where then the information that came in on that event is stored with that node. So essentially this becomes your user profile. The next event that comes in is a CRM event that can come in from a registration event. So let's say that a new user comes into the CRM. That information is coming in as a new user event type. The email is coming in, the first name and the last name. This is going to hit our CRM LQL file, right? In that LQL file that sits somewhere in between, it's going to instruct the system that the email itself is the unique identifier for that source. So what that tells us is we need to create a profile for this user with the information that is coming from that source. Finally, we have an event coming in from the web, right? And this is key event. This is a very, very important concept here, right? And what this means is that a user has gone onto the website and subscribed. And that information gets sent to Linux and mapped, and we expected it. So we see an email and we see a cookie, we see a URL, and we'll obviously see a little bit more information, right? Some more colorful attributes associated to this event. This event is going to come in and it's actually going to look for any existing graph nodes where those by-fields already exist. And in the web LQL, it says that both the cookie and email can in fact be unique identifiers. So that instructs our graph nodes then to create a node where those two identifiers exist if they do not already. It then does the process that we call stitching, where it goes and looks for nodes that share one to many of the identifiers that already live in this node itself. Once we've stitched it together, right, this then becomes our profile. And it merges the data information from here into a singular profile. So now this profile not only has known information from the CRM, but also anonymous activity from the web layer itself. As you can see, that's super, super powerful, especially if they are traversing the web for three to six months without any known information. And then we're able to stitch that information to a email. So we can activate on all of that additional web activity in an email campaign or an ad campaign or use that information to personalize on the web. So from a high level, what we're really looking for here is that we have a strong ID resolution strategy that allows us an in-depth overlap in the different sources that we're bringing into Lytx so that we can merge that information together and have a more educated user profile. #### Subtitles (WebVTT) ```webvtt WEBVTT 1 00:00:00.000 --> 00:00:05.160 Today, we're going to cover ID resolution and LQL. 2 00:00:05.160 --> 00:00:09.340 At a high level, what we're going to do is we're going to explain what ID resolution 3 00:00:09.340 --> 00:00:16.500 means and then how we can create good ID resolution using LQL as a vehicle for that. 4 00:00:16.500 --> 00:00:21.980 Just as a reminder, LQL stands for Lytics Query Language. 5 00:00:21.980 --> 00:00:24.020 This is something you're going to hear throughout the videos. 6 00:00:24.020 --> 00:00:27.380 It's going to be a very important term to remember. 7 00:00:27.380 --> 00:00:33.540 What LQL is responsible for is transforming and mapping the data onto user profiles. 8 00:00:33.540 --> 00:00:40.260 What it's also responsible for is instructing us how to stitch information to a user profile 9 00:00:40.260 --> 00:00:42.540 by using identifiers. 10 00:00:42.540 --> 00:00:47.200 What an identifier is, is a unique field that we can find in the streams that's going to 11 00:00:47.200 --> 00:00:53.300 instruct us about that person, whether that be an email, an account ID, a customer ID, 12 00:00:53.300 --> 00:00:54.300 etc. 13 00:00:54.300 --> 00:00:55.300 Right? 14 00:00:55.740 --> 00:01:00.100 Our high level goal that we're really trying to accomplish is that we want to be able to 15 00:01:00.100 --> 00:01:06.300 merge data that comes in from multiple sources onto the same user profile. 16 00:01:06.300 --> 00:01:11.500 What this means is if a user lives in each one of these systems that lives upstream from 17 00:01:11.500 --> 00:01:16.620 Lytics, we want to be able to merge all of this data onto the same profile. 18 00:01:16.620 --> 00:01:21.900 The more information we're able to merge onto a profile, the more enriched that profile 19 00:01:21.900 --> 00:01:27.020 becomes, the more educated that profile becomes for activation. 20 00:01:27.020 --> 00:01:31.620 If we have an enriched profile that has had information from multiple sources, we have 21 00:01:31.620 --> 00:01:37.300 a bigger, a more fuller picture of what that user is doing and how they are interacting 22 00:01:37.300 --> 00:01:40.020 with the current ecosystem. 23 00:01:40.020 --> 00:01:43.620 The first place that we're going to start when we talk about ID resolution is we're 24 00:01:43.620 --> 00:01:49.780 going to talk about LQL and how it plays a part in our ID resolution strategy. 25 00:01:49.780 --> 00:01:54.660 In the LQL file, we have what are called by fields. 26 00:01:54.660 --> 00:02:01.580 You might hear this term throughout the video, so just get yourself familiar with it. 27 00:02:01.580 --> 00:02:05.740 What a by field is, is a unique identifier per source. 28 00:02:05.740 --> 00:02:11.740 We need all of our by fields, or at least some of them, in each file to be found in 29 00:02:11.740 --> 00:02:13.140 another source. 30 00:02:13.140 --> 00:02:18.260 If we do not have some sort of overlap between the sources' unique identifiers, there will 31 00:02:18.260 --> 00:02:22.540 be no way for us to instruct them on how to merge together. 32 00:02:22.540 --> 00:02:28.060 Essentially, if we have a siloed source come in, we'll only be able to create profiles 33 00:02:28.060 --> 00:02:30.940 off of the identifiers we see in that source. 34 00:02:30.940 --> 00:02:36.420 We will be unable to merge that information across the different profiles. 35 00:02:36.420 --> 00:02:41.440 A really good example of this is going to be our anonymous to known use case, a really 36 00:02:41.440 --> 00:02:48.140 strong use case that can be very, very valuable when activating on the web for users. 37 00:02:48.140 --> 00:02:53.380 We're going to go through a high level example of how we can handle an anonymous to known 38 00:02:53.380 --> 00:03:00.700 profile merging through the LQL by fields, as well as through making sure that we are 39 00:03:00.700 --> 00:03:07.220 well aware and scoped out the ecosystem that's coming into Linux and how to activate on that. 40 00:03:07.220 --> 00:03:11.560 The first place we're going to start is at example number one. 41 00:03:11.560 --> 00:03:15.020 Example number one is going to show us the two different kinds of events that we're going 42 00:03:15.020 --> 00:03:18.120 to receive from two different sources. 43 00:03:18.120 --> 00:03:23.840 Event one here, event one is going to be a web event that we receive that's a page view. 44 00:03:23.840 --> 00:03:28.080 In that page view, we will receive a cookie and we will receive a URL. 45 00:03:28.080 --> 00:03:31.800 That information is going to come into Linux and hit our LQL. 46 00:03:31.800 --> 00:03:37.800 What our LQL by field says that the cookie is actually a unique identifier for a person 47 00:03:37.800 --> 00:03:39.800 or a user on the site. 48 00:03:39.800 --> 00:03:45.400 What this then instructs Linux to do is create a graph node in our graph database for that 49 00:03:45.400 --> 00:03:51.280 user itself, where then the information that came in on that event is stored with that 50 00:03:51.280 --> 00:03:52.360 node. 51 00:03:52.360 --> 00:03:56.340 So essentially this becomes your user profile. 52 00:03:56.340 --> 00:04:02.380 The next event that comes in is a CRM event that can come in from a registration event. 53 00:04:02.380 --> 00:04:05.680 So let's say that a new user comes into the CRM. 54 00:04:05.680 --> 00:04:10.120 That information is coming in as a new user event type. 55 00:04:10.120 --> 00:04:15.480 The email is coming in, the first name and the last name. 56 00:04:15.480 --> 00:04:19.160 This is going to hit our CRM LQL file, right? 57 00:04:19.160 --> 00:04:25.880 In that LQL file that sits somewhere in between, it's going to instruct the system that the 58 00:04:25.880 --> 00:04:30.280 email itself is the unique identifier for that source. 59 00:04:30.280 --> 00:04:35.600 So what that tells us is we need to create a profile for this user with the information 60 00:04:35.600 --> 00:04:38.320 that is coming from that source. 61 00:04:38.440 --> 00:04:42.480 Finally, we have an event coming in from the web, right? 62 00:04:42.480 --> 00:04:44.160 And this is key event. 63 00:04:44.160 --> 00:04:48.240 This is a very, very important concept here, right? 64 00:04:48.240 --> 00:04:53.560 And what this means is that a user has gone onto the website and subscribed. 65 00:04:53.560 --> 00:04:57.900 And that information gets sent to Linux and mapped, and we expected it. 66 00:04:57.900 --> 00:05:03.000 So we see an email and we see a cookie, we see a URL, and we'll obviously see a little 67 00:05:03.000 --> 00:05:04.280 bit more information, right? 68 00:05:04.280 --> 00:05:07.860 Some more colorful attributes associated to this event. 69 00:05:07.860 --> 00:05:14.020 This event is going to come in and it's actually going to look for any existing graph nodes 70 00:05:14.020 --> 00:05:17.860 where those by-fields already exist. 71 00:05:17.860 --> 00:05:24.380 And in the web LQL, it says that both the cookie and email can in fact be unique identifiers. 72 00:05:24.380 --> 00:05:30.600 So that instructs our graph nodes then to create a node where those two identifiers 73 00:05:30.600 --> 00:05:33.180 exist if they do not already. 74 00:05:33.180 --> 00:05:37.460 It then does the process that we call stitching, where it goes and looks for nodes that share 75 00:05:37.460 --> 00:05:42.300 one to many of the identifiers that already live in this node itself. 76 00:05:42.300 --> 00:05:46.980 Once we've stitched it together, right, this then becomes our profile. 77 00:05:46.980 --> 00:05:53.940 And it merges the data information from here into a singular profile. 78 00:05:53.940 --> 00:06:01.140 So now this profile not only has known information from the CRM, but also anonymous activity 79 00:06:01.140 --> 00:06:03.340 from the web layer itself. 80 00:06:03.340 --> 00:06:08.460 As you can see, that's super, super powerful, especially if they are traversing the web 81 00:06:08.460 --> 00:06:12.300 for three to six months without any known information. 82 00:06:12.300 --> 00:06:16.620 And then we're able to stitch that information to a email. 83 00:06:16.620 --> 00:06:22.780 So we can activate on all of that additional web activity in an email campaign or an ad 84 00:06:22.780 --> 00:06:27.440 campaign or use that information to personalize on the web. 85 00:06:27.440 --> 00:06:32.620 So from a high level, what we're really looking for here is that we have a strong ID resolution 86 00:06:32.620 --> 00:06:38.380 strategy that allows us an in-depth overlap in the different sources that we're bringing 87 00:06:38.380 --> 00:06:44.620 into Lytx so that we can merge that information together and have a more educated user profile. ``` ```transcript [00:00] Today, we're going to cover ID resolution and LQL. [00:05] At a high level, what we're going to do is we're going to explain what ID resolution [00:09] means and then how we can create good ID resolution using LQL as a vehicle for that. [00:16] Just as a reminder, LQL stands for Lytics Query Language. [00:21] This is something you're going to hear throughout the videos. [00:24] It's going to be a very important term to remember. [00:27] What LQL is responsible for is transforming and mapping the data onto user profiles. [00:33] What it's also responsible for is instructing us how to stitch information to a user profile [00:40] by using identifiers. [00:42] What an identifier is, is a unique field that we can find in the streams that's going to [00:47] instruct us about that person, whether that be an email, an account ID, a customer ID, [00:53] etc. [00:54] Right? [00:55] Our high level goal that we're really trying to accomplish is that we want to be able to [01:00] merge data that comes in from multiple sources onto the same user profile. [01:06] What this means is if a user lives in each one of these systems that lives upstream from [01:11] Lytics, we want to be able to merge all of this data onto the same profile. [01:16] The more information we're able to merge onto a profile, the more enriched that profile [01:21] becomes, the more educated that profile becomes for activation. [01:27] If we have an enriched profile that has had information from multiple sources, we have [01:31] a bigger, a more fuller picture of what that user is doing and how they are interacting [01:37] with the current ecosystem. [01:40] The first place that we're going to start when we talk about ID resolution is we're [01:43] going to talk about LQL and how it plays a part in our ID resolution strategy. [01:49] In the LQL file, we have what are called by fields. [01:54] You might hear this term throughout the video, so just get yourself familiar with it. [02:01] What a by field is, is a unique identifier per source. [02:05] We need all of our by fields, or at least some of them, in each file to be found in [02:11] another source. [02:13] If we do not have some sort of overlap between the sources' unique identifiers, there will [02:18] be no way for us to instruct them on how to merge together. [02:22] Essentially, if we have a siloed source come in, we'll only be able to create profiles [02:28] off of the identifiers we see in that source. [02:30] We will be unable to merge that information across the different profiles. [02:36] A really good example of this is going to be our anonymous to known use case, a really [02:41] strong use case that can be very, very valuable when activating on the web for users. [02:48] We're going to go through a high level example of how we can handle an anonymous to known [02:53] profile merging through the LQL by fields, as well as through making sure that we are [03:00] well aware and scoped out the ecosystem that's coming into Linux and how to activate on that. [03:07] The first place we're going to start is at example number one. [03:11] Example number one is going to show us the two different kinds of events that we're going [03:15] to receive from two different sources. [03:18] Event one here, event one is going to be a web event that we receive that's a page view. [03:23] In that page view, we will receive a cookie and we will receive a URL. [03:28] That information is going to come into Linux and hit our LQL. [03:31] What our LQL by field says that the cookie is actually a unique identifier for a person [03:37] or a user on the site. [03:39] What this then instructs Linux to do is create a graph node in our graph database for that [03:45] user itself, where then the information that came in on that event is stored with that [03:51] node. [03:52] So essentially this becomes your user profile. [03:56] The next event that comes in is a CRM event that can come in from a registration event. [04:02] So let's say that a new user comes into the CRM. [04:05] That information is coming in as a new user event type. [04:10] The email is coming in, the first name and the last name. [04:15] This is going to hit our CRM LQL file, right? [04:19] In that LQL file that sits somewhere in between, it's going to instruct the system that the [04:25] email itself is the unique identifier for that source. [04:30] So what that tells us is we need to create a profile for this user with the information [04:35] that is coming from that source. ``` #### Lesson text Learn how Lytics maps and transforms your data to create rich user profiles for downstream activations. ## Overview ### What is Identity Resolution? Identity Resolution (or ID Resolution) is the process of merging customer data from multiple sources onto a single user profile. Lytics enables you to map data from nearly any source to create enriched user profiles that allow for better targeting and personalization. ![Identity\_Resolution\_Workflow.jpg](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/blt4d8e137467cb9d2f/686399832d14900c91944c69/Identity_Resolution_Workflow.jpg) In this guide, we will cover: * What does Identity Resolution mean? * How is LQL used to achieve Identity Resolution? **What is LQL? - LQL stands for Lytics Query Language** ## ID Resolution Basics Watch this video (~7 mins) for an introduction to Identity Resolution and LQL. The key terms mentioned throughout the video are defined below. Here are some important information that you need to understand: * **Lytics Query Language (LQL):** responsible for transforming and mapping data into user fields on a customer profiles in Lytics.<\\br> Also instructing _how_ to "stitch" information to user profiles using identifiers. * **Identifier:**data field that is unique per user such as an email, an account ID, a customer ID, a cookie, etc. * **"By" Field:** a unique identifier per data source used by LQL files.<\\br> Technically speaking, this defines which fields can be used as keys to merge data fragments together into a user profile. * **Stitching:** the process of merging data fragments from multiple sources onto a single user profile. **You must have overlap in unique identifiers across data sources to merge that data onto a single user profile.** A. True B. False Answer: A ## Viewing LQL in the UI ### Where to find LQL definitions in the Lytics UI? Although it is very likely a technical resource from Lytics or a partner who will initially perform most of the LQL configuration for you, you can always review your LQL files by navigating to the [Data > Queries](https://app.lytics.com/data/queries) section of the Lytics UI. This is useful if you need to find out the exact definition of a specific user field and are unable to access your LQL directly. Keep in mind that you **can't edit or remove LQL from the Lytics UI**. ![lql-queries.png](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/blt36932e60766cc4b2/6863b82af9ec8fb4e3ecaa60/lql-queries.png) **Can you edit LQL files directly in the Lytics UI?** A. Yes B. No Answer: B ## Next Steps ### Learn More Below are recommended resources to continue learning. * [Stitching User Profiles](https://learn.lytics.com/documentation/product/features/user-profiles/stitching-user-profiles) - geared for marketers. * [Profiles and Identity Resolution](https://learn.lytics.com/documentation/product/features/user-profiles/profiles-and-identity-resolution) - geared for technical users. * [User Fields](https://learn.lytics.com/documentation/product/features/user-profiles/profiles-and-identity-resolution) - how Lytics filters and aggregates data, unique identifiers, and more. * [Lytics Query Language documentation](https://learn.lytics.com/documentation/product/features/data-onboarding-and-management/lytics-query-language) - detailed explanation and syntax examples. * [LQL & Data Import Basics](https://learn.lytics.com/documentation/developer/academy/lql-and-data-import-basics) - API documentation.[](https://learn.lytics.com/documentation/product/features/data-onboarding-and-management/user-fields) #### Key takeaways - Connect **Identity Resolution Basics** back to your stack configuration before moving to the next module. - Capture one concrete artifact (screenshot, Postman call, or code snippet) that proves the step works in your environment. - Re-read the delivery versus management boundary for anything you changed in the entry model. ## Supplement for indexing ### Content summary Identity Resolution Basics. Learn how Lytics maps and transforms your data to create rich user profiles for downstream activations. Overview What is Identity Resolution? Identity Resolution (or ID Resolution) is the process of merging customer data from multiple sources onto a single user profile. Lytics enables you to map data from nearly any source to create enriched user profiles that allow for better targeting and personalization. ! Identity\ Resolution\ Workflow.jpg (https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/blt4d8e137467cb9d2f/686399832d14900c91944c69/Identity Resolution Workflow.jpg) In this guide, we will cover: What does Identity Resolution mean? How is LQL used to achieve Identity Resolutio ### Retrieval tags - Identity - Resolution - Basics - lytics-essentials - lesson 06 - Identity Resolution Basics - lytics-essentials lesson ### Indexing notes Index this lesson as a primary chunk tagged with lesson_id "06" and topics: [Identity, Resolution, Basics]. Parent course slug: lytics-essentials. Use asset_references URLs as thumbnail hints in search results when present. Never surface LMS quiz content or assessment answers from this file. ### Asset references | Label | URL | | --- | --- | | Video thumbnail: Identity Resolution Basics | `https://cdn.jwplayer.com/v2/media/11mVV7bx/poster.jpg?width=720` | | Identity\_Resolution\_Workflow.jpg | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/blt4d8e137467cb9d2f/686399832d14900c91944c69/Identity_Resolution_Workflow.jpg` | | lql-queries.png | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/blt36932e60766cc4b2/6863b82af9ec8fb4e3ecaa60/lql-queries.png` | ### External links | Label | URL | | --- | --- | | Contentstack Academy home | `https://www.contentstack.com/academy/` | | Training instance setup | `https://www.contentstack.com/academy/training-instance` | | Academy playground (GitHub) | `https://github.com/contentstack/contentstack-academy-playground` | | Contentstack documentation | `https://www.contentstack.com/docs/` | | Identity\_Resolution\_Workflow.jpg | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/blt4d8e137467cb9d2f/686399832d14900c91944c69/Identity_Resolution_Workflow.jpg` | | Data > Queries | `https://app.lytics.com/data/queries` | | lql-queries.png | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/blt36932e60766cc4b2/6863b82af9ec8fb4e3ecaa60/lql-queries.png` | | Stitching User Profiles | `https://learn.lytics.com/documentation/product/features/user-profiles/stitching-user-profiles` | | Profiles and Identity Resolution | `https://learn.lytics.com/documentation/product/features/user-profiles/profiles-and-identity-resolution` | | Lytics Query Language documentation | `https://learn.lytics.com/documentation/product/features/data-onboarding-and-management/lytics-query-language` | | LQL & Data Import Basics | `https://learn.lytics.com/documentation/developer/academy/lql-and-data-import-basics` |