Want to understand the difference between view_log and query_execution tables

Get Help
1

Hello data heros,

I am performing some analyses on the usage of metabase at my company. I am looking to pull some stats around how many times users have opened dashboards/questions. Some example stats could be:

  • total # of metabase pages viewed by users last month
  • .# of times a question was viewed/run
  • users that use metabase the most

What I can't seem to understand however is the difference between a run in the query_execution table and a view in the view_log table. As far as I can tell through my tests, as soon as you navigate to a question (question is viewed) it runs the query to populate it (question is run). And navigating to a dashboard is logged as both runs and views for all the questions that loaded on the dashboard

Is there a situation where a user visiting a question/dashboard/table would be logged on the view_log table and not the query_execution table or vice-versa?

What is the action that causes a line to be added to either of these logs?

Bonus question: is there a spot where I can see the documentation for all these metabase tables? I could not find any :sweat_smile:

Thanks so much for any help!
Zack

1 Like
2

Hi There,

a while ago I created this repository containing a set of useful queries to measure how users are consuming queries and dashboards.

I use both query_execution and view_log.

Generally, I am using query_execution to monitor queries, while view_log to monitor users, dashboard, and so on.

Add a star to the repo if you like it :innocent:

Best

3

Hey Roberto,
thank you for the response! Just to clarify : when you say you are " using query_execution to monitor queries", the queries you are talking about are metabase questions, yes?

If i understand correctly, what you're saying,
if i was trying to find the most used questions -> query_execution
but if i was trying to find the most viewed pages -> view_log

Thanks!

1 Like
4

I try to give you a good example: by using query_execution you could cluster your queries by execution time, making straightforward identifying slow or inefficient queries.