Monitoring Tableau... with Tableau
A rehash of a post of mine from a little over a year ago today. It's just nice to have everything in the same place! Plus, this is as relevant now as it was then.
Working with Tableau Server can be exciting, mostly due to capability of the software itself, but every so often you discover something new when diving deep into the layers beneath it.
A challenge was sent to me from a collegue earlier this week, looking to do something quite specific. Using Tableau Server’s inbuilt Postgres repository, they wanted to find users who were downloading the underlying data on a dashboard. (I.E – exporting CSV files of data).
This is where the fun really starts. The findings should be presented back in Tableau itself, so using Tableau to monitor things going on… in Tableau. For those interested, I’ve outlined the steps below.
STEP 1 – CONNECTING TO THE REPOSITORY
Now I won’t go into this in depth here, the instructions on how to connect to the repository itself can be found here: http://onlinehelp.tableau.com/current/server/en-us/adminview_postgres_connect.htm
Once connected, the magic table you want to find and connect to is the http_requests table within the workgroup database.
STEP 2 – ASSESSING THE DATA
The http_requests table has a wealth of information regarding user actions on the server. If you haven’t already, I suggest browsing through your own to just get a feel of what’s there. You could easily find which views (or users) have the most activity. Great if you want to drive usage or dashboard popularity.
The particular columns we’re looking for this time are the Action & Http Request Uricolumns. Any time a user views the underlying data this is recorded in the action column as “vud” (for short). However, that alone doesn’t tell us when a user downloads an extract of the data, and this is where the Http Request Uri string comes into play.
Hidden at the end of the string is a little indicator that only exists if the user has gone into the vud and opted to download the underlying data. I used a boolean calculation on the field to find where that was true for users within my Tableau Server.
STEP 3 – A LITTLE BIT OF LOD
We’re not quite there yet though. At this point, we may be able to calculate the amount of times a CSV extract has happened, but not attribute it back to who. The keen eyed among you would have spotted that a User ID is only assigned to the first row of a session meaning that we’d encounter a great big userid=”null” if we tried to build a view now.
So, what’s the solution? A level of detail (LOD) calculation of course!
Fixing the level of detail at the Vizql Session means that we can attribute the User ID back to the row.
For the Excel users among you, this is a little like doing a VLOOKUP to find our missing values. Because we know each Vizql Session is unique per User ID and that the value is either null or a User ID, we can use a MAX User ID per Vizql Session to apply to each row.
STEP 4 – USERS & SITES (POLISHING).
So at this point, we’re pretty much there. We can identify which users ids are downloading data from particular dashboards at least. A little extra step is to join the User/Site tables to our data in order to make the information a little bit more meaningful.
To do this, I simply joined the sites and users_view tables on the Site ID & User ID respectively.
Note: you’ll have to repeat the LOD calc above for the Username. ({ FIXED [Vizql Session] : MAX([Name])})
And there we have it! Using Tableau to monitor Tableau Server users exporting data from… Tableau. My attempt can be found below. #heresoneimadeearlier
Or... see it on Tableau Public here.