Looker Business Analyst study materials
Looker Business Analyst study resources

Lumen Stream: One Metric, Four Definitions, Rising Query Cost

Looker Business Analyst · Put your knowledge to work in context.

All case studies

Lumen Stream: One Metric, Four Definitions, Rising Query Cost

Lumen Stream is a subscription media company with 320 Looker users, 25 of whom build content. Three LookML projects have grown organically: Marketing, Finance, and Product. There are 700 saved Looks and 62 dashboards. The metric 'Monthly Active Subscribers' appears in four places with different logic: Finance counts paid accounts with a current billing status; Product counts distinct device sessions in the last 30 days; Marketing uses a SQL Runner query copied into a dashboard. Eighteen dashboards mix these definitions. After a reorg, the new VP of Data asks for a single metric layer and a 30-day cleanup plan. Meanwhile, cloud warehouse spend is up 35% quarter over quarter. Twenty-two dashboards refresh every 15 minutes, and several are viewed only once a week. The team has four LookML developers, one part-time Looker admin, and no formal content ownership model.

1. What should the team do first to resolve the conflicting 'Monthly Active Subscribers' definitions, and how should ownership be assigned? Explain the trade-offs.

Read the worked answer

Start with a definition workshop, not a LookML sprint. Finance, Product, and Marketing should agree that two different questions are being asked: paid subscriber count and streaming engagement. Forcing one metric would make one team wrong. Define 'Paid Active Subscribers' as distinct accounts with an active billing status, owned by Finance, and 'Active Streaming Devices' as distinct devices with a session in the last 30 days, owned by Product. Marketing's SQL Runner copy should be retired because it cannot be governed or validated. Build the canonical measures once in a shared LookML project, then expose them to departmental models with extends and refinements rather than copying SQL. Give each metric a business owner and a named LookML maintainer. Use label and description to state the definition, including exclusions. Deprecate old fields in stages: mark them 'DEPRECATED - use Paid Active Subscribers', update high-usage dashboards, then hide them after content validation shows no references. The trade-off is short-term dashboard churn versus long-term trust; two clearly named metrics are better than one misleading number.

2. The VP wants to cut warehouse spend without breaking executive dashboards. Propose a concrete sequence of Looker changes, with reasoning about caching, schedules, and user experience.

Read the worked answer

Measure before cutting. Use System Activity to list dashboard and Look scheduling frequency, runtime, and viewers. The 22 dashboards refreshing every 15 minutes are the first target, but do not simply turn everything off. Classify them by freshness need: operational dashboards may need 15-30 minutes; executive reviews usually need hourly or daily data. Consolidate duplicate schedules and replace fixed-frequency refreshes with a datagroup aligned to the warehouse load. Set max_cache_age to a defensible interval, such as one hour for executive dashboards, and use datagroup_trigger for persistent derived tables so they rebuild only when source data changes. Turn off automatic dashboard refresh where viewers open a dashboard and read it once; keep 'Run on load' for the few dashboards used in live meetings. Convert rarely viewed daily PDFs into links or weekly schedules. Sequence matters: remove duplicate schedules first, then set caching and datagroups, then optimize expensive Explores with derived tables or aggregate awareness. Validate that the executive numbers still match Finance after each change, and publish a freshness statement so users know what to expect.

3. How should the team organize content and permissions so that this cleanup does not regress? Specify folders, boards, validation, and developer workflow.

Read the worked answer

Create a content architecture that makes the right thing easy to find. Use domain folders such as Finance, Product, and Marketing, plus a small 'Certified Metrics' folder or board for executive content. Put only governed dashboards on the executive board; leave exploratory Looks in team folders. Manage permissions through groups and model sets, not individual folder grants, so a new analyst inherits the correct access. Keep production LookML in Git with development and production modes; require pull requests and at least one reviewer for changes to shared views or measures. Add content validation as a release gate: validate affected dashboards and schedules against the updated model before deploying. Use refinements to add departmental fields without forking the shared view. Assign a dashboard owner in the description and review usage quarterly via System Activity. Track leading indicators: content validation errors, number of dashboards using deprecated fields, duplicate schedule count, and percentage of executive dashboards with named owners. Without ownership and validation, the same metric sprawl will return within a quarter.