51ºÚÁϲ»´òìÈ

Transcript

Hello and welcome to my session of the Skill Exchange Demystifying Common Metrics. My name is Mandy George and I currently work as a Senior Ecommerce Analyst at Staples Canada. I’m a three-time member of the 51ºÚÁϲ»´òìÈ Analytics Champions program. I’m also a user group leader for the Analytics Champions office hours and a community advisor on the Experience League forums. You can feel free to connect with me on LinkedIn. I’m always happy to chat about analytics.

So in this session I’m going to cover some of the common metrics that you see every day and explain a little bit more about what they mean. The session should help you understand how these metrics are defined and what they’re really telling you. You should also know when and how to use these metrics or when not to use them and what you should use instead. And all of this should help you understand how to pick the best metric for each situation and maximize the usefulness of your reporting.

So when you look at your components list you probably see most of these metrics every day, but we’re going to look at them in more detail. We’ll start off with unique visitors, visits, page events, and page views. We’ll cover what the difference is between them. Then we’ll go over occurrences, which you’ve probably seen as 51ºÚÁϲ»´òìÈ’s default metric in freeform tables.

We’ll look at bounces, bounce rate, and single page visits and what the subtle differences are between them. We’ll look at conversion rate, orders over visit, and orders per visits. Then we’ll look at all of our time spent on site metrics. And finally we’ll go over bot occurrences, bot page views, and bot page view ratio. These ones you might not have used quite as often as the others, but they can still provide you some pretty good information.

So let’s get started with our visits and visitors.

These metrics you’ve probably used every day, but there are some distinctions that are very important. First, unique visitors is the number of distinct visitor IDs that have visited your site. A visit, on the other hand, is a single continuous browsing session until there’s 30 minutes of activity. This is the standard definition of when a visit ends, but this can be altered using a VRS or a virtual report suite. When estimating the amount of traffic coming to your site, you’re probably going to use one of these two metrics. Some of the other common metrics that you’ll see are page views, which is the number of times that a dimension was set or persisted on a page, and finally page events, which is the number of times that any link tracking call was made. Page views and page events are mutually exclusive. A hit can be one or the other.

Looking at these together, you can think of unique visitors as a book series. The series as a whole is a single item, but within that series, there’s a number of individual books. Each of those books is like a visit. A single visitor can have multiple visits. Then within each visit or book, there are a number of pages. Each page is either a page view or a page event.

Let’s look at all of these in a little bit more detail. First, we have visitors. So we know that this is the distinct count of customer IDs on your site, but there’s a lot of factors that can impact this. If a customer visits your site using two or more different browsers or devices, each browser and device is going to have a different visitor ID. Also, if they use a private browsing session, like Google’s incognito window, that again makes them look like a new customer. All of this means that over a long period of time, the same person might appear as two or more different visitors on your site. Now, there are some things that won’t impact the visitor count. If someone closes or updates their browser, that doesn’t impact their visitor ID. Restarting your computer or changing your network also doesn’t have an impact.

Next is visits. We know that a browsing session continues until there’s 30 minutes of inactivity, but there are a lot of other things as well that can cause a visit to end. If there’s 12 hours of continuous activity, at that 12-hour mark, the visit ends and any subsequent activity starts a new visit. Another way for a visit to end is if there’s 2,500 hits. Once you hit 2501, you’ve got a new visit.

The next way is if there’s 100 hits in 100 seconds, although traffic this rapid is typically bot traffic. And finally, some of the other ways that a visit can end is if somebody clears their cache, resets their cookies, or switches browsers or devices. These actions also cause someone to look like a new visitor, so with the new visitor comes a new visit as well. But there are also several actions that don’t end a visit, such as going past midnight. Your visit can span from one day to the next, but that midnight time point doesn’t end a visit like it does on some other analytics platforms. This is important to keep in mind when you’re looking at your data, as one visit can be associated with two different dates. 51ºÚÁϲ»´òìÈ does also support multi-tab browsing, so opening a new tab as long as it’s in the same browser won’t start a new visit. Your visitor can switch back and forth between the tabs, and those hits will be stitched together to make one visit. Other actions like closing and reopening your browser, restarting your computer, or switching networks also won’t cause your visit to end, as long as the time that you’re away from the site is less than 30 minutes. When you return, it’ll continue the same visit.

