.png)
How to build sustainable LookML Projects, a robust user permissions framework and increase self-service BI adoption with Looker
In issue two, I’d like to cover the essentials for standing up a profit-driving Looker architecture in your SMB SaaS company.
This article is geared towards SaaS leaders and derives from a LinkedIn post I made a week or two ago on setting up a broader data architecture. It’s not designed to get super technical.
Our goal is to give leaders a working knowledge of what they NEED to be aware of while implementing Looker at their organization
Disclaimer: Steinert Analytics is not affiliated with or a partner of Google Cloud and Looker, but it is a core tool in our arsenal for building profit-driving data products with clients.
Our Looker Experience
If you are to look at my credentials, the bread and butter of my experience sits in the business intelligence and analytics realm.
I’ve been the Lead Data Architect of Steinert Analytics since December 2021. Prior to that, I’ve led multiple Looker implementations and data teams as a Lead Looker Engineer in F200 and high growth start-ups.
I have extensive experience architecting Looker from an administrative and LookML development capacity. My goal is to provide you with a few foundational tips when implementing Looker and LookML at your organization.
Why Looker?
First, a little more information for clarity and context. Google has made the Looker brand somewhat confusing. In October 2022, Google Cloud moved all of its business intelligence tools under the Looker brand name. Now we have
Looker (Google Cloud Core & Original
Looker Studio (formerly Google Data Studio)
Today we are focusing specifically on Looker Google Cloud Core & Original implementations. Steinert Analytics is proud to be leveraging both Looker and Looker Studio with clients of all sizes, but I figured the most value would come from where I have deep experience and expertise.
One of the biggest gripes with Looker when comparing it to leading competitors like Power BI or Tableau is its price. Since the acquisition from Google Cloud, Looker’s customer support has been lackluster at best and its prices are high when compared to its competitors.
However, I still think Looker can be justified as the premier BI tool of choice. This will depend on a company’s willingness to adopt its demanding learning curve. Furthermore, a company’s strategic direction needs to see the value of self-service analytics to activate users in many business departments.
With that said, I’d like to cover the following three core Looker architecture topics today:
Map out LookML project framework, scope of reports, and needed Explores
Document a user permission strategy that leverages Looker User Groups
Create a user onboarding program to heighten user adoption
My plan is to take you through each one of these in detail, and how to tactically implement them. We’re trying to provide you the knowledge for a foundational Looker deployment to ensure it succeeds in your organization.
1. Map out LookML project framework, scope of reports, and needed Explores
If your organization is new to Looker, I recommend starting from a Blank Project. You can also Generate Model from Database Schema or Clone Public Git Repository, but I won’t spend time on these functionalities (Read more about these here: https://cloud.google.com/looker/docs/create-projects).
A LookML project is a collection of tables and data models that you create to use and explore your data for uncovering insights.
If brand new to Looker, my advice is to start on a clean slate, with a clear direction in mind for what data products you build and who it will serve.
Maybe obvious, but it’s worth noting that you shouldn’t start building in LookML until you’ve successfully finished consulting with stakeholders.
A great post this week from Ergest Xheblati (LinkedIn post) talks about starting with the business problems/questions they’re trying to answer for decision-making. Work backwards from there to define the metrics/KPIs, entities, and dimensions to answer those questions.
Now onto the scope of reports. I’m going to highlight how to build a strong reporting foundation in Looker as an SMB SaaS company without boiling the ocean.
Maybe just due to my experience, but I like to focus on revenue operations, finance and product usage as the three cornerstone reporting lines.
Revenue Operations encompasses sales, marketing, and customer success teams working together to grow revenue. A few foundational reports to get started leverage your CRM (Salesforce, Hubspot, etc.):
Leads / Lead by Stage
Opportunity by Stage
Lead to Opportunity (Conversion Rate)
Closed Won Opportunity (Revenue)
From a Looker standpoint, you’ll probably have two Views. One for lead and one for opportunity (think like they’re database tables!).
The key question to ask yourself is how can you combine this entire reporting line into a single Explore? This is where data modeling comes into play, and we are assuming you already have the tables you need from your data engineer(s).
Finance in a SaaS company centers around:
Monthly Recurring Revenue (MRR)
Annual Recurring Revenue (ARR)
Forecasting those accordingly
Furthermore, viewing subscription growth overtime and billing vs. cash are also very useful to understand the health and sustainability of your SaaS company.
It’s worth noting that, just like the Revenue Operations CRM, you’ll have different Looker Views for different entities (tables) of your financial source system’s data model in Looker/LookML.
Product usage is a tricky one, but critical for understanding how customers are using your software. I say it’s tricky because the reporting use cases can vary widely depending on the industry and type of software.
From my experience in telehealth, we had a few different reporting data models for video chat usage, secure text, and e-faxing all available as separate Explores in Looker. Combining all of these didn’t make since with our MySQL data models, so we chose to keep the Explores individualized.
Hopefully this sparks some ideas for your own usage reporting with Looker, and keep in mind balancing individual Explores with modeling them together.
LookML Project Considerations
What you want to avoid is always creating individual Explores — one for lead, opportunity, MRR, ARR, Billing, Cash, video chat, etc. This creates unnecessary clutter with your LookML that results in project code debt…
I see this commonly happen because it takes less effort to stand-up a basic lead report in Looker as opposed to going through extensive Explore data modeling and validation.
Joining all of your Looker Views together for a given report takes time, but the end result is worth it. It removes end users having to chase down metrics from a bunch of different Explores, and instead everything needed is in one convenient and cohesive Explore.
Our suggestion is to set the expectation up front with your stakeholders that delivering robust Explores in Looker takes time.
The amount of time it takes to stand up a Looker Explore is dependent on a few factors:
The complexity of your source systems’ data models
The quality of data engineering’s curated tables
The logic needed in your LookML Views’ derived tables (if using them, but best to avoid!), dimensions and measures
How you’re tying them together in LookML
If your stakeholders push back on timelines, try to deliver stop gaps with raw SQL queries instead, using data engineering’s curated tables.
This is an approach I leveraged at the telehealth start-up I was at and it allowed us to deliver quality in Looker while satisfying immediate needs for stakeholders. I know this might be controversial, but I stand by this to create the most complete and clean LookML project possible while delivering immediate value.
Lastly, once you have a foundational number of reports determined, map out the LookML Project’s Explore structure using the below diagram as your guide.
2. Document a user permission strategy that leverages Looker Groups
Looker user permissions are an important administrative consideration when implementing Looker. It’s particularly useful when you have multiple users and reports across different departments in your organization.
It’s important to note that one can be an excellent LookML developer, but know little to nothing about the administration of Looker as a super admin.
Ensure that you cover Looker administration topics when looking for Looker talent (no pun intended, hah!) if you’re in need of advanced user management.
The best way to think about Looker user permissions are at the Group level. The permissions hierarchy is as follows:
Group > Role > Permissions Set(s) & Model Set(s)
You can get even more tailored by permissioning users on a Folder level as well using something called Content Access. As an architect or enterprise leader, worry less about this. Leave this to your Looker admin to figure out a quality folder structure and Content Access. (Read more about this here: https://cloud.google.com/looker/docs/admin-panel-users-content-access)
Folder structure could be an article all on its own, but they function just like folders on your Mac or PC. As a little side tangent tip, I’d recommend starting with folders that encompass each business department for organizing your reports (ie. Sales, Marketing, Finance, Operations, Accounting, etc.)
Another concept regards advanced permissions - when you set access grants using Looker User Attributes. At the end of the day, User Attributes leverage Groups, so don’t worry about these right now either. You’ll naturally be able to use these as long as you set up the foundation with Looker Groups correctly.
In the world of Looker best practices, even a seasoned Looker admin will tell you to roll everything up to the Group level. The reason for this is because it provides standardization when organizing users.
If you individually assign users on a Role, permission set or model set level, it gets EXHAUSTING keeping track of who has access to which dashboards and Looks.
I’ve dealt with instances that failed to leverage Groups for standardized permissioning. It’s a nightmare to manage as soon as your Product Owner begins customizing report permissions based on business lines and job functions.
So do yourself a favor and spend considerable time on architecting your Looker Groups and their associated Role!
If you have enterprise cloud infrastructure, I recommend configuring your Looker Groups using SAML from your company’s Active Directory. This allows you to avoid manually adding users in the Looker UI when onboarding someone new. Google Cloud provides more documentation on how to do this here: https://cloud.google.com/looker/docs/admin-panel-authentication-saml
Below I’ve provided a template and example you can use to document your Looker Group permission structure.
I’ve leveraged this exact template as a Senior Looker Engineer at a F200 real estate investment management company (shared in a OneNote and Word doc). The firm had different global business lines (Americas, EU, and Global/Corporate) with extremely confidential data and this structure worked well.
TEMPLATE
Looker User Region and/or Business Team
Active Directory Looker Group > Looker Role > Permission Sets > Models or Model Sets > Explores
Active Directory Looker Group…..etc.
Example
Key: Active Directory Looker Group > Looker Role > Permission Sets > Models or Model Sets > Explores
Finance Company Americas
Finance Company AM Users > Finance Company User > User > finance_co_am_genie > Explore Names: finance_co_am, am_vacancies
Finance Company AM Viewers > Finance Company Viewer > User > finance_co_am_genie > Explore Names: finance_co_am, am_vacancies
Finance Company EU
Finance Company EU Users > Finance Company User > User > finance_co_eu > Explore Names: eu_occupancies, eu_vacancies
Finance Company EU Viewers > Finance Company Viewer > Viewer > finance_co_eu > Explore Names: eu_occupancies, eu_vacancies
Finance Company Global
Finance Company Global Users > Finance Company User > User > global_aum_finance_co > Explore Names: global_aum, coinvest_finance
Finance Company Global Viewers > Finance Company Viewer > Viewer > global_aum_finance_co > Explore Names: global_aum, coinvest_finance
Hopefully this helps get your gears turning on Looker permissioning!
3. Create a user onboarding program to heighten user adoption
Looker and User Adoption Issues
Looker deployed in a vacuum encapsulates two strengths very well: self-service business intelligence and data governance.
If you set up your Explores and their associated Views/dimensions/measures correctly, it gives users the power to self-serve their data needs while relying on the robust and accurate LookML model you constructed.
Seemingly, adoption appears like it’s a no brainer. However, that’s far from the case. A few contributing factors include:
Looker’s Explore UI learning curve
Unfamiliar feel compared to spreadsheets
The need for performance optimization
I’ve seen all three of these scenarios play out in the corporate and start-up workplace.
Explore UI
The Explore UI, although in my opinion one of the easier BI tool interfaces, has its own complexities.
Getting users to understand the difference between dimensions and measures (black text vs. bronze in the field picker)
and how to properly filter dimensions is difficult for those new to BI tooling.
Not to mention, Looker has a very quirky feature for date ranges. When you select a date type dimension as a filter and use the “is in range” start until (before) end - you always have to select the succeeding day for your end date. This is because Looker writes the SQL as start date less than (<) end date. It can be very weird for new users and I’ve seen this throw off numbers ever so slightly for financial reporting. See picture below for example.
Additionally, the Explore UI allows users to build table calculations in expression language.
This language is similar to Excel or Google Sheets, however the syntax can be tricky and get complex depending on what you’re doing. For new end users, this can be an intimidating hurdle to be trained on.
Dashboards aren’t spreadsheets
Correct, Looker visualizations in either individual reports (Looks) or dashboards are not like spreadsheets. They’re not supposed to be either.
However, I’ve had to work extensively with sales managers in the past that refused to use Looker due to their infatuation with spreadsheets. Unfortunately, this is more of a mindset and cultural shift, and something that a user adoption plan can help.
Performance Optimization
Lastly, Looker performance can be a bear if the underlying data models and tables are not set up correctly.
For end users, a report load time greater than 5-10 seconds is at risk of being dismissed by end users. For technical team members, I’d say it’s more along the lines of 30 seconds as the cut off. This is just from my experience.
If load times are slow on your Looker instance, it could be due to a number of issues such as database slot usage, poor SQL logic in Looker derived tables, bad Looker caching and persistence strategies, and if self-hosted - low Looker application memory available.
You’ll need to work with your Looker Engineers and Data Engineers to diagnose and treat these issues.
Below is a step by step outline to maximize your success with Looker User Adoption
As you build Looker products for end users, create video tutorials and collateral how-to documents that highlight how to use the Looker Explores, dashboards, and reports available. These can be recorded on Microsoft Stream or Loom. Make a library / folder of these recordings and how-to guides.
Configure a welcome message on the Looker homepage using their welcome markup feature in the Admin settings. Provide links to the training materials here.
Once your Looker instance and reports are productionized, communicate to stakeholders with a department or company-wide email. Point them to the relevant dashboards, Looks and training materials via links or Looker homepage. Conclude the email with a note on Looker training dates with calendar invites to follow.
Hold several Looker training sessions for end users by department. I recommend these be 30-45 minutes at a time. Highlight key dashboards and Explores. Have one session to go over the dashboards and reports, and another to highlight the Explore UI.
Send follow up emails to both training sessions with a routine schedule for Looker office hours. These will be meeting blocks where 1-2 days a week people can join and ask questions about the dashboards, reports and Explore UI functionality as they get used to the tool.
In this process, begin to identify Looker champions of the organization. Go the extra mile by leveraging Looker’s system activity Explores to analyze user activity overtime. This will show you who is using Looker consistently and those who are not. (Note that system activity needs the see_system_activity permission)
a. Leverage the Looker champions by highlighting their wins using Looker. Communicate this to Slack or Teams channels. Spread awareness to other end users!
I’d recommend creating automated report sends to Slack or email to get users exposed to updated reports on a routine cadence. More info on the Slack integration here: https://cloud.google.com/looker/docs/scheduling-slack.
Repeat weekly office hours until you see adoption at a suitable level.
Hopefully this adoption framework helps your company unleash the power of Looker self-service.
Thanks for your time reading Rooftop Insights Issue 2!
We covered three foundational Looker architecture concepts that will help you maximize the value of your company’s Looker practice.
With this knowledge you have in place, you will be able to successfully guide the implementation, permissioning and adoption for the best Looker user experience possible.
In turn, we hope this gives your company a massive productivity boost, while driving up your profit with the insights Looker unlocks!
You can follow me on LinkedIn .
If you need help with your Looker implementation, please don’t hesitate to book a free consultation with us.
Wishing you the best start to 2025!
Comments