Skip to content 
Looker has developed a couple of handy models to track instance activities, which are available for users with the necessary admin permissions. Below we follow the evolution of activity tracking provided by Looker, starting with the i_looker model and then moving onto the newer iteration available with Looker 7.0. We'll close with a few ideas about how these dashboards can be customised and extended to suit the needs of individual use cases.
Before Looker 7.0
The i__looker Model
The i__looker model gives you a way to access metrics about the history, dashboards, looks, and users in your instance. It’s divided into 4 parts :
- The History Explore, which includes information about queries run on your Looker instance in the last 90 days. You can explore it using:
URL | https://<instance_name.looker.com>/explore/i__looker/history
by replacing <instance_name.looker.com> with the address of your Looker instance.
- The Look Explore, which includes information about all saved Looks. You can access it via:
URL | https://<instance_name.looker.com>/explore/i__looker/look
- The Dashboard Explore, similar to the Look Explore but for dashboards:
URL | https://<instance_name.looker.com>/explore/i__looker/dashboard
- The User Explore, which displays data on user interactions:
URL | https://<instance_name.looker.com>/explore/i__looker/user
Some useful tiles have already been created by Looker. For example, you could search for the most popular Dashboard by query count using the following URL :
URL | https://<instance_name.looker.com>/explore/i__looker/history?fields=dashboard.title,history.query_run_count&f[dashboard.title]=-NULL&sorts=history.query_run_count+desc&limit=500&column_limit=50&query_timezone=America%2FLos_Angeles&vis=%7B%7D&filter_config=%7B%22dashboard.title%22%3A%5B%7B%22type%22%3A%22%21null%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%7D&origin=share-expanded
Or see which Explores are most popular by different user roles:
URL | https://<instance_name.looker.com>/explore/i__looker/history?fields=history.query_run_count,query.view,role.name&pivots=role.name&f[role.name]=-NULL&sorts=history.query_run_count+desc+0&limit=500&column_limit=50&query_timezone=America%2FLos_Angeles&vis=%7B%7D&filter_config=%7B%22role.name%22%3A%5B%7B%22type%22%3A%22%21null%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22%22%7D%2C%7B%7D%5D%2C%22id%22%3A1%2C%22error%22%3Afalse%7D%5D%7D&origin=share-expanded
The following URL is for Looks which have been deleted:
URL | https://<instance_name.looker.com>/explore/i__looker/look?fields=look.id,look.title,look.link,look.deleted_date&f[look.deleted_date]=NOT+NULL&sorts=look.title&limit=500&column_limit=50&query_timezone=America%2FLos_Angeles&vis=%7B%7D&filter_config=%7B%22look.deleted_date%22%3A%5B%7B%22type%22%3A%22%21null%22%2C%22values%22%3A%5B%7B%22constant%22%3A%227%22%2C%22unit%22%3A%22day%22%7D%2C%7B%7D%5D%2C%22id%22%3A1%2C%22error%22%3Afalse%7D%5D%7D&dynamic_fields=%5B%5D&origin=share-expanded
We have experimented with Activity Dashboards by adding tiles such as the number of Active Users, the last dashboard deletions, last errors, and top explores and dashboards used. But since the System Activity model is to replace the i__looker model in more recent versions of Looker, we decided to give this new feature a try.
System activity
The System Activity model is a Lab feature that can be enabled in the Looker’s Admin menu. It is a definite upgrade on the i_looker model as it provides us with much more data on the different kinds of interactions happening in our instance.
Here is the list of explores available upon activation:
Users can also find 3 Looker generated dashboards in the Admin Panel:
User Activity
As the name suggests, this dashboard contains information about users and their usage patterns. Here we have some really interesting tiles such as the Total # of Users, Weekly Querying Users, Weekly Engagement per User, Top Users, and Unengaged Users.
Content Activity
This one can show us which pieces of content attract the most attention and which looks, dashboards and explores perhaps need some revamping.
Performance Audit
If you're looking for ways to optimize your platform, this dashboard is a great place to start. It has data on query and source runtime, which allows you to easily identify if there are persistent issues or bottlenecks in your instance. For troubleshooting, tiles such as Errors by Query Source and Dashboard Errors can help you to pinpoint where issues might be coming from.
Customize it!
These dashboards are a good starting point, but they have not been designed specifically for your project. From experience, we've found that this is general and useful data, but you could easily miss important information if you stick to the preset templates.
For example, you might want to filter out data about LookML developers, which is included by default, in order to focus on your business users instead. The nice thing is, that you can modify these automatically generated system dashboards by creating a new one from a relevant Explore.
What we did
In one of our projects, we decided to keep some tiles from the Looker-generated dashboards, to add a set of new ones that we needed for our particular use case, and to also split Performance from Errors. Our goal and recommendation are to go over these at least each week.
User Activity
Here we cleaned and reorganized the dashboard by adding a tile for the number of Users who are not Developers and filtering the rest of the content to include Non-Developer users only.
Content Activity
On this project, as we barely used Looks, we mainly focused on Dashboards. But of course, in a project that makes greater use of Looks, you can easily add more data and tiles...
Performance Audit
Here we kept most of the tiles about queries and runtimes. These are great indicators that must be consulted each month.
Errors
An important requirement we often have is to split the Errors from the overall Performance Audit so that it's easier to locate and quickly fix errors with bad models, views or tiles.
Errors on the front and back end could easily diminish the adoption of a new tool if users encounter too many issues along the way, and impact their confidence in the validity of any data-driven insights, as nobody trusts a tool that keeps producing errors! Even when your LookML developers have gone to great lengths to verify the multiples conditions of a model, it’s still possible that your users might run into errors.
That's why it is best to consult this dashboard regularly and expediently resolve any issues. As you can see, in our case most of the tiles are filtered on a history of the last 7 days.
But of course, this is just an example and all can be personalized according to your needs!
After Looker 7.0
This article was written a few months before the release of Looker 7.0. Now that we have the new version, here's a quick overview of the changes.
The 3 built-in dashboards available with the System Activity feature have been extended to 5:
- On the User and Content dashboards, Looker removed2 tiles about Explores by Group and Group Querying.
- The main modifications are about the Performance Audit dashboard, which has been split into 3 parts. The first is related to queries' runtimes and the performance of Looks, Explores, and dashboards. The second is about schedulers and content which could slow down dashboards - such as having more than 25 tiles or having auto-refresh enabled, for example. And the last one shows details about errors and broken content.
We can see that Looker has streamlined the Performance Audit Dashboard, which is a welcome improvement as at first, it contained too much information. And it's a looking much slicker now!
Thanks to @Irina and @Nas for proofreading and upgrading this article!
