With the rise of “big data” and a generation of business managers attempting to make decisions based on data rather than instinct, the common output of data science and business analytics teams is business intelligence (BI) dashboards. Increasingly, these dashboards are made available to external users as well. In my experience building and consuming such dashboards, I have come across an observation: if a dashboard is slower than Google Trends1, it is almost certainly too slow to fully engage users. In most cases, the data being processed is much smaller than the search history of any arbitrary query on Google. It stands to reason slow dashboards are a result of poor implementation or using the wrong tools that come at the cost of engagement.
Empirical research shows that slower internet load times have a negative effect on engagement, but little research exists around the user experience of business intelligence dashboards specifically2. My own anecdotal experience coincides with the more general evidence on website design, BI dashboard engagement increases with the speed with which a user can manipulate data up to the point where loading a new permutation is imperceptible.
The technical reader will point out that Google’s Trend tool is surely highly optimized, utilizing database indices to return queries quickly because the form of the query is predictable. Google affords to dedicate software engineers to build an application optimized towards the type of queries their dashboard tool will generate. On the contrary, the average business intelligence tool (such as Tableau, PowerBI, etc.) must account for a much wider range of possibilities as the end user may query. The average dashboard is built by a business analyst, not a team of software engineers, in half the time.
Therein lies the opportunity for a new generation of business intelligence tools: cannot our dashboards, once published, reach the performance of a custom application? After a dashboard is published, the underlying database queries become predictable so it is conceivable a database, BI tool, or other technical system could adapt to make the finished product equivalent to a purpose-built data application.
One interesting natural experiment has recently been the proliferation of Covid dashboards across state and government websites. In the United States, every individual state published some version of a public health dashboard reporting on the state of the Covid pandemic. These were generally implemented in Tableau, PowerBI, and ArcGIS. Almost universally, the load time of these dashboards was far longer than the load time for an arbitrary Google keyword search query, despite the underlying datasets being a fraction of Google’s.
An overview of the literature can be found here: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4974011/ ; Corporate literature includes https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/
Good observations on dashboard speeds. I think that two important difference between Google Trends and BI dashboards like Tableau and ArcGIS are: (a) the amount of data sent to the browser (b) real-time calculations done within the dashboard. I am no software engineer.... the beauty of Google Trends is that it is so lightweight. Very little data in the browser and no clunky sliders/radio buttons/dynamic filtering. Both of these allow Google Trends to be much faster than Tableau & others.