We've just learned about Metrics in the last section. One way to think about per-actor metrics is as named expressions that compute something per actor over a window of time. This section is focused on Sessions, a named expression for each actor that divides a sequence of their actions into discrete sessions. Interana sessions are very flexibly defined using arbitrary idle times or restart events — neither one of which needs to defined at the time the events are collected. Sessions provide a powerful tool for understanding how various actors interact with your application, the environment, and each other. Let's dive in and take a deeper look.
Sessions in Action
Head back to the landing dashboard by clicking the Interana logo at the top of the navigation panel. Once there, scroll down until you find the chart showing the average number of users engaged with an article during an edit session. It should look something like this:
Click the compass to bring the chart into the Explorer, and check out how it's defined. Notice that the measure being visualized is the Average of a session object named Article_DayInactive.Users. Click the tool tip icon to learn more about the session named expression:
The results are shown for two name spaces: Main and Talk, which makes sense since we're grouping by
space. The events getting visualized are further filtered based on three criteria. They are edits to the article (rather than new article creation), they occur in the Main and Talk spaces, and they are associated with sessions that have more than a single event (Article_DayInactive.events_count > 1).
The events_count metric is an automatic metric that Interana computes and provides for sessions, along with the session duration. In this example, we're trying to understand what happens to articles that are repeatedly edited, so we're filtering out articles that have a single edit with no follow-up changes in over a day.
Getting back to the Measure, we see that we're looking at the average number of users who were actively involved in editing an article (Main name space) or discussing the article edits (Talk name space). This metric is attached to the per-article session definition.
How sessions are defined
Let's see how the session was defined. Click the tool tip and then the Edit link. You'll see a box with the following definition:
Click that copy button and we'll continue with your own version that can be modified. Name it something like MyArticle_Session. Then head over to the My area of the Sessions page and click the pencil icon to edit the session definition. We'll explain each section while we make some changes:
The first thing we come to is the definition of the dataset and actor. Here, we see that the session is defined for each article in the Wikipedia dataset. Actors don't have to be something typical like users or devices — articles, topics, etc. are just fine. Since we're interested in the behavior of articles, we choose them as the actor for this session definition.
Next, notice the New Session conditions:
What makes it special: Analytics often uses the term "actor" to refer to the entity initiating an action. These are sometimes hard coded into the analytical frameworks and need to be defined and tagged into an application prior to collecting data. With Interana, what constitutes an actor is very flexible and can be defined after the data has already been collected. As this example shows, it's also useful to treat entities acted upon (like articles, films, or devices) as actors. We can then study what happens to those entities over time and how they are acted upon by people.
A new session for the article begins when the article hasn't appeared in the sequence of events for at least a day. There's also the ability to explicitly define a session start event — for example: user logs in — but here it's not being used. Let's edit the definition and say that a session starts when the article is created. (This might make sense if the article was controversially deleted and gets created from scratch by qualified editors rather than undeleted.) Click the + button for the Restart session event, and select
type is one of new. The end results should look like this:
Next, take a look at the filters and description. Leave the filters as is, and update the description to mention the new restart event:
Now we come to the most powerful part of Interana sessions — the ability to attach as many custom metrics as you need. The current session has three metrics: Users, Bytes, and Abuse. Each of these are accessible for use as measures or filter conditions in the Explorer, and you can add more using the + link at the bottom:
The Bytes measure is using our old friend
length.abs.delta from the last section. This captures the total number of bytes changed (additions and deletions) for an article. But what if we wanted to understand the net changes to an article during the session? Did the article grow or shrink during the session? By how much? Turns out that we have another derived column around called
length.delta that tracks deletions as a negative value. If we sum that, we would have the information we need.
Let's add another metric by clicking the + link at the bottom. Name the metric NetBytes and define it as the Sum of
length.delta. The end result should look like this:
Notice that the new metric is now listed among the custom metrics at the top of the Session Metrics block:
You might have also noticed the list of automatic metrics shown in the session definition area toward the top right of the box:
The duration and event count are available for all sessions, even if you don't add any other custom metrics. There's an invisible scroll bar in the description area, so you might need to scroll down to see them in your browser.
Ok, let's save the improved session expression and try it out. Click the big blue Save button at the bottom, and head back to the Explorer where we had our previous session chart.
Using the improved session metric
Let's see if we can use the new metric to look at the evolution of English Wikipedia articles during editing sessions. Click into the Measure field where the original session is referenced. Start typing the name of your new session (e.g., "MyArticle") and you'll see all the metrics associated with the session, including the new one you just defined:
Select the new NetBytes metric. How does it look? Probably something like this:
Notice that there seems on average of 2-6KB of added content per edit session. Seems a bit strange for what's essentially text. Let's take a deeper look, grouping by
wiki as well as
Interesting! We can clearly see stretches of time where there are big purges of information (negative values) and well as additions. The other bit that stands out is that English Wikipedia doesn't even show up in the top 10 groups. The scales are much larger than the 2-6KB range we were seeing before. That's not exactly what we're trying to explore. Let's drop the
wiki grouping, filter for
wiki is one of enwiki, and see how it looks:
Ok, this looks a bit more expected. The actual content changes average less than 1000 bytes, and there's much more action in the Talk space (discussing changes) than making actual changes to the article. (By the way, you can see just the Main edits by unchecking the Talk box in the legend. That makes the amount of article changes more obvious. Select the Talk box again to return to the original view.)
Let's explore a bit more. Sometimes averages can be misleading, especially if there is a small number of very large contributions. Let's change the Measure from Average to Median and see what shows up:
So it looks like there's still tons of discussion happening in the Talk space, but the median net change to an article is very small (less than 100 bytes). So it looks like most edits to an article are indeed small, but there's still a lot of discussion around making each edit. Sounds like a good community effort in action!
One last bit of exploration: let's check to see if the amount of discussion stays the same when it comes to large changes, or if the discussion also goes up proportionately. Change the Measure from Median to 95th Percentile and repeat the query:
So it looks like larger changes do indeed get much more discussion among the editors. That's a bit of insight about Wikipedia editor behavior that we might have intuitively known, but can now confirm with data.
How can I use it? Session metrics are generally useful in any situation where users start and stop actively using a service. Often the idle periods are in terms of hours, but it could be days, weeks, or even months. For example:
- Business owners can use sessions to relate engagement and activity with retention and lifetime value.
- Product managers can see which features are most engaged in the greater percentage of sessions.
- UX experts can use them to streamline on-boarding or increase engagement.
You can use sessions to count clicks to complete a certain task, the number of turns from passenger pickup to dropoff, or anything that's bounded by time or specific actions.
We just saw how to flexibly define sessions on sequences of per-actor events and create our own new session metric. Interana provides powerful mechanisms to define sessions based on user behavior as well as idle periods. You can adjust the definition dynamically. However, perhaps the most powerful aspect of our sessions is the ability to attach multiple custom metrics to the session definition, and have those metrics appear in the Explorer as columns. No coding is required.
Let's continue to what is perhaps Interana's most powerful behavioral analytics feature: funnels.
Keep in mind that you're using a shared demo system meant for learning by everybody. The dashboards and objects you create will stick around for a while, but we will periodically clean up the system and remove stale accounts.