This article is an excerpt from an Eckerson Group report, "The Ultimate Guide to Embedded Analytics: Keys to Product Selection and Implementation" published in February, 2018.

The world is full of paradoxes. Here’s one for data analytics professionals: analytics becomes pervasive when it disappears.

By placing analytics at the point of need—inside operational or custom applications—embedded analytics closes the last mile of BI. Workers can see the impact of past actions and know how to respond to current issues without switching applications or context. Analytics becomes an indispensable part of the way they manage core processes and solve problems. As a result, embedded analytics has a much higher rate of adoption than traditional BI or analytics.

To succeed with analytics, you need a sound plan. Many teams start their embedded analytics project by selecting the technology platform to deploy. Although choosing the vendor to power your analytics is a critical step, it shouldn’t be the first milestone you tackle. Instead, start by considering these questions: What are you trying to build, for whom, and why? These essential questions will help you better target your product and will aid in the selection of the best technology for your situation.

Establish the Focus

Setting the goals for your analytics project is an essential first step to ensure that all key stakeholders—from the executive team to the end users—are fully satisfied upon project completion. There are three basic steps to planning for a successful analytics project: define table stakes, define delighters, and define what’s out of scope.

1. Define table stakes. Table stakes are the essential elements the project must include in order to be considered successful. For example, you might decide that the analytics must include dashboards for the CEO, or that they need to include both sales and financial data in order to be useful. These items are considered “table stakes,” and you should plan to include them as part of your development plan.
2. Define delighters. Delighters are product elements that are “nice to have”—not essential, but highly beneficial to customer satisfaction. These may be elements that would greatly streamline workflows, or would simply make the product more enjoyable to use. They aren’t critical to using the application, but they would “delight” the customer if present.
3. Out-of-scope items. It’s also important to decide what won’t be in the product. Try to avoid putting the analytics team in the difficult situation of deciding whether to address a late-arriving customer request. Although it’s impossible to identify all out-of-bounds features or services in advance, you should try to create a set of guidelines. For example, you might choose to deliver dashboards that users can tailor to their needs, but not raw data feeds. Or, you may decide that you’ll provide a standardized set of analytics covering a variety of use cases, but you won’t build customer-specific, “one-off” data models. 

Define the Project Team

The composition of the project team can be a key element in the success or failure of an analytics project. For example, more than a few projects have been derailed at the last minute when the legal team—not included in the process—surfaced major issues with the plan. When structuring your analytics product team, consider including the following in your “core team” for the project:

• Product owner/head of product

• Head of development/engineering

• Head of sales

• Head of marketing

• Head of operations and support

Next, identify representation from roles that, although not involved in daily decisions, will need to be consulted along the way, including finance, billing, legal, and sales enablement/training.

Create the Plan

A best practice is to get the key project stakeholders in a single room to discuss core elements in a facilitated session. Although it might be necessary to have some participants attend remotely, in-person attendance makes for a faster and more effective session.

Too often project teams—whether analytics-focused or otherwise—fail to create a plan to guide the key steps required to bring embedded analytics to market. Without a plan, teams are liable to spend too much time gathering requirements and too little time analyzing persona needs. Without planning, the time required to perform key tasks, such as resolving issues from beta testing, might be overlooked. The steps to creating a basic, but useful, plan are simple:

Set project goals. Setting project goals before any technical work starts is a good way to ensure that everyone involved agrees on the success criteria. Set aside time to create project goals as the first step in your analytics plan.

Set a timeline. A timeline may seem obvious, but it’s important that, in addition to the overall start and end dates, you plan for intermediate milestones such as:

• Start/end of product design: When will you begin and end the process of defining what functionality will be in your analytics product? Without scheduled start and end dates, this segment of the process can easily extend far longer than anticipated.
• Start/end of technical implementation: When will the technical aspects of the project commence and complete? This should include items such as connecting to data sources, implementing the analytics platform, integrating with the core product, and applying user management.
• Start marketing efforts: If you build it, you want them to come. But you don’t want to raise expectations for a speedy arrival before development has completed. Plan on setting dates for key marketing activities, including the development of logos and advertising, demos and sales collateral, and training documentation.
• Start/end the beta period: Before you launch your analytics, you’ll want to test your analytical application with a set of carefully chosen beta users. Pick reasonable dates for this process and be sure to include time for selecting beta users, educating them on the product, reviewing testing results, and resolving identified issues.
• Start/end user onboarding: Don’t forget that, once the product is complete, you still need to onboard any existing users. Plan to onboard users in tranches—define manageable groups so that your team doesn’t become overwhelmed with support issues. And don’t forget to leave time between each tranche so that you can resolve any issues you might find.

Create a Communication Plan

