A startup should invest in data collection and analytics early on, with your product ideally having data collection capabilities as soon as the first public release in order to help you understand your audience and take important business decisions reliably. Having such data means you will be able to direct resources where it matters, from which features your development team should focus on, to how you should market your product for optimum results. Without it, your decision making will be mostly based on gut feelings and other external data such as download statistics which do not reflect the true picture on how your product is performing.  Usage Intelligence makes it easy for startups to collect product usage data without having to invest precious time on an in-house call home infrastructure and reporting platform. Integrating the Usage Intelligence SDK into your product will take no more than 30 minutes, and this will immediately give you access to several reports out-of-the-box including: Runtime Intelligence: Activity overview of how much time your users actually spent interacting with your product in terms of active days, number of sessions and runtime hours. Churn Analysis: Reports based on the lifetime of lost and active users to help you identify how users engaged with your product before churning away Distribution Reports: View the geographical location of your users, what versions/editions/builds they are running, the type of license and its status, as well as how these distributions are changing over time. Architecture Reports: Get data on the devices that your product is installed on, including CPU, memory, operating system architecture and language, display resolution, device type etc. Feature Usage and Event Tracking: Get detailed information on what features are popular with your user base and how users interact with various functionalities in your application at each stage in their lifecycle. Apart from this, Usage Intelligence offers further capabilities such as license key management and in-app messaging, marketing and user feedback collection through its ReachOut™ in-app messaging service. This means that once time passes and you start to understand what it is that you would like to know more about, it will be a painless transition to go from collecting the bare essentials to more advanced analytics. See How to Price Software Licensing for further reading on how much effort startups should invest into data analytics and how to strike a balance in your data collection. ... View more

Custom properties are available with all paid plans. To confirm the cost of increasing the number of custom properties to your account, contact Revenera Sales. More information on the type of data that can be stored in custom properties can be found in What Type of Data Can I Store in Custom Properties?. ... View more

