Is it a Feature or is it Friction? Looker Edition

Categories

Table of Contents

In this edition of friction or feature, we will be looking at Looker. If you have browsed around for analytics solutions, chances are that you have stumbled upon Looker at one time or the other. With its latest connection to Google cloud, we wanted to dive deeper into some of its features, to understand if they were actually benefiting the user or just creating data friction.

For a more general overview of Looker, check out this article. Now let's get into the specific functionality of Looker’s analytics solution and see if it is a feature or friction for the users. 

DOWNLOAD THE INFOGRAPHIC

  • Pre-packaged applications

Result: FRICTION

Looker promises to accelerate your business with its pre-packed application. But the reality is far from it. These applications might be easy to use but severely limit the capabilities of your analytics. It starts by only allowing a specific number of rows and columns to be made, putting a limit on the scalability of your data. It might not be a big issue for smaller companies, but the more you grow, the harder it is to make Looker work. 

Pre-packaged applications rob you of the ability to customize your visualizations, with limited chart options and dashboard object placement. This effectively prevents the ability to white label analytics or use Looker to embed an analytics solution into your product. Here is what one reviewer on G2 had to say,

Looker Friction pre-packaged applications

Now we understand that the pre-packaged applications are just another form of friction. 

  • Looker developer portal

Result: FRICTION for non-technical users, FEATURE for developers

One of Looker’s crowning features is the developer portal —  a platform that consolidates developer resources. Aimed to be a community of developers where they can engage, learn and share information about building visualizations on Looker. 

For an analytics solution platform that promises self-service, ease of use and access to everyone in the organization, there seems to be an awful lot of focus on the developers. Almost as if without having a dedicated developer team, it might be impossible to make Looker function to its best potential. The developer portal is a well-disguised form of friction that to most users would look like a valuable feature. 

Looker Friction developer portal

  • Chat-based support

Result: FRICTION

In theory, chat-based support sounds like a 24/7 accessible channel where you wouldn’t have to be put on hold to wait for a technical analyst to help you with your problems. That is until you try using it. Imagine trying to explain a complex analytics issue or bug in the platform to a chatbot. How much of it can the chatbot really understand with its predefined script and lack of technical knowledge? 

Wouldn’t it be easier to jump on a call with a technical person, with whom you could share your screen and immediately have them understand what your problem is? Further, they could help run tests on the spot to identify bugs and have your analytics running smoothly in no time. So when you think it out, the chat-based functionality is just another complication leading to data friction. 

Looker Friction chat based support

  • LookML 

Result: FRICTION

LookML is used to build data models in the Looker platform. If you are a non-technical person, you might be scratching your head wondering, what is a data model? It’s a depiction of data relationships, behaviors and extensions, such as how the primary key connects two sets of data, or the expansion of the address into a street name, city and country. While necessary for optimal query performance, the way Looker has implemented modeling, quickly becomes spaghetti code.  Freeform, unstructured lines of code in a giant document where any field could be anywhere. It’s confusing for anyone other than the original model creator, non-intuitive for people who aren’t LookML experts, and makes finding exactly what and where to change tricky if not well-structured.

This data friction in the extreme.

Looker Friction LookML

  • In-database architecture

Result: FRICTION unless you’ve only got one data warehouse and don’t need to use CSV or Excel files

This is a great feature of Looker, connecting to modern data warehouses like Snowflake and utilizing their power for heavy-duty analytical processing. But what if you are aggregating data from MULTIPLE databases? Where will the processing be performed? 

The friction is taken one step further when you realize that you cannot upload CSV or XLS files into Looker. If you need to augment your data warehouse data with the occasional CSV file for things like sales targets, the feature becomes friction very quickly. So this great, in-database processing feature can easily become a cause of frustration if you need to use multiple data sources (not in one data warehouse) or enrich your data with uploaded files.

Looker Friction Architecture

  • Three-level data governance

Result: FRICTION

Data governance is critical to make sure the right users get the right data in the right situations. But with Looker’s three-level data governance, things get complicated fast. Looker is divided into model, group and role level permissions, with each level having further sub-levels into which users can be classified. It gets more complex: users can be on multiple sub-levels, where permissions can overlap or contradict one another. It’s nests upon loops upon nests. What starts off as a great (and necessary) feature ends up complicating the data governance process instead of simplifying things.. 

It becomes a major source of data friction.

Looker Friction Data Governance

  • Embedding via iframes 

Result: FRICTION (and a show-stopper for some)

Ahh, iFrames. They used to be the only way to embed analytic content inside an application, like a CRM or inventory app. But the world has moved on from iFrame embedding and with good reason. Many consider iFrames to be a security risk. iFrames have a terrible reputation of being vulnerable to cross-site scripting attacks, man-in-the-middle attacks, and clickjacking attacks. And,  they can slow page load times, creating a poor user experience. As an added bonus, iFrames have very limited interaction with other page elements. Change a field, click a button to refresh the iFrame analytics. Modify another field, click to refresh. It gets old, fast. With all these drawbacks, it’s no wonder other vendors have started offering alternatives to iFrame embedding.

Don’t settle for friction-filled analytics masquerading as features. Toucan analytics are designed to be friction-free and make even the most powerful analysis easy for business users. 

Try it for yourself and start reducing friction in your business.

 

 

 

 

This is a heading 2

This is a paragraph

Create your dashboard in less than 10 minutes

 

Get a demo
tabletmobile

Table of Contents