5 Replies Latest reply on Feb 12, 2019 6:02 AM by Ciara Brennan

    Mobile App - Size of Data

    James Frick

      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.

        • 1. Re: Mobile App - Size of Data
          Toby Erkson

          I don't know all of the ins-and-outs of Tableau mobile but I recommend this quick read in the Tableau Server manual:  About Client-Side Rendering

          If you're going to use the Tableau Mobile app:  The Tableau Mobile Deployment Guide - Tableau

          The mobile app isn't required to view vizes on a mobile device.  I've VPN'd into our corporate intranet and used a web browser to view our Tableau Server as if I was using my laptop...it's just not as pleasing to view

          1 of 1 people found this helpful
          • 2. Re: Mobile App - Size of Data
            James Frick

            Thanks.  I will read these.

             

            Unfortunately the CEO wants us to start today.  I have already gone to my boss to try to have this project delayed until we can get more details.  He said no.

             

            I need to get some quick answers as to what is "doable" in Tableau and what is not.  My first inclination is to tell them that based on the current data sources in the desktop workbook, this is not a doable app.  However I want to make sure this is correct. 

             

            Alternatively, if there are modifications we can take to make the conversion doable, then I need to get them to my boss as soon as possible.  These steps might be aggregation tables, reducing some of the calculations we do on very detailed data, etc.

             

            I just do not know enough about Tableau mobile apps and how it moves data around to give my boss a cogent, logical sounding argument.

             

            Thanks for your posts.

             

            James

            • 3. Re: Mobile App - Size of Data
              James Frick

              I did look quickly at your first reference.

               

              It talks mainly about rendering.

               

              Our issue is not rendering.  It is more along the lines of sending too much data to the mobile device or doing too much calculations on detailed data in order to achieve an aggregate result.

               

              Again thanks for your reply.

               

              James

              • 4. Re: Mobile App - Size of Data
                Toby Erkson

                Please read about how Tableau determines a viz's complexity threshold:  Data Science and Cognitive Computing Techniques: About Client-Side Rendering

                Where the rendering takes place can affect the end user's observable visualization performance.  Instead of the local device taking in the data and then pulling it all together to display it, the Tableau Server would take on those tasks and send the final result to the device.

                Complexity threshold is just an additional consideration.

                 

                Have you read about workbook optimization and performance analysis?

                https://onlinehelp.tableau.com/v2018.1/pro/desktop/en-us/help.html#performance_tips.html%3FTocPath%3DReference%7COptimiz…

                You could do this with your current workbook to help you see where improvements can be made.

                 

                Have you actually published the workbook to the TS and then viewed it on a mobile device?  If so, what were your results?  Did you try using :render=false at the end of the URL?

                As a rule-of-thumb, if a workbook is slow in Desktop it will be the same or slower on Tableau Server.  So at least you're aware of this and looking to tackle it, which is great!

                 

                < soapbox takeWithGrainOfSalt='true' >

                You may need a redesign of how the vizes will look, that is, don't try to make the mobile visual experience a 1:1 of the Desktop visual experience as it's not always a reasonable expectation...and something to not be afraid to state.  In my full-time AND contracting work I'm the expert, not my employer (that's why they hired me) so I'm upfront about expectations, particularly unreasonable ones.

                < /soapbox >

                1 of 1 people found this helpful