The Usage Intelligence SDK version 5 was released on July 3, 2017. This release contains various enhancements and new functionality. If you are planning to upgrade to SDK V5, please note that API calls have changed and this is not a simple drop in replacement. This article is intended to give developers an overview of the changes. For full details please review the SDK V5 documentation on the Usage Intelligence SDK Download Links and API Documentation page. Upgrading From Version 3 to Version 4 and 5 Change from singleton to dynamic classes. This requires you to create an instance of the class instead of making use of static functions. To create and destroy an instance: V4 -  tbCreateInstance()  and  tbDestroyInstance() V5 -  ruiCreateInstance()  and  ruiDestroyInstance() Setting the path where the Usage Intelligence SDK files will be saved is compulsory. In V4 this is set by calling  tbSetFilePath()  and in V5 set by  ruiCreateConfig(). Key check/change and message check always allocate memory,  tbFree()  in V4 and  ruiFree()  in V5 must be called on the message or license array to free memory. The following functions have been deprecated: tbVersionCheck() tbSetPrivacyMode() Upgrading From Version 3 and 4 to Version 5 The naming convention has changed from tb to rui prefix for all SDK functions, e.g.  tbCreateConfig()  is now  ruiCreateConfig() . This change was done to reflect the new company branding that was changed from Trackerbird to Revulytics in 2016. ruiCreateInstance()  accepts a boolean parameter to specify if the default ReachOut™ handler should be registered. If set to true, the SDK will handle the display of the window when an automatic ReachOut™ is delivered. If set to false, you will need to use  ruiSetReachOutHandler()  to specify custom functions which will be called to display and close ReachOut™ windows. The default ReachOut™ handler is available for the Windows and Mac SDK. For Linux, a custom handler must be set to display automatic ReachOut™ messages. Refer to the documentation for more information on  ruiSetReachOutHander() : Windows: C/C++ | .NET Mac: C/C++ | Objective-C Linux: C/C++ V5 does not save product and licensing info in the config file anymore and it is recommended to set all known info before every start. This includes product edition, language, version, build, custom properties, and license key type and flags (activated, expired, blacklisted, whitelisted) when licensing is client managed. If these settings are only set once and the SDK is not able to callhome during that application runtime, the settings will be lost. tbSetFilePath()  and  tbCreateConfig()  have been consolidated to  ruiCreateConfig() , which now accepts the file path as the first parameter. ruiCreateConfig()  parameters have changed, the following are now required: configFilePath – The path where the Usage Intelligence files will be saved, in previous versions this used to be set by  tbSetFilePath() productID – The ID of your product, retrieved from the Usage Intelligence Dashboard > Administration page appName – A name for the application, it cannot contain spaces. If multiple applications in the same product suite are tracked under the same product ID they should have different app names serverURL – The callhome URL for your product, retrieved from the Usage Intelligence Dashboard > Administration page protocol – The protocol used when communicating with the server: 1 - HTTP with AES-128 encrypted payload 2 - HTTPS with fall back to HTTP with AES-128 encrypted payload 3 - HTTPS only (with no fallback) aesKeyHex – AES key retrieved from the Usage Intelligence Dashboard > Administration page to be used for HTTP with AES-128 encryption communication. Must be empty if HTTPS only is used multiSessionEnabled – true/false whether sessions are managed by the application reachOutOnAutoSync – true/false whether the SDK should check for available automatic ReachOut™ campaigns when it automatically syncs with the server Setting product version and build is no longer done when creating config. To set product details in V5: ruiSetProductData()  accepts parameters for product edition, language, version and build Functions to set individual product details still remain,  ruiSetProductEdition() ,  ruiSetProductVersion()  etc.. tbStartAutoSync()  and  tbStopAutoSync()  are no longer available. The SDK now automatically syncs with the server every 20 minutes by default. This setting cannot be changed or switched off. Function names to set license properties and check / track license changes have changed: tbSetLicense()  is now  ruiSetLicenseData() tbKeyCheck()  is now  ruiCheckLicenseKey() tbKeyChanged()  is now  ruiSetLicenseKey() ruiSetLicenseData()  now accepts a session ID parameter, which can be specified when running in multi session mode or left empty. The order of the license array values when using  ruiCheckLicenseKey()  and  ruiSetLicenseKey()  has changed. The new order is: RUI_LICENSE_ARRAY_INDEX_KEY_TYPE (0) RUI_LICENSE_ARRAY_INDEX_KEY_EXPIRED (1) RUI_LICENSE_ARRAY_INDEX_KEY_ACTIVE (2) RUI_LICENSE_ARRAY_INDEX_KEY_BLACKLISTED (3) RUI_LICENSE_ARRAY_INDEX_KEY_WHITELISTED (4) Function names to check for manual ReachOut™ messages have changed: tbMessageCheck()  is now  ruiCheckForReachOut() tbMessageCheckWithMessageType()  is now  ruiCheckForReachOutOfType() In V5 there are different ways to track events with custom data: Same functionality of  tbEventTrackTxt()  is available in  ruiTrackEventText() New function  ruiTrackEventCustom()  accepts an array of key/value pairs and will be saved in the format (Key1, Value1)&&(Key2,Value2). Refer to the documentation for more info: Windows: C/C++ | .NET Mac: C/C++ | Objective-C Linux: C/C++ ruiTrackException()  accepts a struct with exception details instead of individual parameters. Refer to the documentation for more info: Windows: C/C++ | .NET Mac: C/C++ | Objective-C Linux: C/C++ The Mac and Linux SDK now support setting proxy settings through  ruiSetProxy() . This functionality was previously only available for Windows. Function return values have changed: “OK” value has been changed from 1 in V3 and V4 to 0 in V5, i.e. TB_OK (1) is now RUI_OK (0) In general, a negative return value now means an error occurred, while positive values are info Check respective function documentation for new return values If you require further technical assistance during the upgrade/migration process, contact Revenera Support. ... View more

