Looker Reviews

The most valuable features are the ability to create visualizations for non-technical employees, as well as the ability to provide ways to dynamically slice the data. This is especially useful for keeping track of potential issues with our data warehouse, to which the product is connected, and for providing controlled access to potentially sensitive information.

Our BI team, and otherwise less-technical employees, are able to design and schedule their own reports without additional knowledge. They are now able to create a number of more-complicated visualizations, such as churn diagrams and acquisition funnels, which are used to track milestones and immediately spot anomalous behavior.

This product is useful for non-technical users, who are able to use the interface to easily slice data. But for the admin users who are responsible for maintaining the schemas and files behind the scenes, it can easily become a chore, as there is a lot of manual work involved in defining the schemas of the connected database(s), as well as any refactored tables; the restrictive syntax also makes maintenance difficult. A personal feature request I have is the ability to create reports in such a way that the end users can inject values into the query and dynamically change the results in this way.

I have been using it for approximately a year.

Stability is generally not an issue. We do sometimes have trouble with larger data sets, but Looker does not seem to be intended for such purposes. In fact, certain restrictions are placed automatically to limit the number of records available for viewing at once. One major issue we have discovered is that the computations required for more complicated metrics can often overload Looker, forcing us to create additional refactored tables in the data warehouse in order to reduce the load on Looker. This is particularly restrictive when users want to create reports from raw data.

Customer support has generally been helpful; they tend to be helpful, provide suggestions and be open to feature requests.

Initial setup was relatively simple. The main difficulty lay in picking up the syntax of the LookML files that determine what is shown in the UI, but the Looker team was always available to provide training over the phone.

An in-house team implemented it. The only setup required was to feed the connection details through Looker, and to later integrate with GitHub.

The alternative when decided to use Looker was Tableu, which was recommended by several employees who had used it in the past. The main reasons why we opted for Looker over Tableu were the existence of a web interface, simplicity of use, and the general look of the product.

While Looker is great for simple visualizations and is a great start in terms of providing a framework for dynamically generating graphics, don't expect it to do any heavy lifting. It struggles with large data sets, and the syntax will often require you to feed refactored data into Looker.

I like many parts of Looker. The Developer Experience is top notch. To me, Looker leads the way in the modern BI trend. If you know SQL, you can be a data modeler with very little training. This allows SMEs to drive analytics instead of engineers. Additionally, I can develop on production data sets and not impact production workflows.

I also love LookML. LookML is Looker's data modeling language, which is a derivative of YAML and easily translates to SQL. SMEs can easily model business logic for all other users to share. Also, LookML modeling and its extension abilities allow Knewton to use one code base for multi-data center data warehousing. Example: We have the same data model in Europe and the US that are separate for legal reasons and we can share the same data model code base. Build it once, deploy to production; realize the value everywhere.

The data sharing experience is also quick and useful. I can generate a saved query (a.k.a. a Look) and share it with a user in seconds.

I have multiple product managers and an implementation specialist who build whole dashboards with filtering widgets and multiple visualizations. These are non-technical people implementing new dashboards with new fields or calculations on billions of records, and I don't have to have any data engineering resources involved.

I want to have temporary derived tables so that users can prepare data sets before exploring them and committing code. I am looking forward to the upcoming improvements in workspace security. This will allow me to remove a lot of visual noise from my c-level customers, by reducing what they see in the UI to just what matters to them.

I have used it for three years.

There have a been a few minor bugs, including a security bug that did not affect us. I have seen a little bit of caching issues with the data-driven drop-down filters. E.g., If you have a State/Province filter field and you add a new state to a lookup table. There is no recourse to repopulating the cached data sans waiting for the cache to expire or rebooting the service.

Until recently, it was not possible to alias a model, so in the past, we were stuck with poor naming convention choices. Looker has been very responsive to customer feedback.

Technical support is the best ever. Seriously, this is why we bought the service. The in-app technical support for the LookML developers has allowed me to scale to self-service exploration with a handful of data warehouse/data engineering staff. We have > 40 LookML developers and 200 users of the service.

At Knewton, we had our own custom-rolled solution with D3 before. It was great, but not agile. A REST API for data access and a framework for visualization. An engineer was always required for new dashboards. We wanted to empower self-service analytics.