So whether you use visits or visitors to count your traffic, as long as you understand the caveats to both, it’s up to you to decide what you want to do. I’ve worked at companies that use visits and others that prefer to use visitors. My personal preference is to use visits to measure my traffic, because over a long period of time, visitors can tend to double count people.

Finally, we have page views and page events. If you’ve used a page management platform, you probably recognize the T and TL calls. If you haven’t though, that’s fine. The T calls are page view calls, so they fire when a customer lands on a page. The TL are custom links, so stuff like customers clicking on a button on your site. The page view metric counts those page view calls and only page view calls. It doesn’t include any custom links or other data brought into Workspace via data sources. Page events, on the other hand, are events that are seen on a page. They include the custom links, download links, and exit links.

These two are mutually exclusive, but a typical visit will be made up of a combination of both of them.

Next, let’s talk about occurrences.

You’ve definitely seen this one pop up in your dashboard, as occurrences is the default metric that shows up in a freeform table after you drop in a segment or a dimension. Now, you can go into your settings and change this so that way it’s a different default metric. Personally, I set my default to be visits, but let’s talk about what occurrences actually is. It’s the number of hits where a given dimension was set or persisted. This includes most of the hits that you’re going to see in your reporting, such as page views, page events, like link tracking calls, and data imported via summary data sources. The one thing that this does not include is hits that were excluded due to 51ºÚÁϲ»´òìÈ’s default bot rules.

Occurrences can sometimes be confused with instances. All EVARs have an instances metric that goes along with them, but the instances only count the hit when the dimension was set, whereas occurrences will count the hits where it was set, but also where it persisted. Say for example, a customer does a search on your site and you fire an EVAR to capture the search term. Both instances and occurrences will fire for that hit, but occurrences will also count any hits where the search term persisted through the rest of the visit.

We can also compare occurrences to page views, where page views capture only the page view tracking call, occurrences capture page views, but also all of the different types of custom links. So occurrences captures a lot of different information. You can think of customers visits to your site like a fish tank. It contains all the information from what they did. And occurrences are like the fish in that fish tank. They can be quite varied. They can be page views, custom links, searches, product views, card additions, checkouts, orders, and exit links. Each one of these actions is like a different type of fish, but they’re all still fish and they’re all still in the same fish tank. So together they make up a pretty good aquarium or a visit to your site.

But because occurrences is so varied, there’s often a better metric that you can use instead. If you want to look at an EVAR and see how many times it fired, you can use the EVAR instances. The instances only count when a dimension first fires and not any of its persistence. So you can be sure that the number you have is exactly how often customers interacted with something.

If you want to know how many pages an item has appeared on, you can look at page views.

Alternatively, if you want to know how often something was clicked on, you can use the custom link instances. If you want to know how many unique visitors or visits saw an item at least once, you can use the unique visitors or visits metrics. Instead of counting each interaction, it counts the number of visits or visitors where your dimension was seen, essentially deduplicating the data.

Finally, if we want to know how many times something was searched for, instead of occurrences, we can use the metric searches. This is more specific to what we’re trying to see. Now if the search term only fires on searches, then occurrences and searches might end up being the same number. But if you’re building a dashboard and sharing it with your business partners, and they look at it and see occurrences, they might not know what that means. Whereas if they look at your dashboard and see searches, that might be a little bit easier to understand. So typically, you can find something other than occurrences to use that will be a bit more specific and can help people understand the information that you’re trying to convey.

So now let’s talk about bounces and single page visits.

