Ad Hoc Reporting is a form of report creation which allows non-technical users to create and modify reports on the fly without training. Ad hoc reporting generally boils down to three steps. First, a technical user sets up databases and data sets in a way which makes sense to a user. This can mean creating a “semantic” data layer which may have additional organization, naming conventions, drill downs, drill ups, drill across, or things like formulas or counts which add additional context to the data to make it easier for a non-technical end user to understand. Second, security and permissions are set up so that the non-technical end user only has access to the data they’re supposed to see. In an embedded use case, this often means matching your existing permission sets to the analytics engine. And finally, end users are able to create and edit reports on the fly through an easy-to-use dashboard creator.
Software/SaaS companies have long recognized that analytics is a top 3 requirement in their business applications. If they haven’t already implemented some form of Ad Hoc Reporting, Software/SaaS company customers will certainly start asking for things like “self-service reporting”, “web authoring”, “dashboard customization” or “Ad Hoc Reporting”.
Customers want the freedom to create their own analytic content and Software/SaaS companies are happy to free themselves from the effort of servicing Ad Hoc Reporting requests so that they can focus on higher value, differentiated software development tasks instead.
Usually there’s a journey that a Software/SaaS company goes through as they seek to balance ease of use, flexibility and maintainability with Ad Hoc Reporting.
The Software/SaaS embedded analytics product journey
- Phase I: Often application developers, being software developers, develop! They’ll download a component/visualization library and code around it. There’s great flexibility in this approach since developers can code exactly the user experience they want to create…however, there’s incrementally greater effort required over time and as legacy code is laid down, the flexibility and maintainability of these embedded analytics become increasingly difficult to maintain…it can become unsustainable even!
- Phase II: Furthermore, capabilities that customers are asking for, often called things like self-service reporting, web authoring, dashboard customization or Ad Hoc Reporting, add an additional layer of complexity that becomes “the straw that breaks the camel’s back”.
At this point a development team will often turn to “buy-v-build” alternatives. The first obvious port-of-call will be the many excellent BI tools available in the marketplace. These tools are ideally suited in providing an ad hoc analytics user experience, particularly if the user is an analyst, especially a data analyst or data scientist.
There are two challenges however:
- Embeddability: When it comes to embedding, BI tools are primarily finished applications designed to work perfectly happily on their own, thank you very much…can they be integrated into other applications, somewhat yes; but the user experience is already primarily pre-defined and the level of integration somewhat limited.
- Commercial Viability: Commercially, BI tools tend to licence on numbers of users and servers/cores. That’s fine if you have 10 users, but if you have 100, 1,000, 10,000 or more…pretty quickly software and SaaS companies are scrambling to find a more economically sustainable alternative.
Sure you can think of this as a cost-plus exercise and simply pass the cost on to the customer, but then the customer starts asking for interfaces for every single BI tool they have and furthermore the Software/SaaS has just lost one of its key differentiators by passing a large part of the responsibility for analytics over to the customer.
- Phase III: Once Software/SaaS companies conclude that neither in-house development nor BI tools are going to be longer term solutions, that’s when they start looking for tools that strike the happy balance between flexibility (custom user experiences) and maintainability (configure rather than code) and with a commercial model that is scalable, economically sustainable and often that means not married to users and servers/cores.
Ad Hoc Reporting’s Impact on User Experience
Ad hoc reporting gives users the ability to rapidly generate reports that meet their individual needs faster than ever. Instead of submitting a ticket, waiting for a report to be created, submitting any additional changes, waiting again for a final report, users can now dynamically create and modify reports on demand and at their own pace.
The ability to create any type of report or visualize data in any way they chose creates lots of room for innovation and creativity. Analyzing data from different perspectives and through different visualizations ultimately means increased flexibility and speed for analytic insight. This has become the norm and expected. Users feel the data that’s produced through the application is inherently part of the offering they’re paying for and they expect to be able to manipulate it as they choose to maximize the benefit of their investment.
Other core user benefits of Ad Hoc Reporting are the ability to share insights between users, and to reuse components and reports. Many ad hoc reporting systems allow users to share reports they’ve created with other users with appropriate permissions, meaning insights proliferate across a user base quicker than through traditional means. The reusability of components and reports also means that individual users can save a copy of a report and edit it to meet their own individual needs meaning quicker time to insight and more flexibility.
With icCube’s ad hoc reporting and dashboarding functionality, you can empower your users through your host application to do this and more. With fine-grained security and white-labeling capabilities you can create a fully embedded experience that looks and feels like your own application.
Monetizing Ad Hoc Features in Your Application
Monetizing self-service analytics features depends on software user persona profiles.The competitive landscape, and the value driven from insight driven through self-service analytics. Three main ways Ad Hoc Reporting and self-service analytics are monetized are:
- increasing revenue (more new business, more quickly and higher average deal value),
- reducing risk and ongoing maintenance costs (more focused effort on core competency with the same or fewer assigned resources and more reliability), and
- improving customer satisfaction and lifetime value (x-sell, wallet share, expansion and renewals).
Increasing Revenue
Increasing revenue comes in two distinct ways: Product Differentiation and Product Portfolio Expansion. In competitive software markets, ad hoc functionality can make your product stand out, not only does it empower end users, but it is by definition visually rich meaning it can often be an easy-to-demo product feature. What does all that mean? By embedding self-service analytics you can help your salesfolks close more business, more quickly, and for higher average deal sizes.
The first way software vendors generate incremental revenue is by using self-service as an additional premium add-on for new and existing clients. There is a user perception that self-service is seen as a premium offering that allows it in many circumstances to be used as a product portfolio extension rather than as an included add-on. This user perception gives many software vendors the opportunity to upcharge both new and existing clients. This can also align to, or create different user tiers that are given different capabilities at different per user charges. This capability is already built into icCube, where software vendors can choose who gets to use what depending on their credentials. Developers get access to everything unless otherwise determined. Consultants at customer-facing end of software or SaaS companies, who understand the end-customers business and how to leverage the product to output high value custom analytic content for customers may get access to almost everything as well. End-Customer Power Users may be given rights to configure custom analytic content for people at the end customers. And end-users who are primarily consumers of analytic content may be given the ability to just view content interact and navigate that content and perhaps customize using drop-down/multi-select filters, sort, group, select columns etc. or they may be given the capability to edit/create/or add to certain types of reports depending on their technical acumen and business need.
Reduce Risk/Cost
The second way in which software vendors monetize ad hoc reporting and self-service analytics is by reducing future competitive risk and ongoing maintenance costs. Competitive markets frequently push innovation and no one wants to be left behind. If your customers don’t see ad hoc reporting as a premium offering and you’re starting to see competitors take strives towards an ad hoc future, then working with an embedded analytics provider to get your users ad hoc reporting functionality now is a great way to mitigate future competitive risks you may encounter. It can give your users new functionalities, while giving your development teams enhanced focus by reducing the maintenance hours it takes to maintain a legacy reporting system. In the long term helping to make analytics reliable, sustainable, and more cost effective.
Improve Customer Satisfaction/Experience = LTV
The final way software vendors monetize ad hoc reporting and self-service analytics is by improving customer satisfaction and experience creating more meaningful, lasting relationships. If your users are already asking about additional analytics capabilities now’s the time to act. Don’t wait for “lack of reporting” to be the death knell answer on your churn surveys.
Why Data Structure is the First Step to Self-Service
The native, underlying data structure of most applications isn’t very user friendly, from non-descript field names to formulas that may require complex queries that can put a strain on your databases if not stored in-memory. Because of this, setting up a semantic metadata layer for end users is the first, and most important step in evolving your analytics to be more self-service, best of all, it’s normally a one-time job. icCube allows developers to easily create a metadata layer that can be formatted to fit user needs, from date format changes to simple field name clean up. It also gives developers the ability to define drill-down relationships, organize fields, build additional formulas, and more:
- Many-to-many relationships
- Unbalanced dimensions (ragged, parent/child)
- Asymmetric dimensions
- Create calculations using MDX, Java or R
- Localization of the semantic layer (e.g. country names on different languages)
The next step is to start defining security and permissions based on your host application’s existing permissioning system. icCube allows you to customize authentication and authorization through a variety of methods like Single Sign-On to ensure the security of your application.
Types of Interactivity Available in Ad Hoc Reporting (Options)
icCube’s embedded self-service analytics capabilities allow users to interact with reports in a variety of ways to extend the usability of reports and to provide users with deeper insights.
Some of the ways users can interact with reports through icCube include:
- Custom Dashboard Creation: Users can surround themselves with a cockpit of useful interactive tables, charts and maps which help guide them in their everyday tasks and ultimately help build efficiency throughout the organization.
- Filtering data:
- Combobox (dropdown)
- Buttons
- Multiselect
- Tree and Slider
- Date filtering
- And more!
- Sorting data: Similarly sorting data by different range types is quick and easy giving users.
- Drill down: icCube’s powerful MDX language structure makes drilldowns very powerful and gives users access to underlying data hierarchies as set up by administrators.
- Drill up: Similarly drilling back up to summary views in both dashboards and web reports can be done intuitively by non-technical end users making data navigation simple yet powerful.
- Adding and moving components on-the-fly: The ability for users to further edit and manipulate reports and dashboards is invaluable for increasing the flexibility of your analytics capabilities. icCube allows users to do so seamlessly and easily without having to go back to developers.
How Long Does it Take to Implement Ad Hoc Reporting in Your Software?
The age old question that every product team has asked their development teams at one time or another if there’s ever been an interest expressed by clients for self-service. The reality comes down to many factors, including what your data structure currently looks like, how modern or legacy is your code base, what vendor are you working with, etc.
At icCube we pride ourselves on providing the best experience possible to potential clients. We help developers build a proof of concept in as little as 30 days. A realistic timeline for most development teams using non-dedicated teams is anywhere from 90-120 days from initial contact to implementation, but many do it in less time than that.
Analytics, done well, is a never ending story. It offers Software & SaaS companies opportunities to broaden the user base as well as engage in more strategic, high value conversations. There’s always an opportunity to ask the customer where new value can be derived from analytics and open up the possibility for further product differentiation by embedding that new value in the product.
No Software nor SaaS Company is going to buy embeddable ad hoc reporting capabilities “off-the-shelf” without testing/evaluation.
So what should that process look like? Should it have some structure? Should it have a timeline? Are there key stakeholders and resources that need to be made aware of the process and/or whose availability needs to be secured?
If you haven’t already started thinking about the stakeholders in embedded ad hoc reporting – now’s the time!
- The Product Management Team: The product management, if there is one, often lead the effort as it is typically their task to interface the needs of the customer with the needs of the product.
- The Development/Engineering team: No new technology will make it inside the front-door of any Software/SaaS company without the rightful approval of the Development/Engineering team. We’ve seen product management teams try to “go it alone” without the development team – it’s just not going to happen. Sometimes the product management team and the development team are the same team.
- The Senior Management Team: Sometimes the decision to go with an embeddable ad hoc reporting platform is not seen to be strategic enough for review by the senior management team. In a Software/SaaS company that is almost never the case. There are implications for the company across the company and across most of not every function of the senior management team.
- The Customer: Of course Customers are key stakeholders in bringing ad hoc reporting into the product…in the end they will pay for it! When testing potential ad hoc reporting capabilities, it’s probably best to bring real customer use-cases into that process.
- Sales and Marketing Teams: Of course there’s nothing quite like asking customers what their expectations are from ad hoc reporting, but there’s that old saying in sales: “The customer never knows what they want until you show it to them!”….and of course sales and marketing teams understandable have strong opinions as to what customers want.
One of the primary differences between a BI tool and an embeddable analytics platform is that a BI tool starts with the premise that the user is a data analyst or data scientist and the product can be used by those people“out-of-the-box”.
With an embeddable analytics platform the premise is that every user of the Software or SaaS application is a potential analytics user without even thinking about it. Furthermore the premise is that the Software/SaaS company will use the platform to create a customized user experience that conforms and is consistent with the existing user experience.
So when it comes to budgeting, it’s important to think primarily about the development process, which members of the team from development and/or consulting will be the go-to people for ad hoc reporting initially as well as on an ongoing basis.
When it comes to licensing, it makes sense to start thinking about the “dimensions of value” that define the licensing for the existing application. Traditionally, the number of users or perhaps customers has been the primary dimension, however most Software & SaaS companies have already questioned whether it makes sense to define value based on the number of customers/users.
For example could the value be measured in terms of Shipping Vessels for Shipping Management software, Rented Rooms for Hotel Management software, MegWatts for Power Generation Monitoring software and many, many other examples.
A key conversation with the Ad Hoc Reporting vendor, then, is having a conversation for understanding the core value of analytics and attributing not only a price-point but also a licensing methodology that makes sense to both parties.
icCube – A Leader in Ad Hoc Reporting for Embedded Use Cases
icCube enables your development team to embed advanced ad hoc reporting and dashboarding capabilities into your host applications, empowering your users to create, modify, and save, fully interactive custom reports with no technical expertise and little to no training. Dashboards can be built just as quickly as reports by dragging and dropping data components in icCube’s embeddable web interface.
icCube gives your users access to a wide variety of charts and widgets to analyze data quickly and easily including:
- Table
- PIvot Table
- Serial
- Pies and Funnels
- D3
- Geo Chart and SVG Map
- Maps – Heatmaps, Markers and Custom Layers
- Maps – Columns and Pies
- Repetition Widget
- Text and HTML boxes
- and you can add your very own Custom Widgets
