7 Example Shiny Applications

In this section, we will look at some examples of how Shiny applications are used in business today.

7.1 Next Best Action Application

As the name applies, a Next Best Action model, or NBA model, is a model whose output provides recommendations on what actions will lead to the best outcomes. These types of models are often developed by data science teams at companies that have large call centers. For instance, insurance companies have large call center operations to handle claims and customer service calls. Companies in other industries such as telecom and e-commerce also operate call centers. A NBA model provides specific recommendations, or “actions”, the call center representative can take which is expected to improve desired outcomes, like customer retention. In this section, we will take a look at how Shiny can help operationalize such a model.

To start, a data science team will first create the NBA model. They will determine desired outcomes, such as increased retention, and use existing data from their call center to train a model. This step might be done using R, using tidyverse packages to import and clean the data and then use any number of powerful prediction modeling packages like xgboost, tensorflow, or caret, to train the model, just to name a few. Once the model has been created, the next step is to deploy it. Deploying a model, also referred to as putting it into production, means making your model available and used by the business and extracting real value from it. In this example, this means getting the model in the hands of the representatives answering the customer calls.

Because the goal is to make the NBA model’s recommended actions available to human beings, the call center employees, a Shiny application is a great option for deploying our model. In some other cases, we may want expose our model to other systems or programs, in which case building an API would be more suitable. An example of this might be wanting to integrate our predictive model’s output into a mobile application, something we could certainly also do using R but will not cover here.

The benefit of using Shiny is that the same data science team who created the model can also be the team to build the interactive application for it. Although it would be an option to use more traditional web programming languages like html, css, javascript, or react to build the web application, learning and using these languages can be a full time job. With Shiny, the data science team can use R, the same programming language they used to create the model and already know very well, to create a production worthy web application in very little time. Because Shiny is simply another R package, it works particularly well for sharing models created with R. The data science team is now no longer dependent on other teams, such as IT or the web team, to build a custom application for them which can often take months, if not years. Shiny gives them the option to be indepedent and shorten the time to production, getting the application in the hands of users more quickly. Because of all this, Shiny gives organizations more options and flexibility on how to deploy their models: each project can be evaluated on a case by case basis to determine whether Shiny or a more traditional web technology stack makes sense.

Here is what a NBA model deployed via a Shiny application might look like: a customer calls into their insurance company’s call center to cancel their auto insurance policy. The customer representative who takes the call has the Shiny application on their computer screen where they can enter the customer’s policy number. The policy number could also be automatically pre-populated based on the phone number the call is coming from, making the process even easier for the representative. Once entered, the Shiny application would then return the NBA model’s recommendations. This might include recommended actions the representative can take that will increase the likelihood of saving the policy. These recommendations would be based on the many different data points the company has about the customer, which are sometimes referred to as “predictors”. These predictors might include the customer’s age, zip code, vehicle type, number of accidents, number of vehicles, age of the policy, recent rate increases, and other data. These predictors would be fed into the model, which would then predict the next best action the representative should take to increase the chances of saving the policy. These recommendations are based on the tens of thousands or hundreds of thousands of other calls the model was trained on, helping the representative leverage the learnings derived from all the call data that was collected over the years.