If you are developing a software application and have been exposed to Google Analytics, you might find yourself asking a very common question: “Why not use Google Analytics to Track my Desktop Application?” At first glance this might seem like a very attractive option, however if you had to look into the details you will realize there are a number of fundamental problems that you are likely to encounter. The way users engage with a website/browser is very different from the way they engage with a desktop application. This means by simply using the same tracking metrics for websites and desktop applications alike, you cannot effectively measure both. Google Analytics does a good job at tracking website browsing sessions, however a number of deficiencies arise when trying to adapt browsing session metrics directly to track desktop application runtime sessions. Such deficiencies can drastically limit your ability to report on application usage and in some cases also affect your client user experience. In this article we discuss some points you need to keep in mind when looking into such a tracking solution.
When should you use Google Analytics?
- Build your own tracking framework – assuming you have the expertise, development time/resources, and server infrastructure to handle big data.
- Use a third party solution such as Trackerbird Software Analytics
Below we have outlined a number of points that you should keep in mind when comparing Google Analytics with a specialized Desktop tracking solution such as Trackerbird.
How web analytics differ from desktop software analytics
Web analytics solutions (such as Google Analytics) were designed to track user engagement with your website. Essentially this means all metrics are based around browsing sessions where during a session, a visitor enters your website from one of your public pages, clicks around a few pages, possibly generating a few events along the way, until they convert or drop off your site. This gives you enough information to track the count of new vs returning visitors as well as their browsing path through those pages. However as far as Google Analytics is concerned, that is the end of the browsing session and if that user comes back, they will be tracked just like any other new/returning user, irrespective of who they are, how often they return and what happened during their previous visits. Therefore there is no concept of building a user profile to track how their usage patterns vary over their lifetime or throughout their evaluation lifecycle.
This also means that with Google Analytics you cannot generate any reports - such as conversion funnel analysis - that span over a number of days, since the longest conversion path must start and terminate in a single browsing session. This of course makes sense for website visitors, but it is not always applicable for desktop applications.
In order to track desktop software effectively, whatever solution you choose must keep track of each individual user’s story and not a single runtime session. This is an essential building block that will change your reporting abilities from simple generic statistical reports to truly actionable business intelligence reports.
Comparing Google Analytics with Trackerbird Software Analytics
Below we have listed some specific issues that you will need to cater for if you consider tracking your desktop application with Google Analytics. We also explain how Trackerbird manages to solve these issues so the developer does not have to worry about them.
Developer Hacks: Mapping software events to page views
Keep in mind that what you are doing with Google Analytics is a hack, so before you start you need to become familiar with the traditional web-based tracking system using ga.js. The Google Analytics collector is designed for websites (not applications), so it is up to the developer to determine what constitutes a change of page or clicking of a link inside the application to be able to pass that to Google Analytics. Therefore all the ‘events’ within your application will have to be manually mapped to page views and URLs in a way which can be reported on later.
- The Trackerbird API on the other hand was designed specifically for tracking user engagement with a Desktop Application, therefore it contains all the functions that you need to track runtime sessions starts, stops and other application events such as feature usage and exceptions. The API can be easily integrated in just 30 minutes without the need to worry about the inner workings.
Effect on User Experience
Always-on requirement: To track any event with Google 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 in order to be tracked.
Web traffic: When using Google Analytics, 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 or raise eyebrows of administrators who might be monitoring internet traffic passing through a corporate gateway.
- Trackerbird uses an intelligent caching system where everything is logged in memory and/or to file. The logs are compressed at the most appropriate time before being sent to the server without interfering with user experience. If a user goes offline, the logs are sent the next time a connection is available and no tracking data is lost. This intelligent caching mechanism will cut down hundreds of HTTP calls to a mere 2-3 calls per runtime session. The system also caters for users who are permanently offline so that log sizes are automatically kept under control.
Protocol Security and Reliability
With web analytics, a single malicious user can simply sniff the connection (using tools like Wireshark) to copy your callhome URL and use this in a script to skew all your reporting data, and unfortunately there is not much Google can do about this since you are simply tracking using anonymous web requests.
- The Trackerbird callhome protocol on the other hand implements various security checks including fingerprinting and RSA encryption to prevent replay attacks which make it much more difficult for a malicious users to simply use your callhome URL to skew data on the server.
read more on next page…
Pages: 1 2