Operational analytics can be a very powerful tool for understanding how end users are interacting with your services. Rather than relying solely on direct user feedback, you can control what data you receive, such as how frequently and in what fashion each component of the app gets used. Armed with such information, you can continually modify your app's architecture to approach optimal efficiency and usability.

 

Worklight's Operational Analytics component facilitates the gathering of analytics data, storing it on a dedicated server, and providing visual representations of the data in the Analytics Console. However, the displays in the Analytics Console are currently fixed, and cannot be modified or added to by developers. The purpose of this article is to demonstrate how to record and visualize your custom analytics.

 

The Getting Started module Operational Analytics lists the default data that are gathered by the Worklight Analytics platform; the data include application activities (e.g. Worklight adapter calls), notification activities, client logs, and server logs. These data are automatically captured when certain API calls are made (such as the WL.Client and WL.Logger javascript APIs). For developers who want to record and analyze data specific to their apps, such information may be insufficient. The best option in this case would be to use the Worklight Analytics API to record data and Kibana in concert with the Worklight Analytics platform to visualize your data. I will demonstrate how to do so with a (very basic) sample app.

 

Let's create a UI for a banking app that has some clickable buttons: in this case, Checking Account, Savings Account, Investment Portfolio, and Loans.

 

Note: This demonstration is done with a Worklight native iOS app, but the same basic process applies to hybrid and native Android apps as well.

 

Supposing that we are developers at this hypothetical banking corporation, we want to make sure that our UI is as efficient and useful as possible. To help us determine a more optimal layout than our first iteration of the UI, we can keep track of the frequency with which each of our four service buttons is pressed. To record this event, we can make use of the WLAnalytics API.

 

Each button has an associated callback method that executes when the button is clicked. The WLAnalytics API is used for native iOS and Android, and the WL.Analytics API for JavaScript. Data are recorded using the "log" method.

 

Collected analytics data from the client are automatically sent to the server after a successful WLClient connect and a successful adapter call. If you are not explicitly calling the WLClient connect method and are not calling adapters, you will need to call the WLAnalytics send method.

 

More information on connecting to a Worklight server from a native app can be found in the Invoking adapter procedures Getting Started modules.

 

Now that we have captured the analytics data at the client side and sent it to the server, we need a way to visualize the data. The Analytics Console currently provides no displays for custom analytics data, so we will set up our own interface using Kibana, which can be downloaded here. The developerWorks blog post Using Kibana for Worklight Analytics describes the steps needed to incorporate Kibana in your Analytics Console. Just make sure to use the field of your log's metadata (i.e. "worklight_data.button_pressed").

 

Here is a sample pie chart in Kibana based on many button clicks in the sample app:

 

With this information, we may decide to remove the rarely used investment_portfolio button, or we may want to put the loans button above the savings account button since it is used more often.

 

Of course, this example barely touches the surface of the possibilities with custom analytics. With your own Worklight apps, there is a tremendous variety of data to be gathered and insights to be gleaned to improve the architecture of your services.

Tags:  worklight