Yes, Usage Intelligence provides you with the option to create a CNAME record in your own DNS server and point it to your personal call home URL provided by Usage Intelligence. However, there are a number of points you must follow for this to work. For every product that you register with Usage Intelligence, we supply you with a call home URL for that specific product. Each URL is unique to a single product and the server will not accept any call home data to that URL unless it is originating from the product associated with it. You can get this Call Home URL by logging on to the Usage Intelligence Dashboard and doing the following: Usage Intelligence v2.0: Open the Admin page and look in the Developer Zone section. Usage Intelligence v3.0: On the Administration menu, select Developer Zone. The URL is usually in the form:  '123456.tbnet1.com' Now let's say your domain is  mycompany.com  and you choose to create the following CNAME DNS entry: check4updates.mycompany.com  pointing to:  123456.tbnet1.com Once the CNAME is set up in your DNS server, please allow 48 hours for DNS replication and then contact Revenera Support to request an update to your call home URL. From this point onward, all new and existing end-user installations will be automatically updated to start calling home to your new URL:  check4updates.mycompany.com NOTE: Custom URLs are limited to 64 characters. NOTE: This is an optional paid feature available on all paid account plans. NOTE: The callhome URL should not be changed in the Usage Intelligence SDK before the necessary updates are made from the server side. If clients try to callhome using the custom URL before it is configured on the server the sync will fail. What If I Want To Use HTTPS? When you have a custom call home URL configured, we will use a certificate from Let’s Encrypt (https://letsencrypt.org) to enable the SDK to call home via HTTPS. This requires no further setup from your end. Let’s Encrypt is an automated and open certificate authority managed by the Internet Security Research Group (https://www.abetterinternet.org). Its board of directors includes representatives from Cisco, Mozilla, EFF, RedHat, Facebook, Akami, etc. and the project is sponsored by a number of major internet companies such as Google, Shopify, Verizon, Zendesk, etc. If you prefer to use your own domain SSL certificate, contact Revenera Support to discuss your requirements. Why Should I Use a Custom Call Home URL? There are a number of advantages of using your own call home URL such as check4updates.mycompany.com . The most evident advantage is that users who check on their web gateway logs or sniff their network traffic, will see your software calling home to your own domain, rather than an unknown domain belonging to Usage Intelligence. This could improve customers' perception and make them more comfortable in allowing that traffic through their web filters as they can immediately associate that HTTP(S) traffic to a known software provider - in this case your company. Another advantage of your software calling home to a custom URL on your own domain is that it will increase your credibility since it would seem as if you are running your own call home server infrastructure just like larger well-established enterprises. ... View more

The Usage Intelligence SDK does NOT require administrator privileges on the machine. However, if you want to avoid any issues with Windows UAC, please follow the recommendation below. Every time your application is run, the Usage Intelligence SDK accesses/maintains 2 files on disk (i.e. ruiconfig.cfg and ruiconfig.log). More information about these files can be found in What Files are Created by the Usage Intelligence SDK and What is the Folder Location?. If you are using Usage Intelligence with Microsoft Windows Vista or higher and your application runs from the Program Files directory, you should make sure to set the file path to a location where your application has write permissions when calling ruiCreateConfig(). This is because on some machine configurations if the user does not have administrator privileges, your application will be denied access to the Program Files directory. ... View more

When your software is first run, the Usage Intelligence SDK creates the following files on disk: ruiconfig*.cfg ruilog*.log NOTE: The SDK may create multiple ruilog*.log files at any given time. Every time your application is run, the SDK will attempt to search for these files which are used to store config data as well as tracking/usage logs. If the files are not found in the specified location, the SDK will recreate these files, generate the client fingerprint again and registers itself with the server. The location of the folder where the files are created is set through the ruiCreateConfig() function in the Usage Intelligence SDK. You must make sure that your application has write permissions to the folder you specify. Ideally you set this path to the same location where your application stores data/config/settings. Keep in mind that on some machine configurations (especially Microsoft Windows Vista or higher with UAC enabled), if the user does not have administrator privileges, your application will be denied access to the ‘Program Files’ directory. Therefore you want to avoid using the default path if your application runs from the Program Files directory. If your application supports multiple user profiles and you want to track statistics from each user separately, then when calling the ruiCreateConfig() method you need to specify a unique folder for every user. This can either be a folder within the user's Windows profile or else a manual folder created inside your application data directory where the folder name would include a unique username/ID/hash identifying that user. Using independent folders for every user would allow Usage Intelligence to generate a unique fingerprint for every user and therefore track them as independent installations. CAUTION: The configuration and log files are unique for every installation and should not be copied between installations and users, both on the same or different computers. Doing so will cause the client fingerprint verification to fail and the server will not track usage statistics for that client. You should always allow the Usage Intelligence API to create the config and log files for new installations. CAUTION: The content of the log and config files should only be used by the Usage Intelligence SDK. Your application should not modify or otherwise rely on the content of these files. Flexera reserves the rights to change the structure and content of the files without notice. Related Articles Dealing With UAC and File-Access Permissions for Non-Administrators Accounts How Does Usage Intelligence Identify Unique Users/Installations? ... View more

