Question

"History: Query Run Count" explanation?

  • 10 December 2020
  • 2 replies
  • 83 views

I’m trying to analyse my company’s Looker usage (~100 people), and the History explore has had a treasure trove of information. We don’t have an intense data-culture, so I’m just actually trying to find the few super-users, so I can reach out to them. In the meantime, I don’t expect very high usage-counts.

So when I see the “Query Run Count” hitting tens of thousands in the timespan of a few weeks, I’m kind of confused.

 

How is this measure counted?

  1. If someone clicks “Run” in an explore, does that make their count +1?
  2. If someone clicks “Run” in a merged query, does that make their count +1?
  3. If someone opens a dashboard (that’s not cached) with multiple tiles, is it +1 for each tile?
  4. etc

Also, some people have query-counts at ridiculous hours of the day (e.g. 3am) that I imagine some automated processes are going on that are incrementing these counters?

No one uses embedded content though, or anything like that. Our Looker usage is pretty limited to making a couple dashboards, and maybe 4 or 5 people have scheduled some stuff.


2 replies

Hey @Jamie Friday, I had the same question and just got a few answers from the DCL that I think might be helpful for you!

The “Query Run Count” measure is aligned with description #3 - if someone opens a dashboard with multiple tiles, it increments for each tile that automatically loads. So a dashboard with 20 tiles on it would increment by 20 - or in the words of @kevin.dunn “a dashboard with 1 tile could be run 10x more than a dashboard with 20 tiles, but the dashboard with 20 would appear more popular.” Not super helpful when you just want to know how often someone is opening the dashboard.


A great workaround that Kevin gave me was to create a custom measure on the history explore based on the “Dashboard Session” dimension. Make it a “Count Distinct” and boom, you’ve got a count of each dashboard run. 

For context - “A 'dashboard session' is one run of a dashboard. Every time a user opens a dash that runs automatically, that's one dashboard session. If they hit the run button, that's another. So what we can do is create a custom measure that's a count distinct of the dashboard session field, and each count will essentially be one dashboard run.”

 

There is supposed to be a new field in version 21 for the dashboard run count, but until then you can use this custom field workaround and get what you are looking for.

@bullsean great to hear, thanks for the tip :). I did not know that “Dashboard Session” dimension existed.

On my other points, I had actually reached out to Looker support directly; apologies for not having updated this post earlier.

Better late than never, for others in the future.

 

Regarding Query Run Count:

  • It’s equal to the number of query runs:
    • 1 Explore query run = +1
    • 1 Merged query run = +1 per query (For example: a merged query with 3 queries = +3)
    • 1 Dashboard run: count each tile based on the previous 2 points
  • A scheduled run will increment Query Run Count by the same amount as a normal run.
  • It's possible to have usage metrics that exclude merged queries by setting the Is_Single_Query flag to “Yes”. (Alternatively, you can filter exclusively for merged queries by setting that flag to “No”.)
  • Cached query are included in Query Run Count. If you want to distinguish between the query ran from cache, you can use the measures Results from cache and Results from database.

 

Also, regarding Approximate Web Usage in Minutes (which is also related to user-usage):

  • This is an approximation of the number of minutes that a user used the Looker platform. This is estimated from his/her query usage data. It is calculated in 5min chunks based on a user's query runs, and only when running active queries. For example: if I run a query at 12:00, Looker records that as 5min usage; if I run another query at 12:01, it's still the same 5min; if I run another query at 12:05, now total usage is recorded as 10min.
    • Confirmed by this other post: “Here at Looker, we use a 5-minute engagement because we find that it better captures the attention time of a typical user.”

Reply