Composable is at its heart a platform founded on extensibility. Users can extend our core DataFlow engine with custom modules for their use case, actions in Composable can be scripted via our Fluent API, and automated processes can be packaged up and shared for use across an enterprise. One of our most recent extensibility efforts has been the ability to host 100% custom web applications inside your Composable instance. These front-end interfaces can leverage existing Composable web services, custom DataFlow-backed service endpoints, and parameterized QueryViews with minimal code and configuration. This means web applications can be spun up without developing or setting up a backend server/middleware — your existing Composable resources are your microservices and API endpoints. On top of that, deploying as a Composable WebApp gives you user authentication and fine-grained role-based access control (RBAC) for free, built right into the Composable platform.
The next stage for Composable WebApps is offering application authors a detailed look at their audience and how they’re engaging with the interface, regardless of use case. Web analytics libraries are commonplace but often intrusive, so we’ve developed a minimalist usage analytics platform for Composable-hosted web apps. In a few months, a web app developer will be able to import a single JavaScript file into their HTML and instantly start receiving audience information for a few key categories of events:
- Who is opening the WebApp?
- What pages are users viewing?
- What features are users interacting with?
At the outset, we’re not looking to provide aggressive behavior tracking or flood product owners with information, but we are taking an important first step towards getting key usage metrics into admins’ hands with minimal setup required. When these analytics tools launch, we’ll collect some basic user information whenever a user opens a web app, views a page inside of the app, or clicks on any important element in the app.
With any interaction, we’re collecting the following metrics, which we think strike a balance between informing app development and protecting user privacy:
- Current URL
- Browser and User Agent
- OS Version
- Browser Window Size
- IP Address (local IP if on a corporate intranet)
- User Language
- Referer (where did the user come from to arrive at the application)
- Page Name (within the app)
When an application owner wants to track user interactions with a particular feature, they can do so by adding a small HTML attribute to the element in question. A link which performs an action that you’d like to track would simply go from looking like this:
1 2 3 |
<a ng-click="ctrl.openInNewWindow()"> Open in New Window </a> |
To the following, with our simple log attribute. Just give the interaction a unique name, which can be shared across multiple elements that engage with the same feature you’d like tracked.
1 2 3 |
<a ng-click="ctrl.openInNewWindow()" log="OpenNewWindow"> Open in New Window </a> |
Now, whenever a user clicks on this link, we’ll capture the name of the interaction (“OpenNewWindow”) along with details about the specific element that was clicked and the coordinates of the click event in the browser window.
We’re still building out our solution for consuming and analyzing these usage metrics, but you can see a prototype dashboard below. We’re excited to roll this out for all users and keep you up to date on new features to come.
