Best Practices for Looker Development: A Practical Guide for Data Teams

When building and maintaining Looker projects, the difference between a smooth, scalable setup and a tangled mess often comes down to following the right practices from day one. Whether you are a Looker developer or part of a data engineering team, applying these best practices can help you avoid costly mistakes, keep your code maintainable, and deliver consistent, reliable insights.

Below, we will cover six critical areas: LookML Project & Git Integration, Dimension & Measure Modeling, Code Organization & Readability, Explore Modeling & Joins, Derived Tables, and Caching & Datagroups.

💡 To check our previous blogs about Looker, click here.

1. LookML Project & Git Integration

Looker’s Git integration is more than just a convenience; it is the backbone of version control and collaboration in LookML projects. Here is how to make the most of it:

• One project = one Git repo
  Maintain a one-to-one mapping between your LookML project and its dedicated Git repository. This makes version control simpler and reduces merge conflicts.

• Always pull before you push
  In Development Mode, pull the latest changes from production before editing. This ensures you are working with the most up-to-date version of all files.

• Write meaningful commit messages
  A short comment explaining your changes can save hours of confusion later. Be clear and descriptive.

• Review before deploying
  Test your changes in Explore before pushing them to production. This helps catch errors early.

• Run Project Health checks
  Always run Looker’s Project Health tests before deployment to avoid broken content or performance issues.

2. Dimension & Measure Modeling

Modeling is where LookML’s flexibility shines, but it is also where inconsistent naming, hard-coded logic, or poor structuring can lead to future headaches. Follow these practices to keep your modeling clean and scalable:

• Use ${field_name}, not ${TABLE}
  When building new dimensions based on existing ones, reference them with ${field_name}. This avoids hard-coded column names and ensures your new fields inherit any transformations or logic.

Example:

• Avoid redundant names in time dimensions
  For dimension_group: type: time, do not add “date” or “time” in the name. Keep it clean.

• Use duration dimension groups
  Instead of manually calculating date differences in sql, create type: duration dimension groups. This gives business users flexible time intervals and adapts better if the source changes.

• Follow a consistent naming convention
  Use lowercase letters and underscores for field names (full_name, total_sales). LookML is case-sensitive, so consistency matters.

• Keep the semicolons
  Always leave the two ;; at the end of SQL expressions inside the sql parameter. This signals where the SQL ends.

• Validate as you build
  Keep one Explore tab open in Development Mode. After each change, refresh to quickly confirm it works as expected.

3. Code Organization & Readability

Keeping your LookML code clean and organized makes it easier for your team to maintain and scale.

• Order fields logically
  While not strictly enforced, place new dimensions or measures after existing ones in the view file to keep related fields together.

• Use clear dashboard filenames
  Follow the convention name.dashboard.lookml for LookML dashboard files. This helps with quick identification and consistency.

4. Explore Modeling & Joins

Explores are the heart of Looker, and getting their structure right impacts both performance and usability.

• Prefer direct joins from the base view
  Use a join key from the base view when possible to avoid the performance costs of indirect joins.

• Always define a primary key
  Set primary_key: yes in every view, even if it is not currently being joined in an Explore. This enables symmetric aggregation.

• Specify relationships correctly
  For every join, set the relationship parameter accurately to ensure correct aggregation results.

5. Derived Tables

Derived tables can be powerful, but they require disciplined setup to avoid future headaches.

For SQL Derived Tables (via SQL Runner):

• Move the new view file to the views folder.
• Remove any LIMIT clauses used for testing.
• Hide unnecessary auto-generated count measures or remove them entirely.
• Define a primary_key for the view (e.g., primary_key: yes for order_id in order_facts).

For Native Derived Tables (NDTs):

• Create a new view for each NDT.
• Move the new view file to the views folder.
• Rename the auto-generated view name to match the view file name.
• Leave the model file reference commented out to prevent circular dependencies.

For Persistent Derived Tables (PDTs):

• Use a dedicated schema in your database for PDTs (e.g., X_scratch).
• Prefer datagroup_trigger if datagroups are already defined.
• If using persist_for, pair it with sql_trigger_value or use either on its own for data freshness.
• For cascading PDTs with the same datagroup_trigger, Looker will handle dependency order automatically.
• Add indexing to PDTs for faster query performance.

6. Caching & Datagroups

Caching is essential for performance, and datagroups are the key to controlling it effectively.

• Use both parameters in datagroups
  Define both max_cache_age and sql_trigger for reliable caching with a fallback mechanism.

• Link PDTs to datagroups
  Apply the datagroup_trigger parameter to PDTs to keep data up to date.

• Know the limits with dynamic usernames
  If your connection uses dynamic usernames (e.g., BigQuery OAuth), datagroups and PDTs are not supported. In this case, use persist_for to cache Explore queries for a set duration.

Business Use Case: Building a Regional Sales Performance Dashboard in Looker

⭐⭐⭐

Looker is a powerful platform, but its true potential comes from disciplined, consistent development practices. From Git integration and field modeling to Explore joins, derived tables, and caching strategies, every best practice you follow adds up to a cleaner, faster, and more scalable analytics environment. By standardizing these approaches, your team can work more efficiently, reduce errors, and deliver insights your business can trust, today and as your data needs evolve.

If you are ready to take your Looker development to the next level, contact us today. We will help you implement these best practices and build an analytics foundation that grows with your business.