We had our first dashboard and the majority of the data model that people use today up in < 4 hours from the time Looker spun up a dedicated server for us. We already adhered to industry-standard data warehousing practices and Looker leveraged our schema effortlessly, by generating data models and joins from fact tables to dimension tables with remarkable quality.

Not everyone would have this experience, but if your column names are consistent between tables for things like users and event identifiers, you will be quite pleased with the results.

What about the implementation team?

We implemented it in-house. Make your data models contain only a few explores. Use more data models with fewer explorable tables. Organize around business principles, not tables. Example: For one data mart we have, there are 100 tables but only three Models: People, Content, Events. Also, I recommend grouping explore definitions and view definitions in special views that are exposed in your models. This allows for the same explore in multiple models. Message me on twitter at @rexgibson for examples.

It's definitely worth it for us, but I can't get into details. We want as many people as possible at Knewton using Looker because we believe that decisions should be supported with data.

Start small. Don't try to build a whole complex warehouse. Pick an important and simple business problem and solve that first. Get clear on how LookML works in your company before building a lot of explorable tables.

We're able to surface data very quickly and easily. Once Looker is connected to your database, it's very easy to produce reports, dashboards, charts, etc., that expose the data. The tool makes it easy for non-technical people to explore data in ways that would not have been possible before without significant SQL experience. Now, literally anybody can do it.

It's now very easy for non-technical users to "self-serve" and produce the information and gain the insight they need. For example, account managers often deal with customers who have unique needs. These AMs are able to quickly produce individualized "Looks" or dashboards, save them, and send them to internal users along with customers. Of course, we can produce a variety of "standard" reports and dashboards, but giving people close to the business access to what they need without involving data engineers or analysts is a huge time-saver and convenience.

Some of the visualizations are a bit limited on how much you can customize them. That said, Looker pushes frequent releases, and they typically contain improvements to visualization options.

We've been using Looker for a little more than two years.

We've never (that I recall) had any significant Looker stability issues. It's always up when we need it.

We're not a huge organization, but we've not had any trouble here. We have around 300 users, and around 100 unique users per day (peak), and that's never been a problem.

Technical support is one of my favorite things about Looker. They are always very helpful when we have technical questions. Typically, I hate "chat support", but it's really good with Looker. The people who help are always very knowledgeable and if they don't know an answer right away, they are able to find it quickly.

We've previously used at least two other solutions. Looker was better for several reasons. Number one, it makes it easy for 'non-techie' people to do "techie" things. LookML is powerful and intuitive. Looks and dashboards are easy to complete on the fly even if you don't use LookML. Number two, we really like the API stuff and the ability to use "Looker data" in other apps lends itself to solving the "one-source-of-the-truth" puzzle BI folks often face. Number three, their support is fantastic. It was pretty useless with others, and is really great with Looker.

I can't speak to the entire initial setup, but once Looker is connected to the DW, it's extremely easy to get Looks and dashboards built. And, from what I understand, connecting it to the DW is very straightforward – but another engineer handles that.

Depending on what you want to do with Looker, you might see some price barriers. For example, embedding "reporting" in a customer portal might sound great and, depending on the customer, $50 per month might be very reasonable. But, if you have numerous "small" customers, that price point does not scale well.

Before choosing this product, I evaluated Domo, Pentaho, Jaspersoft, Birst, Tableau, and a few others too.

It's easy to build too much too fast. What I mean by that is that it's really easy to "build stuff" in Looker. If I had it to do over again, I might take a more measured approach to determine exactly what I build, and document it better. Looker opens up the data world to a lot of new people, and it's so easy to spin up a quick dashboard, it's easy to forget what you've done (or somebody else did) six months down the road. Also, make sure you truly understand all your data. Once you open it up, people will use it. Sometimes, users make assumptions about the data that might not be true.

We LOVE Looker here at Snagajob. No single solution checks all the boxes on any BI team's wish-list, but Looker comes very close. The product itself is great, and meets nearly all our needs. The support is fantastic, and the user community is very collaborative and eager to give advice within the Discourse forum (the Looker user forum).