It’s easy to forget that although you, as a member of the product team, might be fully aware of everything that’s taking place within your analytics project, others might not know about your progress. In the absence of information, you might find that inaccurate data is communicated to customers or other interested groups. You can prevent this by establishing a communication plan, both for internal personnel and for potential customers. Although the plans will be different for those inside your walls versus external parties, all communication plans should include:

• Regular updates on progress
• Revisions of dates for key milestones
• Upcoming events such as sneak peeks or training sessions

Set Metrics and Tripwires

Once you’ve started your product development effort, particularly once you’ve started beta testing or rollout, it can be hard to identify when critical problems surface. That’s why setting metrics and tripwires is a good idea during the planning phase.

It can be hard to identify when critical problems surface. That’s why setting metrics and tripwires is a good idea.

Metrics are used to measure product performance. Consider tracking:

• Product uptime
• Responsiveness of charts and dashboards (i.e., load time)
• Failed data loads
• Total users
• Users by persona type
• Time spent using the analytics
• Churn (users who don’t return to the analytics application)
• Functionality being used

Tripwires alert you to critical situations before they cause business-disrupting problems. They are metrics values that, if exceeded, trigger a response from the development team. As an example, you might have a tripwire that states if the product uptime is less than 99.9%, the general rollout of the analytics product will cease until the issue is resolved. Each metric should have an established tripwire, and each tripwire should contain the following elements:

• A metric value that, if exceeded, triggers a response.
• A predetermined response such as “stop rollout” or “roll back to the previous version”.
• A responsible party who reviews the metric/tripwire and determines if action is required.

Although metrics and tripwires don’t ensure project success, they can greatly reduce the time —and stress for the team—to address problems.

Choose Target Users

It’s a common mistake to think either that you fully understand the users’ needs or that all users are the same. Many teams launch embedded analytics products without considering the detailed needs of target users or even the different user types they might encounter. Avoid this situation by creating detailed user personas and doing mission/workflow/gap analysis.

Many teams launch embedded analytics products without considering the detailed needs of their users or even the different user types they might encounter

Here’s how it works:

Step 1: Choose Personas. The best way to create an engaging data product is to deliver analytics that solve users’ problems. This is difficult to do for a generic “user,” but it can be accomplished for a specific user “persona” or user type. Start by picking two or three key user types (personas) for whom you will tailor the analytics. These might be strategic users looking for patterns and trends (like executives) or tactical users focused on executing work steps (like salespeople or order fulfillment teams). Although you may ultimately add functionality for many personas to your analytics, start with personas that can impact adoption—key decision makers—first. Get these user types engaged with your analytics application and they can help drive adoption among other users.

Step 2: Identify mission. For each chosen persona, the next task is to understand the user’s mission. What is the person trying to accomplish in their role? Are they trying to improve overall sales? Are they striving to increase revenue per customer? Understanding what the persona must accomplish will help you understand where analytics are needed.

Step 3: Map workflows and gaps. Now that you understand each persona’s mission, the third step is to outline the workflow they follow and any gaps that exist. These steps—and gaps—inform the project team where they can add analytics to assist the persona in accomplishing their mission. Keep it simple. If your persona is “head of sales” and the mission is “increase sales,” a simple workflow might be: (a) review sales for the month (b) identify actions taken within those segments (c) recommend more effective tactics to managers. Within this workflow, you might find opportunities where analytics can improve the effectiveness of the head of sales. Perhaps reviewing sales performance or identifying underperforming segments requires running reports rather than simply reviewing a dashboard. Maybe seeing what actions have been taken requires investigating deep within the customer relationship management (CRM) system and correlating actions back to segments.

Within this workflow, you might find opportunities where analytics can improve the effectiveness of the head of sales. Perhaps reviewing sales performance or identifying underperforming segments requires running reports rather than simply reviewing a dashboard. Maybe seeing what actions have been taken requires investigating deep within the customer relationship management (CRM) system and correlating actions back to segments.

By finding information gaps within workflows and understanding personas’ missions, project teams can ensure they put high-value analytics in front of users.

By finding information gaps within workflows and understanding personas’ missions, project teams can ensure that they put high-value analytics in front of users. It becomes less of a guessing game—replicating existing Microsoft Excel-based reports and hoping the new format attracts users—and more of a targeted exercise. Only analytics that truly add value for the persona are placed on the dashboard, in a thoughtful layout that that aids in executing the mission. Engagement increases as target users solve problems using analytics.

In the embedded world, testing, team-work, and timely delivery will go a long way for your applications.  For those curious about criteria for selecting an embedded analytics product, keep an eye out for my next comprehensive article on the topic. Thanks for reading! 

This article is an excerpt from an Eckerson Group report, "The Ultimate Guide to Embedded Analytics: Keys to Product Selection and Implementation" published in February, 2018.