# Data Ingestion & Profile Construction ### About this export | Field | Value | | --- | --- | | **content_type** | course | | **platform** | contentstack-academy | | **source_url** | https://www.contentstack.com/academy/courses/data-insights-data-ingestion-profile-construction | | **language** | en | | **product_area** | Contentstack Academy | | **learning_path** | lytics-practitioner-certification | | **course_id** | data-insights-data-ingestion-profile-construction | | **slug** | data-insights-data-ingestion-profile-construction | | **version** | 2026-08-24 | | **last_updated** | 2026-09-08 | | **status** | published | | **keywords** | ["Contentstack Academy"] | | **summary_one_line** | This course dives deep into the technical architecture of customer profile creation and data unification. You'll master the data processing pipeline and learn advanced techniques for enriching customer understanding thro… | | **total_duration_minutes** | 75 | | **lessons_count** | 16 | | **video_lessons_count** | 15 | | **text_lessons_count** | 1 | | **linked_learning_path** | lytics-practitioner-certification | | **linked_assessment_ref** | LMS_UNCONFIGURED_COURSE_ASSESSMENT | | **markdown_file_url** | /academy/md/courses/data-insights-data-ingestion-profile-construction.md | | **generated_at** | 2026-09-08T13:38:54.392Z | | **intended_audience** | [] | | **prerequisites** | [] | | **related_courses** | [] | > **Academy MD v3** — companion `.md` for Ask AI. Quizzes and graded assessments are **LMS-only**; this file never contains answer keys. ## Course Overview | Metadata | Value | | --- | --- | | Catalog duration | 1h 15m 8s | | Released (if known) | 2026-08-24 | | Product area | Contentstack Academy | ### Description _This course dives deep into the technical architecture of customer profile creation and data unification. You'll master the data processing pipeline and learn advanced techniques for enriching customer understanding through multiple data sources and intelligent modeling._ ### Overview ### What You'll Learn This comprehensive session teaches you how to build robust, unified customer profiles using advanced identity resolution, data integration, and enrichment techniques. You'll gain practical experience with schema design, data mapping, and leveraging AI-powered features for deeper customer insights. ### What We'll Cover We'll explore how identity resolution automatically merges data fragments using shared identifiers like email addresses, demonstrating real-time profile unification in action. You'll master the data processing pipeline architecture, learning to create custom fields with proper data types and merge operators, configure mappings to transform raw data into profile attributes, and publish schema changes with version control. We'll cover advanced data integration through Cloud Connect for warehouse data, implement lookalike modeling to score unknown visitors, and leverage automated content classification and interest scoring. Finally, you'll learn to set up triggers that enable real-time personalization and downstream activations. ### Learning objectives 1. Follow each lesson in order. 2. Practice in a training stack using placeholders **YOUR_STACK_API_KEY** and **YOUR_DELIVERY_TOKEN** in local `.env` files only. 3. Validate API responses against the official documentation. ### Topics covered Contentstack Academy ## Course structure ```text data-insights-data-ingestion-profile-construction/ ├── 01-data-insights-course-3--identity-resolution-recap · video · 248s ├── 02-data-insights-course-3--the-data-pipeline · video · 334s ├── 03-data-insights-course-3--leveraging-common-schema · video · 406s ├── 04-data-insights-course-3--customizing-schema · video · 540s ├── 05-data-insights-course-3--the-importance-of-identity-fields · video · 150s ├── 06-data-insights-course-3--publishing-schema-version-control · video · 98s ├── 07-data-insights-course-3--working-with-apis-csvs · video · 301s ├── 08-data-insights-course-3--working-with-integrations · video · 450s ├── 09-data-insights-course-3--identifier-ranks · video · 253s ├── 10-data-insights-course-3--working-with-warehouse-data · video · 579s ├── 11-data-insights-course-3--building-lookalike-models · video · 224s ├── 12-data-insights-course-3--interest-scores-classification · video · 340s ├── 13-data-insights-course-3--example-exploring-classified-content · video · 73s ├── 14-data-insights-course-3--content-recommendations · video · 289s ├── 15-data-insights-course-3--what-are-triggers · video · 223s ├── 16-data-insights-course-3--quiz · quiz (LMS only) · 3 min ``` ## Lessons ### Lesson 01 — Identity Resolution (recap) #### Video details #### At a glance - **Title:** 9-data-insights-identity-resolution-recap - **Duration:** 4m 8s - **Media link:** https://cdn.jwplayer.com/previews/qzUxiNrH - **Publish date (unix):** 1752870442 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113697 kbps - video/mp4 · 180p · 180p · 148960 kbps - video/mp4 · 270p · 270p · 173809 kbps - video/mp4 · 360p · 360p · 194886 kbps - video/mp4 · 406p · 406p · 209537 kbps - video/mp4 · 540p · 540p · 260745 kbps - video/mp4 · 720p · 720p · 342337 kbps - video/mp4 · 1080p · 1080p · 577512 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/qzUxiNrH-120.vtt` #### Video transcript So one thing that I wanted to circle back to, let me pull up my little examples here, is just to recover the profile itself, what we're doing on the back-end, how that profile gets built, and then we'll go through a variety of different examples of how you can actually get data into the system, what the process is for mapping that information. So just to kind of rehash one of the things that we've already talked about is that real-time identity piece. I have a little bit better example to show the example in real time. I think I might've goofed the demo a little bit yesterday, but here, if I open an incognito window, and I'll go to, we'll just use petsy.lytics.com for all of these. So I'm gonna send my first event. It's going to include first name, last name, and email of Sansa Stark. And maybe I'll change this to some other Stark. I can't remember what emails I've used. So I'm gonna send this email. It's gonna collect that user's event, and then we'll be able to pull up this fragment over here. So you can see that it's actually, it merged with a few different profiles that are in there, but you have this user that's already in the system. And then if I were to go over here, close my incognito window, open it again, and then now I'm in a different session. If I started to collect, say, a status that I'm currently in a live training, I'll do that. I will get the ID so that I can pull the profile. So as soon as I start to collect information. Okay. That was the very first event for that user ever, right? Like, so it was. Exactly, yeah. So all of my cookies got cleared. It's gonna essentially create a new fragment. So if I go back over here and let me actually just open. By the time you sent the event in one browser and by the time you were in Linux, it was already there. Yes, exactly. For that, yeah. For that, the previous example, yes. And the same thing, if I can open all of my crazy windows. So if I look for the other profile that we just created, it too will be here. So there's two fragments that we created, right? There's the one that just has the sort of status of, so if I search for status, if I don't make a typo. So on this user, we set the status currently in live training. So you can see that that's the profile that represents that browser view. Over here is the one that we created in the other one, a totally separate profile. They're fundamentally disconnected at this point, two fragments that live in the system. If though, in that same experience that I collected the status event, if I now and go and say, perhaps this user logged in and that email address matched, which is an identifier in the system, which is kind of where we're going with this conversation. So if now I collect this information, it's going to associate the email with the UID, the cookie that represents this particular session. And now if I go back to this window and I refresh the profile, so now you can see that Linux made the association between the cookies. Even if I go to this tab, you can see that now my graph. So this one, I have it refreshed. Before I refreshed, there's two cookies with an email in the middle. Now in literal real time, like in milliseconds, it's making those associations. So now this graph is a little bit bigger. There's now three cookies associated with it. One represents that browser session and the unified set of data is all there together. Thank you. #### Key takeaways - Connect **Identity Resolution (recap)** 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. ### Lesson 02 — The Data Pipeline #### Video details #### At a glance - **Title:** 10-data-insights-the-data-pipeline - **Duration:** 5m 34s - **Media link:** https://cdn.jwplayer.com/previews/iDsatXS7 - **Publish date (unix):** 1752870616 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113538 kbps - video/mp4 · 180p · 180p · 139245 kbps - video/mp4 · 270p · 270p · 155091 kbps - video/mp4 · 360p · 360p · 169179 kbps - video/mp4 · 406p · 406p · 178649 kbps - video/mp4 · 540p · 540p · 213373 kbps - video/mp4 · 720p · 720p · 267723 kbps - video/mp4 · 1080p · 1080p · 425608 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/iDsatXS7-120.vtt` #### Video transcript So, that all happens in real time. Why I wanted to kind of refresh and show that again is it speaks to then, okay, how does it have the logic to understand for all of these different sort of data sources and streams, how do they ultimately map to the profile, if there's a UID or a first name in each of those streams, which one wins, right, so like is it the first in, is it the last in, what's that logic? So really the process that the data, so every single event, takes as it goes through Linux is it starts in a data stream, so under data pipeline you have access to all of your streams. The default stream is where the web information will go by default. You can customize that in the JavaScript tag if you want to, if there's some obscure use case or maybe you're collecting stuff from different websites and you want to map it a little bit differently, but all of that data automatically goes to this sort of raw event stream. From there, it uses mappings, is what we call them, to say, okay, I want to take the data that comes in from this stream, so we'll use email as an example inside of building profiles under schema, you have access to your fields and mappings. So if I, for instance, look for email under mappings, you'll see that there's a number of different streams and ways that this sort of system tells it how to handle the event. If I, for instance, go to the default stream, and actually maybe I'll just go into the field, it's a little bit easier to see. So if I click on email, you'll see all of the mappings, and you can see on the default stream, there's a few different ways that we map it, but in most cases it's just taking, okay, if I see email, just like this, the raw key, all lowercase, I'm going to do some normalization, verify that it's an actual valid email, and then I'm going to push that up to the email field. So the mapping is sort of that translation layer between raw data that comes into a stream and how it can ultimately send it to a field. The field itself on it, if I go back into email, has all of the controls on how that merge happens. So for email in particular, and we'll run through all of these and go through a few different examples of building them from scratch, but for email address, you define a data type. So in the case of email, it's just a string. There's essentially every data type that you could ever possibly want that we can support, but in this case, it's just a string. In this case, it's flagged as an identity key. So again, that's what's telling the system that if I see email in the default stream, and I also see email in this MailChimp stream, I can merge those fragments together to build the profile. Likewise, if I see an event with an email in just the default stream, and then another event in that stream with email, just like we did in our demo, it can merge those fragments together to build that unified profile. So this flag for an identifier key is really, really important. It's also one of the ways that customers can get themselves in trouble by being overzealous on what actually is an identity key, which causes you to overmerge profiles into one big super profile. The merge operator is how you actually handle the data coming in. We'll come back to this one on a field that hasn't been predefined so that I can actually show you the different options, but you can actually say that, okay, for this particular field, maybe I only want the first value that it's ever seen. Maybe I want the latest value. Maybe it's an array, and I want to merge them together. All sorts of different merge operations are controlled at the field level, which is what tells you how to make that information come together. Otherwise, you would have first name over here, this different from this first name over here, and you'd have this big, crazy, nebulous, unusable profile. The merge operators are really important in how that unified profile actually gets resolved and surfaced to the end user. There's a variety of things that we can go through when we actually build a field on the format type to, you know, do we want to base 64 encode it? Do you want to set any type? Length sort of characteristics. We'll come back to kind of cap and keep helps us sort of limit the size of arrays over time and how long data hangs around. So all of that said, essentially, streams receive data. Mappings allow that data to be translated and sent to a field, and then a field is ultimately kind of like the rule master on how that data gets represented on the profile. These fields are ultimately what you see over here on an actual profile when you see it. So the profile fields are driven from that schema, and that's kind of the resolved piece there. Anything at a high level that I missed, Eric? Just one minor clarification. Use the term cap and keep, which is our internal term for capacity and number of days to keep. It's a restriction that we put on fields to, we'll shorten it to cap and keep often, so it might slip out when we're talking, but it means the capacity, which is the number of things that can be stored in a map and keep the number of days to keep each element. #### Key takeaways - Connect **The Data Pipeline** 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. ### Lesson 03 — Leveraging Common Schema #### Video details #### At a glance - **Title:** 11-data-insights-leveraging-common-schema - **Duration:** 6m 46s - **Media link:** https://cdn.jwplayer.com/previews/IpTB9DvQ - **Publish date (unix):** 1752871658 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113582 kbps - video/mp4 · 180p · 180p · 148044 kbps - video/mp4 · 270p · 270p · 171185 kbps - video/mp4 · 360p · 360p · 186101 kbps - video/mp4 · 406p · 406p · 201597 kbps - video/mp4 · 540p · 540p · 249425 kbps - video/mp4 · 720p · 720p · 324626 kbps - video/mp4 · 1080p · 1080p · 551509 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/IpTB9DvQ-120.vtt` #### Video transcript All right, so let's pull up one thing that I like to show folks is just some sort of as you start to play with the system, Lytx comes with a set of what we call the common schema. It's a set of attributes that you can use out of the box that don't require any mappings, any maintenance, any sort of configuration. Definitely always recommend that folks start with those and just sending data into the fields that exist. So I like to call it a couple of things that are really easy to use as you start to play with it. And then once you kind of get the hang of stuff, you can go look at your scheme and see what all is available. So if I go back over here. Let's pull, make sure we're on the right profile. Okay, so this is our profile on the left hand side. We'll make this a little bit bigger because it is probably teeny tiny. So we went through sort of just like first name, last name, email. As I'm playing with accounts, two really, really useful fields that are kind of special in our predefined schema or common schema is one, this attribute. So you can send, and we should do this within reason. You shouldn't send like 10,000 different attributes to be very clear. But as you're starting to play with it, you're just like, I want to send data into the system so that I can build an audience and see how it works. There's this sort of special attribute field where if you prefix a value with HTR underscore and then send a string, it'll actually add it to a map on the profile. So for instance, if I go in here and say, I'm going to just send the attribute underscore example as testing, I'm going to copy and paste that, send it as that user. And then over here, if I refresh and go to my profiles. So you'll see this field called custom user attributes. And in this case, we pass example as value testing, you can then actually build segments and do some sort of playing with that particular piece of data with no mapping, no configuration, nothing necessary. It works very similarly to some of our event and actions. So for instance, if I pass event open, it's going to map that to an email open and so on and so forth. But as an example, if we then go into the mapping for this attribute, just to see how it's defined, how we're able to essentially be smart enough to just pull if it matches that prefix, it gets mapped, we'll go into our schema, we'll go into fields, and we'll search for attribute. So if I pull up this field, which is not an identity field, so it's not going to merge profile data together, it's just going to surface information that you can segment, ultimately leverage it, one is a map string string, so it's going to take it and create a map of the information that you pass. And then we talked about merge operators, in this case, it's doing the merge operator of merge, which just means it's going to continue to push that object together, it's not going to fully overwrite it. So if I push a new key of like, example two, it's just going to add it to that object and combine the two together. So it's not going to overwrite it. If you open this up, there's a number of merge operators. So like I was mentioning, in the case of say, like, I want to know the first item that a user ever purchased, maybe you want to keep the oldest value of that. If I want to know the latest product that they purchased, you can keep the latest. Same thing with latest map and oldest map. So the different field types have different merge operators. I don't know if it's worth walking through, like all of the different options, they're all in our docs. But I would say as those things come up, and you'll see it kind of come up in some of the examples that we'll build, the merge operator is really important, and that it tells the system how to sort of combine that data together. Merge, merge is the one that I always like to touch on, because it's probably poorly named in the long run. But it's what sort of like keeps the old data and merges it with the new data that comes in so that you're not wholesale overwriting the object. So you've been doing or we've been using the JavaScript tag to collect data, which just uses our collection API. But there are a number of different ways that you can ultimately pull data into the system. So one of which is just our API. So for instance, I have just a simple, very simple JSON file over here, that's just an array of two objects. If I wanted to just push that information to a particular stream, and again, I'll share this document out so that you have some of the API calls, but I can just essentially fire a POST request to our collection API. The last parameter is the stream that it's going to pass to. So it's important to make sure that whatever stream you're passing data to has the mappings in place necessary to ultimately surface that on the profile. One major gotcha that a lot of folks run into is if you collect the data before it's mapped, it's not going to retroactively surface that data. We do have the concept of a replay or a rebuild. It's sort of I always like to describe it as like the last, the last ditch effort and that like if a customer were to go and goof up their data or mess up their mappings and need to essentially replay all of their events, we have the ability to do that from scratch to fix some of the issues that they run into. But it's a thing that one, can be very expensive, two, we don't like to do it very often. So it's important to think about before you actually collect data, where are you sending it and making sure that the mappings are in place to translate those raw events to the fields. Otherwise, it'll just sit in your stream and never get used. Could you just walk through the stream functionality stream once actually? And like streams just a tag that gets tagged onto the event that comes in. It's commonly just used to give you an idea of what the source it's from. So like if the data is coming from like Salesforce, the data from Salesforce will be in the Salesforce stream. If it's coming from the web, it goes to the default stream, which is typically web data. So it's really just a way to say, oh, this data from this source, I want to treat with these mappings, which are how the, it's kind of like the ETL process of how we convert that stream into fields. Yep. #### Key takeaways - Connect **Leveraging Common Schema** 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. ### Lesson 04 — Customizing Schema (fields & mappings) #### Video details #### At a glance - **Title:** 12-data-insights-custom-schema - **Duration:** 9m - **Media link:** https://cdn.jwplayer.com/previews/fGpn7GIn - **Publish date (unix):** 1752872612 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113479 kbps - video/mp4 · 180p · 180p · 140452 kbps - video/mp4 · 270p · 270p · 157205 kbps - video/mp4 · 360p · 360p · 174433 kbps - video/mp4 · 540p · 540p · 224977 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/fGpn7GIn-120.vtt` #### Video transcript The main thing that I want to cover in this session is how the fields and the mappings work and how their relationship is to stream. So a perfect example of that is we have a common schema, a bunch of the heavy lifting has already been done, we'll connect MailChimp in a little while and it automatically gets the fields and mappings, but it is inevitable that you're going to want to push custom data into Linux. So I built a very simple, also Game of Thrones themed CSV, where we're pulling in things like email and first name and last name, and we use the attribute field, which comes kind of pre-mapped. But then you run into this field where it's likelihood to rain, which is, you know, akin to say like a custom score that's coming out of your warehouse or whatever it may be. So this is a thing that isn't in the system, it's totally custom. We need to make sure that when we upload this data, whichever stream we upload it to, it's going to ultimately get mapped properly to that particular profile. So I wanted to walk through that example together anyway, so we can just start to do that. So if I were to upload this information right now with no mappings, you would see it in the streams. So I'm not going to do that, but you could ultimately upload this to whatever stream you would want. You could go over here and you would see the raw data in the stream that actually was received, but it's not going to have anywhere to go with it. So it's going to sit in the stream as sort of a metric. It's never going to get mapped to the profile. It's just going to sort of confuse you. So it's really, really important to know that streams to Eric's point are kind of just a construct to help you separate the logic for mapping that data to a particular field. So in our case, we want to add the field likelihood to rain. The way that I would start to do this, and there's a couple of different approaches, but because we know that this field is net new, you're going to first need to go create a field, right? So you need to put a place on the profile where this information can actually live. We don't want to use any of the common scheme of fields, so I'm going to go to create new. You first select an ID. This can be any sort of sluggified input, so I'm just going to paste likelihood to rain. We'll just call it that for now. We'll say, you know, custom score on like rain, which is really just surfaced in the information in the UI. We'll choose the data type. So in our case, it looks like it's an integer. We want to be able to do things like greater than less than in the segmentation engine. That's one really important point when you're choosing the data type. It impacts the way that you can actually leverage that particular field in segmentation. So for instance, if I were to make this a string, it would work, but when I go to build a segment, if I wanted to find anybody that was like greater than 50 on likelihood terrain, it's not going to work. It's not going to allow you to do that because it can't do a sort of numeric operation on a string. So those kind of things are really important to keep in mind as you're doing custom mapping. Obviously there's lots of different data types that you could use. There's arrays, there's string arrays, there's time arrays, there's maps, et cetera, et cetera. We're just going to choose an integer in this case. You can add an optional description. This is just purely for the UI, so we won't do that here. You could choose it as an identity key. If it's a string, you can't do that with an integer. We don't want to do that with likelihood terrain. If I were to accidentally do that, the net result would essentially be that anybody that had, say, like a 95 score of likelihood terrain would be merged into one super profile, which is definitely not what you would want to do. So that's why only clicking the identity key when it's absolutely necessary and you want to use it to merge data together is very, very important. For a merge operator, because it's an integer, you'll see that there's a number of different ways that you can ultimately handle this data. Maybe I want the total purchase amount over time. You could do the integer as a sum. As new events come in, it's going to continue to add those up so that you have this one value that represents total purchase over time. You could just count the events. So instead of having an understanding of, like, the specific number, it's just how many times I've seen this sort of field change. The max number, the min number, the latest, the oldest. In our case, we want it to just represent the actual score value, and we want it to be the latest value so that if a new one comes in tomorrow when we push this information, it gets updated and overridden. So we're going to do latest. And then we'll leave all of the other fields. They're all grayed out, actually, in this case, because you can't set them. If we were to set or choose an array or a map, you'd have some more options to Eric's kind of earlier point on the size limit and how long some of that information hangs around. The other thing that's really important is you can flag your fields as if they contain PII or not. Because a CDP is collecting user information, a lot of that information can be personally identified, which becomes really, really important. We have lots of controls in the UI to hide or show that information for particular users. In a lot of cases, our customers will maybe encrypt or encode or Base64 encode an email address to never expose that. So there's lots of controls that you'll see around privacy. This just lets you know the field may contain PII so that throughout the UI, we can put the proper controls in place. And then there's some categorization options that are totally optional. They just show up in the actual profile kind of filtering when you're exploring. So we'll just say that that's behavior for now. So this is how we're going to configure our field. If I hit create field, this essentially just gives it a place to live on the profile. But there's still no logic on how do I take the raw data that's coming in and map it to that particular profile, right? There's still that kind of gap. So that's where mappings come in. So if I go back to my field, likelihood terrain, I'll go to current mappings and I see that there's no mappings. So we'll hit create new mapping and you'll see three new concepts that we have not touched on yet. So well, two of the three we haven't touched on yet. So stream is going to say, where do I want to create this mapping to? I can choose one of the streams that exist, or we'll just do demo custom CSV. I'm going to copy this and put it over here so I don't forget that. And then you have an opportunity to do an expression or a condition. So what the expression does is there's a few different functions that we have. So you saw it like on email, as an example, where it's going to take it, it's going to lowercase it, it's going to do some basic validation. There's things for phone number to normalize. There's ways that you can split, you can uppercase, you can lowercase. There's a whole list of the different expressions in our documentation that we can kind of come back to. But this is one of the, I wouldn't call it a cleansing layer by any means, but it's one of the ways that you can manipulate some of the endpoints to make them consistent. In our case, we're just going to do likelihood to rain. So we just want to like take a direct translation, oops, I pasted the wrong value. That's not what we want. So all I want to do is I want to take the key that'll ultimately come in as likelihood to rain in our CSV. And I want to say anytime that that value comes in, we're going to, as long as it's on the demo custom CSV stream, we're going to map it up to that profile. The conditions we'll come back to, and I'll show you a few different examples, but conditions give you a way to say, like when we're mapping conversion events or events in general, if it's a particular type, then I want to map it in this way. So you can add essentially if else equals type logic to a particular mapping so that there's conditional logic, whether it should map that field or not, as opposed to just in this case, anytime that likelihood to rain shows up in this particular stream, it's going to map it to the field that I chose, which is this custom score likelihood to rain. So I'm going to create, oh yeah, go ahead. One comment here real quick. If this was like a untrusted source, where this data was coming from, you probably would want to put an expression in there that would validate that it's a number in the range of one to a hundred. But since this is a source that we generated that we know is clean the whole way through, we can just take the value straight from the CSV. Yep. And we'll pull up the docs and show some of like the conditions and expressions and whatnot, just so you know where it is. There's a whole bunch of things that you can do ultimately from a logic perspective, but try to keep it as simple as possible for this example. So I am going to create that mapping for that field. #### Key takeaways - Connect **Customizing Schema (fields & mappings)** 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. ### Lesson 05 — The Importance of "Identity" Fields #### Video details #### At a glance - **Title:** 13-data-insights-importance-of-identity-fields - **Duration:** 2m 30s - **Media link:** https://cdn.jwplayer.com/previews/6luUta7L - **Publish date (unix):** 1752873256 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 114055 kbps - video/mp4 · 180p · 180p · 145867 kbps - video/mp4 · 270p · 270p · 165550 kbps - video/mp4 · 360p · 360p · 178700 kbps - video/mp4 · 406p · 406p · 191694 kbps - video/mp4 · 540p · 540p · 230255 kbps - video/mp4 · 720p · 720p · 292367 kbps - video/mp4 · 1080p · 1080p · 470432 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/6luUta7L-120.vtt` #### Video transcript So now I have a way to map likelihood to rain from this new stream that we're going to create based on the CSV to the new likelihood to rain field, however, every stream has to have at least one identity key in order to map it up to that profile. So if I were to just publish this and import my CSV, it would say, okay, I found likelihood to rain and that score is 85 for Jon Snow. But I don't have any context of that Jon Snow is the sort of owner of that particular event until I've created a mapping from the new stream that we're going to create to the email field. If I go into fields and email again, as an example, there's a whole bunch of mappings, none of which are represented by this new stream that we're going to create. So I need to also create, oops, a, oh boy, misclicked, go back in here. So I need to also create a new mapping for the new stream that we're going to add. That's why I copied it over here. So I also want to say that, okay, in the demo custom CSV stream that we're about to create, I also want to make sure that I map email to email, I think we called it email, yeah. So email to email, just like it is. So it's going to do some, and I don't know if you know all the logic actually off the top of your head, Eric, that the email function actually does, I think it's pretty basic validation. Yeah, it basically, there's a giant regular expression under the hood of that, that validates that it's an email. Got it. It's basically, if it has that regular expression that says that it's a valid email, then it's an email. Perfect. So we're going to make sure that we do that just so that it's consistent and mapped the same way that all the other sources are. So now I can create that mapping. So now at this point, I've created some changes, I've added a new field, I've mapped that new field to the new stream, and I've also made the association from the new stream that has an email to give it a path essentially to map it to that master profile. #### Key takeaways - Connect **The Importance of "Identity" Fields** 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. ### Lesson 06 — Publishing Schema & Version Control #### Video details #### At a glance - **Title:** 14-data-insights-publishing-schema - **Duration:** 1m 38s - **Media link:** https://cdn.jwplayer.com/previews/PCj1HuBz - **Publish date (unix):** 1752873656 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113834 kbps - video/mp4 · 270p · 270p · 171748 kbps #### Video transcript The final step as you're changing your schema is to actually publish the version. So if on the left hand side under schema, I go to versions, you'll see that okay, there's three unpublished changes that we've just made. So I actually have to go in here and hit publish changes, it'll walk me through the sort of diff what was added, we added a new field, we added two mappings, there's no ranking changes, we will come back to ranking and the importance of that, you know, in a byfield or an identity field, we'll go through next. So you're going to name something around the version. So added, likely, we'll just do the same thing for the description. And I'm going to publish that change. So now at this point, all of those changes have been merged with my actual live schema. One caveat here to be aware of is, it can take some time for schema changes to be reflected in the UI and take effect. But if as you're playing with it, you're actually customizing the fields and adding some stuff, and it's not working right away, we have to kick what we call field info on our side, which is what refreshes all the things to make sure that the mappings and whatnot take place. #### Key takeaways - Connect **Publishing Schema & Version Control** 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. ### Lesson 07 — Working with APIs & CSVs #### Video details #### At a glance - **Title:** 15-data-insights-working-with-apis-and-csvs - **Duration:** 5m 1s - **Media link:** https://cdn.jwplayer.com/previews/5OaqXTP0 - **Publish date (unix):** 1752876729 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113680 kbps - video/mp4 · 180p · 180p · 145874 kbps - video/mp4 · 270p · 270p · 166323 kbps - video/mp4 · 360p · 360p · 183204 kbps - video/mp4 · 406p · 406p · 196247 kbps - video/mp4 · 540p · 540p · 240152 kbps - video/mp4 · 720p · 720p · 307691 kbps - video/mp4 · 1080p · 1080p · 506438 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/5OaqXTP0-120.vtt` #### Video transcript Now, I should be able to import this set of data, the CSV, to my account. There's a few different ways you can do that. There's APIs if you just want to push up the CSV. There's a number of integrations. We'll walk through how to do a Mailchimp one here in a second, so you can get a taste for it. But when I'm playing with new accounts and whatnot, one of the easiest ways is if you go to the data pipeline and you go to Streams, this little menu in the top right corner, if you click it, it'll allow you to do two things that are pretty handy. One, you can upload data to a stream, which is what we'll do. So you can just take the CSV off your computer, upload it, and push it directly to a stream. Super easy. You don't have to use the APIs. The other mechanism that could be really handy as you're learning is you can actually download an example CSV template for a stream. So it'll look at all of the different mappings that exist and generate a CSV with all the headers that you could theoretically push data into. For the default stream, there are a lot of mappings that come out of the box, so it could be a little bit confusing. But once we get our data imported, I'll do it for this new stream that we're creating, so you can see an example of what it generates. But it's a really handy tool as you're starting to play with it and get familiar with the fields and whatnot that exist. So we will upload data to the stream. We will paste in our stream name. We will upload the file, which is just sample CSV. And then you can also, we don't have a timestamp field in this data, but if you want to associate event times with the actual event time that they come in, which is important for things like purchase information or count signups, consent, whatever it may be, you can actually tell it which timestamp field to use the map. There's also a number of advanced options on controlling headers, and if you want to append data to every record, and all sorts of stuff that you can do. But in our case, we just want to upload the CSV. You hit Submit. It's going to push it to the stream. So one other important note, we call it stream stats, but our stream page is updated every two to four minutes. I think it's usually two. Sometimes it takes a little bit longer, depending on where you are in that cadence. So as soon as I do that, it's going to come back here and say, hey, there's no data yet. If we hang around for a couple of minutes, we'll see this field or this stream populate, and that data will come in. So with all of that, in theory, if we go back to our stream, so now, like I said, every two minutes, this usually updates. We gave it much longer than that. You'll see that all of the information from the CSV is now here. And then even more, in theory, if I were to go and pull, say, ARIA start, we will be able to see how good or bad my demo is. So now, you can actually see that that data was mapped up to a profile. ARIA now has an actual profile in the system. Furthermore, if I were to copy ARIA, and we'll go back to our incognito window, we'll close that. So we connected that from a CSV, a totally separate channel. If I go back to Petsy, and I click around, it just sort of builds up some profile information. I'll visit PetBeds, and then we will go back over here. And if we paste ARIA in there, so now, or even actually, I could just do this. It's even easier. If ARIA were to come to the website and sign up for the web newsletter, whatever it may be, and join that, and I go back to the profile, which is Sansa, that's ARIA, refresh it, and you should see. So now, we've associated a CSV, totally separate channel, with web data. So you can see how, as you connect multiple channels, and you have your mobile data, and your web data, and your CSV data, and your CRM data, and all these different sources, they all map up to this unified profile that's now accessible in the web layer. So you can personalize content stack-based content on the website based on email activity, or ads activity, or CRM activity, all pseudo and real-time, depending on how those systems connect. So that's kind of, for me, the best demonstration of what you start to unlock as value. There's tools that can do just the web layer. There's tools that can just do the email layer. But to be able to sort of personalize content on the website based on the email that you clicked or haven't clicked, and based on your past purchase history all in real-time, can be and should be pretty magical. #### Key takeaways - Connect **Working with APIs & CSVs** 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. ### Lesson 08 — Working with Integrations #### Video details #### At a glance - **Title:** 16-data-insights-working-with-integrationsed - **Duration:** 7m 30s - **Media link:** https://cdn.jwplayer.com/previews/gzn6uDlP - **Publish date (unix):** 1752876102 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113470 kbps - video/mp4 · 180p · 180p · 143275 kbps - video/mp4 · 270p · 270p · 163596 kbps - video/mp4 · 360p · 360p · 184251 kbps - video/mp4 · 406p · 406p · 198040 kbps - video/mp4 · 540p · 540p · 243738 kbps - video/mp4 · 720p · 720p · 316433 kbps - video/mp4 · 1080p · 1080p · 530638 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/gzn6uDlP-120.vtt` #### Video transcript The other popular way to get data into Lytics, which is super nice and magical because all of the fields and mappings have already been handled by our data team, is using one of our pre-built integrations. So out of the box, there are hundreds of different ways to connect with different tools. And under most of these tools, there's several different jobs. So for instance, if I search for Google Cloud, as an example, and I go under here, not only can we integrate with Google Cloud, you can integrate with BigQuery and Cloud Storage and PubSub and Event Stream, essentially any way that you'd ever dream of pulling data in or pushing data out. There is probably already a connector for it. If there's not a connector for it, there's some really cool capabilities that we'll probably cover in tomorrow's session around webhooks and webhook templates that allow you to essentially build your own integration. But for our example, real quick, just to kind of walk through what it looks like to connect data from a typical marketing tool, we will go here, Create New. Before this meeting, I created a free MailChimp account. So hopefully I remember all of my passwords and stuff, but we'll just do MailChimp. We'll import audiences and activity data. You can also export your audience and do some webhook stuff within MailChimp. First thing that's going to ask you to do is create an authorization. Authorizations are going to be dependent on the particular downstream tool. Sometimes it's OAuth, sometimes it's a JWT, sometimes it's just an access token, just depends on what that sort of downstream tool needs. I'll hit Create New. MailChimp, I believe, just uses OAuth. So I will sign in. Hopefully this pre-fills and it locks me in. I will allow it. Perfect. I'll just name it so that it's in the account. I'll continue. And then so now once I have an authorization over here in MailChimp, I don't know how many folks have seen MailChimp or any ESP sort of system. They all fundamentally work the same in that they have some sort of list mechanism. I just ingested sort of like 50 records, 20 records, whatever it is of sample email addresses with first name, last name, just to kind of show what it looks like to connect that information. So this is the account that we actually connected to. If I go back over here to the right screen. So all of our pre-built integrations have a set of configuration options. It's obviously going to be custom for the particular channel. Some are super simple. Some have a lot of different options. In the case of, say, like Salesforce Marketing Cloud, you can choose specifically which fields to pull in and how those fields map to the profile fields. And there's lots of different configuration options. MailChimp is pretty simple in that you just say this is kind of like demo MailChimp import. We don't need a description. You'll choose the list to import. My list was just named Lytx because it's in the lytx.com account. You'll have some options on, do you want to sync subscribes and unsubscribes? Do you want to import just a portion of the data? Maybe you have 100 million records and some of them are old, so you only want to do the last year, whatever, controls like that. You can import activity data as well. This account's not going to have any activity data, but in most ESPs, traditionally, you would have opens and clicks and bounces and that kind of information that you also want to pull in. And then you can have the same sort of mechanism to control how far back you go. This account is brand new as of like 45 minutes ago, so there's not a whole lot of history there. So I'm not going to do any of those toggles. And then when I hit complete, two things are going to happen. So one very important thing is that the job will automatically kick off in the background. All of our integrations are built to be real time if they can be. So that means that as a user enters the audience, we have that trigger capability. We're going to sync individual profiles as fast as we possibly can. Many of our integrations don't support real time syncs, so they'll do some sort of batch cadence on every hour, every day, whatever it may be. There's a whole bunch of functionality at the end of the day that we can support in real time and throttling and controls, which I know have come up a lot in kind of the Linux to content stack integration. MailChimp, I believe, is real time. So as users enter that audiences that we ultimately push out, they're going to be pushed to those lists in real time. So the job on the back end is sort of thing one that happens. Thing two that is really important that our customers love is it's also going to automatically update your schema based on what we know about MailChimp. So over here, just as a example, so all of our prebuilt integrations outside of webhooks and like CSV and like custom data type integrations come with a predefined set of fields and mappings. What you see on the screen is our older logic, still very useful. We call it LQL. So it's kind of more of a raw view of how those mappings happen. But you can see. So in the case of MailChimp, these are all the fields and mappings that come out of the box. So we map email to the email field. We pull off the domain with the email domain function. We hash it. We pull in the list IDs. Some of the consent stuff that comes from MailChimp, first name, last name. So all of our integrations come pre-mapped, which makes it really, really simple to get data in. In the case that you're, you inevitably have some custom mechanism in these tools. You can update the schema to kind of match accordingly. But for most of our customers, the out of the box sort of integrations do the heavy lifting and that you don't have to think about identity or how the things merge together or which ID to use. We've already done all of that work for every single one of our integrations, which makes connecting things super easy. You'll also see in this case. So now that I've connected MailChimp, there's actually 54 unpublished changes. This is one of the things that we're working on in our UI to make a little bit more seamless and easy. But it'll actually ask me to go through and publish the MailChimp fields. Oops. I think I need to refresh. So you could see all of the fields and mappings and stuff that come from MailChimp that ultimately get added all of the different mappings. All of this stuff gets added out of the box. Soon we'll bypass the having to actually approve the schema changes that will just apply what we call a patch. So this is sort of a temporary thing that we're working through that's a little bit clunky, but it allows you to sort of see all the things that are happening out of the box. I'll just say MailChimp connect and publish. So now all of those fields are also in my account. As the MailChimp data comes in, you'll see those users and profiles. So lots of different mechanisms to kind of pull data in automatically. But most of our pre-built integrations are that easy. It's just clicking through, doing an auth, filling in some questions, and then we do all the heavy lifting on the back end. #### Key takeaways - Connect **Working with Integrations** 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. ### Lesson 09 — Identifier Ranks #### Video details #### At a glance - **Title:** 17-data-insights-working-with-ranks - **Duration:** 4m 13s - **Media link:** https://cdn.jwplayer.com/previews/FFIRINGI - **Publish date (unix):** 1752877181 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113666 kbps - video/mp4 · 180p · 180p · 141064 kbps - video/mp4 · 270p · 270p · 157856 kbps - video/mp4 · 360p · 360p · 171996 kbps - video/mp4 · 406p · 406p · 182307 kbps - video/mp4 · 540p · 540p · 217867 kbps - video/mp4 · 720p · 720p · 276684 kbps - video/mp4 · 1080p · 1080p · 443311 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/FFIRINGI-120.vtt` #### Video transcript I'm coming back real quick, just because I don't want to skip over it. So if I were to go in and create a field, so we'll just like do it example one, like let's say this was, you know, Mark's school ID, and I want to make it a string. And in this case, I want to make it an identity key. I'll let Eric talk through so there's one setting for all identity keys, that's really important and ultimately how we resolve those identity called ranks. So it's managed over here in the ranks section, I'll back out of here, but you'll see all the different identifiers that are in this particular account. So there's an email, there's a UID, there's a chat user ID, external ID, et cetera, et cetera, in kind of a priority order. So I'll kick it over to Eric for a moment to talk about the importance of ranks and how they actually impact the merging and building of profiles. Yeah, so if you think about identity, there's lots and lots of identities that represent us as real, real, real people. If you ask a marketer, they'll always tell you that, well, no, there's just Eric, like there's just Eric. But if you think about it, if you start to think about it, like I have four or five email addresses, so that's not really a good identifier for me, but it's better than all the cookies that I probably have. I probably have thousands of cookies on the web. And so there's this concept of ID, identifiers being stronger and stronger as you get to certain identifiers to the point where maybe the strongest is a customer ID. And so at my bank, my account, my social security number, my government ID is probably my strongest identifier. And so without establishing rank and identifiers, if we just had a graph with no ranking structure, we would never have this concept of a canonical ID. And all marketers really want this concept of what we call a canonical ID, which is that they can just call Eric, Eric, and they're always targeting Eric. And if Eric opts out, they know that Eric's opted out and that kind of thing. And they don't want my identifier to churn and change all the time. So the rank statements allow us to say, this identifier has a higher precedence. And what we do is when we generate what we call the Lytx ID, which is this canonical ID that marketers can use as like a key in databases and things like that, is we look at these ranks and we always choose the highest ranked identifier out of the list of all the identifiers that we know about a user. So there's the Lytx ID and that profile. And that one is actually derived from, if you look at the identifiers that are on this profile, it's derived from the highest ranking ID. This one's a bad one, because it only has- It's only got a UID. Well, if there's an email on here, if there was an email on here, it would be derived from emails. So externally, that's the primary use case for it, for the concept of ranks. Internally, we use it a lot to optimize graphs. And that's maybe at the very end, when we get into some more architecture discussions, I'll start to talk about how we maintain graph health and optimize graph lookups. And we have this concept of identifiers aging out and expiring, and all of that is related to ranks as well, but we'll get to that one in the last session. #### Key takeaways - Connect **Identifier Ranks** 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. ### Lesson 10 — Working w/ Warehouse Data #### Video details #### At a glance - **Title:** 18-data-insights-warehouses - **Duration:** 9m 39s - **Media link:** https://cdn.jwplayer.com/previews/u1mD3rGg - **Publish date (unix):** 1752878424 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113588 kbps - video/mp4 · 180p · 180p · 135498 kbps - video/mp4 · 270p · 270p · 148923 kbps - video/mp4 · 360p · 360p · 162108 kbps - video/mp4 · 406p · 406p · 170215 kbps - video/mp4 · 540p · 540p · 200907 kbps - video/mp4 · 720p · 720p · 245465 kbps - video/mp4 · 1080p · 1080p · 382520 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/u1mD3rGg-120.vtt` #### Video transcript So, we talked about integrations that pull from marketing tools. We talked about all their APIs, our JavaScript tag, which uses our APIs. The thing that we haven't touched on that I think is pretty easy to demo, it certainly can be a bigger conversation to go into the weeds. But the other source of data that is super common to pull in is from your warehouse. So we have integrations in the data pipeline, if you just want to stream the entire table in and not have any filtering from your warehouse, you can do that through the connection just like we did MailChimp. But we have a special tool called Cloud Connect that allows you to actually connect to your warehouse. We support all of the major warehouses, BigQuery, Snowflake, Redshift, et cetera. What it allows you to do is create a connection, which is very similar to what we did with MailChimp, so I won't walk through that. Like it's a BigQuery, we just use a JWT to get authorization into BigQuery. But what it allows you to then do is build data models, which is essentially a SQL query against that particular table or set of tables inside of your warehouse to pull that data in uniquely to the profile. It goes through, and this is why we'll have a bigger conversation on what it actually means to the profile and how it works, but it maps things in a pretty unique way in that it doesn't go through a data stream. It doesn't necessarily have to adhere to the mapping and the sort of those rules. It creates its new own set of fields that also go away if you lose access to the data. So this comes up a lot when customers want to add scores or information to a profile, but they don't want to create a duplicate and copy and stream it in and go through all of the inherent kind of risks there. They just want to plop something on a profile and kind of like override some of those settings. It allows you to go in, in this sample BigQuery instance, it'll actually pull up a SQL editor. I have a very simple query that I wrote. You can just paste it and say, I want to select everybody from the sample data set with email first name, last name, and an average annual revenue from sample customers. You can test the query. It'll actually query that, in this case, BigQuery in real time. And then as you connect it, you can actually then describe how you want to map that to a profile. So we'll just say BQ test. The only thing really you have to choose is the primary key. So from my data set, I want to map the email that I just selected. Again, that's the only kind of context. You still have to tell it how you're going to map this Cloud Connect data, this warehouse data to a profile. So I want to merge it based on the email address. I want to merge that with the email field. And then you can choose optionally if you want to pull in additional information. So I want to add first name, last name, and average annual revenue. With Cloud Connect, because it's less of a real-time thing, more of a query-based thing, you can then choose the cadence of how often you want that to run. For tests and demo, I always do an hour. In reality, you probably don't want to just spam your warehouse instance with these big expensive queries every single hour. So most customers are going to do 24 hours or 48 hours or whatever it may be. But you have that. You can flag if you want to create net new profiles from that data. If you don't check this box, it's only going to map to the profiles that exist and never create net new ones. Because our sample database isn't built of Game of Thrones characters, I'll create new so that it creates those profiles. Then ultimately, you create this data model, and it's going to go through, query that BigQuery database on that cadence that we described. And then ultimately, those profiles will come in to the UI. I don't know how long that will take. So I think in our next session, I'll be sure to show you what that data looks like on a profile because it looks a little bit different. All of the segmentation and activation capabilities are exactly the same. But I just wanted to touch quickly just to introduce the idea that's the final piece of where data can come from. The Cloud Connect product represents a little bit of a different method for getting data into Linux. All of the other methods that we talked about, the JavaScript tag collection, the APIs, all of our background jobs, all of that kind of stuff uses our streaming pipeline. So it goes into a stream, a stream maps to a field, fields ultimately show up on the profile. Cloud Connect, just to kind of re-cover this part, is quite a bit different, actually, in that it doesn't use our streaming pipeline to actually get data onto the profile. It has a whole different mechanism that we can talk at length at. At some point, Eric can go into details there, but it essentially bypasses that streaming pipeline and injects the results of that query directly onto the profile. It's really useful for a few different reasons, but the one context that it comes up often is around sort of security and control. So think about like a situation where customer A wants to share a subset of data with one of their partners, with an agency, with another customer, whatever it may be, but they don't want to just give access to the raw data, something that they can like copy and own forever. So all of the warehouses have a different kind of methodology for how you can share and unlock that capability. In BigQuery, you essentially can give access to a specific dataset, and then you don't have to necessarily expose all of the raw data. With how Cloud Connect works, where it doesn't stream that data in, it's not creating a sort of like hard copy that gets written to our system, that gets backed up in our files, and it's creating kind of a less persistent temporary store for that data. If customer A wants to unshare essentially that data from their partner, from the other customer, whatever it may be, and they then lift that access, so they prevent somebody from actually being able to query that database, the next time that query runs, it'll actually clean up that system all the way through, so you don't have that kind of like legacy data that's in that stream system and all that kind of stuff existing. So it comes up often when security or data control, data access, is a key part of that conversation. And it's because, like I said, it doesn't actually stream the data to Lytx in the exact same way. So to just quickly kind of recap on Cloud Connect, it's under data pipeline, the same place that all of our jobs and all the other sort of collection profile sort of building is. Within Cloud Connect, you have the idea of connections, which is just that connection to the database. We won't rehash there. You have the data model, which is essentially the query that's going to run. In our case, in the last conversation, we built this sample query. It just pulls in a set of sample users, first name, last name, email, customer type, and then just an example of a score, for instance, that would be maybe in your warehouse. The thing that we didn't totally cover was how you then get the Cloud Connect data, this warehouse query into Lytx to store it on a profile so that it functions essentially fundamentally like one of our normal attributes. There's a publishing process in this. So when I hit next, but I think we might have briefly touched on this, if I recall, but we didn't actually complete it. And then we definitely didn't show it on the profile. So with Cloud Connect, you don't have to have everything mapped. You don't have to have all of the attributes configured in the same way that the streaming pipeline is. The only question that you have to answer is essentially how to map this data to a single profile. So you have to essentially pick the key from your data that you're querying from, say BigQuery, and what key you want to be able to write it to, so which identifier inside of Lytx you want to associate that data with. So in this case, in this one that I've already pre-configured, we're basically just saying in this query, there's a bunch of stuff, but all we want to do is we want to find anybody that matches on email. And if they match on email, we're going to append this information to that profile. The thing that is unique about Cloud Connect, if I go to a profile, for instance, that I think I had pulled up, yeah. So this one is one of the records that's in that sample data set. They have a profile, just like any other user, regardless of where that was generated from. But if you scroll down and see the data that came in for that particular data model on their profile, you're going to see a few different things. One, you'll see the raw attribute that we pulled in, first name, last name, but it's going to be independent of the other first name, last name fields that are already in the schema. And then you see this unique, and this is actually the more useful part of this particular thing, is there's this unique membership attribute that now gets added. So back to that example of like, I'm Nike.com and I'm sharing data with a partner and I want to give them access to everybody that has a high propensity to buy women's running shoes or whatever it may be, but I don't want to give them all of the data that I needed to use to pull this score to build that list. I just want to give them sort of that Boolean yes, no. That's where this membership flag can come in and that you don't have to have access to all of the information in order to make the calculation. You're just essentially pulling this information in temporarily as long as you have access. And then when you go to build a segment, it functions full scale, just like all of the other attributes in the system. So you can mix and match. There's no sort of limitations there, but like the one thing to just kind of be aware of and know is the use case of where this particular method for pulling data in from a warehouse is super useful, is around that sort of access control. I want to be able to pull things away. I don't want that data to persist. I don't want to store it somewhere. Whereas the streaming method, which also has a warehouse connection, or if I just want to pull everything from a particular table or whatever it may be, you can use our kind of back end integration. #### Key takeaways - Connect **Working w/ Warehouse Data** 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. ### Lesson 11 — Building Lookalike Models #### Video details #### At a glance - **Title:** 19-data-insights-lookalike-models - **Duration:** 3m 44s - **Media link:** https://cdn.jwplayer.com/previews/qZ02gNuc - **Publish date (unix):** 1752878955 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113880 kbps - video/mp4 · 180p · 180p · 132922 kbps - video/mp4 · 270p · 270p · 144948 kbps - video/mp4 · 360p · 360p · 153786 kbps - video/mp4 · 406p · 406p · 159929 kbps - video/mp4 · 540p · 540p · 180737 kbps - video/mp4 · 720p · 720p · 211742 kbps - video/mp4 · 1080p · 1080p · 295901 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/qZ02gNuc-120.vtt` #### Video transcript Linux has a pretty powerful lookalike modeling feature which allows you essentially to go into the UI, it makes it super easy for marketers and less technical folks. If you have a data science team, they're probably already doing scoring, it probably lives in your warehouse, you probably don't want to just bank on lookalike models. But for somebody that wants to kind of like fill gaps in some of their data or get a better understanding easily in a few clicks, what lookalike model allows you to do, and I think one of the best use cases is like, if I am a brand and I use Sixth Sense, for those that don't know, Sixth Sense allows you to understand where traffic, like what business traffic comes from. When I go to a website, they can, for a portion of my audience associated with, okay, Mark works at ContentStack, ContentStack has X number of employees and here's their annual revenue and all this information. The downside to tools like Sixth Sense is that they only effectively analyze 10, 15-ish percent of traffic. So for that 10% of the users, you have a really good understanding of, is this a highly qualified lead, right? So even like ContentStack as a company, when people go to the website, do you want to understand, do they work for and represent a company that's a high value company that looks like a good ContentStack customer? You can do that with a tool like Sixth Sense for about 10% of the audience, but you lose the other 90% and that you don't really know where they're coming from or what they could do. So what lookalike model allows you to do is take a target audience, say the 10% of the users that you know that you've built an audience that, okay, here's my highly qualified users. Here's the people that work for a company that's big enough that has the right sort of focuses or whatever it may be. And then I want to compare that to the other 90% of the audience and see where their behaviors overlap. So I don't necessarily know specifically where they work or what companies, but I can understand that this 90% of the audience, whether they behave like, they act like, they're looking at the things, they're clicking on the same things, that sort of like 10% of highly qualified leads looks at. Effectively, if you have a portion of your audience that you don't understand and a portion of your audience that you do understand, you can go in here, you can create a new lookalike model, you can choose your source audience. So if I go to one that's already configured, for instance, this one that we just did, it is going to essentially compare the no Sixth Sense data to the all audience that it already has Sixth Sense data. And then from there, it's going to essentially put a score on how much they look like based on their behavior, based on their interest scores and their behavioral scores and all that information that we're ultimately putting on these profiles to tell you how much or how little they actually look like a particular set of users. That data too is represented by scores on the profile. So like, so we can come back and kind of like dig deeper into lookalike models. But there are particular like marketing use cases that are super useful. The net result, though, is ultimately a score on the profile. So you'll be able to see that Mark Hayden has a score for this particular model, and it's a 76 out of 100 or a 10 out of 100. So then you can go build an audience of people that look more like highly qualified leads than less than highly qualified leads. A lot of the marketing tools also have similar functionality, like when you get to the ad tech and whatnot, they'll have their own lookalike modeling and whatnot. But we find this is really useful when you're trying to explore your data. So that's it for this week. I hope you found this video helpful. If you did, please like and subscribe. And if you want to see more videos like this, please subscribe to our YouTube channel. And if you have any questions, or you have any questions about the product, or any other topics that you'd like to see covered in this video, please leave them in the comments below. And I'll see you in the next one. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. #### Key takeaways - Connect **Building Lookalike Models** 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. ### Lesson 12 — Interest Scores & Classification #### Video details #### At a glance - **Title:** 20-data-insights-interest-scores-classification - **Duration:** 5m 40s - **Media link:** https://cdn.jwplayer.com/previews/iRhAPCRQ - **Publish date (unix):** 1752879751 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113718 kbps - video/mp4 · 180p · 180p · 138386 kbps - video/mp4 · 270p · 270p · 155796 kbps - video/mp4 · 360p · 360p · 172959 kbps - video/mp4 · 406p · 406p · 183666 kbps - video/mp4 · 540p · 540p · 221294 kbps - video/mp4 · 720p · 720p · 279070 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/iRhAPCRQ-120.vtt` #### Video transcript But we covered our behavioral scores as well, right? The momentum and propensity, those are really, really important behavioral statistics, behavioral scores that help fuel and empower these models. The other one that is maybe the most important thing, certainly one of the most important things in the kind of Linux coming together with content stack story is our interest scores. So you saw them, I think, in the very first conversation where we go back to Petsy, turn on our trustee Chrome extension. So at the bottom of the Chrome extension, you'll see a set of interest scores. These, for most customers, just come out of the box. So we'll talk about how they actually work, what we're doing to classify the content associated, but ultimately what it allows you to do as a customer is as I browse, you'll see in real time and it might be kind of like subtle because I've used this profile a lot, but you'll see my scores change with every single piece of content that I interact with. So as I go here and I look at pet carriers, obviously, and this is like a sandbox demo account, but you'll see those scores, like again, it's a little bit kind of like hard to see in the bigger scale, but they're being recalculated every single time that an event comes into the pipeline, which is super, super useful in one, helping you understand anonymous users, which is most users in the case of marketing. That's where a lot of other CDPs fail and fall short as they don't talk about the importance of anonymous and how that particular product helps with the anonymous use cases. It's always around. We help you get your data together and build known profiles and it will, at the end of the day, it's pretty easy to mark two people that, you know, if you have their email address and everything about them, it's much more difficult when you only have the information that they give you in sort of like different browser sessions, essentially. So kind of to just start at how all of this works, these values on the profile are called interest scores. So if I go to the raw details for this particular user and find. So the thing that's actually happening is for every single one of the topics, which we'll talk about topics here in a second, there is a score of how much or how little I am interested. This works the exact same way that all of our other scores do. So not only do you understand what I'm interested in, you can target the people that have an above average interest in a specific topic on your website. So that granularity is super important. But what you see in the bar is essentially this data getting digitized. Today how this works is every time that a user visits your site that's been tagged, we get a URL. Our system actually goes out, scrapes that URL and runs it through a series of different systems to do NLP, image analysis, some of those kind of things to ultimately uncover the topics that are associated with a particular document. So for instance, if I close this, give us some more screen real estate. If I go into our Petsy sandbox account real quick and just go to like documents with images, what it's actually doing automatically. So this is with no configuration from the user other than saying, you're okay to classify this domain. We're going to go out, we're going to look at the content, we're going to pull that content in, we're going to understand what topics it's about, what images are on it, all of this information. So that every time that a user visits that particular URL, we know what the content is about. And then we can start to build scores for how much the topics on that particular document align with all of the other interests that we've seen from that particular user. So it's essentially, we go out, we scrape the content, we turn it into topics. And then every time that the user then sees that content, we understand what it's about, we can associate that with their scores and we can update them in real time. So we're actually going through what we call classifying the documents. So if I go into, for instance, this like Elegant Paws Cat Carrier, again, make-believe content. And this is the thing that I wanted to touch on. One of the things that is really cool, and my biased opinion about Linux is that the same exact identity resolution model, the way that we handle profiles and that graph and all of that kind of stuff, works in the exact same way for content. So we essentially out of the box build a user table, and that's how we're able to associate all the different profiles with mark together. We also have a content table. So for every document, we go out, we analyze that document, we collect the information about that document, and we essentially build document profiles inside of Linux. So on the screen, they're not as pretty, because we haven't spent as much time sort of like showcasing this particular thing. But you can see that like for a piece of content, this URL that we just clicked on, you understand the hashed value, which is how we associate it with the user, the number of users that have seen it, the different information, the entire body of that document, the topics, the header image, the primary image, we can pull in meta tags, whether it's fail, like all of this meta information around not just the content, but this sort of document that ultimately users interact with. Thank you. Thank you. #### Key takeaways - Connect **Interest Scores & Classification** 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. ### Lesson 13 — Example: Exploring Classified Content #### Video details #### At a glance - **Title:** 21-data-insights-exploring-classified-content - **Duration:** 1m 13s - **Media link:** https://cdn.jwplayer.com/previews/r5mEINso - **Publish date (unix):** 1752879987 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 114950 kbps - video/mp4 · 180p · 180p · 145410 kbps - video/mp4 · 270p · 270p · 165318 kbps - video/mp4 · 360p · 360p · 171917 kbps - video/mp4 · 406p · 406p · 181549 kbps - video/mp4 · 540p · 540p · 212738 kbps - video/mp4 · 720p · 720p · 263879 kbps - video/mp4 · 1080p · 1080p · 399501 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/r5mEINso-120.vtt` #### Video transcript So with that, so real quick, just to kind of show how Linux works today. If I close this, so let's say let's just go to the bond toy. And if I go to classification, you can do a manual classification. So again, we do this automatically, we look at what URLs users are engaging with, we make sure that we have a document that matches that, keep it up to date, etc, etc. But it'll essentially go out and classify that particular document. So it's going to pull in to make sure you have the right thing, it's going to say here's the image. In some cases, there's more context, you can manually curate topics, I think inevitably over time, this goes away, that's a thing that you would want to do inside of the CMS portion of the management system. But this is how users can start to get kind of a sneak peek of what's working and what we're seeing and ultimately classifying. #### Key takeaways - Connect **Example: Exploring Classified Content** 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. ### Lesson 14 — Content Recommendations #### Video details #### At a glance - **Title:** 22-data-insights-understanding-content-recommendations - **Duration:** 4m 49s - **Media link:** https://cdn.jwplayer.com/previews/zt7iltQ2 - **Publish date (unix):** 1752880653 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113809 kbps - video/mp4 · 180p · 180p · 136938 kbps - video/mp4 · 270p · 270p · 150874 kbps - video/mp4 · 360p · 360p · 163745 kbps - video/mp4 · 406p · 406p · 172426 kbps - video/mp4 · 540p · 540p · 200843 kbps - video/mp4 · 720p · 720p · 246386 kbps - video/mp4 · 1080p · 1080p · 366924 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/zt7iltQ2-120.vtt` #### Video transcript That's kind of how classification works at a high level. The net result is we understand the content. We have topics. Those topics are associated with the user. The thing that we haven't talked about at all is kind of then how can a customer use that information? One of the simple ways is you can build audiences, of course. I can go into here. I can build an audience. I can say that it's content, say content topics, and I want to just target anybody that has a ... We're just making up numbers on a demo site. Any number that you want to have a higher interest for this particular topic and it's going to pull up three users, so you can build a very targeted audience of just people that are going to want to engage with this particular type of content is kind of like obvious way one to use it. So Lytics out of the box for every one of our interest engines, which we'll kind of cover what ... Interest engines, what we used to call them, we're now calling them context layers as we kind of like start to rebrand some things. But for any of these interest engines, you could actually make a recommendation for a specific user from a selection of content. So when Mark visits the website, I want to surface some portion of content that we know that he's going to be interested in based on his past behaviors. If I go back over here real quick ... So if I do a recommendation, and I have not tested this in a little while, but it still works. So it's going to actually go through and it's going to select from a collection, which we'll talk about here in a second. But based on my information that I know specifically about Mark and what he is interested in, as well as the specific corpus of content that could be surfaced to Mark, here's a set of recommendations that also have scores on how well or how little they align. We have our path forward kind of web personalization tool allows you to surface content recommendations. Content recommendations is one of our most common use cases. It's the easiest thing to stand up and you can just surface a modal with recommendation for content based on whatever a user is going to want to help drive their sort of session depth essentially. So that all comes out of the box with Lytx. The APIs are already all there to support it. And then the other unique aspect of content in that sort of recommendation pipeline is what we call collections. You can think of them as just a segment of content. So again, in the same way that Lytx is building profiles, Lytx is building document profiles. If you can build an audience of Lytx users, nothing stops you from building an audience essentially of Lytx content. So recommendations are made based on content collections. So if I only want to recommend documents that have images or documents by a particular author or documents that are about dogs, whatever it is, you can build a segment of content. And then when you make a recommendation, you can choose that segment collector, that content collection to recommend from to sort of whittle down the content that you can choose from. That way you're not making just a recommendation from all of your content, you're making one only from products that want to focus on in fall or whatever it may be. So content collections, and we can walk through just creating a collection real quick, are super simple. You can go here and just say I want particular titles or authors, if it has an image, if it has a description. And then I think where I usually go is in this top right button, there's an advanced editor, which takes you into the literal segment builder, but now you're focused on a document. So you can go in here and say, you know, any, you know, content that was created after whatever certain day, things that you're going to publish in the future, certain attributes, certain brands, again, like there's some part of I think what we can unlock is that when you're building the content model, more information that you all probably already have instead of content stack could be surfaced on the document profile so that you can then segment on that information, for instance. But anyway, you can build a collection off of essentially any of the document attributes that are on there. #### Key takeaways - Connect **Content Recommendations** 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. ### Lesson 15 — What are "triggers"? #### Video details #### At a glance - **Title:** 23-data-insights-trigger-basics - **Duration:** 3m 43s - **Media link:** https://cdn.jwplayer.com/previews/AW2Mx2Bb - **Publish date (unix):** 1752881258 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113752 kbps - video/mp4 · 180p · 180p · 130023 kbps - video/mp4 · 270p · 270p · 138491 kbps - video/mp4 · 360p · 360p · 145476 kbps - video/mp4 · 406p · 406p · 150625 kbps - video/mp4 · 540p · 540p · 166917 kbps - video/mp4 · 720p · 720p · 192897 kbps - video/mp4 · 1080p · 1080p · 263885 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/AW2Mx2Bb-120.vtt` #### Video transcript Once you have a profile built and you start to build audiences, what's the actual mechanism to allow you to do something with that? How do we know somebody just entered an audience? How do we know they exited an audience? How do we know a value changed? How do the jobs that are real-time syncs even work at all? All of the answers to those questions are what we call triggers. So essentially, this is where I'm going to explain it like a noob. If we want to go into more detail, Eric can go into much more detail on the processing pipeline. But essentially, data comes into Lytx. You have raw events. It's the stuff that we're collecting. It's the stuff that we're pulling from systems. We do what I call enrichment. So that's where our behavioral scores are calculated. Audience memberships are calculated. The model scores are calculated. So there's a bunch of things that are happening to where we're improving, updating, and adding additional context onto the profile. Based on the results of that, it then can trigger things. Most of the triggers, certainly the most common triggers, are around segment membership. So at that point in the pipeline, once data has been collected, we've done all this analysis, now we understand all of the audiences that this user is either a member of and no longer a member of or isn't a member of and now will be a member of. At that point in time, you can essentially use what we call a trigger to say, Eric is now joining segment A. Because Eric's joining segment A, I want to fire off that information, that profile, in these 16 different systems, or I want to fire this webhook, or I want to do something downstream based on that specific signal. So segment entry is one of those. I'm now a member of a segment. Segment exit is one of those signals. So now I'm no longer a member of that segment. Yep. A new trigger, I guess, technically, is flows. We'll go through and talk about flows specifically, but flows is somewhere between segment and attribute. It's a little bit different than its own special thing, but sort of like flow, stage, step membership is also a trigger, but it's all contained kind of within flows, which is in a segment context. But yeah, the triggers are super important in that it's how data gets out of the system and kind of understanding what you can do and what you can't do with them is important. And then also for our jobs, you have the non-trigger base, which is sort of like on a cadence. We're going to go through and just do a scan of the users in that segment and pass it. That's still a possibility as well. But I think more and more, we try to do everything in that sort of real-time streaming system. Every time a trigger happens, it sends to the information. Yeah, the other thing that we probably won't get into very deep here is there are sort of like candidates to be triggered later. So it's the concept of like, maybe we need to look at this profile again in the future. And that's another thing that we look at during the same evaluation. So if one of these custom rules has been inactive for five days, that would be like, as soon as they have any activity, it would make them a candidate to be inactive five days in the future. And that's another thing that happens all at the same time that we're calculating these triggers. #### Key takeaways - Connect **What are "triggers"?** 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. ### Lesson 16 — Data Insights: Building Profiles Quiz #### Lesson text **This lesson is a knowledge check hosted in the Academy LMS.** This companion Markdown contains **no quiz questions, answers, scoring rules, or explanations**. #### Key takeaways - Connect **Data Insights: Building Profiles Quiz** 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. ## Resources & references | Page | Companion Markdown | | --- | --- | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--identity-resolution-recap | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--identity-resolution-recap.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--the-data-pipeline | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--the-data-pipeline.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--leveraging-common-schema | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--leveraging-common-schema.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--customizing-schema | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--customizing-schema.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--the-importance-of-identity-fields | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--the-importance-of-identity-fields.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--publishing-schema-version-control | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--publishing-schema-version-control.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--working-with-apis-csvs | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--working-with-apis-csvs.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--working-with-integrations | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--working-with-integrations.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--identifier-ranks | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--identifier-ranks.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--working-with-warehouse-data | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--working-with-warehouse-data.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--building-lookalike-models | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--building-lookalike-models.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--interest-scores-classification | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--interest-scores-classification.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--example-exploring-classified-content | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--example-exploring-classified-content.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--content-recommendations | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--content-recommendations.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--what-are-triggers | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--what-are-triggers.md | | /courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--quiz | /academy/md/courses/data-insights-data-ingestion-profile-construction/data-insights-course-3--quiz.md | ## Supplement for indexing ### Content summary This course dives deep into the technical architecture of customer profile creation and data unification. You'll master the data processing pipeline and learn advanced techniques for enriching customer understanding thro… This course dives deep into the technical architecture of customer profile creation and data unification. You'll master the data processing pipeline and learn advanced techniques for enriching customer understanding through multiple data sources and intelligent modeling. What You'll Learn This comprehensive session teaches you how to build robust, unified customer profiles using advanced identity resolution, data integration, and enrichment techniques. You'll gain practical experience with schema design, data mapping, and leveraging AI-powered features for deeper customer insights. What We'll Cover We'll explore how identity resolution automatically merges data fragments using shared identifiers like email addresses, demonstrating real-time profile unification in action. You'll master the data processing pipeline architecture, learning to create custom fields ### Retrieval tags - Contentstack Academy - data-insights-data-ingestion-profile-construction - Identity - Resolution - recap - The - Data - Pipeline - Leveraging - Common - Schema - Customizing - fields - mappings ### Indexing notes Chunk at each "### Lesson NN — Title" heading; copy lesson_id and topics from the preceding HTML comment into chunk metadata for RAG filters. Course slug: data-insights-data-ingestion-profile-construction. Union of lesson topic tokens: Identity, Resolution, recap, The, Data, Pipeline, Leveraging, Common, Schema, Customizing, fields, mappings, Importance, Fields, Publishing, Version, Control, Working, with, APIs, CSVs, Integrations, Identifier, Ranks, Warehouse, Building, Lookalike, Models, Interest, Scores, Classification, Example, Exploring, Classified, Content, Recommendations, What, are, triggers, Insights, Profiles, Quiz. Do not embed or retrieve LMS-only quiz items or mastery exam answer keys from this export. ### Asset references | Label | URL | | --- | --- | | Video thumbnail: Identity Resolution (recap) | `https://cdn.jwplayer.com/v2/media/qzUxiNrH/poster.jpg?width=720` | | Video thumbnail: The Data Pipeline | `https://cdn.jwplayer.com/v2/media/iDsatXS7/poster.jpg?width=720` | | Video thumbnail: Leveraging Common Schema | `https://cdn.jwplayer.com/v2/media/IpTB9DvQ/poster.jpg?width=720` | | Video thumbnail: Customizing Schema (fields & mappings) | `https://cdn.jwplayer.com/v2/media/fGpn7GIn/poster.jpg?width=720` | | Video thumbnail: The Importance of "Identity" Fields | `https://cdn.jwplayer.com/v2/media/6luUta7L/poster.jpg?width=720` | | Video thumbnail: Publishing Schema & Version Control | `https://cdn.jwplayer.com/v2/media/PCj1HuBz/poster.jpg?width=720` | | Video thumbnail: Working with APIs & CSVs | `https://cdn.jwplayer.com/v2/media/5OaqXTP0/poster.jpg?width=720` | | Video thumbnail: Working with Integrations | `https://cdn.jwplayer.com/v2/media/gzn6uDlP/poster.jpg?width=720` | | Video thumbnail: Identifier Ranks | `https://cdn.jwplayer.com/v2/media/FFIRINGI/poster.jpg?width=720` | | Video thumbnail: Working w/ Warehouse Data | `https://cdn.jwplayer.com/v2/media/u1mD3rGg/poster.jpg?width=720` | | Video thumbnail: Building Lookalike Models | `https://cdn.jwplayer.com/v2/media/qZ02gNuc/poster.jpg?width=720` | | Video thumbnail: Interest Scores & Classification | `https://cdn.jwplayer.com/v2/media/iRhAPCRQ/poster.jpg?width=720` | | Video thumbnail: Example: Exploring Classified Content | `https://cdn.jwplayer.com/v2/media/r5mEINso/poster.jpg?width=720` | | Video thumbnail: Content Recommendations | `https://cdn.jwplayer.com/v2/media/zt7iltQ2/poster.jpg?width=720` | | Video thumbnail: What are "triggers"? | `https://cdn.jwplayer.com/v2/media/AW2Mx2Bb/poster.jpg?width=720` | ### 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/` |