Public and Internal Origin

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.

What is the problem?

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 Help > About. Now, in your QA department they run an automated UI-test that also clicks Help > 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, Telerik Analytics has a way to address this problem.

Distinguishing between Public and Internal data

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:

The data Origin indicate whether data is public or internal

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

Marking sessions as internal

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:

  1. For all data received from specific IP addresses
  2. For all data received from specific versions of the application
  3. 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:

The 3 ways of marking data as internal origin

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 Product Filter decides what data should be marked internal

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 Telerik 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)
    // Javascript for AppBuilder
    var settings = global.plugins.EqatecAnalytics.Factory.CreateSettings("key", "1.0");
    settings.TestMode = true;
    var monitor = global.plugins.EqatecAnalytics.Factory.CreateMonitor(settings);
    // Javascript for web apps
    var settings = window.eqatecUtil.createSettings("key", "1.0");
    settings.TestMode = true;
    var monitor = window.eqatecUtil.CreateMonitor(settings);
    // C++ for Windows
    IAnalyticsMonitorSettings *settings = AnalyticsMonitorFactory::CreateSettings("key", "1.0");
    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 =
    // 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"));
    IAnalyticsMonitor monitor = AnalyticsMonitorFactory.createMonitor(settings);

Showing Public/Internal data in the Analytics Client

In the Analytics client, the global filter can be changed to show you either only public, only internal, or all data:

The Product Filter decides what data should be marked internal

The default setting is to show only public data.

All views are affected

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.

A note for Developers

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.

Using origin in Advanced Query

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.

See Also

Start a free trial Request a demo
Contact us: +1-888-365-2779
Copyright © 2016-2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.