Although sometimes there may be valid reasons where you might consider tracking only a sample of your user base, keep in mind that this may not give you a real picture of your product usage trends and will limit your ability to use ReachOut in-app messaging with users that are not tracked. For this reason we always recommend to avoid this practice and track your entire user base.

However if for some reason, such as a limited budget, you need to track only a sub-set of your users, care should be taken to choose your sample diligently and ensure that you always track the same installations so that your metrics are reliable and you do not end up with gaps in usage data. If you simply allow the number of installations to exceed your monthly quota available with your subscription, you do not have a guarantee that the same users are tracked each month. As a result, the data will be skewed and your reports will be inaccurate. More information about the implications of running over quota can be found in What Happens If I Exceed My Usage Intelligence Account Quota?.

The following are some implementation options that you can consider when you need to track a sample of your users:

• Track a pre-selected group of users based on geography, product edition, marketing campaign or similar by providing a tracked build and a non-tracked build of your software to different user groups. This can be easier to implement, but statistics might still be skewed since the sample of users you’re tracking is very specific and you could potentially miss out on usage patterns from other user profiles.
• Randomize the sample across your entire user base. This is recommended since you will get a totally random sample across all user profiles and thus have a more statistically accurate view of reality. One of the easiest methods to achieve this is to implement the following logic which is executed the first time a user runs your application:
  

  if (random_number modulo 5 == 0)
    //Flag user as tracked
  else
    //Flag user as not tracked​

  This logic will statistically flag 1 in 5 users (20%) as tracked. The flag should be saved in a product config file and every time the application is launched the value is checked to decide whether to start the Usage Intelligence tracking or not. In this case once a user is flagged as tracked, they will always remain tracked until they stop using your product. On the other hand if a new installation does not make it inside the tracked pool, then you will not even know that installation exists.

• Track everyone by default and implement mechanism to turn off tracking at a later stage by using ReachOut. This is useful if you want to be able to switch off tracking for a specific user group in the future. By using ReachOut filter criteria you will be able to choose which installations to stop tracking after they have started getting tracked. For example you might want to turn off tracking for very old build numbers or stop tracking freeware users if they have not converted after 6 months. If using this method you will need to:
  
  
  • Check for manual ReachOut messages at the start of your application as described in the documentation:
    
    
    • Windows: C/C++ | .NET
    • Mac: C/C++ | Objective-C
    • Linux: C/C++
    • Generic: Java
  • Implement code in your application to process the ReachOut message and disable tracking accordingly
  • Create a manual ReachOut campaign with the appropriate filtering to be sent to the installations you want to permanently disable. This campaign can be enabled/disabled at any time from the dashboard.

  For more information on ReachOut visit this blog post: In-App Messaging and In-App Marketing Using ReachOut.

IMPORTANT: To make sure that you do not end up with skewed and/or missing gaps in data, whichever method you choose to implement must make sure that if an installation is not tracked it remains so for its lifetime.

IMPORTANT: If you choose to initially track all installations and then switch off tracking for specific user groups, it is recommended that you make use of a custom property to tag those installations as "switched off users". This will give you the ability to filter out such installations from reporting, otherwise you will see an inflated number of lost users which does not reflect the number of users which were truly lost. More information on custom properties can be found in What Type of Data Can I Store in Custom Properties?

Should you wish to discuss your specific use-case, please reach out to your account manager or to Revenera Support, who can guide you on the best implementation method to meet your requirements.