A bounce by definition is a visit to your site that contains exactly one hit. So someone comes, they load up that first page, they don’t interact with it, they don’t click on anything, and then they leave. A single page visit is one that contains exactly one unique page identifier. So this means that they can have more than one hit on your website, as long as they only see one page. So they come to the site, they load a page, then they get a pop-up asking them to accept cookies, or they get asked to enter their email to be sent a flyer or a coupon, or all of these actions happen. As long as they don’t click to a second page, there can be multiple hits and it’ll still be a single page visit.

51ºÚÁϲ»´òìÈ does also create a default relative metric for you called bounce rate. This is calculated as the percent of visits that are a bounce. But since bounces can be impacted by additional calls being fired on that first page, it can actually undercount a little bit. So instead, I’ve always made a custom bounce rate. This custom bounce rate is the percent of visits that contain a single page visit. If a customer lands on your site, a page view call fires, and then they’re asked to accept cookies. Is that a meaningful interaction? Or if there is some other type of pop-up that fired an impression call. Is that meaningful? In most cases, it probably isn’t, especially if they didn’t do anything else on your site. So creating a custom bounce rate metric using single page visits can help give you a clearer picture of who is bouncing from your site.

So just to recap the difference, if someone comes to your website and lands on a page and that’s the only call that fires, that’s a bounce. But if they also see a bunch of custom link calls in addition to the page view, as long as it’s still only one page, that’s now a single visit, but it’s no longer a bounce.

So looking at the performance of these visits, there’s 51ºÚÁϲ»´òìÈ’s default bounce rate, which is defined as the percent of visits with exactly one hit. Now notice that it says hit and not page view. It is rare, but it’s possible that if a custom link call fires, but no page load calls fires, as long as there’s only one hit, that still counts as a bounce, which is why I prefer to use the custom bounce rate metric where we look at single page visits. This way we don’t have to worry about if a call double fires or if there’s impressions on the page. Our bounce rate is based on people only seeing that first page.

All right, let’s talk about conversion rate. There are three different metrics that 51ºÚÁϲ»´òìÈ provides by default. The first is conversion rate, which is orders divided by visits. The second one is orders over visit, which is also calculated as orders divided by visits. And the third one is orders per visit, which the documentation says is calculated with the formula orders divided by visits. So these three are pretty much the exact same thing. The main difference is how they appear. You can see that conversion rate is a percentage, whereas orders over visits and orders per visits are both decimal numbers just with different levels of granularity.

But with these being relative metrics, there are a few other things that you should keep in mind about how they’re calculated. There’s another metric that I sometimes use called order success. This isn’t an 51ºÚÁϲ»´òìÈ default metric. This is a calculated one. It’s defined as the number of visits that place an order, which does sound the same as conversion rate, but it’s slightly different. So let’s look at an example. Customer one comes to our site and places an order. Customer two doesn’t buy anything. Customer three places an order. Customer four places an order but then realizes they forgot something, so they place a second order in the same visit, and then customer five decides not to buy anything. If we were to use the conversion rate metric, we would count the number of orders divided by the number of visits. So four orders divided by five visits gives us a conversion of 80%. Order success, on the other hand, doesn’t count the number of orders. It counts the number of visits with an order. So for customer number four, instead of counting two orders, we count one visit. So now our calculation is three visits with orders divided by five visits gives us an order success rate of 60%.

Let’s look at a second example. And instead of counting the orders, let’s look at another relative metric, add to cart rate. Customer number one adds two products. Customer two doesn’t add any. Customer three adds three products. Customer four adds two. And customer five doesn’t add any. If we were to calculate add to cart rate the same way that we did order conversion, we would count each cart addition, which is seven, and divide by visits, which is five, giving us an add to cart rate of 140%, which isn’t very useful.

Using a metric similar to order success, visits with cart addition, we’ll count the number of visits that added a product to cart, which is three visits, divided by our total visits, five, to give us a visit with cart addition rate of 60%. This number is a little bit more useful to us. Since you can do more than one cart addition in a visit, looking at the number of visits instead of the raw number of cart additions can help you see how many customers successfully took an action. You can also apply this logic to any event in a visit, especially those that are likely to happen more than once.

