Ă۶ąĘÓƵ

Transcript

Hello, everyone. Thanks for joining. We’ll be starting in the next couple of minutes.

Today’s session is focusing on sequential segmentation and being led by Andy Powers. So we’ll just allow a few more minutes for people to file in.

Here’s an overview of the forthcoming sessions in this series, wide variety of topics and solutions that we’re covering. So I’ll leave it up there on the screen. You can have a look at what might be interesting to you in the future.

There’s a longer list and I’ll just put that in the chat.

You can click on any of the ones that take your interest.

So I think it’s probably time to get started. That’s given us five minutes for everyone to come into the session. So this session is on sequential segmentation. It’s being led by Andy Powers. I’ll hand over to him to continue the start, the actual content for this session.

Sounds great. Thank you, Richard. Let me bring up my agenda and also give a quick introduction for myself. So I’m part of the Ultimate Success team along with Richard and our other hosts.

My expertise is mostly in analytics and CJA, also in Journey Optimizer and Experience Platform. But I’ve done a lot of focus over the last couple of decades on analytics tools and especially using segmentation or filters and CJA to slice and dice data really carefully. So this is the third webinar in our series on this topic. And today we’re going to look at… Let me switch to see my internal presenter view. Okay. So we’re going to… In all these, I need to start off with a quick review just to bring back to mind some of those concepts what we’re talking about. We’re going to revisit a use case where the idea is we want to analyze every sequence and something that happened after every sequence. We’ll give the details on that and what that means and how you can apply it. We’re going to talk about the theme mentioned here, starting and stopping. So far we’ve talked about things for starting and doing some sequential logic, but today we’re really introducing the idea of how you stop and make repeat segment matches. And we’ll look at some demos or live examples of fake demo data, of course, and then we’ll wrap up.

So the goal… What I want you to get out of today, the goal is to understand how to… In analytics or CJA, how to configure a sequence that is some behavior of interest that you want to analyze for your customers or whoever your data set is comprised of, where they start and stop at points of interest. So we’ll be able to say, if someone submitted an application, I want to study the point between that and the next session of engagements they have with us. And I want to do it if they had five separate applications, no matter when they happen. So we’ll do the review, make sure we’re clear on communication and how to talk about these things. Then we’ll talk about the way we accomplish the starts and stops kind of theme, which is with only before, only after, combined with exclude logic, and then look at use cases in the samples. Again, as with other sessions, I don’t expect a lot of time for Q&A here, but I would like you to use… If you put things in chat, I can review them later or you can reach out to your TAM or CSM. And when we submit our poll at the end for feedback, feel free to put in topics of interest there as well. Oh, and of course the webinar materials will be shared with all of you attending and this session is recorded. So this is our third session. The first one was some foundational elements, kind of basics and simple operations. The second was really talking about how to think visually and understand what this logic is doing and how to use it. And then today is starting and stopping with precision. The links to those recordings and to blog posts are also available in the meeting abstract as well as the materials you’ll receive afterward. We’re creating a blog series that’s essentially a kind of lagging documented form of webinar content, but I’m pretty behind on that while getting ready for a summit and for this session. So there’s only one post so far, but I have more ready to go shortly. For today, I would say that to get the post out of this, it’s very helpful if you can refresh yourself on the prior topics from previous webinars. And then also just to really adopt some of these techniques, we’re now doing some very advanced things. It really takes some comfort, some moderate experience with our toolset, with segmentation, trying to use the sequential operators to do some of the earlier use cases we’ve prescribed. That’s really what you’ll need to be able to start applying this in your environment because learning about it from another person is half of it or some portion of it, but trying it yourself and then seeing where your assumptions didn’t match the results, that’s where you need to go to be able to really apply this for your use cases. However, you can also get a lot out of this just by thinking a strategic level of what things are possible, what you can have your analytics or CJA data and get answers to and have your practitioner team execute on your behalf. Because the audience is going to be those who use Ă۶ąĘÓƵ Analytics, traditional analytics, as well as CJA, we’re always going to be sharing terms because the kind of hierarchy behind both of them is very similar and the approaches to sequential logic can be applied in either interface. So visitor person, session visit, hit, event record, we’ll use all those, but all the concepts can be applied whether it’s just digital web analytics focused or a customer journey cross channel environment. So I’m calling this a quick review because I need to touch on a bunch of things and make sure that we’re up to speed together to then apply it to this new concept. Data comes into analytics and CJA with a bunch of timestamps and some sort of person identifier.

