We’re going to be spending some time today talking about web user journeys—simulating these user behaviors on our website—and go into some best practices for it because there’s a lot you can do with user journeys and because it’s so powerful, you have to have some ways to do some troubleshooting.
So let’s get into it, here’s what the agenda is. I’ll first go over, briefly, some best practices—kind of a bullet point, show a few examples—and then we’ll get into some tips, both simulations and user journeys, and a little bit about troubleshooting. I’ll show you, actually, a method for troubleshooting and putting error messages on execute commands. Then we’ll get into some extra tips as we have time. Let’s just jump right in.
Probably, I have trained at many of your sites. I’ve trained all over the country, all over the United States I should say, and internationally as well. So it’s likely I’ve trained at your company or maybe some of your people have some to some of my classes when I worked at Adobe as an analytics trainer.
Let’s jump into some best practices. Number one: plan for maintenance. This is really not an obvious one until you think about it, and you think, “Oh yeah, I should plan for maintenance.” Because every time you set up a user journey, and you simulate those activities that a user is going to be doing on your site, you’ll find that thing change. Your website undergoes a little bit of maintenance and something changes. You change some code on the page, you change a tag on the page, and all of a sudden you start running your simulation and it breaks. It can’t make it through and you say, “What happened? The page doesn’t look any different.”
Remember that a simulation is really based on the underlying code on a page, so the page may not look any different, but the IDs or the other elements that it’s looking for underneath the page may have changed. Even if they only changed slightly, say the spelling of an ID or the case of a CSS collector, even changes as small as that can interrupt the flow of your simulation. You have to plan for maintenance. The idea is that every time you update a webpage that has a simulation associated with it, then you have to go in and run that simulation again, just to make sure it works. And if it doesn’t work, you quickly go in and fix it. We’ll talk about some troubleshooting as well. That maintenance plan is part of your data governance plan, part of the whole, overarching plan that you’ve got for analytics on your site.
Here’s another one: breaking down each step. Sometimes we get so familiar with our website, that we forget to actually do this step. We think that we can just put our IDs into our HTML element selectors and our actions inside of our simulations and it will work. But sometimes you really have to think about what’s going on. I’m going to take you through two examples of this, one simple and one more complex, to illustrate how important it is to break down each step. I’ll come back to that in a moment. Then there’s this idea of testing it out manually, so you’ve got HTML elements, you’ve got execute statements that you’re going to be running. You want to make sure that they work first, so try it out in the console. Let me just flip to my console…
Demo Screen 1:
You might be familiar with this website. This is what we often use in training as we have errors built onto the site. I use it all the time and it’s an easy thing for me to make illustrations on. I want to click on this blog link, so let me go inspect it. It doesn’t have an ID on it, but I can overcome that. I go to the copy selector, and with that copy selector in here, I type “jQuery” and paste it in here, and there it is. There’s the item that I’m looking for. Now I want to say, “click” on it, and what happens? Nothing happens. For some reason, it can’t actually click. This looks like a perfectly valid statement, so if I were doing it without checking it out first, I would copy this, put it into my simulation, and then come back and a few minutes later and wonder why it can’t get through, it can’t do this. This is one of the things that is really helpful and leads into my next little tip…
Using an index number on my jQuery selectors. An index number is simply another way to identify this.
Demo Screen 1:
It’s a square bracket with a zero inside. This is index number one. What it means is: find me this item the first time that it occurs. It seems redundant if this selector here is unique, but for some reason, about 90 percent of the time, I find I have to do that in order to make it work. Try it without first, and if it doesn’t do what you’re expecting it to do, then put the index number on it. In this case, we put index zero, that means the first item. Now let’s see what happens. Low and behold, it takes me to my blog page. We’ve got a success. Test it out manually and use that index number on jQuery selectors.
The fourth best practice here is to use IDs wherever possible. An ID is often put on an element, and sometimes it’s only put on some of them and not all of them. If you have them on all of the elements that you’ll be using for your user journeys, it’s perfect, but you can’t always do that. If you have some influence over the developers, have them use IDs at least on the ones that you’ll be using on those HTML elements. Sometimes a problem with IDs, is they get dynamic, so every time you refresh the page, it loads a different ID. That defeats the purpose of an ID in my mind. That could be a problem. If there’s a way to turn that off so it is a static ID, that would be ideal.
The last little tip here is: create a version of your simulation for each major browser. You have maybe Windows and Macintosh and you have Safari and Chrome and Firefox. You want to do the latest browsers for each of those. You can’t actually copy those, right? We can. If you call up your consultant and say, “I’ve got this simulation that I need copied so I can use it for multiple browsers.” They can copy that for you and this works much better that going in and having to recreate each of those. It saves you a lot of time.
Let’s go back, and I’m going to go into breaking down each step a little bit further to illustrate the issue with it. I’ve got this login page, this is my JPStyle login and they’re four steps. I’ve got navigating to this page, so that will start on the homepage. Click on the login and land here. Once I’m here, I’ll enter the username, enter the password, and click on the login button. Four steps, that’s easy to look at. If you look at your own sites, you might have simple simulations just like that. But what happens if we get into something a little bit more complex?
I’ve got one that takes many, many steps. It’s a loan application. I’ll show you this from Chase, a real live website. I’m only going to show you the pictures of it, and really it doesn’t matter what’s underneath the code here. We’re going to assume that all the items we need have IDs on them. We’ll count how many steps we need. Here’s the first page. You click a button, you get into this request page, fill out this form. There’s several things to click on, things to drop down, you get to another page and there will be things to fill out.
I want you to take a look at this. If you will just download the loan application, a PDF file, in fact I’ve got two of them, one’s Loan Application and the other is Loan Application Answers. I’m putting you on your honor—I’ll show you the answers afterward—but go ahead and try your skill at defining all the steps that have to take place. Use the required items, everything that has to be filled out. Count the number of steps on each page and add them all up and see what you come to. I’ll leave this here for a moment and give you about a minute, minute and a half to do this and then we’ll come right back. I hope I’ve given you enough time to do that, but if not, we’ll go over the answers anyway.
Demo Screen 2:
Here’s the file that you should have downloaded. Looks like a loan application PDF file. And starting there, here’s the answer sheet. Click and action to start the application. Choose one of these options. Select from the download. Continue on. Sometimes we forget something so simple as continue on. Here’s first name, last name. Then a phone number. One, two, three things that have to be put in there. I’ve got all of these here. How many steps are there? Let’s look. I’ve got a total of 52 steps. How many did you get? I think this illustrates the difficulty there is in just determining how many steps there are in something. You have to be careful and walk through it very deliberately.
Part two: general tips and troubleshooting tips.
First one: use session storage to pass data in. This is an HTML5 feature that comes with the new HTML, and it’s easier to use than cookies. You can set an item by putting in the name and the value, the key value pair. Then you can retrieve it easily by setting session storage dot whatever your key name is. The nice thing about this is that it automatically deletes whenever you end a session. Take these items and use them inside your execute scripts throughout your actions as you need them. As you need to pass, maybe a confirmation number, from the beginning to the end of your session. Then execute actions, and there’s a couple of things we want to do. One is: consolidate the selectors. Sometimes we get selectors that are so long it makes it really, really difficult to touch anything on the page without affecting the selector. I’ll give you an example here in a moment. There’s ways to consolidate, or to use alternate data points like styles or attributes. I’ll show you some examples on this. And then, at the end here, I’ll do some error handling for execute scripts.
So let’s jump into consolidating selectors. Here’s my method one. Back at the Chase Bank example, I actually did inspect the page and looked at the items and as I looked at that button that has a really long selector on it, it doesn’t have an ID, but you can see that it just goes on forever and ever. It’s not unusual, but the problem is, anytime something changes on the page, there’s more things in this selector that might be affected. If we can reduce them, we might be able to reduce the number of times it can get broken with updates to the page. Let’s try this first thing, and that is remove some of the things. In this case, we’ve got extra CSS. Actually, in this case, we can remove them and shorten it—as you see on that second line—and that makes it quite a bit more simple.
Of course, you have to evaluate this for your own site. This won’t work on every site, but it may work on yours. Then I can take that further, and remove some of those extra items and go, much more easily, to the final destination point. If there should be another div tag added in where they’ve got those red div tags, later on if somebody comes and they add another div tag in here, it may not affect it as much. But it’s much easier to read through this, right? So that’s one of the things: consolidating the selectors. Getting back to this one, this does have a problem: if anything is changed, it still could affect this, so that’s one of the drawbacks.
Method two: using CSS.
You might have, like on these four buttons, they all have the same styles applied to them. That’s what it looks like at the bottom here, on the page you can see how I’ve made a selector out of all of those styles. That works well, except all of them are the same. We’ve got four items, and how do we know which one to take? Well of course we use that index number on the end and we take the first one. So you can use CSS selectors, and if you have multiple of the exact same CSS styles, you can use the first one or whichever one you want. That’s how we limit it with an index number.
Method three of using these selectors, is using an attribute. Sometimes if you don’t have an ID on a page, you might have an attribute.
So going back to these green buttons here, if I looked at all of these buttons, they have an attribute called: “data-pt-name.” each of them have that same attribute, but the attribute value is slightly different. I use a little bit of jQuery syntax in order to get that item. The syntax as the attribute is listed in square brackets. You can see I put a square brackets around that attribute with a value—you have to be careful about nesting quotes—and then zero index and dot click. That finds that specific item.
Really quickly: handling errors on execute scripts, execute actions.
Here we’ve got a simulation that has five steps in it, and the last step didn’t actually work. That’s where it shows me the error, but as you can see, up at the top it’s got—on the second step—it’s got some garbage in the selector. That’s where it actually broke, but jQuery doesn’t throw an error automatically most of the time. What you want to have, is you want your actions to look like this in your report showing exactly the step where it fails. I put some error detection in these scripts to make sure that I can tell exactly where they failed. Let’s talk about how we do that.
Demo Screen 3:
To give you the context here, here is my login page. In my login page I have the name, username, and the password and this field is called, “edit name,” and I want to put student into there.
I’m going to put an error check on it, so I surround it with “var err equals whatever my selector is.” Put the semicolon at the end because we’ve got more than one line of code. Now if there’s no value there, if I can’t find that object, then do “a” and that’s what throws the error.
Now let’s go into part four: these extra little tips. I’m going to go through them quickly. You can download this powerpoint and you have the scripts in here, so if you don’t get it right now, you can always come back and get them out of this power point. Use them and modify them as you need.
Here’s one thing; sometimes we want to randomly choose search results in an execute step. Here’s an example of when we might want to do that. Perhaps we’re Hotels.com and we have this list of selections for this location, let’s use one of these randomly. Or perhaps when we get to the search results, we want to get to one of these search results randomly, but we don’t want to exceed the number that are in the list and we don’t want to blow it up.
Let’s try something here; I’ve got a little script showing this line by line. The first line is a maximum of what we can choose from, the number of items that we’re looking for. I’ve got this selector here, and I’ve got it general enough that I can get all the listed items. I can count them and subtract one, and that gives me my maximum number I can choose from. Then I make just “x”, and this is my random number. So I’ll make a random number anywhere between zero and the maximum number. Then I can take it and use that “x” to say, “Find this selector: ‘x’,” whatever it is—if it’s one or ten or whatever it be. So randomly getting search results out of an execute statement.
Basic authentication. Here’s another thing that is a difficult thing. Sometimes you have to do a simulation behind a firewall and you’re using basic authentication. When you’re using basic authentication, that requires a username and password to be sent along with the URL. Here’s the syntax for it: username, colon, password, at whatever your secure site is. You can simply put this in as one of your steps, as one of your execute actions. Your username, colon, password, at and then your site should log you in. be sure to use https as secure protocol instead of http because it will encrypt.
Another type of authentication is: two factor authentication. This poses a real challenge, but here’s a little tip to get by one kind of two factor authentication. If you have questions and answers, and I’ve got an example here, this is often done at financial places.
Demo Screen 4:
Here’s my fake two factor authentication login. I’ve got some questions and answers. I set up these questions as I made my profile when I first registered for this site, so I know what questions and what answers I have. I have to make a script that gets those questions, find out what’s this question here and what’s this question here? Then match it up with whatever I know the answers are going to be. Let’s go through this really, really quickly.
Fins the questions. Make an array, and say we’ve got a sample of four different questions, well we know what they are, so we just put those in as one of our execute statements.
Then we have to get the answers. We make a new array for each answer and a corresponding response to each of the questions.
Then we have to find out, what question is on the page. So I’m going to go through twice and make a loop and look for question one and say, “Does it match the first question in my array?” If so, then I know what that question is and I’ll keep that number. Then I’ll do it again for the second question.
Then simply, answer the questions. Use one for question two and one for question three, passing this value on. It’s a variable, so the question and answer two factor authentication is a quick way to do it.
Thank you very much. It’s been a great half hour with you, it’s gone fast. Hope you learned a lot about troubleshooting and best practices of advanced web user journeys.