Of Visits and Sessions

17 Feb 2019 » Analytics Tips

As I have said a few times, it is very easy to measure page views. I have also explained how to measure visitors. There is, though, another typical question to answer: how many times has a visitor visited our website? Seems like a simple question, right? Well, it turns out, measuring visits is not that simple.

If you think of a brick-and-mortar store, you can count visits by the number of times a person has entered the shop. However, in the digital world, there are more questions that you will want to answer:

  • If the visitor leaves the browser window open for hours, does this count as a single visit?
  • If the visitor comes and goes multiple times during the same day, when do you consider that a visit has finished and starts a new one?
  • Do we want to apply the same definitions to apps and web?

I hope that, by now, you start to understand the issue.

Browser session

Before I jump into how Adobe Analytics deals with visits, let’s start with the intuitive solution. In theory, you would like to count the number of times a visitor has opened a new browser window or tab and has gone to your website, one way or another. This is what we call browser session.

While this sounds simple, it is easier said than done. The first issue is that there is no way Adobe Analytics servers know when a user opens or closes a tab/window. When you click on the browser close icon, it just removes the website from the screen, without notifying anybody. There could be some workarounds:

  • You could send a hit every X seconds, to signal that the visitor is still on the website. But it has two additional problems: it would cost you a fortune in server calls and you do not know whether the visitor is actually watching the page or has switched to another tab or even another application in his laptop. It could even be the case that he has left the browser open and had gone to sleep!
  • I believe it is possible to capture in JavaScript when a page is unloaded. However, this may not always happen or the browser could kill the code to be more responsive.

The second issue is more conceptual and it relates to the mere definition of a visit. Here are some additional questions that you need to take into account:

  • What if the visitor has multiple tabs and moves from one tab to another? Do you count a visit even if the tab is not visible?
  • What if the visitor closes a tab with your website and immediately opens a new tab, to go to the same website? Will this count as one or two visits?

In summary, as you can see, trying to calculate the total number of browser sessions can be very tricky. In fact, it is so tricky that Adobe Analytics ignores browser sessions altogether.

Mobile apps

If we did not have enough with the web, mobile apps add more dimensions to the visit calculation. Again, you could think that it is as simple as counting the number of times an app is launched. But there are another array of things to consider:

  • As with the web, what if the visitor closes and opens again the app in a very short period of time?
  • In case you did not know it, when you “close” the app, the operating system does not actually close it. It just puts it in the background. The reasons is that, in case you want to use it again, the app is already loaded and the response time much lower. You probably have noticed that, if you open the app soon after closing it, it is in the same state as you left it. The operating system will only unload (i.e. close) the app from memory when it needs additional resources and you are not using that app.
  • If you send hits while the app is in the background, they will count towards the visit and visitor count.

Although apps are different, the problem is still the same. The concept of session has too many issues and it is not used.

Web visits

Let’s now focus on the solution. Adobe Analytics has created an artificial definition of visit. It is a succession of page view and interactions with the website, which ends with any of the following circumstances:

  • 30 minutes of inactivity. This is a time that can accurately be measured server-side. Remember, Adobe Analytics’ servers can only see server calls, not browsers. I believe that this limit makes sense. If you have not been interacting with the website for more than 30 minutes, it most probably means you have left.
  • 12 hours of consistent activity. Who spends 12 hours browsing a website? Anybody?
  • 2500 hits. Again, who watches 2500 pages from the same website in a single visit?
  • 100 hits in 100 seconds. And, who views 100 pages in 100 seconds? Can you read a page in 1 second and go to the next one?

By far, the most typical case for ending a visit is the first one and it is the only case you should remember. The other 3 are just to protect Adobe Analytics: calculating a visit is a very resource-intensive process and very lengthy visits will affect the processing. I can only think of two options for these 3 latter conditions:

  • A bot or any other automated process. In other words, not a real human.
  • An implementation issue. If you are sending a server call every few seconds, you should change it and limit to a few minutes. It could well be that a visitor leaves the browser open and the computer unattended.

This is an objective measure: you know exactly how it works. I am not saying that this is the best definition. In fact, some competitor software uses a slightly different method, although still retaining the 30 minutes boundary.

App engagement

In the case of the apps, we can still use the visit metric, as defined above. However, the apps run in a more controlled environment. The Adobe SDK takes advantage of this and offers a few more metrics, part of what Adobe calls lifecycle metrics:

  • First launches. The SDK can detect when the app launches for the very first time after being installed. Since the SDK is not executed while the app is downloaded and installed, this is the closest we can get to calculate the number of downloads/installs. However, if the user downloads an app and never opens it, you will never know it. On the other hand, if the user uninstalls and installs again the app, the SDK will fire again the first launch metric.
  • Launches. The SDK fires this event when the app is brought to the foreground and the session timeout has been exceeded. Bringing an app to the foreground just means that the app is ready for the user to interact with it. This can happen both when the app is completely stopped or is in the background, as I explained before. You can configure the timeout and the default to 300 seconds (5 minutes). Now you can play with this timeout to find a value that suits you.
  • Daily Engaged User. This metric is fired one per day, no matter how often you launch the app.
  • Monthly Engaged User. This metric is fired one per month, no matter how often you launch the app.

They are just regular events, although they do not take any of the custom metrics.

Virtual report suites

Finally, there were multiple requests to create a more flexible definition of visits. Making any changes to the out-of-the-box metric was probably not a good idea. The solution that Adobe created was to add new features to virtual report suites, like allowing for a different definition of visit:

You can now do the following changes, which will affect only the virtual report suite, not the physical, underlying report suite:

  • Define the timeout for the end of a visit, instead of the default 30 minutes.
  • Define an event as the start of a visit.
  • Prevent background hits in mobile apps from starting new visits.

Other Adobe tools

I did not cover how Adobe Target counts visits. That could be another post. However, be aware that it is different from Analytics. Therefore, do not try to compare reports from both tools.

Adobe Audience Manager has no concept of visits.

 

Photo by Martin Vorel

Related Posts