Ilooker and user engagement

(Richard) #1

I’ve just read this fantastic interview with Lloyd Tabb and it got me thinking about how engaged our own Looker users are. Currently I’m charged with “Creating a data-driven culture” within the company and one of the things I track as a proxy to that behaviour is Looker usage. But my metrics are mostly vanity metrics such as ‘number of accounts’, ‘daily active users’ and ‘total web usage minutes per day’. This is fine at a top level but when talking to people I sometimes discover they are only checking saved Looks and dashboards that other people have sent them as they don’t know how to make their own, completely missing the benefit of the system.

Does anyone know how to use ilooker to identify users that may need a refresher course and generally monitor user behaviour in the same way we do for our actual business? Also, is there a reason why ilooker is so hidden away and the history table is limited to the last three months? It would be great if this mysterious part of Looker was promoted to a proper LookML model. (Even if it was read only.)

0 Likes

(Jonathan Leedham) #2

Hi Richard,

I would also echo your comments on ilooker being front and center to the product (exposing as normal model), really useful for reminding BI teams when to do more outreach activities to build usage. On the vanity metrics we have started to use the API to look at last logged in and compute days since logged in and account creation dates. We plan target users with additional training and support early on (first 20 days) and users who usage has lapsed (past 90 days). Though still in beta we are also looking at api for volume and age of saved content. We encourage sharing ad-hoc data and while this is not directly measured we could then segment users as those who log in but don’t create content (but have permissions) from those who do. An extensions of this we plan to snapshot daily usage at user level and join to internal lists of users by department. Plan is to check that we have trained champions in each team but also to compare peers so that we can spot where potential access, training or utility issues. Goal is not to say everyone must use looker but just to check that there are no hidden barriers to access and that the output we curate as an organisation offers something for everyone to unlock value from data.

0 Likes

(Paola) #3

Hey @Rich1000, I definitely hear you on the idea of exposing the i__looker model, that’s currently not an option within Looker but I can pass it along to our product team for you.
As far as identifying users who may need a refresher, it could be useful to dig into users who are only using Looks and Dashboards vs users who are only using the Explore page. Might also be good to look at users who ran queries 2 months ago and haven’t since then. We have a few URL examples for the i__looker history explore in this discourse article you can take a look at.

0 Likes

(Richard) #4

Of course, it hadn’t even occurred to me that you could use the API for that. I think I’m going to set this up pretty much as you describe - thanks!

0 Likes