The IP address is collected, but it is only used to determine the software install location (i.e. country or state) to support geographical reports and is then deleted. Read More ... View more

At this time there is not a self-hosted option for Usage Intelligence. ... View more

By using the Reporting API, Usage Intelligence enables you to export a copy of your data for archiving purposes. The export must be carried out before you terminate your account, since after this point the data will no longer remain available. ... View more

Automatic ReachOut™ campaigns allow you to send in-app messages to your users while they are engaged with your application. On most platforms the Usage Intelligence SDK provides a default handler to display the message as a popup window with no additional code changes required in your application. The following is a list of supported platforms / SDK versions for displaying automatic ReachOut™ campaigns: SDK Version Windows  C/C++/.NET Mac C/C++/Obj-C Linux C/C++ Java V3 ✔ ✔ N/A N/A V4 ✔ ✖ ✖ N/A V5 ✔ ✔ ✱ ✱ ✔ Automatic ReachOut supported and includes default handler ✖ Automatic ReachOut not supported ✱ Automatic ReachOut supported but requires the application to specify a ReachOut handler. Further details can be found in the documentation: Linux: C/C++ Generic: Java More Information: When are automatic ReachOut™ campaigns delivered to my users? In-App Messaging and In-App Marketing using ReachOut™ ... View more

The Usage Intelligence SDK can check for automatic ReachOut™ campaigns when it calls home to the server. This can happen during an automatic or manual sync and in both cases you control whether it should check for available automatic ReachOut™ campaigns. Automatic Sync The Usage Intelligence SDK performs an automatic sync when  ruiStartSDK()  is called, and every 20 minutes after that while the application is running. If ReachOut on auto sync is enabled when creating the configuration through  ruiCreateConfig() , it will check for automatic ReachOut™ campaigns every time it performs an automatic sync. More information about creating config can be found in the documentation: Windows: C/C++ | .NET Mac: C/C++ | Objective-C Linux: C/C++ Generic: Java Manual Sync Your application can instruct the Usage Intelligence SDK to call home to the server by calling  ruiSync() . This function accepts a Boolean parameter to specify whether it should check for automatic ReachOut™ campaigns during the sync. More information on manual sync can be found in the documentation: Windows: C/C++ | .NET Mac: C/C++ | Objective-C Linux: C/C++ Generic: Java Note that the Usage Intelligence SDK never checks for automatic ReachOut™ campaigns when the sync is done as part of the  ruiStopSDK()  function. More Information: Automatic ReachOut™ Supported Platforms In-App Messaging and In-App Marketing using ReachOut™ ... View more

Whenever you run a tracked application, the tracking results should show up on the dashboard in real-time. Therefore if after running (and exiting) your application, that particular installations is not shown among the list of active users, then it probably means the data was not sent by the client to the server. By default, the Usage Intelligence SDK calls home to the server at least once per runtime session when calling  ruiStartSDK()  and then every 20 minutes of runtime after that. Typically another sync occurs when  ruiStopSDK()  is called just before the runtime session terminates. At this point the client will attempt to sync with the server and send any cached data for that session. Whenever an internet connection is not available or the server for some reason rejects the call from the client, the data remains cached on the client until the next sync. You may programmatically force a sync by calling  ruiSync() , however this is not necessary and also not recommended unless you need to cater for some specific usage scenario. Troubleshooting If you have followed the integration instructions and still cannot get data to show up in the reports, please go through this check list: Make sure you are using the correct callhome URL and product ID for that particular product. Every product has its own unique URL and the server will reject any calls from that product unless they match the designated URL. If you have changed the product ID or callhome URL at any point (such as if you previously tried tracking using a test account) then you must delete the Usage Intelligence log and config files before your client will be able to sync with the server. The files are located here. Confirm that the Usage Intelligence SDK has write access to the folder you have set when calling  ruiCreateConfig() . On calling  ruiStartSDK()  the Usage Intelligence SDK should create the following files:   ruiconfig.cfg ruilog.log  More info on using the  ruiCreateConfig()  function can be found here. Check whether the Usage Intelligence SDK has a valid internet connection to reach the server. Programmatically you can check whether the SDK has connectivity to the server by using the  ruiTestConnection()  API call. More info on using the  ruiTestConnection()  function can be found here. Please note that connection to the server may be blocked due to proxy authentication or gateway firewall. You may use  ruiSetProxy()  to cater for proxy server authentication. For more info please check out the related KBase article on How to use Usage Intelligence in proxy and firewall environments. If you go through the above check list and all seems in order, then please open a support ticket here and send the 2 config/log files created by the Usage Intelligence SDK, so that we can help to identify the problem. If your query is related to EVENT / FEATURE tracking data, then please check out this KBase article. ... View more

