There are many out-of-the-box reports available in Reports & Analytics (formerly SiteCatalyst) such as Referrers, Countries, Browsers, Device types, Search Engines etc etc. But the real power of Reports & Analytics lies in the creation of custom reports, it’s also important to note that these custom reports can be quite unique across different industries.
So what do we need to create custom reports?
Basically you need to set variables. There are 3 different types of variables that allow you to do a multitude of custom reports, and these variables all have different characteristics which can be changed. The variable types are commonly known as:
1. Custom conversion variables (eVars)
2. Custom traffic variables (props)
3. Success events
Although written a few years ago now, Back to basics – props, eVars and events is a great article to give you a background on these variables.
How does this all tie together?
Let’s have a look at how these variables actually end up giving us our custom reports, starting with a brief description of the 3 variable types.
eVars (Conversion variables)
An eVar is a persistent or sticky variable, which basically means it holds its value until the variable expires. We can change the expiration of an eVar in the admin console and it can be based on a time period (a week, or a month) or after a visit ends. There are actually many options available but we’ll look at how you go about choosing the right option a little more deeply in another article.
Events
These are basically the counters for what we consider to be success events on our site and which we tie back to our eVars. We may want to know how many times a sale occurred as an example.
props (Traffic variables)
A prop is a non-persistent variable. They allow you to breakdown things like page views into more meaningful buckets, such as the page name, or the section name of your site.
While you can create general reports using props (looking at those bucketed values), they’re the only way to create pathing reports and Real-Time reports as well as a good way to create segments.
So what do we do with these variables?
Let’s look at a real life example of how these variables work and how we end up with our final product – the custom report. In the following scenario we’d like to know how many users tried to contact us via an online form, to do this we need to capture the name of the form (e.g. contact us) and if a user has started the form and completed the form.
The type of report we would end up with would look similar to the following image:
From this report we can see a lot of Form Starts, but a only a small number of Form Submits. This would make me curious and I would start to dig deeper to see if there are issues with the form. Maybe a lot of users are starting the form, but there is some type of road block stopping them from completing the form. If we aren’t collecting the data we may never really know if there is something wrong or not with the form.
How did we create this report?
Ok lets take a few steps back. This report ‘Form Name+’ shows a value ‘contact us’ with a number of Form Starts and Form Submits. Form Name+ is actually an eVar that is set when our form initially loads – e.g. set eVar43 to ‘contact us’.
Hold on, what is eVar43? Basically an our variables (eVar, prop and event) are defined by a number which then in our admin we give user friendly names. So we map eVar43 to the user friendly name ‘Form Name+’.
We can then look for the report called Form Name+ which is a bit more meaningful then a report called eVar43.
What does the Form Start and Form Submit represent?
These are the counters which show us how many times a form was started, and how many times it was completed; they are our events variables. So as well as setting our eVar43, we also set these events in the appropriate places: When a user starts the form we set event5 which increments the value by 1 and represents a Form Start in the report. When they complete the form we set event6 and increment that by 1 which represents Form Submit. Again we have given these events user friendly names via the admin section.
Is there an example of when I would use a prop?
Yes, as mentioned there are 3 scenarios where a prop can come in handy.
Segmentation
Ok, say we want to look at different visitor types on our site to look at trends in their behaviours. We might have 2 visitor types – Member and Non Member – depending on whether the user has logged in or not. In our admin we have set prop3 as our Visitor type:
So in prop3 we would set the value ‘Non-Member’ on each page when a user has not logged in, and set the value to ‘Member’ on each page after a user has logged in. We would then have a custom traffic report that would look as follows:
We can now create a segment from this where we only look at ‘Member’ visits and we can look for behavioural trends for that particular Visitor Type. Stay tuned for my next blog post when I will chat more about segments.
Real-Time reports
Real-Time reports are a great way to see what is happening on your site now. The only way to generate these reports though is to use props. We will leave the intricacies of how this works for another article, but following is a sample of a Real-Time report showing a trend of page views over a 15 minute period.
Pathing
Pathing reports are a nice and simple way to see the common user journeys on your site. You have to enable pathing on traffic variables in the admin section. In the following screenshot we can see that pathing has been enabled for prop40 (or Tool Name).
This would then enable us to see the journeys between the different tools for this particular website. The custom report would look as follows:
So we have looked at practical examples for each of the 3 variables that are available to us in Reports & Analytics. If you can get your head around these 3 different variable types then you are well on your way to understanding the process starting from setting a variable to looking at how they connect in the final report.
