Skip to main content
Interania

Interpreting queries that use per-actor metrics

6votes
21updates
730views

Goal

Per-actor metrics are extremely powerful behavioral constructs that help you understand your key metrics on an actor-by-actor basis.  Using per-actor metrics, you can answer questions like:

  • On average, what is the number of times a member of our site uses our "private message" functionality per day?
  • What is the 90th percentile of errors seen on a per-user basis?
  • What is our weekly user churn over time for our group of users that view more than 5 videos in a week compared to the group that viewed less?

With this flexibility and power can come several big questions.  Here are the questions around per-actor metrics that I receive most often:

  1. What is the difference between filtering in the metric itself and filtering in explorer view?
  2. How are aggregated per-user metrics affected by grouping?
  3. What happens when I apply an explorer view filter on a per-actor metric?

The goal of this how-to is to clarify the behavior of per-actor metrics in the cases above, through simple examples that you can apply to your own datasets.

Exposition

I'll be using a very simple data set to demonstrate query behavior.  We have 3 users generating pageview events from mobile and web platforms over a week long period starting 9/1/2016:

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John Mobile 0 Web 2 Mobile 0 Web 3 Mobile 2 Web 0 Mobile 0 Web 0 Mobile 0 Web 5 Mobile 0 Web 4 Mobile 0 Web 3
Danny Mobile 2 Web 2 Mobile 0 Web 2 Mobile 4 Web 0 Mobile 1 Web 0 Mobile 2 Web 2 Mobile 1 Web 1 Mobile 2 Web 0
Alexis Mobile 2 Web 3 Mobile 3 Web 4 Mobile 5 Web 0 Mobile 2 Web 0 Mobile 2 Web 3 Mobile 4 Web 4 Mobile 0 Web 8

A sampling of those events, in JSON:

{"user":"John","event_name":"pageview","timestamp":"1472744606248","source":"web"}
{"user":"Danny","event_name":"pageview","timestamp":"1472921457736","source":"mobile"}
{"user":"Alexis","event_name":"pageview","timestamp":"1473152661044","source":"web"}

And here's our daily event count by user, once we've imported the events into Interana:

Filtering and Per-Actor Metrics

Get Bearings with Unfiltered Metric

The key to understanding explorer queries that reference per-actor metrics is understanding how the per-actor metric values are calculated and applied to the events in explorer view.  

In short, per-actor metric values are calculated in "sub-queries", which are run before the main query.  This is necessary to do things like filtering on per-actor metric values.  The parameters of these sub-queries are specified in the per-actor metric definition, and often inherited from the explorer query itself (in particular, the time windows that the subquery results are calculated over).  Once calculated, the metric values are associated with each relevant event - for instance, all 3 of the events that "John" generated on 9/2/2016 will be associated with per-actor metric value 3, when the metric was calculated with a 1 day time window.

Let's begin by taking a look at the most simple per-actor metric possible with this dataset, eventsperuser:

Since we're not using a time override, the metric calculation will inherit the time window of the explorer query.  Here's what the average of this metric looks like over time, at a resolution and time window of 1 day:

As you can see, we've calculated the count of events for each user in our dataset on a daily basis, and graphed the average of that per-actor metric.  In the case of calculating the average without an explorer filter:

The numerator is the sum of the event count metric for each actor that acted in that time window
The denominator is the number of unique users that generated events within that time window

This example exposes a very critical point in understanding per-actor metrics in all contexts- if an actor does not generate an event within a time window that the metric is calculated over, they will not have a metric value associated with that time window.  In plain English, we describe this calculation as the "average events per user that acted within the time window".

This is why the average eventsperuser is 1.5 and not 1 for 9/4/2016 in the chart above- the denominator is 2, not 3, because user "John" does not generate a single event on 9/4/2016.

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John 2 3 2 0 5 4 3
Danny 4 2 4 1 4 2 2
Alexis 5 7 5 2 5 8 8
Average 11/3 = 3.67 12/3 = 4 11/3 = 3.67 3/2 = 1.5 14/3 = 4.67 14/3 = 4.67 13/3 = 4.33

Explorer Filtering

You may have noticed that there are actually 2 places we can filter in the query above (explorer view and in the metric construction).  Let's see what happens when we apply the explorer filter (`source` = "mobile") to the analysis above:

What's happening here?  This is clearly not the average event count per user where (`source` = "mobile").  The key to understanding this behavior lies in understanding that the metric subquery ran before the explorer filter was even applied, and counted all events that matched the filter set specified in the metric filter (none were applied, so we counted all events).  The explorer filter filtered to the events where (`source` = "mobile"), and those events have metric values associated with them that were calculated over all events.