At its basis level, one of the things that the platforms do is organize the data by timestamp and by its person identifier. Person, if we know who it is, unique cookie ID if we don’t, and we’re going to have each of these representing a hit or an event that have some attributes on them. We’re going to be able to identify sessions or visits that are periods of activity bounded by periods of inactivity and we’ll also be able to study visitors holistically as well. The idea of a segment or a filter is just a powerful way to apply complex logic to study subsets of your business questions are going to require you to use your global data set that covers all regions and all product lines and whatever else you have collected. There’s a lot to know and use that’s not even sequential about it. We have ways to define the scope we’re looking at. Are we looking at all of a person’s activity? Are we going to look at just part of a session or visit of activity? We can add lots of conditions with lots of operators for that. We can say kind of negation exclude or include conditions. But on the sequential side we have a lot more and this is where the series has been going. So we can set checkpoints that need to occur in sequence. We can say the proximity they need to be to one another. We can say don’t allow this checkpoint to have been seen in this sequence and it lets you apply to business questions like what do people do on their next engagement with a brand after they submit an application? Or how many people went to the website then to the app then closed their account? Basic controls we have then lets us just say I want to see the visits where we saw a web and email interaction occurred and web needs to precede email. So if we look at this some fake data web hits email hits across three sessions for one visitor. We’ll see it’s evaluated we look for a web hit then we look for email following web we find it. That means this session is going to be returned in our result. We look at another session for that visitor web followed by email good we’ll return that and here we have a web interaction not followed by email so that would not match. And the result that we can analyze then is just just the behaviors of interest where they met the conditions we care about.

We can up level it to a person level and just say if I ever saw one web followed by email give me all that person data to study. We can look at it with time-based controls. So these two checkpoints need to be separated by at least one day but no more than two days. So this web here doesn’t see an application activity within that second day period so it doesn’t match while this web here does see an app interaction within the second day period matches and we get all the person data back to study. We can look at the sequences that happened before. So here we’re going to look for the subset of our customer’s data happens before and up to when we saw this pattern web then mobile app. So here we see web then mobile app and our return is set to give us only the things that came before that sequence. So we get this and again for those of you who may be joining late this is like a quick review to just get up to speed because the topics today are definitely in the like intermediate to advanced category. So I’m just setting some groundwork again on how we’re communicating ideas and just kind of the basic ways that you can influence sequential logic. As I’ve noted other times too it can help for only before to think of it backwards. You know do I see an app preceded by a web hit? I do. Then we’re going to match that and everything before it. And keep in mind too that the idea of segment logic is always greedy. It’s going to give us the largest possible return. So rather than this I’m going to probably for this I am going to for this pseudo data get this larger return because this combination of an app interaction and a web interaction gives me the largest result. So the idea of greedy returns is important to keep in mind. And then the last thing as part of the recap we can add exclusive criteria that say let me study the people who touched web but never touched email afterward. So this web followed by email so it doesn’t qualify but here I have a web activity that’s not followed by email. So this condition is met and I get to study all the data coming back for that person.