During your first stages of evaluating Software Usage Analytics solutions you might be wondering what are the advantages of using Usage Intelligence over a web analytics solution such as Google Analytics. Below we have outlined a number of points that you should keep in mind when comparing Usage Intelligence to Google Analytics or any other web analytics solutions. First of all, as their name implies, web analytics solutions were designed to track user engagement with your website and are not well suited to track desktop applications. The way users engage with a website or SaaS application running in a browser is very different than the way they engage with a desktop application. This means that you cannot simply use the same tracking metrics for websites and desktop applications alike. Google Analytics does a good job at tracking website browsing sessions, however a number of deficiencies arise when trying to adapt browsing session metrics to track desktop applications. Software Usage Analytics on the other hand was designed specifically for tracking how users engage with a Desktop Application so the metrics used can provide you with true actionable intelligence reports. Below we mention just a few of these differences: Always-on requirement: To track any event with web-analytics, you will have to make a web request. This means you will be adding a requirement that your software must always have a live internet connection. Usage Intelligence uses an intelligent caching system so that the logs are only sent at the appropriate time without interfering with user experience. Web Traffic: Every tracked feature, button click, program start, etc. will generate an individual web request which means your software will be constantly generating internet traffic, which in extreme cases can slow down your application. With Usage Intelligence everything is logged in memory and/or to file and logs are compressed before sent to the server. If a user goes offline, the logs are sent the next time a connection is available. This caching mechanism will cut down hundreds of web requests to an average of 2 calls every 20 minutes of application runtime. Protocol Security & Reliability: With web analytics, a single 'malicious' user can simply sniff the connection (e.g. using Wireshark) to copy your callhome URL and use this in a script to skew all your reporting data. The Usage Intelligence callhome protocol on the other hand implements various security checks to make it more difficult for a malicious user to use your callhome URL and skew data on the server. This includes encryption with a choice of using HTTPS or HTTP with AES-128 encrypted payload, fingerprinting, and every message sent to the server is hashed using SHA-256. Every product also has its own product ID which is checked by the server on every callhome and needs to correspond to the correct URL. Ability to Track Unique users and not single sessions: Web analytics solutions are designed to track individual browsing SESSIONS (usually through cookies) and NOT users/installations. Therefore you have no idea if a user launches your application 5 times a day or whether it was 5 separate users launching it once. This limits all reporting by session rather than by user. Usage Intelligence on the other hand tracks a user story from the day they install your application until they 'die'. This means by using Usage Intelligence you can benefit from detailed conversion funnel and sales cycle analysis reports so you know the amount of time users spent in evaluation before buying/dumping your software. This information is not available with web analytics solutions that rely on single session tracking. Usage Patterns over time: Using Google Analytics it is impossible to report on usage patterns for a particular user group over time because Google cannot identify a user from day1 to day2. Thus you cannot know if users are using your application 5 times a week or 5 times a month. You can only tell that a session belonged to either a new or a returning user. Real-time Filtering criteria: Usage Intelligence reports offer you the ability to drill down (using real-time filtering) so you can focus on a particular country,version, build number, edition, OS, license type, etc or any combination of those. Data is NOT pre-computed and presented as static numbers but we allow you to investigate any Product Management/Development question that may come up. This of course means you can check if any UI updates in a particular versions/build effects usage patterns for that feature and also tell between usage patterns of trial users or those who purchased a license. Google Analytics filtering on the other hand is designed for web applications so you can only effectively filter by country/language. Direct-to-Desktop messaging: Usage Intelligence's ReachOut™ direct-to-desktop messaging framework is a unique and very powerful marketing tool which can help you increase conversions and collect user feedback through ReachOut™ Surveys. It is like strapping a rocket to your conversion rate! Google Analytics for Desktop apps Please visit this blog post for a more detailed discussion on The Pros and Cons of Tracking Desktop Applications with Google Analytics. ... View more