It is normal that during evaluation/testing you might collect test data (such as build numbers, event names, etc) which you would like to clean up before deploying your software live. This will allow you to start with a clean, empty dashboard when you start tracking your first live users. For this reason, Usage Intelligence offers premium users the option to manually delete your old/test data. To send in this request, please open a support ticket and include: Your Product ID If your product has custom properties enabled, which of the custom properties you'd like to keep  Requests are normally handled within 1 business day, but please allow up to 48 hours for our admins to process your request. What You Should Do After a Cleanup Operation When a full purge operation is requested, you must DELETE all Usage Intelligence config and log files BEFORE running your application again. Before you do this, your client installations will no longer be able to communicate with the server. The reason is that during the purge operation all data related to your existing installations, including client IDs and encryption keys, are deleted from our servers, so all clients must register themselves again before any data can be collected. The files that you need to delete and their location is documented in What Files Are Created by the Usage Intelligence SDK and What Is the Folder Location? The files will be recreated automatically by the Usage Intelligence SDK on the first time you run your application. NOTE: This option is only available for paid accounts. Therefore, before sending us your request you must ensure that your account has been upgraded to one of our premium plans. NOTE: We can only accept such requests from users who are registered as account administrators. If you have been invited to use a product account for which you have not been given administrative rights, then you must ask your administrator to send the cleanup request. Caution Once this request has been processed, all tracking data is PERMANENTLY deleted from your database and is unrecoverable. Therefore make sure you get approval from all parties managing your account. This operation is only intended to be used for cleaning up any test data BEFORE you deploy your product live. If you have already deployed your product and have a number of end-users being tracked by Usage Intelligence, this cleanup procedure will result in those users to permanently lose the ability to be tracked. The only way to start tracking them again would be to delete all the config and log files used by the Usage Intelligence SDK on the client machines. At that point, the Usage Intelligence server will start to see them as new installations. ... View more

Custom events and Exception Tracking are billed by the amount of data uploaded from your clients. Custom events are counted and reported just like normal event tracking, however you also get the added benefit of collecting custom data whenever an event occurs. The list of raw events together with all data collected is made available as a downloadable CSV archive on a daily/monthly basis. Custom data can contain any string length of your choice so you can collect multiple values delimited by a '|' (pipe) character for example. Each tracked custom event contains: Meta data collected automatically by the Revenera Usage Intelligence SDK. Such meta data includes the full user profile such as product version, build number, OS, language, license type, geo location, hardware architecture, etc) The custom string data that was collected with the event. Every event usually consumes around 500 bytes of meta data plus the size of your custom string data or stack trace in the case of exception tracking. Note that quota is counted in 1KB intervals. So just as an example let's say you have 1000 installations using your software every day and each installation generates 2 custom events/exceptions per day. For each event/exception you are collecting 500 bytes of meta data plus 400 bytes of custom or stack trace data. This case scenario would generate: 30 days x 1000 installs x 2 exceptions x 1KB = 60,000KB = 59MB of data per month Contact Revenera Support for a quote or more details on using custom events and exceptions. ... View more

Custom Events are collected via the  ruiTrackEventText() ,  ruiTrackEventCustom()  and optionally the  ruiTrackEventNumeric() * API calls. When collecting these events, they will be included with the statistics associated with event tracking reports. Additionally you will have the ability to download the custom events in CSV format on a daily and monthly basis, which will include the meta data related to each event as well as the custom data logged with the event. When logging custom text the data field can contain any string length of your choice so you can collect multiple values delimited by a '|' (pipe) character for example. Each tracked custom event contains: Meta data collected automatically by the Usage Intelligence SDK. Such meta data includes the full user profile such as product version, build number, OS, language, license type, geo location, hardware architecture, etc) The unique Usage Intelligence Client ID that generated that event. The custom string or numeric data that was collected with the event. Custom events are designed for download and use for offline processing or automated parsing, as well as for integrating with third party BI solutions. For more information on Custom Event tracking, see Collecting Custom Data with Event Tracking. Custom Events are billed by the amount of data collected. For more info on how this billing works, see What Is the Cost of Custom Events and Exceptions and How Is Usage Billed? NOTE: Numeric events are not collected as custom events by default. Should you wish to enable numeric event data to be included with your product's custom data, contact Revenera Support. ... View more

