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.