New in Version 4 The following updates are available in the Revenera Usage Intelligence SDK version 4: Linux Support - New C/C++ SDK for Linux Support for Plugins - The Usage Intelligence SDK now supports running in a plugin environment, where multiple applications running as part of a plugin framework or multiple modules in the same application can all make use of the Usage Intelligence SDK independently Dynamic Classes - In order to be able to support plugin environments, the SDK now uses dynamic classes instead of singletons. This requires you to create an instance of the class instead of making use of static functions. Refer to the respective platforms below for more information Support for Shared File Path - Usage Intelligence data files now use a new naming convention based on the product ID to allow multiple products to share the same data path Deprecated Functions The following Usage Intelligence SDK functions will no longer be available as of version 4: Checking for Software Updates - version check will no longer be supported C/C++  tbVersionCheck() .NET  TBApp.VersionCheck() Objective-C  versionCheck() Privacy Mode - due to a number of new and more sophisticated reports a client can either be fully tracked or not tracked at all. Privacy can be handled in your application by not calling the Usage Intelligence functions if the user wants to opt out of data collection C/C++  tbSetPrivacyMode() .NET  TBConfig.SetPrivacyMode() Objective-C  setPrivacyMode()   Full API Documentation for SDK version 4 Documentation for version 4 can be found here. Windows   C/C++ Changes Added new function  tbCreateInstance()  which returns a pointer  (TBINSTANCE*) . This pointer is required as the first parameter for all functions Added new function  tbDestroyInstance()  to delete the instance created by  tbCreateInstance() The functions  tbMessageCheck() ,  tbMessageCheckWithMessageType() ,  tbKeyCheck()  and  tbKeyChanged()  now allocate the memory themselves instead of requiring a pointer to pre-allocated arrays Added new function  tbFree()  to free memory allocated by the Usage Intelligence SDK during message check and key check .NET Changes Added new dynamic class  TBClass  which needs to be instantiated, to replace the static classes  TbConfig  and  TbApp **Important Note** In version 4 it is now required to set the file path where the Usage Intelligence config and log files will be created. If you were not previously setting the file path in version 3, the current working directory would have been used. If this is not the same path you used in version 4, upgraded installations will be detected as a new installation. Please contact support to discuss the best way to avoid this according to your application. Supported Platforms The following Windows versions are supported: Windows XP through Windows 10 - 32 and 64 bit Windows 2008 Server through Windows 2012 R2 Server – 32 and 64 bit   Mac The Objective-C SDK has been completely re-designed and re-written. Refer to the online documentation for more information Removed dependency on NSURL to address an issue caused by App Transport Security, since when enabled it only allows HTTPS connections Supported Platforms The following Mac versions are supported: OS X 10.7 and greater - 64 bit only  Limitations No support for ReachOut™ Automatic HTML popup. ReachOut™ Plain Text Message and Plain Text URL can be retrieved using  checkMessageReturningMessage()  or  checkMessageForType() Linux  Supported Platforms The Linux SDK is supported on 32 and 64 bit and has been tested on the following distributions: CentOS 6.7 - 64 bit Debian 8.4 - 64 bit Debian 8.5 - 32 bit RedHat 5 and 6 - 64 bit Ubuntu 14.04 - 64 bit  Limitations No proxy support No support for ReachOut™ Automatic HTML popup. ReachOut™ Plain Text Message and Plain Text URL can be retrieved using  tbMessageCheck()  or  tbMessageCheckWithMessageType() ... View more

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 this KBase article. 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 NOTES 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. 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 this KBase article. Should you wish to discuss your specific use-case, please reach out to your account manager or to our support who can guide you on the best implementation method to meet your requirements. ... View more

The Usage Intelligence protocol implements various mechanisms to ensure that the configuration files have not been compromised. If the SDK detects that the configuration files have been tampered with, it will discard the files and negotiate with the server to create new files with the last known valid configuration for that user. You should never try to read or modify the data inside any of the Usage Intelligence log or config files whilst your application is running as this may cause the SDK to behave unpredictably and in extreme cases could lead to a crash. Thus you should always use the Usage Intelligence SDK for any calls or config changes. Should you have any special requirements please contact support to discuss your specific case. If you would like to learn more about what files are maintained by the Usage Intelligence SDK, you may check out this KBase article. ... View more

By default you can access all of the reporting data available within Usage Intelligence. This is not the raw data, but the data after it has been collected and processed. If you need to access your raw data, please contact us and our support team can work with you to meet your data needs. ... View more

Yes, in order to send a test campaign, first find your own client id from your config file. Then target only that client ID to preview it on your machine before sending out to a larger audience. ... View more