Revenera respects end-user privacy and encourages software vendors to do the same. All data collected by Revenera is anonymous and we do not store any IP addresses on our servers. Users are identified only through the use of a unique client/installation ID generated automatically by the Usage Intelligence SDK during the first program execution. Revenera does not collect any personally identifiable information from end-users. The type of data collected by Revenera can be controlled by the software vendor/developer and is limited to: Platform/architecture data where your product is running such as OS, language, CPU, memory, resolution, etc. Product and feature usage data such as when your product was run, and which features were used. Other information related to your product version/edition/build number and license key. Collecting Data Using Custom Properties or Custom Events If you are making use of Usage Intelligence's advanced features to collect custom data, then you have the ability to collect custom strings of your choice. Revenera has no control on what this data might contain so it is your responsibility on what type of data you collect via this functionality. It is also recommended that you ask permission from your users before collecting any data that might not be totally anonymous. GDPR Compliance If you would like to learn more about how Revenera is GDPR compliant and how you can fulfill your GDPR obligations when using the usage intelligence platform, see How Do I Remain GDPR Compliant When Using Usage Intelligence? User Awareness We always recommend that you include an entry in your product EULA to state that you will be collecting anonymous data which you will use legitimately. It is also your legal responsibility as a software developer to inform your users about any data that is being collected from their machines, both through Revenera or otherwise. Whether or not you want to provide a means for your users to turn on/off tracking is your business decision and dependent on the agreement you have with your customers. Sample EULA Wording Revenera does not provide the legal wording to use within your EULA, since this usually depends on the type of contract/agreement you have with your customers and the legislation of the country where you are established. However common EULA wording would be something along these lines: "We are continually seeking to develop and enhance the products and services we offer to our customers. To facilitate this process it is helpful for us to collect information related to how customers use our software. By installing and using our products, you are agreeing to participate in our CEIP (Customer Experience Improvement Program) whereby you are granting us permission to collect, maintain, process and use analytics data related to your use of our Software. All the data we collect is anonymous and we do not store any IP addresses or personally identifiable information. For the purpose of the CEIP, we may rely on third party analytics services to collect and process this data and such data is stored and processed on servers located in EU and USA. Should you wish to not participate in our CEIP, please contact support for instructions on how to disable tracking within the software." NOTE: The above text is only intended as a guide and should be reviewed by a legal representative before using it in any legal documentation. Providing Users With Opt-In or Opt-Out Options Should you need to cater for end-users who are sensitive on gathering ANY form of data from their machines, we suggest that you add an opt-out mechanism during installation/configuration or as a setting within your software. If a user chooses not to be tracked, then you can simply bypass the call(s) to the Usage Intelligence API. More information on how to stay compliant with privacy laws in your region can be found in How to Stay Compliant with Privacy Laws When Collecting Data with Usage Intelligence. ... View more

The Usage Intelligence platform is used by software vendors to collect software usage data from the end users of their software products. From the perspective of the GDPR, our customer, the software vendor, is the data controller and Revenera is the data processor in terms of data collection and hosting the reporting portal. By default, Usage Intelligence does not collect personally identifiable data. Although the IP address is collected, it is only used to determine the software install location (i.e. country or state) to support geographical reports and is then deleted. The software vendor may extend the default data being collected by Revenera, but they have full control of what is collected and how this data is used. Right to Data Erasure The GDPR requires that a data subject has the "right to erasure". This right may be applicable to data collected using the Revenera technology if the software vendor, the data controller, has extended the Usage Intelligence configuration to collect personal data. In this scenario, an end user (or data subject) may contact the software vendor to request a copy of all data or request that the data be deleted. If a request is made and the custom data being stored on the Usage Intelligence platform contains personally identifiable data, then the software vendor can comply by sending a request to Revenera that data be deleted on specific Client IDs. Procedure to Delete Client Data While data subjects must contact their software vendors, Revenera customers may delete client data by performing the following: To delete client data: Log in to Usage Intelligence Dashboard. Do one of the following: Usage Intelligence v2: Open the Admin page, and under Data Management, click on Delete and Block Clients. Usage Intelligence v3: On the Administration menu, select Delete or Block Clients. Enter the applicable Client ID(s) and select whether you would like to delete the data and allow the client to be tracked in the future or delete the data and block the client from being tracked. Click the Delete button to process your request. If you're collecting Custom Events or Exceptions, user data may also be present in the downloadable archives. In this case you will need to download the archives locally, remove the client's data from the CSV files and delete the original archives from the server.      User Privacy If you would like to learn more about how to protect user privacy when using the Usage Intelligence platform, see Are There Any Legal or Privacy Concerns When Using Usage Intelligence? ... View more