The same calculation rules that we used in the first example also apply in this example, but now we must apply the explorer filter, which filters at the event level.  We defined the calculation earlier as:

The numerator is the sum of the event count metric for each actor that acted in that time window
The denominator is the number of unique users that generated events within that time window

Now that we're considering the explorer filter, we need to add a bit more specificity to the description above:

The numerator is the sum of the event count metric for each actor that generated an event that matches the explorer filter set in the time window
The denominator is the number of unique users that generated an event that matches the explorer filter set within the time window

I've performed the calculations below given our revised calculation definition above.  In red I show the users that do not generate mobile events within each 1 day time window.  Notice that I don't exclude the web events for users that do generate mobile events in the time window in the following chart- this is because those web events contribute to the unfiltered metric value.

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John Mobile 0 Web 2 Mobile 0 Web 3 Mobile 2 Web 0 Mobile 0 Web 0 Mobile 0 Web 5 Mobile 0 Web 4 Mobile 0 Web 3
Danny Mobile 2 Web 2 Mobile 0 Web 2 Mobile 4 Web 0 Mobile 1 Web 0 Mobile 2 Web 2 Mobile 1 Web 1 Mobile 2 Web 0
Alexis Mobile 2 Web 3 Mobile 3 Web 4 Mobile 5 Web 0 Mobile 2 Web 0 Mobile 2 Web 3 Mobile 4 Web 4 Mobile 0 Web 8
Average 9/2 = 4.5 7/1 = 7 11/3 = 3.67 3/2 = 1.5 9/2 = 4.5 10 / 2 = 5 2/1 = 2

Simply put, this analysis gives us the average event count per user that generated a mobile event within the time window.

The next logical question is- well then, how do we calculate the average daily mobile events per user?  We're going to need to filter in our metric to do that!

Metric Filtering

I've created a new metric below that will count up the mobile events per user on a daily basis, by adding a filter to the metric we were using previously:

Now we will count only events that match the metric filter set in our subquery.  As before, this metric value will be associated with all relevant events (those being all of the user's events within the time window each metric was calculated).  Let's have a look at our results:

Applying our calculation rules:

The numerator is the sum of the event count metric for each actor that generated an event that matches the explorer filter set in the time window
The denominator is the number of unique users that generated an event that matches the explorer filter set within the time window

And understanding that our metric value has now changed due to the filter we applied, the calculations are fairly straightforward.  Note that since user "John" has no events that match the explorer filter set for 9/4/2016, the denominator of the average calculation is 2 on 9/4/2016.

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John Mobile 0 Web 2 Mobile 0 Web 3 Mobile 2 Web 0 Mobile 0 Web 0 Mobile 0 Web 5 Mobile 0 Web 4 Mobile 0 Web 3
Danny Mobile 2 Web 2 Mobile 0 Web 2 Mobile 4 Web 0 Mobile 1 Web 0 Mobile 2 Web 2 Mobile 1 Web 1 Mobile 2 Web 0
Alexis Mobile 2 Web 3 Mobile 3 Web 4 Mobile 5 Web 0 Mobile 2 Web 0 Mobile 2 Web 3 Mobile 4 Web 4 Mobile 0 Web 8
Average 4/3 = 1.33 3/3 = 1 11/3 = 3.67 3/2 = 1.5 4/3 = 1.33 5/3 = 1.66 2/3 = .67

Simply put, this analysis gives us the average mobile event count per user that generated any event within the time window.

Explorer and Metric Filtering Together

To round out your understanding, go ahead and calculate what you believe to be the result of adding the (`source` = "mobile") filter in both the explorer query and metric subquery.

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John Mobile 0 Web 2 Mobile 0 Web 3 Mobile 2 Web 0 Mobile 0 Web 0 Mobile 0 Web 5 Mobile 0 Web 4 Mobile 0 Web 3
Danny Mobile 2 Web 2 Mobile 0 Web 2 Mobile 4 Web 0 Mobile 1 Web 0 Mobile 2 Web 2 Mobile 1 Web 1 Mobile 2 Web 0
Alexis Mobile 2 Web 3 Mobile 3 Web 4 Mobile 5 Web 0 Mobile 2 Web 0 Mobile 2 Web 3 Mobile 4 Web 4 Mobile 0 Web 8
Average              

 

 

<scroll down for answers>

 

 

<keep scrolling...>

 

 

<almost there!>

 

 

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John Mobile 0 Web 2 Mobile 0 Web 3 Mobile 2 Web 0 Mobile 0 Web 0 Mobile 0 Web 5 Mobile 0 Web 4 Mobile 0 Web 3
Danny Mobile 2 Web 2 Mobile 0 Web 2 Mobile 4 Web 0 Mobile 1 Web 0 Mobile 2 Web 2 Mobile 1 Web 1 Mobile 2 Web 0
Alexis Mobile 2 Web 3 Mobile 3 Web 4 Mobile 5 Web 0 Mobile 2 Web 0 Mobile 2 Web 3 Mobile 4 Web 4 Mobile 0 Web 8
Average 4/2 = 2 3/1 = 3 11/3 = 3.67 3/2 = 1.5 4/2 = 2 5/2 = 2.5 2/1 = 2

Simply put, this analysis gives us the average mobile event count per user that generated a mobile event within the time window.

And that's that- the difference between filtering in explorer and filtering in the metric definition.  Remember that this logic applied to all named expressions (cohorts, metrics, sessions, and funnels).  The subquery is run with the filter specified in the named expression, the query results are associated with the relevant events, and then the events are filtered by the explorer filter.

Grouping And Per-Actor Metrics

Now that we have a solid understanding of how filtering with per-actor metrics works, grouping is quite simple.  Continuing to use our dataset, let's group by source:

We've seen the "mobile" curve before- when we filtered on (`source` = "mobile") in the section on explorer filtering above!  You can think of "grouping" a per-actor metric by an attribute as applying the different values for that attribute individually in the explorer filter.  To confirm, here's the same chart with compare filters:

As we saw before, here's how the "mobile" group is calculated:

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John Mobile 0 Web 2 Mobile 0 Web 3 Mobile 2 Web 0 Mobile 0 Web 0 Mobile 0 Web 5 Mobile 0 Web 4 Mobile 0 Web 3
Danny Mobile 2 Web 2 Mobile 0 Web 2 Mobile 4 Web 0 Mobile 1 Web 0 Mobile 2 Web 2 Mobile 1 Web 1 Mobile 2 Web 0
Alexis Mobile 2 Web 3 Mobile 3 Web 4 Mobile 5 Web 0 Mobile 2 Web 0 Mobile 2 Web 3 Mobile 4 Web 4 Mobile 0 Web 8
Average 9/2 = 4.5 7/1 = 7 11/3 = 3.67 3/2 = 1.5 9/2 = 4.5 10 / 2 = 5 2/1 = 2

And here's how the "web" group is calculated:

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John Mobile 0 Web 2 Mobile 0 Web 3 Mobile 2 Web 0 Mobile 0 Web 0 Mobile 0 Web 5 Mobile 0 Web 4 Mobile 0 Web 3
Danny Mobile 2 Web 2 Mobile 0 Web 2 Mobile 4 Web 0 Mobile 1 Web 0 Mobile 2 Web 2 Mobile 1 Web 1 Mobile 2 Web 0
Alexis Mobile 2 Web 3 Mobile 3 Web 4 Mobile 5 Web 0 Mobile 2 Web 0 Mobile 2 Web 3 Mobile 4 Web 4 Mobile 0 Web 8
Average 11/3 = 3.67 12/3 = 4 undefined undefined 14/3 = 4.67 14/3 = 4.67 11/2 = 5.5

Simply put, if a user generated an event in a particular group, their metric value is used in the calculation for that group.

Filtering on Per-Actor Metrics

We're on the home stretch!  One last question to tackle- what happens when we use a per-actor metric in an explorer filter?  It's fairly straightforward - we filter to the events of the users that satisfy the per-user metric filter.  Have a look at the following stacked area time chart:

Comparing to the total daily event count of our users, we see that everything matches up:

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John 2 3 2 0 5 4 3
Danny 4 2 4 1 4 2 2
Alexis 5 7 5 2 5 8 8
Users 2 1 2 0 3 2 1

And, if we change the aggregation to count events:

We can see that we're filtering to the events of the users that have metrics that satisfy the per-actor metric filter.

User 9/1/2016 9/2/2016 9/3/2016 9/4/2016 9/5/2016 9/6/2016 9/7/2016
John 2 3 2 0 5 4 3
Danny 4 2 4 1 4 2 2
Alexis 5 7 5 2 5 8 8
Events 9 7 9 0 14 12 8

 

What's Next: Apply To Your Data

Thank you for reading- I hope that this how-to has been helpful on your path to Interana power user.  In general, whenever you seek to understand your query results:

  1. Calculate the results of your subqueries (cohorts, metrics, sessions, funnels) using the filters you've specified inside the subquery.
  2. Associate the results of those subqueries with the events they relate to in the dataset (they may be associated with a particular actor, time window, session, or funnel)
  3. Apply the explorer filter to those events
  4. Perform the aggregations specified in explorer view

If you have any additional questions, don't hesitate to reach out to your success manager!

  • Was this article helpful?