Usage Intelligence SDK implementation is extremely easy, and with about 10 lines of code and 30 minutes, you can get up and running tracking users of your software application. While that implementation doesn't capture every possible data point in your application here is what it does include: Product Metrics Version Edition Build Language Machine ID Client ID Installation Activity User Engagement Runtime Days Runtime Sessions Runtime Hours Churn Analysis Engagement and Churn Rates User Profiles User Activity OS & Platform OS Version OS Platform OS Language OS Architecture .NET Versions (if applicable) Hardware & Architecture Number of Monitors Screen Resolution Memory Graphics Card CPU Type CPU Cores Form Factor Virtual Machines Screen Pixels per Inch Touch Screen Java Environment (if applicable) Java Versions Java Vendor Java Runtime Version Java AWT Graphics Environment Java VM Version Java VM Name Java VM RAM Geographical Continent Country US State Client Profile Data Collection Properties Opt-Out Status Back-Off Status ReachOut Automatic Campaign Deliveries Most Usage Intelligence reports will visualize usage analytics in both time series and aggregated distributions, and are able to be filtered by the properties you collect. ... View more

Under normal circumstances, there is no need to change your Product ID or create a new account to track the same software product. If the reason is related to starting with a new clean account and getting rid of your old test data, you may follow the instructions in this KBase article to clean your statistics. Should you still need to update your Usage Intelligence integration to start tracking with a new product ID, then you must ensure that you delete all the old Usage Intelligence config and log files from your end-clients before deploying the new build. This will ensure that the new build will create its own config and log files related to the new product ID. If the files are not deleted from disk, then your end-clients will not be able to communicate with the Revulytics server since the encryption key-pairs will no longer be valid and thus will lose their ability to be tracked. ... View more

Once you create a free Usage Intelligence account, register your product and integrate the Usage Intelligence SDK, all your software installations will start calling home to the Usage Intelligence server. The server will collect anonymous information regarding software usage, OS, language, hardware profile such as memory, CPU type and resolution, geographical information, and other information regarding your software version, build number, edition, and license keys (if applicable). As a software vendor, you also have the option to control what information is collected from your end-users by adding an opt-out mechanism during installation or as a configuration option within your software. If a user chooses not to be tracked, then you can simply bypass the call(s) to the Usage Intelligence API. Communication Protocol The Usage Intelligence protocol uses a signing and authentication mechanism which protects all call home data from spoofing or other forms of tampering by rogue users whilst the clients are communicating with the Usage Intelligence servers. The Usage Intelligence SDK supports two types of communication protocols, HTTPS and HTTP with AES-128 encrypted payload. The protocol to be used can be specified when creating the SDK configuration. Here is a description for each option: HTTP with AES-128 encrypted payload: Connections to the server will be made using HTTP whilst securing the payload using AES-128 encryption. HTTPS only: The client will only attempt to connect to the server using HTTPS. If HTTPS traffic is blocked, callhome will not occur. HTTPS with fallback to HTTP with AES encryption: The client will first attempt to connect to the Usage Intelligence server using standard HTTPS. In cases where HTTPS traffic is blocked, the client will fall back to using HTTP with AES-128 encrypted data. This method is recommended since, in some environments, especially corporate networks, HTTPS traffic may be blocked by gateway firewalls or web filters. HTTP only (deprecated): In version 4 and older of the SDK, communication was made over HTTP without encryption except for license key info. Following the release of SDK version 5 on July 3, 2017, this method is no longer supported. NOTE: In order to improve your customers’ perception, you also have the option to use a custom callhome URL by setting a CNAME entry in your DNS server. For info on custom URLs please refer to this KBase article. Caching and Lack of Internet connectivity By default, the Usage Intelligence SDK calls home to the Usage Intelligence server as soon as your software is loaded, and then every 20 minutes after that while the application is still running. Other calls can occur whenever the developer calls an API which requires a real-time response from the server, such as during Message Check and License key validation. In the meantime, the Usage Intelligence SDK will cache usage statistics to a log file on disk, ready to be sent on the next callhome. For SDK's older than version 5, a single cache file is maintained with data from all sessions. For SDK version 5 and later, a cache file is created for every runtime session (determined by 'start-stop'). Whenever an internet connection is not available, usage data remains cached until the connection is restored. Note that before a client can track data offline, it must have done at least one successful sync with the Usage Intelligence server to register its existence and get a unique Client ID. A threshold is set on each cache file size so that a machine with a permanent loss of connectivity will stop collecting usage data for that session, once this file threshold is reached. Once the connection is restored, the log files are compressed and sent over to the Usage Intelligence server using minimal bandwidth.   ... View more