So now let’s look at time spent on site.

51ºÚÁϲ»´òìÈ has a number of different metrics used to describe how long someone is spending on your website. The first metric is time spent per visit in seconds. This gives you the average amount of time that visitors interact with a given dimension. It’s calculated by taking the total amount of seconds and dividing that by the number of visits minus bounces. Why subtract bounces? Well, in order to calculate the length of an interaction, 51ºÚÁϲ»´òìÈ needs two time points, a start and an end. And as we’ve discussed earlier, a bounce is a single hit. That means that there’s a start, but there’s no end. Without that, it can’t count the amount of time, so those hits get excluded.

The second metric is time spent per visitor in seconds. This also gives the average amount of time a dimension is interacted with, but this is calculated at a visitor level. It divides the total seconds spent on a dimension by the number of unique visitors.

Then we also have total seconds spent. Instead of dividing the time by visits or visitors or anything else, it simply adds up all of the time that a dimension was interacted with. But just like the others, it needs two time points to count the seconds between them, which means any dimensions that are seen on the last hit of a visit will be excluded from the time calculation.

There are still two other time-based metrics. Unlike the previous one that looks at average time per visit or visitor, the average time and average time in seconds both look at individual hits. So instead of summing up the amount of time spent over multiple hits in a visit or by a visitor, this gives you the average amount of time spent on each individual hit. But again, these need two time points to be able to calculate. So let’s look at a specific example. Here we have a sample visit from one of our customers. For this example, we want to understand when people look at product A, how much time do they spend on it. So our customer comes to the website, lands on the homepage, and then they go to product A at 12.04 and 20 seconds. At 12.05 and 30 seconds, they reload the page. This new hit acts like a barrier and ends the first interaction and starts the second one. So our first hit was 70 seconds long. When the customer moves to product B, that ends the second hit, which was 90 seconds long. Then the customer comes back to product A at 12.07 and 40 seconds, and they stay there until they move to the checkout, giving them a total of 30 seconds for that interaction.

They do a few more actions, and then finally they come back to product A. But that’s the last hit of their visit. So that fourth interaction with product A doesn’t have an endpoint. This means that it won’t be used in the calculation since we don’t know how long they actually spent on it. So for our average time on site, we’re going to take our first three interactions and get average, which is 63 seconds. Whereas if we look at our average time on site in seconds metric, that puts it in a time-based format, so it’ll say one minute and three seconds. Now there is one other thing to keep in mind when using any of these time-based metrics, and that’s how you interpret them. If you notice a customer spent five minutes on a single page, is it because they read every detail on the page, or were they looking for something and they couldn’t find it, so they’re just scrolling around? Or did they leave the page open while they got up and went and made a cup of coffee? It’s really hard to tell what they were actually doing, so just be cautious when you’re interpreting what these metrics mean.

Now finally, we’re going to talk about bot metrics.

Bot traffic can be annoying to deal with. Fortunately, 51ºÚÁϲ»´òìÈ has some default bot detection rules that it runs and filters out this traffic for you. So these bots don’t appear in your regular reporting, but they do still count against your hit budget, so it can be useful to know how much traffic they’re generating. For this, 51ºÚÁϲ»´òìÈ has three specific metrics that are used to look at the bot traffic that has been filtered out. First, there’s bot occurrences. Similar to the other occurrences metric we saw earlier, this includes all types of hits, but those that were filtered out due to the bot rules.

Second is the bot page view. Again, this is similar to the other page view metric we saw earlier. It’s the sum of all page view calls, but again, only those associated with bot traffic.

And finally, we have the bot page view ratio, which gives you a ratio of all the traffic that has been flagged as bots and removed compared to traffic that appears to be legitimate.

These bot metrics do have a warning icon beside them, that little triangle with an exclamation mark. If you click on that, it’ll tell you that these metrics can only be used with certain dimensions. The first is bot name. This is the name of the bot that 51ºÚÁϲ»´òìÈ has identified. You can use bot occurrences or page views to see how frequently each bot hits your site.

