Glassbeam for Glassbeam (Part 2) – Why, Who and for What!

Pramod Sridharamurthy

In my first blog in this series, I talked a little about the importance of log analytics in general and specifically I touched upon the types of logs and the frequency of our log data collection.  In this post, let’s go over the use cases of our teams in Glassbeam. The use cases our teams have are very similar to the use cases that we solve for our customers. 

Every team in Glassbeam has a different set of expectations on what Glassbeam Analytics should do for them. Here’s a skyscraper view of the expectations – team wise.

Our support and infrastructure monitoring team wants to:

  • Improve the monitoring of the Glassbeam applications on our hosted platform by proactively identifying system or product issues  such as high CPU usage, memory bloating, application errors and so on even before the users  experience them
  • Have the ability to zero in on a problem in the shortest time
  • Automate every known problem by setting up rules to identify and alert our support teams without the  need for a manual intervention or investigation about the root cause of an issue

Our Engineering team wants to:

  • Look at historical data related to errors being logged by various modules, time taken for processing through our pipeline, exceptions, performance issues and so on, identify trends and troubleshoot complex problems
  • Automatically receive alerts  as and when specific conditions occur on the platform, so that bugs that are difficult to reproduce can be analysed as it occurs.
  • Monitor hosting performance metrics, so that we can optimize our hosting costs and provide the best response time for our customers
  • Understand how our applications are in use and what  the response times for different APIs are
  • Understand the common user navigation flows to build end-to-end test cases as part of the regression testing processes

As a Product manager, I would like to:

  • Track top issues on the Glassbeam Analytics platform, so that I can rank them as high priority items to address in each sprint
  • Plot usage patterns by way of stacked bar charts, pie charts, bubble charts and so on to know the proportionate use of the product features at the customer sites and derive inferences on what I can do to improve usability, user experiences, and the cost of having reductant features
  • Address user adoption challenges by looking at historical feature usages, demographics, complexity, and so on that can help me run product adoption campaigns targeted at specific features or the entire application
  • Understand the typical navigation flow of the user and see if it matches how the product was designed. For example, how do users navigate once they land on our application? What’s the next link they click after the landing page? On which page of the application do users spend the most time and why? And many more such use cases
  • For every feature request from the field, understand the current usage of the product related to this new feature request and then use that information to set the right priority
  • Decide on EOL of features that are not valuable to customers, so that engineering resources can be better utilized. That is, instead of spending time on maintaining these features, engineering can focus on building more useful features

Our Sales team would like to:

  • Understand the features and its value in terms of the impact on the customer’s install base, cost saved, problems resolved  to upsell and cross sell
  • Monitor the knobs of licensing and help the customer plan for licenses proactively
  • Get a micro-level picture of issues that are impacting customers, in turn helping our sales teams with account relationship management
  • Know the top users of our platform and those who use our platform the least, so that appropriate steps can be taken to understand the gaps and improve adoption

In the next few posts, I will elaborate, using specific scenarios, where Glassbeam for Glassbeam is aiding in the data-driven decision making that we have internalized for each of our teams:   Technical Support, Engineering, Product Management and Sales.


Our customers use Glassbeam for one more use case, which currently is not applicable to our internal use case, though it is a possibility in the future.

Opportunity to create a new revenue stream 

Many of our existing customers (product manufactures) use data parsed in Glassbeam to create analytics that can be made available to their customers as part of their premium service offering. This provides an opportunity for our customers to create a new revenue stream based on log analytics. Examples of this include, medical device manufacturers offering asset utilization, operator utilization type of analytics to hospital chains or storage/networking device manufacturers creating health check analysis to their enterprise customers.