This page will describe concepts used in Analytics, listed alphabetically.
Througout this section the term your application means just that, i.e. your application - the one you produce and which is now tracking usage information using Analytics.
With Analytics added to your application, each installed instance of the application will locally store a unique identifier. This identifier is submitted along with all requests and used to correlate sessions coming from this installation, which are used for e.g.filtering purposes and to calculate unique number of users.
Historically the Anonymous ID has also been called the Cookie ID.
The daily users is a measure for how many unique installations have reported data on a specfic day, i.e. how many individual users have started your application on the given day. This is in contrast to sessions, which is a measure for how many times your application has been started in total by all users.
Naturally you want to know how many users you have in total. How many unique users used my application today? How many unique users have used it the latest month? How many in total for the full lifetime of my application? Analytics can provide the exact anwers to such questions.
Before we dive in let us establish a full understanding of the relation behind the terms sessions, daily users and total unique users. Please take a look at this example:
Imagine that your application is used by 4 individuals: Peter, Paul, Mary and Jill. Each is running their own installation of the software from their own device. This means that each installation of the application is identified with a unique Anonymous ID as described above. With this information the Analytics system can see how many sessions are coming from Peter, how many from Paul, etc. You can e.g. see that on Thursday Mary generated 21 sessions from her device. Peter only did this 12 times. Paul didn't run the software that day and neither did Jill. So on Thursday your application was used 33 times, but only by two users (see Total daily sessions and Total daily users for Thursday).
Now, if you look at the totals for the full week 89 sessions were created. Sessions can thus be summed into totals. Total sessions in a given week is a sensible figure. Also the average number of sessions during a given period is valuable to know. Here we could calculate the average number of sessions per day to 12.7 (89/7 = 12.7).
Daily users on the contrary should not be summed into totals - unless you know what you are doing!! In the example above you can see that the sum of the daily users is 14. This does not mean that 14 different users used your software this week. It rather means that on average you had exacly 2 users per day (14/7 = 2). Those 2 users could be the same individuals or they could be new users each day.
You naturally also want to know how many active unique users you have in a specific period. In the example we can see that this number is 3 for the full week. It is calculated based on the unique Anonymous IDs. To calculated the unique number of users in a specific period there is only one way to do this correctly, and that is to look at every sessions received and stored during the period and then count how many differnt Anonymous IDs are seen. This information cannot be precalculated as we do with most other types of data in Analytics. So the time it takes to calculate this number is directly related to the length of the period you have selected and the number of sessions stored during the given period.
But how do you find the number of total unique active users? You can only do this with Data Studies. Here is an example of how you would do this.
Add the Users widget to a dashboard:
Then create a new data study that will be applied to the Users widget:
Finaly specify in the Summation category that you wish to Show total number of individual users in entire period:
Click Run and find the results in the Data Explorer -> Results view. It may take a short while to calculate the result.
You can read more here about Installations.
Note: Data Studies are not available for the Professional subcriptions. Business or Enterprise are required to run these.
Using the Analytics monitor developers can add tracking-code to their application where desired to track when "features" of the application are being activated or exersized. Feature tracking is divided into three functional areas:
TrackFeatureto track when something happens, e.g. when user clicks on a button or a menu
TrackFeatureTimingto track how long an operation takes, e.g. the processing of a photo in a photo-app
TrackFeatureValueto track the value of something, e.g. the number of photos in a photo-app
Adding the tracking code is a manual process but the code is typically just a one-liner like this:
An application is the Telerik Platform name for managing your analytics integration for one particular product. If you wish to integrate Analytics into your software you must create an application for doing so. There are three kinds of applications: Hybrid, Native and Analytics-Only. The first two have analytics integrated as a service and the last one is only analytics.
A project key is a string that uniquely identifies your application within Analytics. It takes form of a GUID, i.e. a 32-character long hexadecimal string.
Historically the project key has also been called the product id or product key.
The monitor is the platform-specific component you need to add to your application in order for it to report statistics to the Analytics servers.
A session consists of all the analytics data gathered for your application when invoked once. Data is comprised of automatically gathered data (like total runtime and environment data) and custom-specific data (tracked features, exceptions, etc).
Historically a session has also been called a usage.
A session is a core concept of Analytics. One primary measure about your product is the number of times users have run it, i.e. the number of sessions. If a user runs (i.e. opens and closes) your application twice daily from Monday-Friday then that will be recognized as 10 sessions. For instance, for this product the recorded sessions tells us that users have run it about 5000 times each month between 2010 and 2013:
A great deal of information about the user's environment is gathered automatically at the start and end of each session and associated with the session, including location, OS, app version, total run time, etc:
Technically, having your application calling monitor
Start indicates the start of a new session and monitor
Stop marks the end of that session. Everything tracked between
Stop will be associated with this specific session.
There is nothing preventing your application from calling
Stop100 multiple times but it is highly recommended to call
Stopjust once at app startup and shutdown so the reported number actually match the lifetime of your application.
The concept of a session also plays a vital role in Data Studies, where filters can work on all tracked data reported for individual sessions. For instance, using the Data Studies you can say: "show me all the sessions that has reported feature "Menu.Help", originate from France, and are from Windows 7".