The Client ID by itself does not store any personally identifiable information. The ClientID is made up a one-way hash of the hardware fingerprint combined with software data path. The hash value itself is calculated on the client. In addition, when the ClientID is combined with the default data capture by the SDK the combination does not contain personally identifiable information. If the software vendor, the data controller, has extended the Usage Intelligence configuration to collect personal data and an end user (or data subject) contacts the software vendor to request a copy of all data or request that the data be deleted the software vendor can comply by sending a request to Revenera that data be deleted on specific Client IDs. For more information, see How Do I Remain GDPR Compliant When Using Usage Intelligence? ... View more

Answer Transcript We do have a question that came in: Was the opt-in pop-up triggered through a ReachOut campaign, or was that hard-coded in the example you just showed? Effectively with this particular case you will be collecting the data as a custom property so you want this to be hard-coded in your application. That way, as soon as your application loads you want to pop up that that request to the user. And then, when the user answers the question, you would save it as a custom property via the custom property API called. This is mainly a hard-coded version there are options by which you can be more elaborate and have a ReachOut-generated feedback pop-up, but for this particular case it's much easier much simpler to have a hard-coded version. ... View more

The Lifetime Event Usage Report can show you the proportion of users who have who have never used this particular feature before for any particular date range. Transcript Do you have a way to see a count of the number of unique users that use an individual feature? There's a couple different ways you can do that within the feature and event tracking and report here. So if we take a look at this lifetime event usage report basically, the way that this report works is for all users that were active over this date range here we're going to show you the proportion of users who have who have never used this particular feature before. So I can see here that for my reporting printout operation, you know about 3,300 users have used this feature before and 16 users have never used this feature before. Now if I just want to look at today's data basically what this is doing is it's getting all active users who are only active for today and now I can see again specifically out of those however many users were active today, how many have used this feature before how many have never used it before. And so if you want to look at your entire user base what you'd want to do is you'd want to extend this date range out to encompass basically your entire data set whether that's a year's worth of data or if you have been collecting data for a few months, you don't need to go for a few months. But that's one way to see the unique number of users who have or who have never used a feature before.   ... View more

If an application crashes, it never gets a chance to call the SDK to stop, therefore initially the session is not logged, however Usage Intelligence has a built in mechanism that can detect when a session has not reported back data to the server within a week, and at that point the session is marked as stopped for reporting purposes.  Transcript Well what happens if there's an application crash and so as a result I never get to call RUI stop does that session ever get logged? Did it ever stop? What what happens to the data and sort of what happens in that situation? We've actually designed the technology to compensate for this and actually we have an interesting mechanism in place to be able to track this. So basically if a crash occurs what's going to happen is the call to stop SDK will never get called therefore the current session actually doesn't terminate because that stop SDK call will never be made but the server has a safeguard in place to still collect this data and basically what happens is if no data from this session is collected for one week so we never see that session terminate for a period of one week the server will mark this session as a session timeout and then after one week when the user relaunches the product that remaining data from that time out session will be collected. We can actually show you what happens in the dashboard for that case if a session time out occurs. If we take a look at our user flow report again we tag that as an event when a session timeout occurs you can select this session timeout as a hotspot within the user flow report and at that point you'll be able to visualize the sequence of events that lead to this session timeout so this could actually be like a good benefit here because you'd be able to see under what instances am i seeing a session timeout get triggered. I can see here maybe this flow in particular is leading to or indicative of a crash within my product or is leading to some kind of unexpected behavior that's causing the session timeout to occur. So even in the case of an application crash there's still some data that we're going to collect in at later point that you'll actually be able to really visualize the dashboard to help to diagnose what might be causing that crash. ... View more