Build Your Own Analytics Platform: Advantages and Disadvantages of an Extensible-by-Plugins Architecture

Never before has data become so prevalent in everything we do. Sorting out the best way to make sense of incoming terabytes of data has turned into an extreme sport. Likewise, it has become a life-or-death decision in every organization, regardless of their level of maturity, to determine an analytics strategy to harness the potential power of all that data without running the risk of overwhelming teams and paralyzing processes. Yet, a perfect solution would be one that not only helps compartmentalize data effectively but also offers the flexibility of adapting to the data itself. You see, the nature and count of incoming data changes dramatically during every product lifecycle, and with it, the needs for product or user insights from different teams. Wouldn’t it be great to have a single tool that allows you to change how you process user and product data depending on the need of every moment, every lifecycle, or even every product?

Need-based Analytics Customization

While determining the best data analysis logic is not a task for the light-hearted, it is safe to say that determining the right analytics platform that fits an organization must, by all means, allow for a flexible framework that is easy to use and quickly customizable to accompany product changes.

This is particularly true for product and engineering people in organizations with digital products: the data they use to make decisions based on product performance can vary widely across languages, platforms, and overall tech stack. On top of that, it would be ideal if there is a level of overlap between the data they analyze and the insights used by non-technical users within the organization. For example, if engineers rely heavily on crash information but they have difficulty in making the insights derived from such events understandable to other teams, then there will surely be a productivity loss at some point.

Here’s where having a product analytics platform that works like building blocks comes as an advantage. For one, it allows customization of the interactions between the database and the API through SDKs applicable to each application, centralizing information coming from multiple environments. And, most importantly, it empowers turning on and off components of the platform at will depending on the need of the hour, without disrupting the overall data flow to other features.

Plug In and Dig In

The idea of simply activating certain elements of a product based on particular needs is a no-brainer. Basically, whenever you need a particular output, you activate the feature or functionality required and simply deactivate it when you are done. In product analytics, this works seamlessly as long as the features themselves are as self-contained as possible so that their deployment in different environments and integration into the product is the least disruptive to other processes.

However, as much as this setup seems like a perfect solution for every organization, there are different advantages and disadvantages to this approach.

‍

Advantages

Saves data usage: Getting to choose when and under which circumstances a functionality goes into operation reduces the chance of queries running in the background (or accidentally running them in plain sight) which are not strictly necessary. This way, if you have a data point-based product analytics vendor, you can ensure that your data point count and your vendor invoice will not take the hit. Not to mention, it will reduce the overall amount of data stored, also bringing database storage costs down.

Helps keep strategies in focus: Where there is too much incoming data, you very easily run the risk of losing control over what is truly important. Within the same product analytics platform, if a team member is working on metrics related to product performance, they don’t really need to be running queries regarding the revenue of individual user interactions. Similarly, the members of the marketing team perhaps don’t need to be validating the stack traces of each crash. When you use plug-and-play features, you get to choose what is useful for who and when so everybody is working with the information they need without getting distracted by the rest.

Takes part in product life cycles: Say that you got an all-in-one product analytics solution, with many available features that you would want to use, but the kind of user behavior data sent from your application won’t be enough. This way, if you know that working with a particular feature will greatly improve your future product decisions, you can incorporate the implementation of such a feature as you prepare for your next product sprint.

Simplifies the vendor choice: Choosing a product analytics vendor is also not an easy task in itself, so you must ensure that, as your product expands, your analytics needs will continue to be covered. Hence, it’s crucial to have plugin features that you can activate temporarily but then, once you see all the benefits of them, you might keep them running forever. On the opposite side, if you get a product analytics vendor that does not offer this flexibility, you might eventually reach a point where it starts limiting your own growth.

Speeds up changes: In almost all cases, plugin features can be switched on and off quickly, as there is no need to reach out to the vendor with requests. This gives your team full control over when exactly to activate a feature.

Disadvantages

Potential leadership clashes: When an organization acquires a tool, there is usually more than one person involved in the decision-making process, forcing a discussion, a negotiation, or even a compromise. When you have an extensible setup, deciding on using individual features will become more frequent as the data needs of your product grows. So, the leaders will need to ensure that the benefits of each new feature being activated is always clear and that everyone involved is on the same page.

‍Can be a difficult initial choice: When your team and your product are small, you will probably think that you don’t need an expansive list of features to run your product queries. And most likely, this is true, leading you to just settle for the output or insights you need in the moment, without getting distracted by other features that you don’t need. However, always keep in mind that, as your product develops further, you must ensure that the analytics solution you chose is easy to switch from as you opt to move to a more complex, elevated one.

Concluding Thoughts

Recently, we are seeing a higher degree of automation needs and of clients wanting to self-service their way through product analytics. This is why plugin features are so crucial to the future of digital products. However, it might not be the case for every organization, so if you need help deciding if an extensible solution is right for you, just reach out to us now.