Why Castor x Looker makes sense?

Looker's search experience is not optimal. If you try and search for a specific column in Looker, you might have to open each explore and search for this column. End users often end up lost in all the Explores, Looks and Dashboards when they are looking for a specific content. One of the reasons is that lineage and popularity of Explores, Looks and Dashboards are not leveraged to organise these assets. It is hard to trust and have visibility in the Looker UI.

‍

Castor makes it easy to find data the most relevant data assets with a powerful search optimized thanks to popularity and advanced filtering options. Castor also provides lineage between the data warehouse tables and Looker Explores, Dashboards and Looks.

‍

How does it work?

‍

This feature aims at displaying Looker's Explores, Dashboards and Looks within Castor, linking them with the tables they use and leveraging their popularity for search purposes. For example, data consumers can thus search across all explores for the relevant column description.

‍

Use-case #1

As as Sales Manager, I want to be able to find the MRR dashboard based on a search query and their popularity so that I can get a faster analytics insights

‍

Use-case #2

As a Customer Success Ops, I want to be able to find the most advanced/popular data asset for my need and be guided in how to use a table if needed

‍

‍

Ok, but what does it change for me?

Thanks to the Castor x Looker integration, you have better control, trust and visibility on your data infrastructure. This helps with:

• Decreasing the number of duplicate content and work
• Decreasing "Time to answer" as users can use the highest value add asset available (they don't use a table anymore when a dashboard is available)
• Increasing the ability to deploy self-served analytics to less technical users

‍

‍

‍

‍