I have been asked to build a mobile app that mimics a desktop set of 19 dashboards in one workbook. We are in Tableau 2018.1.7.
My concern is that the workbook management wants me to mimic is over 2G in size. So I am turning to this forum for help in how to solve this.
Here is some background on our desktop app:
1. It uses the base level transaction table for invoices for almost all of its calculations. There are no aggregate tables. The base table has over 15 million records in it. It takes over an hour for the extract to refresh every morning.
2. The individual dashboards have multiple sheets and views, usually with no summation. For example, most dashboards show all of the invoice activity for every customer.
3. The dashboards are set to filter based on who the user is. So if I sign in as sales person 101, I would see only his or her data on all of the dashboards.
4. Even with Tableau's "in-memory" capability, it sometimes takes 20 seconds to change a filter and get results, for example, picking a category of products, and waiting for the invoices that make up that category of products.
5. Basically the desktop version has analytical type data, i.e. aggregations and trends at a high level, mixed on the same dashboard with very detailed data, which in my mind is more accounting or operational data.
So here is the challenge. Management wants the desktop dashboard delivered on a mobile device. I am struggling to see how this can happen as the desktop dashboard is already unwieldy and slow.
Can someone explain how Tableau mobile app works from the point of view of the data? Given what I have written above, how would you handle the data design, data structures, etc. to make Tableau deliver the data in a timely fashion?
Here is my comparison:
I have done mobile apps in MicroStrategy. MicroStrategy approaches data delivery in a completely different manner, not necessarily better, but different. the basic difference for a mobile app is that MicroStrategy waits to query the data and only sends to the mobile device the bare minimum of data needed for the screen. Also, in designing these aps, we did not normally work at the very detailed, lowest level of data.
An example might help to explain:
1. The first screen would be filtered on a sales person. It would show be an alert screen that showed the top 25 customers based on declining sales. thus the sales person would know who is endangered of leaving our firm. This data would come from an aggregated table rebuilt every night via ETL. The data would not come from recalculating sales for every customer for that sales person and then ranking them based on declining sales.
2. Next, the sales person could click on one of the Top 25 customers by declining sales and a second screen would come up that shows the sales trend by month for only that customer per product category. This would show 10 to 15 trend graphs so the sales person could see which categories for that one customer are declining. This would be calculated on a customer, category, month basis for the last 18 months. This would come from a different aggregate table built via ETL. The data, again, would not come from recalculating from the base data.
3. The next screen would pop up when the sales person clicked on one category. The dashboard would then show more detail on that one category, either at a subcategory level or at the product level. Again this would be pre-calculated via ETL and not be calculated at the time of display on the individual invoice level.
This is a sample of how we did this in MicroStrategy.
How does Tableau handle this? I am very worried that if our current desktop dashboard seems slow to the sales persons, they are definitely not going to be happy with simply converting it to a mobile device.
Any advice on how to organize the data sources to improve response time for a mobile app would be greatly appreciated.