The use case we looked at last time that I want to revisit is the idea of we want to understand our customers after some point of interest. In this case we’ll say it’s submitting an application. We would like to study what they do when they return to engage with the brand afterward. So we would like to see the first visit back, the second visit or second session after an application. What are they doing? And it needs to work for all our customers even though they all apply at different dates and different times. They may return at different dates and times. So we define this process to let us think through you know high level business question, turning it into chunks of logic, making a test plan, validating those and so forth. In the end this is where we wrapped up last webinar. So we were looking at the idea that we can find the first session after an application like this. This is some customer behavior. They have an application and our goal is to get this session here. So we said we know how to identify this. We can identify this point and return only after results from that point on. We know how to identify this point and return everything after that point on. So if we take this result and we exclude the results of this second approach then we can end up with what we want. We looked at that logic here together. So here I’m looking at visit data with my only after flag set. There’s an app submitted and then we use this idea of day exists to just give us any other activity happened and it needs to be in a separate session because this is a session level container. We did the same thing to find what happened after we skip a session from application. We used the after one session modifier here and then our result was just to do the negation that was shown through that visual. We took our first result set and excluded this red bar here, excluded the second result.

We applied these samples last time in a CJA demo environment where we could see things like for some person they had some activities in April, 14 different sessions. Three of those were application activities, sessions that had an application submitted. We were able to identify that starting with the other two sessions here and containing all their subsequent data through the 10th through the 25th, this is our first kind of sub-segment building block. This was our second and when we subtracted this from the first we ended up with just the first session after the application. So that brings us to today and now we can take a breather and look through things more slowly and in more detail and show the new techniques that I have for today. So what if you have multiple applications? If I have a customer who has an application this first session and in this third session I want to see what they did after an application so it means I’m interested here. It also means I’m interested here probably, maybe. It depends but so far the logic we talked about is only going to result in this because of the greedy nature of it. Here we’re going to get back all this data after the first application. Here we’re going to get back all the data after the first application skipping a session forward. So we need a different approach if we’re going to try to get the activities that happened following a point of interest that occurs many times for any given customer. Another point is what do we do if not only we have multiples but if they overlap how do we want to handle that? We know that this is a session we’d like to study to see what people did after an application submit. We know we want to study this one after this application submit. Do you also want to study this where it’s actually going to contain a different app submit but it’s going to be qualifying because it followed this one? So the point of all this is to say there’s more questions that we need to think through together and this goes into one of the steps in the process. It’s going to be things like all right if we want to know activities that happened relative to some point there’s going to probably be more questions than you may have come to the table with initially. Do we want to look at the past or some z-th time that that happened within the reporting window? Do we need to add some criteria to just identify one time that we care about or do we want to see all the times that this happened in the session after every application if they made five applications for say different credit card accounts? What do we want to do for overlaps? Should we include or exclude the original point of interest? Do we want to include persisting values or instances? So there’s a lot of questions that will come up and need clarification and it all is really going to kind of land this step three. We need to think about what are all the ways that things could go wrong or go against our assumptions here. So places where something like this where we want to match every time we see a sequence where the sequence can occur multiple times might be like what are the common behaviors after someone makes any purchase or what are the common behaviors prior to any negative review or negative brand interaction across any channel? Things where you may want to study say for product one two three what are the things that people do in the subsequent actions when they return to our app but sometimes some of the analysis and insights we want about customers is generalized when they do activity x then what happens and it doesn’t matter whether it was a little bit different in one instance than another we just want to know about the pattern. What’s a typical period between some point of interest and another point of interest or what are the first things they do on when they come to our store what is the next channel within a day after they log a support call all those things could happen more than once and we’re interested to know the common behaviors for those scenarios. So if we update our use case that we’re going to follow here and the rest of the session we really want to see I’m going to assume that in this case we would like to find out for all such scenarios what did they do the session after any application submit not just the first one so every time they submit application we want to be able to study the first visit successive to that the second visit out from that and see what behaviors differed no matter how many quantity of applications occur.