Your second option is to use a time-based dimension like month. This can show you if there have been spikes or drops in the amount of bot traffic over time. Knowing this can help you understand when your site is getting hit with bot traffic the most.

Finally, you can use these metrics with the default page dimension. This will show you where on your site bots are targeting. In addition to bot page view or occurrences, you can also use the ratio metric. This gives you an idea of what percent of traffic for each type of page is coming from bots. It’s likely that there will be a few particular sections on your site that do get hit more frequently than others. In this example, I’ve also included the regular page view metric so that you can see how the ratio is calculated comparing the regular page views to the bot page views.

So, let’s recap what we’ve learned today. Our key traffic metrics are unique visitors, visits, page views, and page events. For visits and visitors, it’s important to know that there are certain actions that can end a visit or cause a visitor ID to be reset. So keep those in mind when reporting on your traffic levels. Occurrences include a wide variety of hits such as page views, events, and data sources. Although it’s 51ºÚÁϲ»´òìÈ’s default for freeform tables, there are often other metrics that you can use instead that are going to give you much more accurate reporting.

Bounces and single page visits appear similar but can provide very different results. Bounces have a single hit where a single page visit can have multiple hits on one page. Relative metrics like conversion rate can be useful but make sure that you understand how they’re calculated so you can interpret them correctly. For your time-based metrics, remember that the last hit of a visit isn’t included in the calculation because there isn’t an endpoint for that interaction. And finally, bot metrics can give you insight into traffic that has been excluded from your regular reporting. This can help you to understand what areas of your site are being targeted and how frequently.

So I hope that this session has helped you to learn a bit more about the metrics that you see and use every day, that you now know when you should use them, when not to use them, and what to use instead, and that you know how to pick the best metric for each situation to maximize the usefulness of your reporting. So thank you for joining us for this session and now it’s time for some Q&A.

Wow, that was practical and real. And I think it cleared up a lot of noise, a lot of the sea when using these metrics. Mandy, thank you so much for joining with us. Thanks for having me today. I’m happy to be here. Awesome. Well, it’s time for our questions. Remember to drop your thoughts into the chat and ask away.

Our first question is, is there a difference between page events and custom link instances? I’ve always used the latter.

This is a great question. With the 51ºÚÁϲ»´òìÈ terminology, there’s a lot of names for different things and it can get very confusing. A custom link is a type of page event. So all custom links are page events, but not all page events are custom links. There’s also download links and exit links that are also different types of page events. So when you go into workspace, you won’t see page events in your metric list. You’ll see custom link, download link and exit link.

Exactly. Yeah, that’s a great, great answer.

Here’s another one that I know that I’ve faced. Why the metrics of the same URL change if you use a different report suite? That’s also a very good question. So if you’re looking at the same page, but you have different report suites, it’s very possible that your implementation may be set up differently. You can have your implementation set up through 51ºÚÁϲ»´òìÈ Launch or 51ºÚÁϲ»´òìÈ Tags, or you could have a third party type of implementation. And there could be differences in how they’re capturing data, the timing of when the calls are firing. There’s a lot of different factors that influence how the data comes into workspace. Different report suites might also have different processing rules, different vista rules, marketing channels.

There’s a lot of factors that come into play. And then of course, if one of those report suites is a VRS, a virtual report suite, and it has additional segments applied to it, that’ll also change how the data comes into workspace. So there’s a lot of reasons why you could look at one page in different report suites and see very different numbers between them.

Yeah, that’s a great point. One thing that I like to do when I come across issues like that is I look at both report suites inside of the admin console and just make sure and validate that all of the settings are exactly the same. In there, you can also check to see if it is a virtual or real. It’s just a really good, if you’re going to be using the same information across the board, just to go through and make sure everything’s aligned.

