Product teams are constantly grappling with how to improve user experience, engage users meaningfully, and attract new users. In context of these challenges, the value of embedded analytics is clear. According to the 2018 State of Embedded Analytics Report, application teams that embed analytics are able to differentiate their software from the competition, reduce customer churn, drive revenue, and improve customer satisfaction.
Given the benefits of embedding dashboards and reports, it’s no wonder the big question has shifted from “Should we embed analytics?” to “How can we embed analytics?”
The two most common options for embedding analytics are to build a solution on your own with the help of analytics component libraries, or buy a solution from an analytics vendor.
The first step for many application teams is to build exactly what they want using a few component libraries. The upfront cost of component libraries is low, sometimes even free, and they give developers a wide range of economic and creative freedom to build what they need.
Although analytics component libraries can be a good solution for organizations that have only simple requirements, it’s also incredibly risky. In the long run, component libraries are more difficult to maintain, update, modernize, and secure than analytics platforms.
Consider these 10 hidden costs of building analytics solutions with component libraries:
#1: Distraction from Core Application Development
Time spent embedding analytics is time taken away from working on core features and functionality. Choosing to build analytics solutions yourself takes significant time and you may end up replicating a solution that is already available in the market.
Unless developing analytics tools is a core competency of your engineering and product teams, you’ll end up spending valuable time building, deploying, maintaining, and scaling analytics capabilities over time. The real cost of building analytics solutions with components comes every time your team has to maintain, update, or upgrade something that’s not core to their skillsets. It can quickly drain your resources.
The Bottom Line: Building analytics solutions—even with the help of component libraries—takes precious time away from innovating on your core application.
#2: Longer Time to Deploy and Maintain
Building analytics capabilities will add a significant amount of time to your product lifecycle. Developers who build analytics spend a majority of their time gathering requirements, then mapping them with free business intelligence (BI) tools and open source components.
Each requirement means sourcing, evaluating, and testing at least a couple component options. And if the analytics tool you’ve developed doesn’t support a new feature that you need down the road, it’s back to the drawing board. This makes your product roadmap longer and delays time to market. Time you could be spending on your core application offering now needs to be spent rebuilding analytics for the next version of your application.
Ask these time-to-market questions when considering analytics components:
- Reusability: How much of what you build will be reusable when your application needs updating? For example, will you have to redo all the work in the component library if you upgrade the Angular UI from 3.0 to 5.0?
- Data Format: Does the component library consume the data in the same format you have available within your application? For example, if you have data in JSON format, check if the component library can consume JSON or not.
- Pagination: How does the component library handle pagination of longer datasets? Does pagination impact the usability of your application? What kind of load does it add to your application server and/or database server?
- Limitation: Does the component library place limits on how much data it can handle?
The Bottom Line: Unless an application team has only the simplest requirements, an analytics development platform is faster to build, deploy, maintain, enhance, and upgrade than building.
#3: Limited Sophistication in Analytics Capabilities
Product teams that use analytics component libraries tend to add mostly basic features. Very few components can support more sophisticated capabilities, which means adding new pieces may mean significant development work, ultimately slowing down your time to market for releases and future updates.
These five popular capabilities will modernize your analytics—but they’re not well supported with component libraries:
- Self-Service Capabilities: Empower end users to get the information they need on their own by drilling down, grouping data, using cross-tabs, filtering, panning, zooming, and more. Most component libraries do not support self-service out of the box, which means you will need to build and maintain it all yourself.
- Predictive Analytics: Allow your end user to leverage the power of machine learning and artificial intelligence without the need for data scientists or teaching developers R, Python, or statistical modeling. Building these capabilities for your application requires significant programming experience and specialized skills.
- Write-Back and Workflow: Workflow and write-back allow users to make decisions and take action within context of your application. Today, there isn’t an analytics library that can provide the same functionality as a platform, because it requires more backend work and technical power than libraries can provide.
- Scheduled Reporting: A few libraries will support small schedulers and basic cron jobs. But even the simple task of building a script and running it via cron has a ton of future work baked into it, such as addressing the script if it goes into error or systems goes down for maintenance; installing a backup cron to support your application; or creating a notification system to alert you when your cron has stopped working or has gone into infinite loop and is overloading your application server.
- PDF Export: PDF exports sound simple, but they can be some of the trickiest parts of an analytics project. The sheer number of possibilities make PDF exports a much bigger problem than you may think. You’ll have to answer a number of questions: Should export happen with or without the formatting? What will happen with tabular data? How will odd sizes of information will be handled? How would you export when charts and tables are together and are spanned over multiple pages?
The Bottom Line: Your users’ needs will inevitably change over time. An analytics development platform helps future-proof your dashboards by supporting new, modern capabilities as they emerge on the market.
#4: Security Risks
Building analytics using component libraries means you’ll need to address all security needs for every single component you use. Consider what it will take to implement security now and on an ongoing basis. Application teams often struggle with storing information in the application tier and passing it from your application to components. Every class/method in your various components will have to support your security parameters and work with your existing policies.
Also consider what level of sophistication you need from your analytics security. Many components don’t support complex features like authorization or using customers’ roles to determine what data they can access.
Finally, plan ahead for testing. Since some analytics components are more secure than others, it’s necessary to test every component to see if someone can get into your system or database. Also worth considering are SQL injection or cross-site scripting (XSS) risks. Your team spends a lot of time protecting against these basic vulnerabilities; make sure your component libraries have been as thorough as you have.
The Bottom Line: The most secure way to protect your application and your embedded analytics is by using one security framework. Since platforms plug into your existing infrastructure, you only have to secure and maintain everything in one place.
#5: Inconsistent Branding and User Experience
The primary reason for using open source data analytics tools is to maintain complete creative control over the look and feel of your application. But since each component supports themes on an individual level, white-labeling the entire embedded analytics solution means branding each component one at a time. Any modification to the brand forces developers to individually apply the new themes to every component, risking breaking one or missing a key piece altogether.
The Bottom Line: Your application’s brand is central to your intellectual property (IP). Choose an analytics solution that lets you easily brand dashboards to match your application’s look and feel, and gives you granular control at both global and individual-object levels.
Analytics components introduce risk when it comes to integration and upgrades. You have no guarantee all your component libraries will work together forever or have consistent versioning. If one library upgrades, you may face regression issues. Consider these factors for stability:
- Upgrades: Consider how you will upgrade your application if one library has a new version or a bug fix. Will new components integrate well with your existing application logic?
- Stable Builds: Dig into what was the last stable build and for how long to find out how often the team behind the component library updates it and creates “stable” builds.
- Interoperability: Does the component library work well with your server environment? Libraries cannot be mismatched or upgraded/downgraded. For example, if your production (and development) environment is upgraded to PHP 7.0, but a library only supports PHP 5.6 and before, that is a dependency that you cannot accommodate.
- Data Formats: Check that the library consumes data in the same format as your application. Also consider how it handles pagination for long datasets and any limitations on the amount of data it can handle. For example, if you have 20,000 rows of data in JSON format, will the library be able to consume it in JSON format? If pagination happens, what kind of load is added to your application server, and how does it impact the usability of your application?
The Bottom Line: Analytics components make it difficult to upgrade your capabilities whenever you need to, because they don’t always connect to your existing technology stack.
#7: Complicated Licensing Issues
Many components come with complicated pricing structures that can hinder your application growth. If one component prices on a per-user basis, costs can quickly skyrocket as your business grows. Also keep in mind that using multiple libraries means managing multiple different licensing policies.
If you have a commercial application, know that many components come with restrictions and complicated pricing for commercial uses. A single component that does not allow for commercial licensing can break an entire analytics initiative.
Ask your component providers if you can:
- Share reports built in the product with external stakeholders or customers
- Install the library on different developer machines and testing environments, and in multiple production environments
- Add however many servers, processors, or cores you need
- Use the component in a commercial product
- Add however many users you need to develop on it, and if those users can use the component at the same time
The Bottom Line: In the long term, an analytics platform offers more cost savings than components libraries, and it’s easier to scale as your company grows.
#8: Lack of Support
Support and documentation will vary widely from component to component. Even with online communities, getting answers to your questions can take a long time and there is no guarantee whether the answer will be accurate.
Components often suffer from a lack of accountability. Who will support the library if one or more components stops working? If something in an embedded dashboard breaks or doesn’t work as intended, you may end up debugging someone else’s component. As a general rule, all enterprise deployments should stay away from unsupported or community-supported libraries.
The Bottom Line: Building with components often means if something goes wrong, you’ll have to solve the problem yourself—if you can solve it at all.
#9: Concerns About Long-Term Viability
Inevitably, some of the developers on your team will leave the company. What happens when they have all the institutional knowledge of the analytics solution? This could have a serious impact on the ability of your team to maintain or upgrade embedded analytics. Unlike components, platforms are thoroughly documented, so anyone can build, maintain, and enhance the embedded analytics with minimal disruption.
The Bottom Line: Partnering with a trusted platform guarantees continuity of your analytics even if a developer leaves.
#10: Integration Issues with Existing Systems
No application exists in a vacuum. They communicate with other business applications and systems. Make sure the components will talk to other systems without breaking or limiting existing workflows. For example, an embedded analytics platform makes it seamless to integrate with systems like Marketo, Google Analytics, or CRMs and power end-to-end data analytics for end users.
Keep in mind that many components are not made to be embedded in existing applications. Each component will be different in how it interacts with other components, with your custom code, and with your broader application. Additionally, a component is limited by inputs it receives and cannot drive action without a lot of custom coding.
The Bottom Line: Embedded analytics platforms make your developers’ lives easier by scaling with your infrastructure, leveraging the investments you’ve already made, and integrating with your preferred technology stack.