So we’re good at controlling the start point so far we can match from some point forward or backward with only after sequence and only before sequence but the piece that we need to add on is a way to say and if you reach this later checkpoint condition stop matching just give me something kind of to negate the greediness sort of I mean it’s not the same thing but to say look at the data between point A and point B but not after point B so that’s the theme for today the stopping the way that we do this is by combining only after sequences where we kind of do our start point for some subset of behaviors and adding in the excludes to do a stop scenario so as defined here this is going to be a subset of some person’s data we’re going to look for the point where they touched web and then touched mobile app and we’re going to match everything from that sequence on due to only after sequence until if until we see an email activity the result of this is going to be event level it’s not really a person it’s not really a visit it’s it’s going to be all the data from when that app followed web up to and including any activities till we see an email it’s going to qualify if this happened five times or one time in a reporting window for our analysis and note that it does not include the email checkpoint so like we’ve done with other sessions I’m going to go through and introduce these you know kind of talk about this theory of what it does and then we’ll apply it and look at examples to kind of prove it out and show how it makes more sense and what it’s like in the tools another way we could do this is with the opposite only before sequence adding excludes in here so this would be the subset of someone’s data before we saw the sequence of web the nap but not going back any earlier than if we see some email activity again the result’s not a person it’s some event sequence and as I mentioned before with only before it can help to think of it going in reverse order so going back in time if we saw app and then before that I saw web we start matching that data and we’ll get to see everything from that web point prior until they hit email as many times as happened it also lets us do something cool where we no longer need as many checkpoints to identify a sequence or a a pseudo sequence of interest so here it just takes two checkpoints even if one of them is an exclude to be able to open up the then operator for analysis so here this is going to give us the subset of someone’s data beginning with the single checkpoint sequence that a web event happened and stopping if there’s an email touch seen in the future it’s this sequence that we’re looking for it’s it’s a single checkpoint sequence it’s just web so it’s going to at a minimum return back all the web data web activities for this person as well as anything that went after web until it sees an email result so this can be useful because sometimes we don’t want to do what we’re doing in our use case today we want to say point of interest let’s skip out to some later point start matching there and then stop later this lets us say i see the point of interest let’s start matching right here and then continue until i want to stop applications for this i can’t i don’t have enough time today to squeeze in but it’s part of what i intend for the next session which is now we’ve introduced all these concepts including advanced ones my next webinar plan would be just just applications and templates of all these things together and this is one that i would share as well in more detail the way that all this only after sequence and only before sequence works it’s always based on all the inclusive checkpoints being found in a sequence here it’s just one before we had two as soon as all those then checkpoints that are includes not excludes are met then it starts to match the data and it’ll continue until it reaches the end of the person or visit data set or it hits an exclude this works as well with after so here we’re going to look for web match everything within a week of web and then stop if we see email afterward so here this lets us kind of say we’re definitely going to get web and extend the results to always get the week after web and even if we have overlapping again the greedy results are going to give us the the largest possible return we can do the opposite to with within so here we’re limiting the scope of when an email can stop our matching here so if we’re looking at our person’s data and they have a web touch and then in the next week they don’t have an email touch we’re going to match everything from that web on till the end of their visitor sequence in our reporting window principles then examples all the includes need to be matched in the sequence or it need to be encountered in this right sequence to begin matching event data it’s going to continue in the direction you selected based on only after only before until it may see the exclude checkpoint condition triggered which at which point that will stop if that sequence occurs multiple times in the result and you’re often going to need to apply within and after conditions to force some more proximity anytime you try something new with this it’s important to validate it it’s very much common to mistake assumptions about your data or mistake the attempt you have to build the segment or filter of interest so let’s talk about how some of this runs only after sequence with exclude we want to see web then mobile app then exclude email so we see web we see mobile app that matches all our include conditions and now we’re going to start matching from then on after until we see an email you see the email next so this is the only data point returned web followed by email curse web followed by app excuse me occurs here we’re going to keep matching up until if we see an email so this is going to be the result and here web is not followed by app so we don’t get anything at the end that that is accurate but it’s not the whole story because it’s not greedy enough consider yes we can have this web and this app and then the email will stop it but our logic also this web then this app there’s no thing here telling us that these need to be next to each other so if we match this sequence it’s going to give us a lot more data it’s going to stop at this email here it’s also going to find this sequence this is web followed by app and there’s no email afterward so this is going to give us a very unexpected result and the validation part is key here even building the material and examples here i hit this twice even though i’ve done it a lot and practiced with it a lot i still forgot coming back to it that i’m going to need to do something like include it within or after to make things a little more strict and do what i want so here let’s add within one event and this is going to say just look at the points where i had web immediately followed by app let’s pretend that that meets our true business requirement in this scenario web the nap matches stops at email web not followed by app doesn’t match web followed by app matches but it’s not going to include this web looking any farther than the next event it’s going to automatically fail so it’s not going to get that web and then a downstream app 10 hits later same thing for this web it’s not going to match here although it wouldn’t have changed the results this is how the logic works it’s looking for every single possible sequence of checkpoints that matches your inclusive conditions here and then giving you the result and modifying it if you have an exclude in there it’s more efficient than that but efficiency aside that’s what it’s doing so that’s how you need to think of it and test against it so by using the within we’re decreasing the window we’re adding some strictness for what could match in that mobile app checkpoint number two if we do the only before kind of think of this in that backwards method app preceded by web start matching and go before that we hit email we stop app preceded by web start matching go before that hit email stop so there’s a lot of combinations here of app and web this app is preceded by this web hit it’s also preceded by this web hit kind of that like long unexpected pattern that we saw before but you can see that really it’s kind of your your ending checkpoint your concluding checkpoint here that really matters for what data you’re going to get back in this case i mean since we’re looking backwards it’s this web hit if we were looking forward so it would be different but you’ll get a feel for you know here it’s much more dependent on where the web hits occur because i need to see app and i need to see web so that’s kind of my my limiting uh required checkpoint let’s go back to end session after every moment of interest so again every time someone submits an application what do they do the first session after second session after we’re always going to think this as what is my start and stop point in my logic for this app i want to see this session this is what i want to study what are the behaviors that happen following the application event i need to start matching here i need to use you know however i identify that logically and i need to set my stop on wherever i want it to not include so here it’s the following session in this case for this app i want to get this session back i need to start my logic on this stop it here and then also for this application i want to get back this session so i want to start my logic here and i could the stop is just not going to have any effect because i know for this visitor data set that they don’t have anything further it’s not going to meet a stop it’s just going to match this and then it’s the end of the visitor data so doing this the idea is to help us think about the ways that these can happen potential overlaps potential oddities and try to clearly define what is our start condition we want the nearest event within one session after our application session and what is our stop criteria the nearest event after the session that contained this start checkpoint when we do this kind of start and stop approach where we throw the exclude in there we’re going to have our stop point be relative to our starting point because we’re going to make this in one nice concise sequential segment that says you know a then b then stop at c so we’re not going to do our approach before where we had this long result and we subtracted this long result but we can use that to build what we want here this is the pivot point for this condition and that’s really where we want to start and this stop to get at least this result here so if we probably look at the logic that’s used in these two examples we can probably find some pieces to pull out for our goal here’s another way to think of it similar patterns of the data so here app visit next visit that i want subsequent visit app visit next visit i want subsequent visit app visit next visit i want no subsequent if we think of these as kind of shared attributes and we rearrange them what we’re trying to do is scan app activity start on the next session stop on the session following that i don’t know that this is really a huge different way to think about it but i thought it’d be helpful visually to give another way to see it and envision how you’re kind of trying to identify the logic that does these conditions so before when we were doing it after just the first application of a visitor’s lifetime we did things like we used only after sequence we looked for an app submission condition who made sure this was at a visit session level and then we used this day exists to just say you know the next time stamped event that i see which is all events all hits all our data and this one the one we subtracted out we added in this after one session so we’re probably going to use similar things only after it’s probably going to come in app submission of course probably day exists and then after or within one session likely as well and we’re well we know we’re going to add in something to exclude so we’re going to play with those elements that i mentioned i want to start after the app session and then stop on the next one so look for the app within a session and then within the next session start matching as soon as i see any data in the next session here this is going to have the same result since both of these are session level it’s basically all these settings here the well these two here to ensure that this is happening separate sessions not just separate events or hits and this one is to enforce that it’s it’s just the next one it’s not that scenario where the 10th session down still matches like we had in our mistaken approach earlier and then we’re going to add exclude anything that comes in the session following that so day exists is just the generic way to say the next data within one session is going to force it to begin in the very next session or else it doesn’t qualify and the exclude checkpoints are kind of naturally strict so we don’t need to throw in another within one session here for the exclude exclude is going to sort of be greedy in the opposite direction as soon as something qualifies it excludes and that’s that’s the end of that so here imagine app we’re getting out of this session and now we’re starting to look for the next session this is where our day exists occurs within one session now we’re only after sequence so we’re going to keep on matching until we get to the next session where we see any hit and we’re going to stop matching so it’s going to stop here and our result is going to be that visit after our app here similarly app visit we hop to the next visit and start looking for a match and we find a hit exists start matching there we continue to the end of the visit and then there’s nothing else so the stop doesn’t come into play but we still get the result that we want this app never is followed by another session so this app doesn’t really play a role think about what would happen if we remove that within so here app this session is going to qualify we’re going to match and stop on the next one just like earlier but it’s also going to do that thing where this is a session with app this is a session with app following the first and so we’re going to get that result and it’s going to do it for this and we’re going to get this long set of data not what we want so let’s go and look at here let me minimize this for a moment i’m looking at person g i searched through my data in cja found someone with some attributes that i could study and selected them here i’m looking at days and their number of sessions so they have 13 sessions in my april window three of those had applications in them i have here for comparison the result from last session or last where we were looking at the the session following the first app only and then here i have the logic to say give us this session that’s after all each of their applications so if i open this up i’m going to make one change i’m going to sort this and try to get rid of the excess dates select those display only those okay so 14 sessions these three one on the 6th 1 10th one of the three on the 22nd had applications so this is the first session it’s going to be one of the other two here i’m let’s assume maybe this was the first session on april 6 this is going to be the second session coming back for us to study and here in our approach for this whole start stop exclude business we’re going to see that session yes but we’re also going to see the next one relative to this application submit which is going to happen on the 20th so we’re going to see that 20th come available for analysis and here’s another one that happened on the 22nd it must be either the first or second on that date because they had three and our match here is still for the 22nd i look at another example this person at 18 sessions four submits here we get just the session following their first application only this one but here we get this activity following that first application activity corresponding to following this one and then here this must have been the ladder of their two activities on the 22nd so we’re getting one of these sessions here and also they had one on this date with four others so we’re actually getting two different sessions coming back for this example if we extend it let’s look at it like this so here what i’m doing slightly different view where we’ve sort of scaled this up 14 sessions for person g three apps submitted now we’re just looking at our new approach just everything after each application we get the session the first session after each the second session after each the third session after each the fourth session after each so i’m going to show what this looks like i think i have it on my other screen yes so this is how we did it before just to look at that first application of interest and here now we’re using this model much simpler and it’s giving us more of that kind of broad data we want each of these in my example is just saying within or after the right number of sessions to give us the next one or the second one now so here this app submit has one following it here this has one following here this has one following it there if we look up two sessions this one is now showing up here this is going to be the third activity from april 22nd and you’re just going to see this cascading effect and the only way i’ve displayed it like this is just this is really helpful it gives us a benchmark to validate i have some small set of data whose characteristics i know i have a variety i have four different people who have different characteristics including overlaps and i can see too here that once i start going out too far the fourth session after each application i’m going to start not matching some because they ran out of data so this one if i try to go out for later and look at the session four sessions afterward to see what they do you know fourth time they come back to our brand i’m actually not matching anything because we went through all these and there was nothing that matched so at this point i’m only going to get these two to study if i applied it at scale for all our data and stop this subset to a particular person i would see something like this here we’re not subsetting to a particular person we’re just being able to study it’s going to look weird because this is fake demo data but in this case we know that a lot of the application submits here in our window were followed with other sessions in this next week or so then our demo data did something weird here where these people only happen to have single sessions and didn’t back again until later but the big way you’d use this is in something like this application not against day days for validating here we’re saying let’s look at content what content is resonating when their next interaction occurs what is resonating three interactions out we can change it to use days to use different instances and it’s going to work as many times as they did this moment of interest even if it was two or a hundred by using this relative analysis method we can see that it’s demo data it doesn’t make any sense but forum high in value or you know at least relevant to visitor interest soon after application then less relevant but then they come back again at a higher percentage after more time has passed we can use that to understand our customers better and design journeys that suit them better so this is the way we would apply it so it’s so much to get through and we have an hour with a few minutes left today what i want you to do is we can define starting and stopping points here we can use logic pretty succinctly to do very powerful things that otherwise are going to be requiring sql and bi team to interpret a business request and translate it you can take a pattern like this and explore it in your own data set you can do the one here this can be applicable to you you’re just going to want to exchange some point of interest and then start doing comparisons and seeing what follows that next session if you want to just replicate this another good way to do it is next day both of those are kind of easy to validate so we can do this for all the times across their life cycle that they had some engagement so what are the behaviors common to every application event and then on the other side we could also say make this a little more strict and look at what about product x applications product y applications what are the behaviors that follow those so that would take a change to your logic to do that one thing you can do with cja just the last tip before we reach get to the end so you build a bunch of filters like i built four for my scenario for one session two three and four if i want to change my moment of interest i’m going to need to edit four filters every time but one thing you can do in certain instances is use derived field in cja let that define your moment of interest and then build your filters relative to that derived field so you have four filters that you can use to analyze whatever the results are based on that derived field that you build in cja’s data view and then if you want to change your analysis to look at a different product application or a different moment of interest altogether if you’re done with what you’re doing at that point edit your derived field one time for the data view and now apply your segments or your filters again and study it relative to the new data new point of interest all right so segmentations and filters let you slice and dice your data a lot of ways but with the addition of excludes along with only before and only after and practice like applying it figuring out what you miss assumed miss built and fixing it you can look at all the visits or the data that you want to see and then we can take those results and add them to something else to limit them to just a sub subset of data that we want for the future session like i said earlier we can take those results and add them to something else to limit them to just a finaly introduce the last like big highly powerful kind of new advanced topic i intend my next session to probably be just applications templates cheat sheets like no more of this kind of building and training use these as the kind of training lesson areas only which had some use cases trickled in but now just give you like here’s all the ways we’ve seen it applied with customers here’s scenarios here’s templates here’s ways that you can apply it if you want to find a thing like abc here’s the kind of structure you need so that’s what i’m thinking next but i would love we’re going to launch a poll in the team’s chat now i would love if you would give your feedback on whether that’s of interest to you or other topics are of interest to you as well as this is meeting your objectives and then while you do that i’ll just also mention the team i’m part of along with richard is ultimate success and what we provide is micro engagements that can be structured in a lot of different ways one of them is kind of this idea of a desk side coaching it’s sort of like what i’ve done today so this would be something where if you subscribe to ultimate success licensing then we’d come in for a three or four week typically micro engagement taking a few hours of commitment from you to help us understand what is a use case you have where you’re blocked or you have questions or you need to understand or apply some concept better we work with you to brainstorm live on working sessions and bring content like this to help explain concepts to help you think like okay in this example like how would i apply this idea to my business case or how would i you know scale make a new lead scoring model all sorts of things but you’d work with your tams or csm’s to arrange that if you’re part of the the ultimate success package it’s not going to be the same thing as like a digital learning services class where you go like all in you know in-person training or virtual training but this is kind of micro engagements to help you on a targeted use case where you need help that’s where we will end again please do fill out the survey it’s like two or three questions we will provide materials to all of you those of you who registered the recording will be published and i will also have follow-up blog posts again recording in page format the content that we’ve covered so far kind of catching up slowly to where we are today thank you so much for attending and thank you richard for hosting i will call it there thank you and have a good day everyone thanks andy that was great session very in-depth great logical consequences of of the different operations um thanks very much everyone