That’s a great tip as well. When you go into the admin section and you look at the report suites, it’ll only show you the actual report suite. The virtual report suites will be under the components. So you’ll be able to determine whether it’s an actual report suite or a virtual report suite based on where you’re seeing it.

Yes.

Okay, let’s move on to our next question.

Do you have any tips on how to ignore employee slash internal traffic from common metrics? This is a question that I have gotten at every organization that I work at. And there is no easy answer to this, unfortunately.

Ignoring internal traffic is always going to be difficult.

When you have a specific group of users that you want to ignore, you typically need to find something that is sort of unique to that group. So if you have a corporate IP address, you can block users based on their IP.

The other thing that you can do, which this one is a little bit… It works somewhat, is what we’ve done at a past organization is we’ve used a query string parameter. So when we share links internally with our team, so say we launched a new page and we share out the link via an internal email, we add a query string parameter to it. And then in our virtual report suite, we filter out all of the visitors with that query string parameter. However, we have had issues in the past where that query string parameter gets published widely outside of the internal traffic. So it does have some limitations as well. So internal traffic is always going to be difficult to try and filter out.

I agree with that, especially in today’s age when we have so many employees that are working remote or working from home, it’s really hard to know if they’re on the corporate VPN or if they’re just using their home, it becomes very messy.

Another tip would be that if you do have remote workers, that they always use the VPN, the corporate VPN, so that we’re coming in and looking at the site from specific IP addresses that you can control. And then you can use that inside of the admin console to just take away that traffic. And another one of the challenges with excluding your internal traffic is when you’ve got your analytics team or your developers that are trying to QA stuff. If you’re doing certain actions on the website and you want to see how that data comes into Workspace, if you’ve got that group of customers blocked completely, then it might be difficult to try and QA. So that’s another thing to keep in mind. Excuse me, another thing to keep in mind with how you’re excluding your internal traffic.

Yeah, that’s a great point as well. Okay, let’s move on to our next question.

If we want to look at custom bounce rate at a page level, should we use single page visits slash entries instead of visits in the denominator? Yes. So when I build out my single page metric, I’m usually looking at it against time-based dimensions. But if you are looking at it against a specific dimension like pages or products or something related to that, you can definitely use entries instead of visits. And what this will change is that if you’re looking at single pages over visits against a dimension, it’s going to include all of the times that that dimension was seen. Whereas if you have single pages over entries, it’ll be when that dimension was the entry version for that particular component. So the entry being the first item of that component that was seen in a visit.

So although they seem similar, visits and entries can give you different numbers. So that is a great thing to keep in mind when building out bounce rate or single page visit rates.

Yes, completely agree with that.

Okay, moving on to our next question. If a user keeps our website open in a browser tab but doesn’t visit that tab for days or weeks, is the visit number resetting? And it goes on, or are inactive tabs slash pages for this visitor no longer triggering a visit or hit or other metrics until the tab is revisited? So yes, if you have 30 minutes of inactivity, then that triggers a new visit. If I’m clicking around on the website and I get up and I go get a coffee and you know, it takes me time, I have to make a whole new pot, and it takes me 35 minutes till I get back and then I click on something else, what 51ºÚÁϲ»´òìÈ does is it looks at the time between the calls that fire. And if that time between calls is greater than 30 minutes, that hit when I come back is going to start a new visit. It’s not going to be a continuation of the previous visit.

Yeah, that’s something that a lot of people have come across. So I’m glad that we brought that up. And that was a great question.

Here’s another one. Is there a workaround on changing default metrics in 51ºÚÁϲ»´òìÈ? So I’m not entirely sure what you mean by changing default metrics. But I guess if you want to change something like the allocation, you can make a calculated metric built off of those default ones. I’ll use revenue, for example, you know, revenue comes in as a default metric. If you want to change how it’s attributed, you can build a custom metric, drop revenue in it, and then use the settings to change the default allocation. So instead of it being, you know, last touch, you could set it to linear or participation, and then save that. You can also change the look back window as well. You can change it to a visit or a visitor look back, a 30 day look back, whatever it is that you need. So the calculated metric builder is a great way to be able to make some changes to the allocation and the look back of different metrics.

