Looker Business Analyst common mistakes
Looker Business Analyst · Understand the traps and how to avoid them.
Treating Looker as a pure SQL-reporting tool and answering questions about dashboards, Explores, and Looks without distinguishing which layer (database, LookML model, Explore, tile) owns a given behaviour, so questions about where a filter or calculation actually executes get answered by intuition rather than by layer.
Candidates coming from BI tools where the semantic layer is thin assume Looker queries are ad hoc SQL the user writes; they never internalise that LookML generates the SQL and that users interact only with fields, so they misattribute capabilities (e.g. assuming users can write arbitrary SQL in an Explore, or that a dashboard tile can join tables the Explore does not join).
What to do instead
Before answering, classify the question by layer: warehouse (raw tables, SQL dialect), LookML project (views, models, Explores, joins, dimensions, measures), Explore UI (field picker, filters, pivots), or presentation (Looks, dashboards, tiles). For each option, ask which layer would have to change for it to be true. Practise by taking one metric and writing down the four layers it touches.
Confusing dimensions and measures when reading LookML or predicting Explore behaviour, for example expecting a dimension to aggregate, expecting a measure to appear as a group-by option, or assuming a numeric-looking dimension is automatically summable.
Both are declared with similar syntax and both appear in the field picker, and the type keyword (string, number, yesno, sum, count, average) is what actually determines behaviour. Candidates skim the SQL parameter and ignore type, then reason from the column's data type in the warehouse instead of from LookML.
What to do instead
For every field, read three things in order: the declaration (dimension vs measure), the type, and the sql. Memorise the consequence: dimensions supply group-by and filter values; measures supply aggregates and are computed after grouping. When a question hinges on aggregation, locate the measure and check whether its type matches the aggregation the question describes.
Assuming a join declared in the model applies to every Explore, or that adding a view to a project makes its fields available everywhere, leading to wrong answers about why a field is missing from an Explore or why fan-out is or is not occurring.
Views are reusable definitions while Explores are the curated join graphs users actually query. Because both live in the same project files, candidates conflate 'defined' with 'exposed'. Fan-out questions compound this: the join relationship (many_to_one, one_to_many) is declared on the join, not on the view, so it is easy to overlook.
What to do instead
Trace the path: project file, model file, explore block, join blocks, then each joined view's fields. If a field is absent from an Explore, check whether its view is joined in that Explore (and whether fields are hidden or excluded). For fan-out questions, find the join's relationship parameter and reason about row multiplication from there before considering symmetric aggregates.
Choosing a visualization type by aesthetic preference rather than by the question the chart must answer, for example using a pie chart for many categories, a line chart for unordered categories, or a table when a single headline number is wanted, and then failing scenario items that ask which visualization best communicates a given comparison or trend.
Exam items describe a business question and a dataset shape, but candidates pattern-match on familiar chart names instead of decoding the question type (trend over time, comparison across categories, part-to-whole, distribution, correlation, single value) and the cardinality of the dimension.
What to do instead
Classify the question first: trend, comparison, composition, distribution, relationship, or single KPI. Then apply cardinality and ordering rules: time dimension on the x-axis for trends, bar for ranked comparison, line only for continuous progression, pie or stacked bar only for a few parts of a whole, single-value or gauge for one KPI. Rehearse by writing the question type next to each option before eliminating any.
Treating dashboard filters, tile-level filters, and Explore filters as interchangeable, and therefore mispredicting which filters constrain which tiles or why a filter appears greyed out or does not affect a tile.
Looker dashboards have their own filter layer that must be mapped to fields on each tile, and a filter only reaches a tile whose query includes a compatible field. Candidates who have only used Explore filters assume dashboard filters apply globally by name, and they overlook that a tile built from a different Explore or a different field will not respond.
What to do instead
For any dashboard-filter question, identify the tile's source Explore and the exact field the tile uses, then check whether the dashboard filter is mapped to that field (directly or via a custom filter / alias). Remember that a filter with no matching field on a tile simply does not constrain it. When studying, build one dashboard with two tiles from different Explores and map a single filter to both to see the mechanics.
Reading a result set at face value without checking whether row counts, totals, or percentages are distorted by joined data, missing values, or the chosen aggregation, and then selecting an answer that describes the wrong cause of an unexpected number.
Looker results reflect the SQL that LookML generated, including joins and symmetric aggregates. Candidates who do not inspect the generated SQL or the join relationships blame the visualization or the filter when the real cause is duplicate rows from a one-to-many join, null handling in a dimension, or a count of rows versus a count of distinct values.
What to do instead
When a number looks wrong, run a fixed diagnostic order: (1) check the join relationships on the path to the measure, (2) check whether the measure counts rows or distinct entities, (3) check for nulls and unexpected filter values in the dimension, (4) inspect the generated SQL to confirm what was actually executed. Answer questions about anomalies by naming the earliest layer in that order that explains the discrepancy.
Confusing content organisation and access mechanisms, for example assuming a folder permission grants data access, that a board is the same as a dashboard, or that sharing a link bypasses the model's access controls, and then answering governance items with the wrong control.
Looker separates several concerns that all sound like 'sharing': content organisation (folders, boards), delivery (schedules, alerts), and data access (model sets, permission sets, roles, access filters). Candidates learn the feature names but not which concern each one governs, so they pick a plausible-sounding but wrong mechanism.
What to do instead
Build a two-column map: 'controls who can see which content' versus 'controls which rows or fields a user can query'. Folder and board permissions belong to the first; roles, model sets, permission sets, and access filters belong to the second. For any governance question, decide which of the two the scenario is about before evaluating options, and remember that content permissions never widen data access.
Answering LookML syntax items from memory of SQL rather than from LookML's own rules, for example mixing up the roles of sql_on and foreign_key in a join, or expecting a derived table's SQL to be a saved database view.
LookML deliberately resembles SQL in places, so candidates substitute SQL intuitions: they assume join conditions are always written explicitly (ignoring foreign_key), or that a derived table must exist in the warehouse (it is generated at query time unless persisted). The surface similarity masks different semantics.
What to do instead
Learn each parameter by what it replaces: foreign_key and primary_key let Looker infer the join condition, while sql_on states it explicitly; derived tables are LookML-defined subqueries, and persist_for or a persistent derived table changes caching, not definition. Keep a short table of parameters with a one-line 'what it controls' note and review it before the exam rather than re-deriving from SQL.
Ignoring how the chosen dimension granularity and pivots change the shape of results, then misreading what a pivot row or column represents and picking an answer that confuses a pivot value with a filter or a total.
Pivoting moves a dimension from rows to columns, so the same query produces a different table layout. Candidates who mentally model results as flat rows misread pivoted output, and they also forget that totals and row limits behave differently once pivots are involved.
What to do instead
Before interpreting any result described in a question, write down the query shape: which dimensions are on rows, which are pivoted, which measures are aggregated, and whether totals are enabled. Then read the described output against that shape. Practise by running the same Explore with and without a pivot and noting how the row count and totals change.
Skipping the stem's constraints and answering the general case instead of the specific one, for example recommending a modelling change when the question asks what an end user can do in the UI, or recommending a UI workaround when the question asks for the durable model-level fix.
Many items present a realistic scenario with a stated role (analyst, developer, admin) and a stated constraint (no LookML access, must be reusable, must apply to all users). Candidates recognise the topic, retrieve the most familiar fact, and never check it against the role and constraint, which is exactly what the item is testing.
What to do instead
Underline the actor and the constraint in every stem before looking at options. Then filter options twice: first by who is allowed to do it, second by whether it satisfies the stated requirement (reusable, immediate, applies to everyone). Eliminate any option that solves the problem at the wrong layer or for the wrong role, even if the technique itself is correct.