{Shiny.Telemetry} 0.3.0: Track User Behavior In Your Shiny Applications

This article was first published on Appsilon | Enterprise R Shiny Dashboards , and kindly contributed to python-bloggers. (You can report issue about the content on this page here)
Want to share your content on python-bloggers? click here.

Understanding how users interact with your application in data analytics is crucial for continuous improvement and user satisfaction. {shiny.telemetry} is a groundbreaking tool that lets you do just that.

shiny.telemetry offers a nuanced approach to user engagement, adoption, and impact assessment. Learn more in this blog post. 

Whether you are a developer aiming to refine the user experience, a business analyst looking for insights into user engagement, or a project manager focused on optimizing navigation and functionality, {shiny.telemetry} has got you covered.

Not just that, {shiny.telemetry} can also replace your traditional logging approaches in Shiny applications.

Here we are announcing the third release of {shiny.telemetry} loaded with new features and some bug fixes.

Introduction to shiny.telemetry 0.3.0

One of our main design goals with this package is to make it really simple, easy to use and easy to integrate with existing codebases. This blog post will walk you through the basics and show you how to integrate with an existing app in no time.

What’s New in Version 0.3.0?

The latest version brings in lots of new features alongside performance and security improvements.

Improved User Tracking

  • Detect username: {shiny.telemetry} can now identify users by their usernames if the shiny app is running in a Posit Connect or ShinyProxy environment and user authentication is enabled.
  • Track Anonymous users: You can now track anonymous users when the user is not logged in or user authentication is not enabled. {shiny.telemetry} will set a cookie in the browser and identify returning visitors. This is now enabled by default in the latest release. (Does not work in apps running in ShinyProxy)
telemetry$start_session(track_anonymous_user = TRUE)
  • Set username programmatically: You can also choose to set the username programmatically if your app does not run in Posit Connect or ShinyProxy environments.
telemetry$start_session(username = your_custom_function())

Track Only What You Want

Prior versions of shiny.telemetry offered basic control over tracked data. The latest release introduces two powerful new arguments to the log_all_inputs() method:

  • excluded_inputs_regex: This argument allows you to define a regular expression pattern to exclude specific types of inputs from tracking. For example, you might exclude all inputs containing “date” in their ID to avoid capturing every date picker interaction.
  • include_input_ids: This argument lets you prioritize specific inputs for tracking. This is useful when you’re particularly interested in certain user interactions within your app. You can provide a vector of input IDs that will be tracked regardless of any exclusions set with other arguments.

By combining these arguments, you can achieve a high level of granularity in your telemetry data.

Here’s an example:

telemetry <- Telemetry$new()

telemetry$start_session()

# Do not track inputs that contain "tbl_" while still tracking "tbl_row_selected"
telemetry$log_all_inputs(
	excluded_inputs_regex = "tbl_",
	include_input_ids = "tbl_row_selected"
)

This code ensures that only changes to the tbl_row_selected is tracked, while all other inputs containing tbl_ in their ID are excluded.

This level of control empowers you to focus on the most relevant user interactions within your Shiny app, leading to more focused and actionable insights.

To learn more about this check our new How-to guide: ”Track a Subset of Inputs to Improve Performance”

Adds Tracking of Shiny Errors

This new version of {shiny.telemetry} adds a new type of event that tracks errors on Shiny applications. They could be exceptions inside render, observe or reactive calls.

This can be achieved natively on Shiny since 1.8.1 with the onUnhandledError callback. However, if our users do not want or cannot update to this version, we added a custom mechanism that supports prior versions.

The error event is tracked by default once you update {shiny.telemetry} to version 0.3.0.

Figure 1: Analytics dashboard showing error on user session.

Support for MongoDB

In the previous version of {shiny.telemetry} all the major relational databases were supported e.g. SQLite, MySQL, MariaDB, PostgreSQL, MSSQL. This release adds support for MongoDB, one of the most used NoSQL databases in the world. Here is an example of initiating a Telemetry object with a MongoDB backend:

telemetry <- Telemetry$new(
  app_name = "your app name",
  data_storage = DataStorageMongoDB$new(
	host = "localhost",
	port = 27017,
	username = "root",
	password = "example",
  )
)

The MongoDB backend shares the same API as others making it seamless to migrate between data storage devices. There are additional parameters to help configure MongoDB connection, please read the documentation for more details.

Bug Fixes and Security Update

Along with the new functionalities we also worked on fixing user reported issues as well as reducing a possible security vulnerability when accessing the analytics data.

We fixed a problem on reading timestamps from SQLite data storage backends. This does not require any action in existing DBs as the timestamps are stored correctly.

This release also has  added extra protections against SQL injection when building queries to data storage SQL backends by using glue::glue_sql to build queries. The previous mechanism already protected against SQL injection by checking if parameters of query building were only dates, but this adds a new extra layer of security.

Documentation and Miscellaneous Improvements

Release 0.3.0 of {shiny.telemetry} adds 3 new guides to the documentation and some changes to the example applications in inst/examples folder.

  1. “Setup shiny.telemetry in a Rhino application” shows step by step on how to integrate {shiny.telemetry} with Rhino;
  2. ”Track a Subset of Inputs to Improve Performance” explains and gives some examples of how to use this new feature in {shiny.telemetry};
  3. “Use External Databases with shiny.telemetry” guide will help users understand how to use {shiny.telemetry} with different database servers and how to protect sensitive information.

Lastly, we also updated our logo in part of an image update of the Rhinoverse.

Try {shiny.telemetry} yourself on your applications and let us know on Linkedin or in our Shiny Community on Slack how you feel about it.

{shiny telemetry} is already being used on our projects and with our clients to help us better understand the users of a dashboard and improve on it to deliver the best possible user experience as per our Shiny Manifesto.

Stay up to the date on the latest in shiny.telemetry and our Rhinoverse packages. Sign up for our weekly newsletter today. 

This blog post was co-authored by André Veríssimo.

The post appeared first on appsilon.com/blog/.

To leave a comment for the author, please follow the link and comment on their blog: Appsilon | Enterprise R Shiny Dashboards .

Want to share your content on python-bloggers? click here.