Okay, great.

Next question. In what scenarios would occurrences be better metrics than page views for measuring performance affect trend analysis over time? So I’m personally of the opinion that occurrences isn’t the better metric compared to sorry, was it compared to page views? Yeah, page views for measuring performance. Okay. Yeah, I personally would use page views over occurrences because occurrences is going to capture every single hit that fires.

Whereas page views is going to be a little bit more specific. So if you have a value that’s persisting through page views and through custom links, occurrences is going to capture all of those. I’ll use an example. Say you have a banner on your home page and there’s a query string parameter attached to it. If you want to see how many times that query string parameter is attached to a page, you can use page views to see the number of page lows. But if that persists beyond the initial page, because you might want to see conversion, if you use occurrences, it’s also going to include stuff like clicks and other custom links that have fired. So you always want to be very careful when you’re using occurrences just because it does incorporate so much information.

Great, thank you for that answer. Here’s a great question as well. I think this one affects a lot of different companies and a lot of different industries. What if there are bots hitting my site and are not captured in 51ºÚÁϲ»´òìÈ’s bot dimensions and metrics? Yeah, that’s a great question and that is almost certainly the case. Pretty much every website will have some bot traffic that is not automatically filtered out with 51ºÚÁϲ»´òìÈ’s internal bot filters. What you can do is you can use different dimensions and metrics to try and identify traffic that looks like a bot. So based on the refer, the ISP domain, other fields such as that, and then build out a segment and apply it to your virtual report suite. What we do is we have our main report suite that captures all the information. We occasionally review it and if we see a spike in traffic that looks like it’s coming from bots, we have a segment that is specifically built out to filter out that traffic. So we add the conditions in there and then we apply that to our virtual report suite and we have our analysts and business partners that are using Workspace. We tell them to always use that virtual report suite so that way it has the segment with the bot traffic filtered out. The conditions that you put in that segment will vary from organization to organization depending on what type of bots are hitting the website.

Yeah, that’s a great tip right there.

That’s the thing with today’s industries and just everything that’s going on on the internet right now. There’s no way to track everything that’s out there. Something always comes in that’s new and we just here at 51ºÚÁϲ»´òìÈ, we just can’t keep up with it. But I love the way that that’s a great solution.

Okay, next question. If a page reload happened multiple times within the same visit, how are occurrences, page views, and visits counted in 51ºÚÁϲ»´òìÈ Analytics and how might the SKU bounce rate interpretation? So if you reload a page, so say you’ve entered the site, loaded one page, and then reloaded it again, that is going to be two page views. So every time you load the page, it does fire a new call. And if it’s a page load call that’s firing, it’s going to come in as a page view. If you’re looking at a metric like bounce rate, that will make it no longer a bounce because there are two calls that fired. But when the page reloaded, if it’s the exact same page as the first one, single page visits counts the unique page identifier. So even though there’s two hits on that page, if it’s the same page, it still counts as a single page visit.

So over time, you will see that the page views and the occurrences will increase with each hit. So that’s why when calculating something like a bounce rate, I use single page visits instead of just bounce rate because seeing the same page, if that’s the only two hits, it doesn’t necessarily mean that they’re doing anything interactive with the site. It’s not necessarily an engaged visit.

They just might have hit refresh by accident or needed to reload some information on the page. Yes, with single page visits, it’ll be the same, but the other metrics, it will increase the count.

Okay.

Well, we might have time for one quick question. I know there’s a lot more questions in here, but can UTM metrics be tracked in this tool? So the UTM metrics aren’t tracked by default, but you can use processing rules to bring those UTM parameters into different EVARs or props. So the processing rules, they’re not really in the scope of this presentation, but processing rules are very powerful and they can help you bring in a lot of other information into your reporting.

Okay. Well, unfortunately, we’re all out of time. Thank you so much for being with us, Mandy. Thanks for having me. I always enjoy presenting here.