51黑料不打烊

Transcript

Hello, everyone. Thanks for joining. We鈥檒l be starting in the next couple of minutes.

Today鈥檚 session is focusing on sequential segmentation and being led by Andy Powers. So we鈥檒l just allow a few more minutes for people to file in.

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

There鈥檚 a longer list and I鈥檒l just put that in the chat.

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

So I think it鈥檚 probably time to get started. That鈥檚 given us five minutes for everyone to come into the session. So this session is on sequential segmentation. It鈥檚 being led by Andy Powers. I鈥檒l 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鈥檓 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鈥檝e 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鈥檙e going to look at鈥� Let me switch to see my internal presenter view. Okay. So we鈥檙e 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鈥檙e talking about. We鈥檙e going to revisit a use case where the idea is we want to analyze every sequence and something that happened after every sequence. We鈥檒l give the details on that and what that means and how you can apply it. We鈥檙e going to talk about the theme mentioned here, starting and stopping. So far we鈥檝e talked about things for starting and doing some sequential logic, but today we鈥檙e really introducing the idea of how you stop and make repeat segment matches. And we鈥檒l look at some demos or live examples of fake demo data, of course, and then we鈥檒l 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鈥檒l 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鈥檒l do the review, make sure we鈥檙e clear on communication and how to talk about these things. Then we鈥檒l 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鈥檛 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鈥檒l receive afterward. We鈥檙e creating a blog series that鈥檚 essentially a kind of lagging documented form of webinar content, but I鈥檓 pretty behind on that while getting ready for a summit and for this session. So there鈥檚 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鈥檚 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鈥檙e 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鈥檝e prescribed. That鈥檚 really what you鈥檒l 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鈥檛 match the results, that鈥檚 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 51黑料不打烊 Analytics, traditional analytics, as well as CJA, we鈥檙e 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鈥檒l use all those, but all the concepts can be applied whether it鈥檚 just digital web analytics focused or a customer journey cross channel environment. So I鈥檓 calling this a quick review because I need to touch on a bunch of things and make sure that we鈥檙e 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鈥檛, and we鈥檙e going to have each of these representing a hit or an event that have some attributes on them. We鈥檙e going to be able to identify sessions or visits that are periods of activity bounded by periods of inactivity and we鈥檒l 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鈥檚 a lot to know and use that鈥檚 not even sequential about it. We have ways to define the scope we鈥檙e looking at. Are we looking at all of a person鈥檚 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鈥檛 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鈥檒l see it鈥檚 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鈥檒l 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鈥檛 see an application activity within that second day period so it doesn鈥檛 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鈥檙e going to look for the subset of our customer鈥檚 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鈥檓 just setting some groundwork again on how we鈥檙e communicating ideas and just kind of the basic ways that you can influence sequential logic. As I鈥檝e 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鈥檙e going to match that and everything before it. And keep in mind too that the idea of segment logic is always greedy. It鈥檚 going to give us the largest possible return. So rather than this I鈥檓 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鈥檛 qualify but here I have a web activity that鈥檚 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鈥檒l say it鈥檚 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鈥檓 looking at visit data with my only after flag set. There鈥檚 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鈥檓 interested here. It also means I鈥檓 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鈥檙e going to get back all this data after the first application. Here we鈥檙e going to get back all the data after the first application skipping a session forward. So we need a different approach if we鈥檙e 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鈥檇 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鈥檚 actually going to contain a different app submit but it鈥檚 going to be qualifying because it followed this one? So the point of all this is to say there鈥檚 more questions that we need to think through together and this goes into one of the steps in the process. It鈥檚 going to be things like all right if we want to know activities that happened relative to some point there鈥檚 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鈥檚 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鈥檛 matter whether it was a little bit different in one instance than another we just want to know about the pattern. What鈥檚 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鈥檙e interested to know the common behaviors for those scenarios. So if we update our use case that we鈥檙e going to follow here and the rest of the session we really want to see I鈥檓 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鈥檙e 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鈥檚 not the same thing but to say look at the data between point A and point B but not after point B so that鈥檚 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鈥檚 data we鈥檙e going to look for the point where they touched web and then touched mobile app and we鈥檙e 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鈥檚 not really a person it鈥檚 not really a visit it鈥檚 it鈥檚 going to be all the data from when that app followed web up to and including any activities till we see an email it鈥檚 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鈥檝e done with other sessions I鈥檓 going to go through and introduce these you know kind of talk about this theory of what it does and then we鈥檒l apply it and look at examples to kind of prove it out and show how it makes more sense and what it鈥檚 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鈥檚 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鈥檚 not a person it鈥檚 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鈥檒l 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鈥檚 data beginning with the single checkpoint sequence that a web event happened and stopping if there鈥檚 an email touch seen in the future it鈥檚 this sequence that we鈥檙e looking for it鈥檚 it鈥檚 a single checkpoint sequence it鈥檚 just web so it鈥檚 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鈥檛 want to do what we鈥檙e doing in our use case today we want to say point of interest let鈥檚 skip out to some later point start matching there and then stop later this lets us say i see the point of interest let鈥檚 start matching right here and then continue until i want to stop applications for this i can鈥檛 i don鈥檛 have enough time today to squeeze in but it鈥檚 part of what i intend for the next session which is now we鈥檝e 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鈥檚 always based on all the inclusive checkpoints being found in a sequence here it鈥檚 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鈥檒l 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鈥檙e 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鈥檙e 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鈥檙e limiting the scope of when an email can stop our matching here so if we鈥檙e looking at our person鈥檚 data and they have a web touch and then in the next week they don鈥檛 have an email touch we鈥檙e 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鈥檚 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鈥檙e often going to need to apply within and after conditions to force some more proximity anytime you try something new with this it鈥檚 important to validate it it鈥檚 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鈥檚 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鈥檙e 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鈥檙e 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鈥檛 get anything at the end that that is accurate but it鈥檚 not the whole story because it鈥檚 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鈥檚 no thing here telling us that these need to be next to each other so if we match this sequence it鈥檚 going to give us a lot more data it鈥檚 going to stop at this email here it鈥檚 also going to find this sequence this is web followed by app and there鈥檚 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鈥檝e done it a lot and practiced with it a lot i still forgot coming back to it that i鈥檓 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鈥檚 add within one event and this is going to say just look at the points where i had web immediately followed by app let鈥檚 pretend that that meets our true business requirement in this scenario web the nap matches stops at email web not followed by app doesn鈥檛 match web followed by app matches but it鈥檚 not going to include this web looking any farther than the next event it鈥檚 going to automatically fail so it鈥檚 not going to get that web and then a downstream app 10 hits later same thing for this web it鈥檚 not going to match here although it wouldn鈥檛 have changed the results this is how the logic works it鈥檚 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鈥檚 more efficient than that but efficiency aside that鈥檚 what it鈥檚 doing so that鈥檚 how you need to think of it and test against it so by using the within we鈥檙e decreasing the window we鈥檙e 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鈥檚 a lot of combinations here of app and web this app is preceded by this web hit it鈥檚 also preceded by this web hit kind of that like long unexpected pattern that we saw before but you can see that really it鈥檚 kind of your your ending checkpoint your concluding checkpoint here that really matters for what data you鈥檙e going to get back in this case i mean since we鈥檙e looking backwards it鈥檚 this web hit if we were looking forward so it would be different but you鈥檒l get a feel for you know here it鈥檚 much more dependent on where the web hits occur because i need to see app and i need to see web so that鈥檚 kind of my my limiting uh required checkpoint let鈥檚 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鈥檙e 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鈥檚 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鈥檛 have anything further it鈥檚 not going to meet a stop it鈥檚 just going to match this and then it鈥檚 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鈥檙e going to have our stop point be relative to our starting point because we鈥檙e going to make this in one nice concise sequential segment that says you know a then b then stop at c so we鈥檙e 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鈥檚 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鈥檚 used in these two examples we can probably find some pieces to pull out for our goal here鈥檚 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鈥檙e trying to do is scan app activity start on the next session stop on the session following that i don鈥檛 know that this is really a huge different way to think about it but i thought it鈥檇 be helpful visually to give another way to see it and envision how you鈥檙e 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鈥檚 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鈥檙e probably going to use similar things only after it鈥檚 probably going to come in app submission of course probably day exists and then after or within one session likely as well and we鈥檙e well we know we鈥檙e going to add in something to exclude so we鈥檙e 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鈥檚 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鈥檚 it鈥檚 just the next one it鈥檚 not that scenario where the 10th session down still matches like we had in our mistaken approach earlier and then we鈥檙e 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鈥檛 qualify and the exclude checkpoints are kind of naturally strict so we don鈥檛 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鈥檚 that鈥檚 the end of that so here imagine app we鈥檙e getting out of this session and now we鈥檙e starting to look for the next session this is where our day exists occurs within one session now we鈥檙e only after sequence so we鈥檙e going to keep on matching until we get to the next session where we see any hit and we鈥檙e going to stop matching so it鈥檚 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鈥檚 nothing else so the stop doesn鈥檛 come into play but we still get the result that we want this app never is followed by another session so this app doesn鈥檛 really play a role think about what would happen if we remove that within so here app this session is going to qualify we鈥檙e going to match and stop on the next one just like earlier but it鈥檚 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鈥檙e going to get that result and it鈥檚 going to do it for this and we鈥檙e going to get this long set of data not what we want so let鈥檚 go and look at here let me minimize this for a moment i鈥檓 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鈥檓 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鈥檚 after all each of their applications so if i open this up i鈥檓 going to make one change i鈥檓 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鈥檚 going to be one of the other two here i鈥檓 let鈥檚 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鈥檙e going to see that session yes but we鈥檙e also going to see the next one relative to this application submit which is going to happen on the 20th so we鈥檙e going to see that 20th come available for analysis and here鈥檚 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鈥檙e getting one of these sessions here and also they had one on this date with four others so we鈥檙e actually getting two different sessions coming back for this example if we extend it let鈥檚 look at it like this so here what i鈥檓 doing slightly different view where we鈥檝e sort of scaled this up 14 sessions for person g three apps submitted now we鈥檙e 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鈥檓 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鈥檙e using this model much simpler and it鈥檚 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鈥檙e just going to see this cascading effect and the only way i鈥檝e 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鈥檓 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鈥檓 actually not matching anything because we went through all these and there was nothing that matched so at this point i鈥檓 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鈥檙e not subsetting to a particular person we鈥檙e just being able to study it鈥檚 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鈥檛 back again until later but the big way you鈥檇 use this is in something like this application not against day days for validating here we鈥檙e saying let鈥檚 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鈥檚 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鈥檚 demo data it doesn鈥檛 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鈥檚 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鈥檙e 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鈥檓 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鈥檚 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鈥檙e done with what you鈥檙e 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鈥檚 all the ways we鈥檝e seen it applied with customers here鈥檚 scenarios here鈥檚 templates here鈥檚 ways that you can apply it if you want to find a thing like abc here鈥檚 the kind of structure you need so that鈥檚 what i鈥檓 thinking next but i would love we鈥檙e going to launch a poll in the team鈥檚 chat now i would love if you would give your feedback on whether that鈥檚 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鈥檒l just also mention the team i鈥檓 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鈥檚 sort of like what i鈥檝e done today so this would be something where if you subscribe to ultimate success licensing then we鈥檇 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鈥檙e 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鈥檇 work with your tams or csm鈥檚 to arrange that if you鈥檙e part of the the ultimate success package it鈥檚 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鈥檚 where we will end again please do fill out the survey it鈥檚 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鈥檝e 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