This article will describe how you can distinguish actual end-user sessions from around the world from internal sessions from e.g. your R&D and QA department.
Once you start tracking features from your application you will likely run into the situation where the data being tracked by e.g. your development or QA teams interfere with the actual data tracked from your end users, skewing the end results.
Why? Here is why:
Those concerned with analyzing the Analytics data (product managers, sales, strategists, etc) are really only interested in seeing pure data from real users around the world using the actual released application.
But those developing the application are usually just as interested, if not more so, in seeing data coming from themselves or from elsewhere in the organization, too.
For instance, say you are tracking clicks on
About. Now, in your QA department they run an automated UI-test that also clicks
About. Over time the QA test may "click" the menu item 10 x more than all your real end-users combined, making the recorded statistics severely "polluted" and not trustworthy to base any judgement on for business analysts.
Surely you don't want that. You want analysts to see real user-data. And you want developers to see their R&D/QA data. Fortunately, Analytics has a way to address this problem.
All received data is tagged with a specific Origin: data coming from your real end-users is marked as public sessions, while data originating from development and internal use is marked as internal sessions. You can then use this Origin as part of your filtering when browsing data, which allows you to view only public, internal or all data as outlined below:
This article will describe how
- how you can mark data to be recognized as either public or internal
- how you can view the public, internal, or all session data
By default incoming data is regarded as public data, i.e. coming from real end users. Session data can be marked as internal in three ways:
- For all data received from specific IP addresses
- For all data received from specific versions of the application
- In an individual application by setting the monitor's TestMode flag to true
This is illustrated below. The figure shows a number of installed applications as little red/green boxes. With the TestMode-flag and product filter settings below, data from the red installations will be marked internal while data from the green installations will be marked public:
Below we will explain how to setup this.
The IP and Version filters
The Product Filter can specify a list of IP addresses or specific versions of your software. When the incoming data matches this filter the data is marked as internal data.
This allows you to mark application usage data from your own company (coming from your company's IP-range) or from specific deprecated versions as internal and thereby exclude their data from the normal view. The Product Filter is maintained in the product's Settings > Filters:
The TestMode flag
You may not be able to determine if data is internal from just the version of the application or even from the IP address of the incoming data. For these scenarios, you will need to resort to a programmatic mechanism. Setting the
TestMode property of the
IAnalyticsMonitorSettings object to true allows you to explicitly declare that data from this monitor shall be marked with origin internal. Assigning this property will instruct the Analytics servers to mark the data as internal, regardless of any Product Filter configured.
This approach is useful for when an individual installation is special in some way (user is maybe a specific beta-tester), or if the IP/Version filter is not working in your setup but you are able to somehow determine from your code that data is internal, based on other information within your application.
The TestMode-flag shall be set before starting the monitor. Here are examples:
// C# for .NET, WinRT, Silverlight etc IAnalyticsMonitorSettings settings = AnalyticsMonitorFactory.CreateSettings("key"); settings.TestMode = true; IAnalyticsMonitor monitor = AnalyticsMonitorFactory.CreateMonitor(settings);
' VB.NET Dim settings As IAnalyticsMonitorSettings = AnalyticsMonitorFactory.CreateSettings("key") settings.TestMode = True Dim monitor As IAnalyticsMonitor = AnalyticsMonitorFactory.CreateMonitor(settings)
// C++ for Windows IAnalyticsMonitorSettings *settings = AnalyticsMonitorFactory::CreateSettings("key", "1.0"); settings->SetTestMode(true); IAnalyticsMonitor *monitor = AnalyticsMonitorFactory::CreateMonitorWithSettings(settings);
// C for Windows Eqatec_IAnalyticsMonitorSettings *settings = Eqatec_AnalyticsMonitorFactory_CreateSettings("key", "1.0"); Eqatec_AnalyticsMonitorSettings_SetTestMode(settings, 1); Eqatec_IAnalyticsMonitor *monitor = Eqatec_AnalyticsMonitorFactory_CreateMonitorWithSettings(settings);
// Objective-C for iOS and MacOSX EQATECAnalyticsMonitorSettings *settings = [EQATECAnalyticsMonitorSettings settingsWithProductId:@"key" version:@"1.0"]; [settings setTestMode:YES]; EQATECAnalyticsMonitor *monitor = [EQATECAnalyticsMonitor monitorWithSettings:settings];
// Java for Android and Java IAnalyticsMonitorSettings settings = AnalyticsMonitorFactory.createSettings("key", new Version("1.0")); settings.setTestMode(true); IAnalyticsMonitor monitor = AnalyticsMonitorFactory.createMonitor(settings);
In the Analytics client, the global filter can be changed to show you either only public, only internal, or all data:
The default setting is to show only public data.
Like the other global filters, changing the origin filter will affect all views that rely on the global filter: essentially every report except the developer reports of exceptions, sessions, etc.
This means that if you change the filter to show only internal data, then the data shown in World Map, Environment, Feature Use, etc will just be for internally reported data.
The default setting of "Public only" has a practical implication for developers:
If you are wondering why newly reported data is not showing up in the Analytics reports, please make sure that you are not sending in internal data and using a filter that will show you only public data.
Unfortunately, it's quite easy to forget about this global filter and wonder why your data is not showing up. You can read more about this in the section on Your First Data.
The origin can also be part of an advanced query. Like the global filter, an advanced query defaults to searching for public data only. Please see the section on filtering on Origin.
It is of practical importance to separate data from internal use from data from real end-users. In this article we have shown how to setup this distinction based on either IP Address or application Version, or for individual installations.