# Building an Audience ### About this export | Field | Value | | --- | --- | | **content_type** | lesson | | **platform** | contentstack-academy | | **source_url** | https://www.contentstack.com/academy/courses/data-insights-using-profiles-to-power-personalization/data-insights-course-4--building-an-audience | | **course_slug** | data-insights-using-profiles-to-power-personalization | | **lesson_slug** | data-insights-course-4--building-an-audience | | **markdown_file_url** | /academy/md/courses/data-insights-using-profiles-to-power-personalization/data-insights-course-4--building-an-audience.md | | **generated_at** | 2026-04-28T06:55:50.210Z | > Part of **[Using Profiles to Power Personalization](https://www.contentstack.com/academy/courses/data-insights-using-profiles-to-power-personalization)** on Contentstack Academy. **Academy MD v3** — structured for retrieval; no quiz or assessment keys. #### Video details #### At a glance - **Title:** 24-data-insights-building-an-audience - **Duration:** 9m 55s - **Media link:** https://cdn.jwplayer.com/previews/LVm9uAFn - **Publish date (unix):** 1752889734 #### Streaming renditions - application/vnd.apple.mpegurl - audio/mp4 · AAC Audio · 113453 kbps - video/mp4 · 180p · 180p · 127895 kbps - video/mp4 · 270p · 270p · 135135 kbps - video/mp4 · 360p · 360p · 143562 kbps - video/mp4 · 406p · 406p · 148506 kbps - video/mp4 · 540p · 540p · 163364 kbps - video/mp4 · 720p · 720p · 187010 kbps - video/mp4 · 1080p · 1080p · 260143 kbps #### Timed text tracks (delivery) - **thumbnails:** `https://cdn.jwplayer.com/strips/LVm9uAFn-120.vtt` #### Transcript Audience building in Lytx at the core is super easy. Just go into audiences, you'll see all of your existing audiences. Lytx comes pre-built with a number of audiences out of the box. So like if you expand it, you'll see things like anonymous profiles and highly engaged users and some of those kind of things. That's what you'll see in a brand new account on day one without doing anything. And then obviously you can go in here and create any number of custom audiences based on your data, based on your specific use cases. When you go into the audience builder, so when you go to build audiences, there's really only two things to keep in mind kind of at a high level. One, you can build Lytx audiences on existing audiences. So usually we'll call those building block audiences. You can think about a use case where, you know, maybe I have a consent audience or audience of high value users in the U.S. or audience of users who have an email address or whatever it may be. You don't want to redefine that logic every single time that you build a segment that uses, say, your consent rules. So you can go in here, build an audience, and then when you come to build a new audience, you can select essentially any of the existing audiences to include in that logic. So for instance, I can search for, say, like known email, which is one of our out-of-the-box audiences, click that, and it'll add that logic to your segment definition. And then you can stack additional rules and ands and ors and all that kind of stuff on top of it. So keep in mind that you can build audiences on top of other audiences. We try to keep the, like, the depth of those includes. Within reason, customers sometimes can do some crazy things and have, you know, an audience that includes an audience that includes an audience that includes an audience that includes an audience. And sometimes that makes the logic difficult to understand. So I wouldn't go terribly deep on those inclusions as a best practice, but there's not really any hard limitations. When you add either a rule, which we'll do here in a second, or an audience, you'll always be presented with included by default. You can toggle it to exclude. And then these counts on the right hand side are real time. The one thing to note about these counts is under the hood, this gets pulled from Elasticsearch. So sometimes, like, if you're doing live testing and pushing a profile in and then building an audience, these numbers will be slightly delayed compared to the profile view, which reads directly from the actual entity store in Bigtable. So just keep in mind that there's some caching, some delay in the actual calculation of these numbers while the data sort of makes its way to Elasticsearch and whatnot. It really only impacts you if you're, like I said, doing a thing in the UI to collect data and then going to build a segment and expect it to show one. It won't always show one right away or whatever that user number is. But for the most part, the counts are pretty close to real time. I think in my testing last week, it's like 10 to 15 minutes and all of the numbers in the audience query should be up to date. And then the other thing you can do, as long as there's users that come back in the audience, is you can sample recent users. So this will pull up a bunch of anonymous profiles because they don't have names yet, but you can click on one of these and actually go to explore the profile just as you're trying to sort of play with and understand the system. The segments at the core in the UI, at least I should say, are built up of rules and rule sets. So rule sets, just think about it as a group of rules, and then rules are the individual logic. We'll probably in a follow-up conversation, maybe go in under the hood how segments are built and touch on filter QL and some of that, which is like the code, the language, the query that the UI builds. But I think we'll save that for a more technical deep dive. But as an example, if I delete this rule, I can go, one thing I would ignore is this content affinity tab is legacy. You're going to open it and there's generally not going to be any content affinities. This thing's going away in the new builder because we don't use it anymore. So just as you see that sort of ignore and pretend that it's not there. The other thing to be aware of is the custom rules. So this is where all of the attributes that we have walked through how to add and change and manipulate and create on the profile, you can ultimately access them and build whatever logic you want. So if I wanted to, for instance, say like, you know, anybody that has had a page view ever, I could add that condition. And then you could add additional rules to the rule set. So like if I did email exists, these two rules in the UI are essentially linked together. So I can switch it and say I want it to be an or or an and pretty basic sort of stuff. I can include or exclude one of them. And then if I were to add another rule set, it's another group of rules that you can then and an or against that top set of rules. So if I did like score frequency is greater than 10. So now you have this rule set, which contains these two rules that have their sort of independent and or switcher. And then I can adjust the logic of this rule set. If I were to add another rule, say like score frequency is exists, whatever bad rule because they're the same ones. But so now these two things work together. These two things work together. And then you can toggle if you want to use both rules or whatever. So it's it's creating this big essentially like and or statement under the hood, which we can show, but just know that you have rule sets so that you can group logic together. And then you have rules which represent the individual rules to be applied. So then the other thing that I wanted to touch on that will definitely come up. Actually, there's two things. So one, you'll see the show unpopulated fields is automatically checked. So it should be on for everybody. If you happen to uncheck it, it's going to hide all of the fields that don't yet have user data on them. So like if I do this, it's going to hide a bunch of fields that maybe we haven't collected first name, last name stuff that doesn't have information yet. So almost always you're going to want to make sure that this is checked. It should be checked by default, but it's a total gotcha of like, I don't see my field. It's not there. How do I build a segment? It generally means that you don't have any users with data on that yet. And then more importantly, field info, which is sort of a background job, hasn't ran yet to update some of those stats. So just kind of a foot gun to always make sure that that's checked. It's going away in the new builder and it's just on. And then the other thing that is a little bit hairy, we'll say, is it's really, really powerful, but it's also a little bit confusing in the UI to use some of that date calculation logic. So if I choose a field first and foremost, that is a time field. So for instance, like event last time seen is a map of the event name and then the time stamp that you last saw it or the time stamp that you first saw it. So if I go in here, for example, and say I want to look at page view, it's going to bring up the sort of date math calculator for lack of a better term. And the first thing to notice, you can do it based on a relative date. So one that slides with you versus specific date. So if a specific date is I want to evaluate this on June 13th, 2025, I can do that and it does it one time. The relative date allows you to do things like I want to reevaluate this an hour in the future for every user based on that date. What I did, because this is always really complicated to explain, I built a picture to try and explain this, which I can share afterwards as well. But essentially, in this UI, if I go back here just real quick, so there's essentially the relative date and there's after, before, or exists. Exists is super easy in that it just evaluates that that key exists. It doesn't care about the time stamp as long as that key's there. So that's just sort of like a check of I've ever made a purchase as an example. But there's after and before and there's in the past and in the future. So this picture sort of breaks down that logic. So for instance, if I say, after one hour in the future, let's say it's 3 p.m. right now, the green, it's going to look at 4 p.m. for my time and then have any time after that, which probably doesn't have any use cases, but technically you could build it. After one hour in the past is going to look an hour in the past. So 2 p.m. in this case, and then look forward from there, essentially. The before one hour in the past is going to look an hour behind and then any time before that. And then before one hour in the future, goes in the future an hour and then looks backward. All of this is horrifically complicated. One of the things that we're working to do, which you'll see in some of like actions and that kind of thing, is like for cart abandonment, we want to pre-build a segment for you that says, okay, we wanted to pull in anybody that has abandoned a cart in the last 30 minutes and hasn't made a purchase in 24 hours, which is a super simple use case, really difficult to build with this particular logic. So you'll see it in the UI, know that this is one of the big focuses for us and one of the reasons that we're rebuilding the segment builder so that we can simplify a bunch of this logic and make it a little bit more human friendly. However, the power of it is super, super cool and that it can do sort of these forward date calculations to reevaluate in the future to see when you're in that segment or not in that segment versus relying on events to come into the stream. #### Subtitles (WebVTT) ```webvtt WEBVTT 1 00:00:00.000 --> 00:00:18.000 Audience building in Lytx at the core is super easy. 2 00:00:18.000 --> 00:00:21.600 Just go into audiences, you'll see all of your existing audiences. 3 00:00:21.600 --> 00:00:25.600 Lytx comes pre-built with a number of audiences out of the box. 4 00:00:25.600 --> 00:00:29.600 So like if you expand it, you'll see things like anonymous profiles 5 00:00:29.600 --> 00:00:32.400 and highly engaged users and some of those kind of things. 6 00:00:32.400 --> 00:00:36.500 That's what you'll see in a brand new account on day one without doing anything. 7 00:00:36.500 --> 00:00:40.100 And then obviously you can go in here and create any number of custom audiences 8 00:00:40.100 --> 00:00:43.100 based on your data, based on your specific use cases. 9 00:00:43.100 --> 00:00:48.200 When you go into the audience builder, so when you go to build audiences, 10 00:00:48.200 --> 00:00:53.300 there's really only two things to keep in mind kind of at a high level. 11 00:00:53.300 --> 00:00:57.800 One, you can build Lytx audiences on existing audiences. 12 00:00:57.800 --> 00:01:00.900 So usually we'll call those building block audiences. 13 00:01:00.900 --> 00:01:05.600 You can think about a use case where, you know, maybe I have a consent audience 14 00:01:05.600 --> 00:01:08.900 or audience of high value users in the U.S. 15 00:01:08.900 --> 00:01:12.300 or audience of users who have an email address or whatever it may be. 16 00:01:12.300 --> 00:01:16.000 You don't want to redefine that logic every single time that you build a segment 17 00:01:16.000 --> 00:01:18.500 that uses, say, your consent rules. 18 00:01:18.500 --> 00:01:21.000 So you can go in here, build an audience, 19 00:01:21.000 --> 00:01:22.600 and then when you come to build a new audience, 20 00:01:22.600 --> 00:01:26.800 you can select essentially any of the existing audiences to include in that logic. 21 00:01:26.800 --> 00:01:30.900 So for instance, I can search for, say, like known email, 22 00:01:30.900 --> 00:01:33.000 which is one of our out-of-the-box audiences, 23 00:01:33.000 --> 00:01:36.800 click that, and it'll add that logic to your segment definition. 24 00:01:36.800 --> 00:01:39.400 And then you can stack additional rules and ands and ors 25 00:01:39.400 --> 00:01:40.700 and all that kind of stuff on top of it. 26 00:01:40.700 --> 00:01:46.300 So keep in mind that you can build audiences on top of other audiences. 27 00:01:46.300 --> 00:01:51.000 We try to keep the, like, the depth of those includes. 28 00:01:51.000 --> 00:01:54.000 Within reason, customers sometimes can do some crazy things 29 00:01:54.100 --> 00:01:57.000 and have, you know, an audience that includes an audience 30 00:01:57.000 --> 00:01:59.300 that includes an audience that includes an audience that includes an audience. 31 00:01:59.300 --> 00:02:02.000 And sometimes that makes the logic difficult to understand. 32 00:02:02.000 --> 00:02:07.400 So I wouldn't go terribly deep on those inclusions as a best practice, 33 00:02:07.400 --> 00:02:10.100 but there's not really any hard limitations. 34 00:02:10.100 --> 00:02:15.100 When you add either a rule, which we'll do here in a second, or an audience, 35 00:02:15.100 --> 00:02:18.300 you'll always be presented with included by default. 36 00:02:18.300 --> 00:02:20.300 You can toggle it to exclude. 37 00:02:20.300 --> 00:02:23.700 And then these counts on the right hand side are real time. 38 00:02:23.700 --> 00:02:27.400 The one thing to note about these counts is under the hood, 39 00:02:27.400 --> 00:02:29.800 this gets pulled from Elasticsearch. 40 00:02:29.800 --> 00:02:32.800 So sometimes, like, if you're doing live testing 41 00:02:32.800 --> 00:02:35.400 and pushing a profile in and then building an audience, 42 00:02:35.400 --> 00:02:39.000 these numbers will be slightly delayed compared to the profile view, 43 00:02:39.000 --> 00:02:43.400 which reads directly from the actual entity store in Bigtable. 44 00:02:43.400 --> 00:02:45.500 So just keep in mind that there's some caching, 45 00:02:45.500 --> 00:02:49.200 some delay in the actual calculation of these numbers 46 00:02:49.200 --> 00:02:53.000 while the data sort of makes its way to Elasticsearch and whatnot. 47 00:02:53.000 --> 00:02:55.400 It really only impacts you if you're, like I said, 48 00:02:55.400 --> 00:02:57.900 doing a thing in the UI to collect data 49 00:02:57.900 --> 00:03:00.300 and then going to build a segment and expect it to show one. 50 00:03:00.300 --> 00:03:03.900 It won't always show one right away or whatever that user number is. 51 00:03:03.900 --> 00:03:07.700 But for the most part, the counts are pretty close to real time. 52 00:03:07.700 --> 00:03:11.300 I think in my testing last week, it's like 10 to 15 minutes 53 00:03:11.300 --> 00:03:14.800 and all of the numbers in the audience query should be up to date. 54 00:03:14.800 --> 00:03:15.800 And then the other thing you can do, 55 00:03:15.800 --> 00:03:17.700 as long as there's users that come back in the audience, 56 00:03:17.700 --> 00:03:20.000 is you can sample recent users. 57 00:03:20.000 --> 00:03:23.200 So this will pull up a bunch of anonymous profiles 58 00:03:23.200 --> 00:03:24.100 because they don't have names yet, 59 00:03:24.100 --> 00:03:27.000 but you can click on one of these and actually go to explore the profile 60 00:03:27.000 --> 00:03:30.600 just as you're trying to sort of play with and understand the system. 61 00:03:30.600 --> 00:03:35.400 The segments at the core in the UI, 62 00:03:35.400 --> 00:03:39.100 at least I should say, are built up of rules and rule sets. 63 00:03:39.100 --> 00:03:42.300 So rule sets, just think about it as a group of rules, 64 00:03:42.300 --> 00:03:44.900 and then rules are the individual logic. 65 00:03:44.900 --> 00:03:46.800 We'll probably in a follow-up conversation, 66 00:03:46.800 --> 00:03:49.200 maybe go in under the hood how segments are built 67 00:03:49.200 --> 00:03:50.800 and touch on filter QL and some of that, 68 00:03:50.800 --> 00:03:56.100 which is like the code, the language, the query that the UI builds. 69 00:03:56.100 --> 00:04:00.300 But I think we'll save that for a more technical deep dive. 70 00:04:00.300 --> 00:04:04.500 But as an example, if I delete this rule, I can go, 71 00:04:04.500 --> 00:04:07.400 one thing I would ignore is this content affinity tab is legacy. 72 00:04:07.400 --> 00:04:10.300 You're going to open it and there's generally not going to be any content affinities. 73 00:04:10.300 --> 00:04:13.300 This thing's going away in the new builder because we don't use it anymore. 74 00:04:13.300 --> 00:04:17.200 So just as you see that sort of ignore and pretend that it's not there. 75 00:04:17.200 --> 00:04:19.200 The other thing to be aware of is the custom rules. 76 00:04:19.200 --> 00:04:22.700 So this is where all of the attributes that we have walked through how to add 77 00:04:22.700 --> 00:04:24.600 and change and manipulate and create on the profile, 78 00:04:24.600 --> 00:04:27.300 you can ultimately access them and build whatever logic you want. 79 00:04:27.300 --> 00:04:30.600 So if I wanted to, for instance, say like, 80 00:04:30.600 --> 00:04:36.900 you know, anybody that has had a page view ever, I could add that condition. 81 00:04:36.900 --> 00:04:40.500 And then you could add additional rules to the rule set. 82 00:04:40.500 --> 00:04:50.000 So like if I did email exists, these two rules in the UI are essentially linked together. 83 00:04:50.000 --> 00:04:54.900 So I can switch it and say I want it to be an or or an and pretty basic sort of stuff. 84 00:04:54.900 --> 00:04:57.400 I can include or exclude one of them. 85 00:04:57.400 --> 00:04:59.200 And then if I were to add another rule set, 86 00:04:59.200 --> 00:05:03.800 it's another group of rules that you can then and an or against that top set of rules. 87 00:05:03.800 --> 00:05:10.500 So if I did like score frequency is greater than 10. 88 00:05:10.500 --> 00:05:14.100 So now you have this rule set, 89 00:05:14.100 --> 00:05:18.600 which contains these two rules that have their sort of independent and or switcher. 90 00:05:18.600 --> 00:05:22.300 And then I can adjust the logic of this rule set. 91 00:05:22.300 --> 00:05:29.100 If I were to add another rule, say like score frequency is exists, 92 00:05:29.100 --> 00:05:30.600 whatever bad rule because they're the same ones. 93 00:05:30.600 --> 00:05:32.900 But so now these two things work together. 94 00:05:32.900 --> 00:05:34.000 These two things work together. 95 00:05:34.000 --> 00:05:36.400 And then you can toggle if you want to use both rules or whatever. 96 00:05:36.400 --> 00:05:40.200 So it's it's creating this big essentially like and or statement under the hood, 97 00:05:40.200 --> 00:05:45.500 which we can show, but just know that you have rule sets so that you can group logic together. 98 00:05:45.500 --> 00:05:52.000 And then you have rules which represent the individual rules to be applied. 99 00:05:52.000 --> 00:05:57.100 So then the other thing that I wanted to touch on that will definitely come up. 100 00:05:57.100 --> 00:06:02.500 Actually, there's two things. So one, you'll see the show unpopulated fields is automatically checked. 101 00:06:02.500 --> 00:06:06.300 So it should be on for everybody. If you happen to uncheck it, 102 00:06:06.300 --> 00:06:10.800 it's going to hide all of the fields that don't yet have user data on them. 103 00:06:10.800 --> 00:06:16.100 So like if I do this, it's going to hide a bunch of fields that maybe we haven't collected first name, 104 00:06:16.100 --> 00:06:18.200 last name stuff that doesn't have information yet. 105 00:06:18.200 --> 00:06:22.100 So almost always you're going to want to make sure that this is checked. 106 00:06:22.100 --> 00:06:26.000 It should be checked by default, but it's a total gotcha of like, I don't see my field. It's not there. 107 00:06:26.000 --> 00:06:31.400 How do I build a segment? It generally means that you don't have any users with data on that yet. 108 00:06:31.400 --> 00:06:33.900 And then more importantly, field info, which is sort of a background job, 109 00:06:33.900 --> 00:06:35.900 hasn't ran yet to update some of those stats. 110 00:06:35.900 --> 00:06:39.100 So just kind of a foot gun to always make sure that that's checked. 111 00:06:39.100 --> 00:06:42.300 It's going away in the new builder and it's just on. 112 00:06:42.300 --> 00:06:49.900 And then the other thing that is a little bit hairy, we'll say, is it's really, really powerful, 113 00:06:49.900 --> 00:06:54.800 but it's also a little bit confusing in the UI to use some of that date calculation logic. 114 00:06:54.800 --> 00:06:59.000 So if I choose a field first and foremost, that is a time field. 115 00:06:59.100 --> 00:07:03.700 So for instance, like event last time seen is a map of the event name 116 00:07:03.700 --> 00:07:07.900 and then the time stamp that you last saw it or the time stamp that you first saw it. 117 00:07:07.900 --> 00:07:12.600 So if I go in here, for example, and say I want to look at page view, 118 00:07:12.600 --> 00:07:18.800 it's going to bring up the sort of date math calculator for lack of a better term. 119 00:07:18.800 --> 00:07:22.300 And the first thing to notice, you can do it based on a relative date. 120 00:07:22.300 --> 00:07:25.600 So one that slides with you versus specific date. 121 00:07:25.600 --> 00:07:30.000 So if a specific date is I want to evaluate this on June 13th, 2025, 122 00:07:30.000 --> 00:07:32.000 I can do that and it does it one time. 123 00:07:32.000 --> 00:07:39.000 The relative date allows you to do things like I want to reevaluate this an hour in the future 124 00:07:39.000 --> 00:07:41.500 for every user based on that date. 125 00:07:41.500 --> 00:07:46.300 What I did, because this is always really complicated to explain, 126 00:07:46.300 --> 00:07:51.900 I built a picture to try and explain this, which I can share afterwards as well. 127 00:07:51.900 --> 00:07:57.200 But essentially, in this UI, if I go back here just real quick, 128 00:07:57.200 --> 00:08:02.600 so there's essentially the relative date and there's after, before, or exists. 129 00:08:02.600 --> 00:08:05.700 Exists is super easy in that it just evaluates that that key exists. 130 00:08:05.700 --> 00:08:07.900 It doesn't care about the time stamp as long as that key's there. 131 00:08:07.900 --> 00:08:13.000 So that's just sort of like a check of I've ever made a purchase as an example. 132 00:08:13.000 --> 00:08:17.000 But there's after and before and there's in the past and in the future. 133 00:08:17.000 --> 00:08:22.300 So this picture sort of breaks down that logic. 134 00:08:22.300 --> 00:08:26.200 So for instance, if I say, after one hour in the future, 135 00:08:26.200 --> 00:08:29.100 let's say it's 3 p.m. right now, the green, 136 00:08:29.100 --> 00:08:33.900 it's going to look at 4 p.m. for my time and then have any time after that, 137 00:08:33.900 --> 00:08:38.500 which probably doesn't have any use cases, but technically you could build it. 138 00:08:38.500 --> 00:08:42.600 After one hour in the past is going to look an hour in the past. 139 00:08:42.600 --> 00:08:48.000 So 2 p.m. in this case, and then look forward from there, essentially. 140 00:08:48.000 --> 00:08:52.300 The before one hour in the past is going to look an hour behind 141 00:08:52.300 --> 00:08:54.200 and then any time before that. 142 00:08:54.200 --> 00:08:58.300 And then before one hour in the future, 143 00:08:58.300 --> 00:09:00.500 goes in the future an hour and then looks backward. 144 00:09:00.500 --> 00:09:03.000 All of this is horrifically complicated. 145 00:09:03.000 --> 00:09:04.500 One of the things that we're working to do, 146 00:09:04.500 --> 00:09:06.500 which you'll see in some of like actions and that kind of thing, 147 00:09:06.500 --> 00:09:08.300 is like for cart abandonment, 148 00:09:08.300 --> 00:09:10.800 we want to pre-build a segment for you that says, 149 00:09:10.800 --> 00:09:14.800 okay, we wanted to pull in anybody that has abandoned a cart in the last 30 minutes 150 00:09:14.800 --> 00:09:16.800 and hasn't made a purchase in 24 hours, 151 00:09:16.800 --> 00:09:18.700 which is a super simple use case, 152 00:09:18.700 --> 00:09:21.500 really difficult to build with this particular logic. 153 00:09:21.500 --> 00:09:26.800 So you'll see it in the UI, know that this is one of the big focuses for us 154 00:09:26.800 --> 00:09:29.100 and one of the reasons that we're rebuilding the segment builder 155 00:09:29.100 --> 00:09:30.900 so that we can simplify a bunch of this logic 156 00:09:30.900 --> 00:09:34.300 and make it a little bit more human friendly. 157 00:09:34.300 --> 00:09:37.500 However, the power of it is super, super cool 158 00:09:37.500 --> 00:09:40.000 and that it can do sort of these forward date calculations 159 00:09:40.100 --> 00:09:42.700 to reevaluate in the future to see when you're in that segment 160 00:09:42.700 --> 00:09:46.100 or not in that segment versus relying on events to come into the stream. ``` ```transcript [00:00] Audience building in Lytx at the core is super easy. [00:18] Just go into audiences, you'll see all of your existing audiences. [00:21] Lytx comes pre-built with a number of audiences out of the box. [00:25] So like if you expand it, you'll see things like anonymous profiles [00:29] and highly engaged users and some of those kind of things. [00:32] That's what you'll see in a brand new account on day one without doing anything. [00:36] And then obviously you can go in here and create any number of custom audiences [00:40] based on your data, based on your specific use cases. [00:43] When you go into the audience builder, so when you go to build audiences, [00:48] there's really only two things to keep in mind kind of at a high level. [00:53] One, you can build Lytx audiences on existing audiences. [00:57] So usually we'll call those building block audiences. [01:00] You can think about a use case where, you know, maybe I have a consent audience [01:05] or audience of high value users in the U.S. [01:08] or audience of users who have an email address or whatever it may be. [01:12] You don't want to redefine that logic every single time that you build a segment [01:16] that uses, say, your consent rules. [01:18] So you can go in here, build an audience, [01:21] and then when you come to build a new audience, [01:22] you can select essentially any of the existing audiences to include in that logic. [01:26] So for instance, I can search for, say, like known email, [01:30] which is one of our out-of-the-box audiences, [01:33] click that, and it'll add that logic to your segment definition. [01:36] And then you can stack additional rules and ands and ors [01:39] and all that kind of stuff on top of it. [01:40] So keep in mind that you can build audiences on top of other audiences. [01:46] We try to keep the, like, the depth of those includes. [01:51] Within reason, customers sometimes can do some crazy things [01:54] and have, you know, an audience that includes an audience [01:57] that includes an audience that includes an audience that includes an audience. [01:59] And sometimes that makes the logic difficult to understand. [02:02] So I wouldn't go terribly deep on those inclusions as a best practice, [02:07] but there's not really any hard limitations. [02:10] When you add either a rule, which we'll do here in a second, or an audience, [02:15] you'll always be presented with included by default. [02:18] You can toggle it to exclude. [02:20] And then these counts on the right hand side are real time. [02:23] The one thing to note about these counts is under the hood, [02:27] this gets pulled from Elasticsearch. [02:29] So sometimes, like, if you're doing live testing [02:32] and pushing a profile in and then building an audience, [02:35] these numbers will be slightly delayed compared to the profile view, [02:39] which reads directly from the actual entity store in Bigtable. [02:43] So just keep in mind that there's some caching, [02:45] some delay in the actual calculation of these numbers [02:49] while the data sort of makes its way to Elasticsearch and whatnot. [02:53] It really only impacts you if you're, like I said, [02:55] doing a thing in the UI to collect data [02:57] and then going to build a segment and expect it to show one. [03:00] It won't always show one right away or whatever that user number is. [03:03] But for the most part, the counts are pretty close to real time. [03:07] I think in my testing last week, it's like 10 to 15 minutes [03:11] and all of the numbers in the audience query should be up to date. [03:14] And then the other thing you can do, [03:15] as long as there's users that come back in the audience, [03:17] is you can sample recent users. [03:20] So this will pull up a bunch of anonymous profiles [03:23] because they don't have names yet, [03:24] but you can click on one of these and actually go to explore the profile [03:27] just as you're trying to sort of play with and understand the system. ``` #### Key takeaways - Connect **Building an Audience** back to your stack configuration before moving to the next module. - Capture one concrete artifact (screenshot, Postman call, or code snippet) that proves the step works in your environment. - Re-read the delivery versus management boundary for anything you changed in the entry model. ## Supplement for indexing ### Content summary Building an Audience. Building an Audience in Using Profiles to Power Personalization (data-insights-using-profiles-to-power-personalization). ### Retrieval tags - Building - Audience - data-insights-using-profiles-to-power-personalization - lesson 01 - Building an Audience - data-insights-using-profiles-to-power-personalization lesson ### Indexing notes Index this lesson as a primary chunk tagged with lesson_id "01" and topics: [Building, Audience]. Parent course slug: data-insights-using-profiles-to-power-personalization. Use asset_references URLs as thumbnail hints in search results when present. Never surface LMS quiz content or assessment answers from this file. ### Asset references | Label | URL | | --- | --- | | Video thumbnail: Building an Audience | `https://cdn.jwplayer.com/v2/media/LVm9uAFn/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/` |