Looker Partners

What a defensible model actually contains

LookML describes your data in three layers. Views map database tables into dimensions, which are attributes you group and filter by, and measures, which are aggregations like counts and sums. Explores define which views can be joined together, in what direction, and at what cardinality, forming the starting points a business user picks from. The model file ties explores to a connection. The skill is not writing this syntax, which is straightforward, but deciding what to expose. An explore offering four hundred fields is not more powerful than one offering forty; it is less usable and considerably more likely to produce a wrong answer through an unintended join.

The difference between a model that lasts and one that is quietly abandoned is usually discipline about definitions. Every measure needs a single canonical implementation, a plain-English description visible in the field picker, and a reason to exist. Fan-out and chasm traps — where a one-to-many join silently multiplies a summed value — need to be handled deliberately using symmetric aggregates or by modeling the join out. Fields that exist only as intermediate steps should be hidden. Done properly, a business user cannot easily construct a materially wrong number, which is the real test of a semantic layer and the reason it is worth paying for.

Ownership questions to resolve before handover

• Where LookML development lives — whether the model is owned by analytics engineering alongside the warehouse transformations, or by a central BI function, since the answer determines who is trained and who reviews changes.
• How many developers you need — realistically two or three people fluent in LookML and SQL, because a single holder of that knowledge makes every change wait on one calendar.
• The boundary with the warehouse — which logic belongs in transformation models upstream and which belongs in LookML, written down, so the same calculation does not exist in both places diverging quietly.
• Naming and description standards — enforced conventions for field names, labels and descriptions, because the field picker is the documentation most users will ever read.
• The git repository and branching model — where the code lives, who can merge, and how your team will work in it after the engagement closes.

Aggregate awareness, derived tables and query budgets

Looker generates SQL and sends it to your warehouse, so every performance problem is ultimately a warehouse query problem with a Looker-shaped cause. Aggregate awareness is the main lever: you define pre-aggregated tables at coarser grains, and Looker automatically rewrites an incoming query to use the smallest table that can answer it. A dashboard asking for monthly revenue by region hits a small summary table rather than scanning the full transaction history. The users see nothing except a faster result, which is precisely the point — performance design should not require the business to know which table to pick.

Persistent derived tables, or PDTs, are queries materialised into the warehouse on a schedule or a trigger. They are the right answer for expensive intermediate results that several explores share, and the wrong answer when used to hide modeling work that belongs upstream, because every PDT adds build time, storage cost and a dependency that can fail overnight. Set a query-time budget early — for example, dashboard tiles under ten seconds and ad-hoc explores under thirty — then treat breaches as defects with a specific cause. Without a stated target, performance quietly degrades until users stop opening the dashboards and nobody can point to when it happened.

Performance levers roughly in order of payoff

• Fix the underlying tables first — partitioning, clustering and sensible grain in the warehouse beat anything you can do in LookML, because Looker only forwards the query.
• Add aggregate awareness for the repeated questions — the handful of dashboards opened daily justify purpose-built summary tables far more than rarely used explores do.
• Tune caching policies per explore — datagroups tie cache expiry to when the data actually reloads, rather than to an arbitrary interval that either serves stale numbers or rebuilds needlessly.
• Restrain default dashboard filters — an unfiltered date range on a large fact table is the single most common cause of a slow dashboard.
• Review PDT build dependencies — chained derived tables create long serial build times and a single failure point that shows up as empty dashboards in the morning.
• Watch the query history — Looker's own system activity data shows the slowest and most frequent queries, which is where tuning effort actually belongs.

Why content multiplies, and what actually stops it

Sprawl is not a discipline failure by users; it is a search and trust failure. Somebody needs a slightly different view, cannot find the existing dashboard or cannot tell whether it is maintained, so they build another. Six months later there are four dashboards named some variation of weekly performance, and the least reliable one is the most widely shared. The fix is structural. Curated folders with clear ownership, a small set of certified dashboards that are visibly maintained, and personal drafts kept in personal spaces rather than promoted informally into shared ones.

Content needs a lifecycle as well as a home. Looker records usage, so unused content can be identified and archived on a regular cadence rather than accumulating indefinitely. Certification should mean something specific: an owner, a defined refresh, a stated definition for each metric, and a review date. Explores need the same restraint — a small number of well-described explores with curated fields will be used correctly far more often than a large number covering every table. Ask any prospective partner how they intend to prevent sprawl, because a proposal measured in dashboards delivered is a proposal that creates it.

Measuring adoption as decisions supported

• Recurring use by role — whether the people the content was built for open it in their normal working week, rather than total view counts across the instance.
• Content that replaced something — the reports, spreadsheets or manual extracts formally retired because a Looker dashboard now serves that need.
• Question depth — whether users move from viewing a dashboard to drilling into an explore, which indicates the model answers follow-up questions rather than only the first one.
• Certified share of traffic — the proportion of views landing on governed content versus personal copies, which tells you whether governance is working or being routed around.
• Time from question to answer — how long a new, unanticipated business question takes to answer with the existing model, which is the clearest test of whether the model was built well.

A promotion path for model changes

Because LookML is code, changes should move through a path rather than being edited in place. Developers work in a personal branch in development mode, where changes are invisible to users. Looker's own validators check LookML syntax, SQL generation and content integrity, the last of which catches the common and painful failure where renaming a field silently breaks dashboards depending on it. Changes are reviewed in a pull request, merged, and deployed to production deliberately. None of this is exotic, but it has to be set up and, more importantly, your team has to be comfortable operating it once the partner leaves.

Two practices make the difference in an environment where several people develop at once. First, treat a metric definition change as a release with a note, because a measure quietly redefined on a Tuesday will be discovered as a broken trend line on a Friday. Second, use separate development and production database connections where your warehouse allows, so PDT builds during development do not compete with production dashboard traffic for the same compute. Agree how frequently deployments happen and who approves them, because the practical risk in Looker is not downtime but a definition changing under a report someone has already acted on.

Embedded and customer-facing analytics

Embedding Looker inside your own product or a customer portal is a different engineering problem from internal reporting, and it is worth scoping separately. The central mechanism is user attributes: values passed in at embed time that drive access filters, so a customer sees only their own rows from a shared model. That filtering must be enforced in the model through access filters and row-level controls, never by passing a parameter the browser could alter. Signed embedding handles authentication without your customers holding Looker accounts, and the signing logic lives in your application backend.

Then consider load. Internal reporting is bounded by headcount; an external deployment scales with your customer base, so concurrency, caching and warehouse cost behave differently and need modeling before launch rather than after. Theming and interaction design also matter more, because the analytics has to look and behave like part of your product. Licensing for embedded users is priced differently from internal users, so establish it early. Ask for a worked example of an existing embedded deployment: the combination of tenant isolation, performance at concurrency and product-grade presentation is a genuinely distinct skill set.

Programs rarely stop at one product. Buyers hiring for Looker often pair it with BigQuery partners , Campaign Manager 360 partners or Display & Video 360 partners , or review the whole Google Cloud landscape before committing.