Netflix Business Intelligence Analyst Interview Preparation Guide (Mid-Level)

Direct answer

WHERE filters individual rows before any grouping happens; HAVING filters groups after aggregation. If a condition references a raw column, it goes in WHERE (cheaper, filters early). If it references an aggregate like COUNT(*) or SUM(...), it has to go in HAVING, because that aggregate value doesn't exist yet at the row level.

Approach

1. Filter to the rows you care about first, in WHERE, so fewer rows ever reach GROUP BY.
2. Aggregate with GROUP BY.
3. Filter the resulting groups in HAVING, using conditions on the aggregate values.

Swapping them either breaks the query (most engines reject an aggregate function in WHERE) or, if you write a WHERE-style row condition into HAVING instead, it still works but wastes work: rows get grouped and aggregated before being thrown away, instead of being excluded up front.

Worked example (sqlite3, verified)

Sample data:

CREATE TABLE orders (order_id INTEGER PRIMARY KEY, customer_id INTEGER, amount INTEGER, created_at TEXT);

INSERT INTO orders VALUES
  (1, 1, 40, '2024-01-05'),
  (2, 1, 60, '2024-02-10'),
  (3, 1, 20, '2023-12-01'),  -- before 2024
  (4, 2, 15, '2024-03-01'),
  (5, 2, 25, '2024-03-15'),
  (6, 2, 10, '2024-04-01'),
  (7, 2, 5,  '2024-04-10'),
  (8, 2, 30, '2024-05-01'),
  (9, 2, 45, '2024-05-20'),
  (10, 3, 100, '2024-01-01'),
  (11, 3, 200, '2024-02-01');

Query 1, WHERE only (row-level filter to 2024 orders):

SELECT order_id, customer_id, amount, created_at
FROM orders
WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01'
ORDER BY order_id;

Result: 10 rows (every order except order 3, which is dated 2023-12-01 and correctly excluded before any aggregation happens).

Query 2, HAVING only (group-level filter, all-time, customers with more than 5 orders):

SELECT customer_id, COUNT(*) AS order_count, SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id
HAVING COUNT(*) > 5;

Result: exactly 1 row, (2, 6, 130). Customer 2 has 6 orders across all time; customers 1 and 3 (3 and 2 orders respectively) are dropped because their group-level COUNT(*) fails the HAVING test, not because any individual row was filtered.

Query 3, both together (2024 orders, then customers with more than 1 order in that window):

SELECT customer_id, COUNT(*) AS order_count_2024, SUM(amount) AS total_amount_2024
FROM orders
WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01'
GROUP BY customer_id
HAVING COUNT(*) > 1
ORDER BY customer_id;

Result: (1, 2, 100), (2, 6, 130), (3, 2, 300). Order 3 (customer 1, pre-2024) was excluded by WHERE before counting, so customer 1's order_count_2024 is 2, not 3.

Key points

• WHERE runs before GROUP BY conceptually; it can never see COUNT(*), SUM(...), or any other aggregate.
• HAVING runs after GROUP BY; it can reference aggregates, and it can also reference a non-aggregated column that appears in GROUP BY, but doing that in HAVING instead of WHERE is just slower for no benefit.
• Putting a row-level condition in HAVING isn't a syntax error, it's a performance mistake: the engine groups and aggregates rows it could have discarded earlier.

Complexity, edge cases & pitfalls

• Cost: a WHERE clause on an indexed column can use that index to skip rows entirely; a HAVING clause always runs after a full GROUP BY pass, so it can't reduce the aggregation work itself, only the number of groups returned.
• HAVING without GROUP BY is legal in most engines (SQLite included) and treats the whole table as a single group, so it just decides whether to return that one aggregate row or nothing.
• Aggregate functions are not allowed directly in WHERE; using one there is a syntax/semantic error in standard SQL because WHERE evaluates per row, before any aggregate exists.
• Watch NULLs inside the aggregate itself: SUM(amount) and COUNT(*) behave differently if amount can be NULL (COUNT(*) still counts the row, SUM just skips the NULL), which can make a HAVING threshold pass or fail unexpectedly if you didn't account for missing values.

I would first separate disagreement on the outcome from disagreement on the method. Then I would bring the executives into a short decision session with a one-page brief: the business goal, the options, the trade-offs, and the decision needed. I would make decision rights explicit using RACI, which means Responsible, Accountable, Consulted, and Informed. That way, everyone knows who recommends, who decides, and who simply needs to stay informed.

For example, if one sponsor wants speed, another wants cost savings, and a third wants risk reduction, I would ask which metric is the tie-breaker if they conflict. I would propose a shared scorecard with 2 or 3 measures, such as revenue impact, operational risk, and delivery date, then ask the accountable executive to make the final call in writing.

While the debate is happening, I would keep teams executing on work that is not dependent on the unresolved choice, pause only the parts that could be wasted, and communicate a clear interim plan. The goal is to prevent thrash, protect momentum, and get everyone back to one set of success criteria.

For example, on a customer-onboarding automation initiative, three executives disagreed about halfway through: the VP of Engineering wanted to prioritize system reliability given a recent outage, the VP of Finance wanted to prioritize cost savings from reduced manual onboarding labor, and the VP of Risk wanted to prioritize compliance controls given a pending audit. In the decision session, the RACI mapping made the VP of Product the accountable decision-maker, with all three VPs as consulted. The proposed scorecard used three metrics: onboarding error rate (tied to reliability), manual labor hours saved per month (tied to cost), and number of unresolved audit findings (tied to risk). The accountable VP decided that the audit-findings metric was the tie-breaker for this quarter, since the audit deadline was fixed and immovable, while the reliability and cost metrics would be weighted equally starting the following quarter. While that decision was being finalized in writing, the teams kept building the shared onboarding data pipeline, which every option needed regardless of the outcome, and paused only the specific reporting dashboard whose design depended on which metric ultimately won.

Direct answer

An actionable metric ties directly to a decision: when it moves, someone knows what to change, and the metric resists being inflated without a real underlying improvement. A vanity metric looks impressive in a headline but doesn't tell anyone what to do differently, because it aggregates away the behavior that actually matters. The distinction is about what the number can trigger, not how big or small it is.

Structured elaboration

Converting a vanity metric into an actionable one. Total registered accounts becomes actionable once it is turned into an activation rate: the percentage of new signups who complete a defined core action within a set window (say, 7 days), segmented by acquisition channel. The raw count cannot tell you where to invest; the segmented activation rate can.

Worked example

Total signups versus activation rate. This month, 1,000 new accounts are created (the vanity headline). Segmented by channel and measured against a 7-day core-action window:

$\frac{100 + 250}{500 + 500} = \frac{350}{1{,}000} = 35\%$

"1,000 new accounts" alone hides that paid-ad signups activate at less than half the rate of organic ones; that split is what actually tells a team where to reallocate onboarding effort or acquisition budget, not the total.

Gross new MRR versus net MRR growth. This month, gross new MRR booked is $50,000, but churned and contracted MRR over the same period is $42,000:

$\text{Net MRR growth} = \$50{,}000 - \$42{,}000 = \$8{,}000$

Reporting the $50,000 figure alone as "growth" implies a business expanding at that pace, when the net figure is $8,000, about 16% of the gross number:

$\frac{8{,}000}{50{,}000} = 16\%$

Trade-offs & pitfalls

Over-rotating entirely to actionable metrics can leave a real gap: raw signup counts and brand-reach numbers still have a legitimate use in board reporting or fundraising narratives, just not as a product-decision input. The more common failure is choosing a metric that looks actionable but is still gameable, for example an "activation" event defined so loosely (any click after signup) that it can be hit without any real engagement; the fix is the same discipline used to convert total signups above, define the action precisely enough that improving the metric requires improving the real experience. Finally, watch for a metric that is actionable in isolation but gets read in a vacuum: net MRR growth without a churn breakdown can mask a retention problem that a growing new-bookings number is quietly compensating for.

Approach (cost–impact matrix): I’d map each request on a 2x2 matrix: Impact (business value / legal/regulatory severity) vs Implementation Cost (time, engineering effort, operational overhead). High-impact / low-cost items get top priority; high-legal-risk items are treated as “impact” with near-zero tolerance.

Inputs to collect:

• Legal risk: regulatory requirements, liability, fines, and Legal’s rationale for 100% masking.
• Business impact: revenue/profit uplift or experiment value from raw PII (product), and Sales’ revenue dependence on daily email lists.
• Implementation cost: engineering effort to mask/unmask, gating, access controls, ETL changes.
• Time-to-value: how quickly each stakeholder needs results.
• Security controls available: encryption, role-based access, audit logs, DLP.
• Alternatives: hashed identifiers, tokenization, consent status.

Assessment example (matrix summary):

• Legal 100% masking → Very high legal risk (top-left: high impact), medium cost to enforce globally.
• Product raw PII → High business impact but moderate legal risk if controlled (top-right).
• Sales daily emails → Medium business impact, low cost if already available (bottom-right).

Pragmatic resolution:
Short-term (days–weeks)

• Pause any broad release that violates Legal.
• Implement role-based access: provide Product and Sales with minimized PII views via tokenization or hashed IDs where possible.
• For Sales, provide a vetted daily extract that contains emails only when consent/contract allows; require approval and audit trail.
• For Product experiments, deliver a secure staging dataset with strict access, pseudonymized keys, and a documented Data Use Agreement (DUA).

Long-term (weeks–months)

• Build an access-controlled PII service: central tokenization, dynamic masking, audit logging, consent flags.
• Update BI/ETL pipelines to support attribute-level masking policies and feature flags for experiments.
• Formalize governance: data classification, approved use-cases, SLAs, and escalation flow between Legal/Product/Sales.
• Automate compliance checks and dashboards showing data access, consent, and risk.

Why this works:

• Respects legal non-negotiables while minimizing business disruption.
• Provides Product and Sales controlled, auditable ways to access needed data quickly.
• Invests in infrastructure and governance to avoid recurring conflicts and scale safely.

Direct answer

I take on a stretch assignment when the upside is real and I have a concrete plan for closing the specific gaps rather than just confidence that it'll work out. I close those gaps in parallel with actually doing the work, ask for help on the exact piece I'm missing rather than vaguely, and I use how it turns out to decide what to go after next, not just as a story that ends when the project ships.

Structured elaboration

• Decide whether to take it on. I weigh what's genuinely new against what's actually adjacent to things I already know, whether a mistake here would be recoverable, and whether there's someone I could turn to if I got truly stuck, before saying yes.
• Name the specific gaps up front. Not a vague feeling of nervousness, but a short list of the particular things I don't yet know how to do, split into what I can pick up just-in-time on my own and what genuinely needs someone more experienced.
• Ask for support surgically. Rather than a general "let me know if I need help," I ask for something specific: a fixed block of a senior colleague's time on the one hard part, or a review at a particular checkpoint, so the ask is easy to say yes to and actually gets me what I need.
• Make decisions under real uncertainty by keeping them reversible where I can. When I'm not sure yet, I favor choices I can undo, and I flag the specific things I'm still unsure about to whoever's relying on the outcome, rather than presenting more confidence than I actually have.
• Let the outcome change what I go after next. Whether it went well or only partly well, I use it to recalibrate: what did I learn I'm actually capable of, and what specific thing should I deliberately go looking for next because this one exposed it as a real gap or a real strength.

Worked example

Early in a role, I was asked to take primary ownership of a technical evaluation for a large prospective customer, something I hadn't done before since I'd mostly supported more senior colleagues on similar calls. I took it on because the downside was recoverable (a more senior person was still one message away) and because the specific gap was narrow: I understood our product well, but I'd never had to run the whole evaluation conversation myself, including handling pushback in the room. I asked a specific colleague for thirty minutes beforehand to walk through how they usually handled the two hardest objections we tended to get, rather than asking generally for "advice." During the evaluation itself, I hit a technical question I genuinely didn't know the answer to, and rather than guessing, I said plainly that I'd confirm and follow up by end of day, which the customer accepted without issue. It closed successfully, and afterward I realized the part that had actually gone well wasn't the product knowledge, it was staying composed when I didn't know something, which told me the next stretch I should look for was one that put me in front of harder, more adversarial conversations rather than more technical depth.

Trade-offs and pitfalls

The risk on one side is taking on stretch work recklessly, with no way to recover if it goes wrong and nobody to turn to, which can do real damage rather than build a genuine capability. The risk on the other side is treating any unfamiliar work as too risky and never stretching at all, which just keeps you at the same level. The other common mistake is hiding uncertainty from the people relying on the outcome instead of flagging it, and treating the assignment as a one-off story rather than letting it actually inform what you deliberately go after next.

Direct answer. The most plausible causes are that the two connections are actually hitting different underlying data (a lagging or differently-tuned replica), that the replica's statistics are stale relative to the primary's, or that a configuration difference between the two (memory settings, cost parameters) leads the same query to a genuinely different plan; isolate which one by comparing statistics freshness, configuration, and data currency between the two connections directly, rather than assuming the query itself is the variable.

Structured elaboration. Start by confirming the two connections are even hitting the same DATA: replication lag means a replica can be seconds, minutes, or more behind the primary, and while that usually doesn't change PLAN shape by itself, it's worth ruling out as a confounding factor before you go further, since a stale replica muddies any comparison you make. Next, compare statistics freshness on the specific tables involved: if the replica's statistics were refreshed at a different time (or on a different schedule) than the primary's, or if statistics don't replicate identically depending on your engine's replication mechanism, the two connections can genuinely be planning from different information even though the underlying schema and data are notionally "the same." Finally, compare configuration directly: a replica provisioned with different memory settings, different cost-model parameters, or even a different engine version can lead an otherwise-identical query to a genuinely different, and genuinely differently-optimal, plan.

Worked example. A replica whose statistics job runs on a different, less frequent schedule than the primary's is a very plausible explanation on its own: if the primary was recently ANALYZE'd after a data shift but the replica hasn't caught up yet, the replica's optimizer is working from an older picture of the data than the primary's, which can easily produce a different (and worse) plan for the identical query text.

Trade-offs and pitfalls. Resist jumping straight to "the replica's hardware must just be slower," which is possible but is a much less common actual cause than a genuine statistics or configuration difference, and treating it as the default explanation without checking the more likely causes first can send you chasing an infrastructure upgrade that wouldn't have fixed the real problem.

1. Clarify scope & reproduce

• Ask: same user region/browser? Interactive vs initial load? Scheduled extract refreshes running at load time?
• Reproduce: open dashboard with Performance Recorder in Tableau Desktop and on Tableau Server (or use Server Resource Monitoring / VizQL logs).

2. Identify bottleneck (DB vs client vs server)

• DB-bound signs: long query times in Performance Recorder / VizQL (Query time >> Rendering time), slow SQL in database profiler, CPU/waits on DB host.
• Client/server-bound signs: long “Rendering” or “Processing” times, many marks, heavy JavaScript/CSS, VizQL worker high CPU, network latency high but DB queries fast.
• Tools: Tableau Performance Recorder (shows Query, Compute, Rendering, Client Time), Tableau Server Admin Views, DB slow query logs, network trace.

3. Deep-dive diagnostics

• Capture performance recording for cold and warm loads (first vs repeat).
• Inspect top queries: check full-table scans, missing indexes, large sorts, cross-database joins, high row counts returned.
• Check number of marks, complex table calculations, LODs, nested quick filters, and dashboard actions causing full reloads.

4. Optimization plan (database)

• Create aggregated tables or materialized views matching dashboard grain.
• Add/selective indexes; avoid SELECT *; push computations to DB if set-based and more efficient.
• Replace expensive cross-DB joins with pre-joined extracts or consolidated schema.
• Consider read replica for analytics or query warehouses (Redshift, BigQuery, Snowflake).

5. Optimization plan (Tableau)

• Use extracts (Hyper) rather than live if queries are heavy and data freshness tolerates it. Use incremental refresh to limit extract size.
• Apply extract filters (date ranges, relevant dimensions) and hide unused fields to reduce extract footprint.
• Use context filters to limit data scanned by dependent quick filters (set only 1 context filter).
• Reduce quick filters: replace many single-value quick filters with parameter controls, cascading filters, or a single filter with search.
• Limit marks: use aggregated charts (don’t plot row-level if not needed), pagination for tables, use BINs or Top N.
• Simplify calculations: precompute heavy table calcs/LOD in DB or extract; avoid row-level calculated fields that force row scan.
• Minimize dashboard objects and sheets: consolidate multiple similar sheets with parameter-driven views; use tiled layout to reduce redraws.
• Disable “Show all values” for filters that cause large queries; set filter to only relevant values.
• Tune workbook: remove unused fields, reduce custom SQL, avoid multiple data sources when possible, use published data sources.
• Use Tableau Server caching settings and schedule extracts off-peak; enable Query Caching where safe.

6. Quick wins (apply immediately)

• Turn high-cardinality quick filters into parameters or search boxes.
• Convert heavy live connection to an extract for the dashboard only.
• Hide unused fields and publish a cleaned, published data source.
• Make the default view use a short date window (last 30/90 days) so initial queries are small.
• Replace table visual showing millions of rows with aggregated summary plus drill-through.
• Precompute common aggregates/materialized views.

7. Measure & iterate

• After each change, re-run Performance Recorder and compare times. Prioritize changes with highest time reductions for lowest effort.
• Document changes, schedule extract refreshes, and add monitoring (alerts on query time or server CPU).

Trade-offs

• Extracts improve speed but add freshness lag and storage.
• Context filters speed dependent filters but add maintenance complexity.
• Pre-aggregations reduce flexibility (less ad-hoc slicing).

This systematic approach finds where time is spent, applies targeted DB or Tableau fixes, and uses quick wins to reduce the 90s load toward sub-10s interactive performance.

A TIMESTAMP column includes a time-of-day component, so a date-only BETWEEN upper bound like '2024-03-31' is treated as midnight at the start of that day, silently excluding every row later that same day; a half-open range using the next day's start avoids the gap.

Structured elaboration

-- Misses late-March-31 rows
SELECT order_id FROM orders WHERE created_at BETWEEN '2024-03-01' AND '2024-03-31';
-- Correct half-open range
SELECT order_id FROM orders WHERE created_at >= '2024-03-01' AND created_at < '2024-04-01';

BETWEEN '2024-03-01' AND '2024-03-31' is shorthand for >= '2024-03-01' AND <= '2024-03-31', and that upper bound, when compared against a TIMESTAMP, is interpreted as 2024-03-31 00:00:00. Any row timestamped later that same day (say, 2024-03-31 23:00:00) is strictly greater than midnight and gets excluded, even though it clearly belongs in "March 2024" by any reasonable interpretation.

Worked example

Given orders at 2024-03-31 23:00:00 and 2024-03-15 10:00:00: the BETWEEN version returns only the March 15 order, silently dropping the March 31 order entirely. The half-open version (< '2024-04-01') correctly returns both orders.

Trade-offs and pitfalls

The half-open-range fix generalizes to any period boundary (a single day, a month, a quarter, a year): always express the upper bound as "the start of the next period, exclusive" rather than "the last moment of this period, inclusive", since the latter requires knowing the column's precision exactly (is it seconds? milliseconds? does '2024-03-31 23:59:59' actually cover a row at '2024-03-31 23:59:59.500'?) while the former never does. This same half-open form is also what makes the query index-friendly, which the question asks for by name: created_at >= '2024-03-01' AND created_at < '2024-04-01' compares the raw created_at column directly against two literal bounds, exactly the shape a B-tree index (the default index structure in most relational engines, storing column values in sorted order) on created_at can use for a plain range scan. A common alternative fix, wrapping the column instead of the bound, e.g. WHERE DATE(created_at) BETWEEN '2024-03-01' AND '2024-03-31' or CAST(created_at AS DATE) = ..., looks similarly correct but applies a function to every row's created_at value before comparing it, which prevents a plain index on created_at from being used at all, since the engine can no longer look up sorted values directly and instead has to compute the expression for every row. Keeping the column bare on one side of a plain comparison is what index-friendly means in practice.

Direct answer
A semantic layer is a translation layer that sits between raw warehouse tables and the tools people use to consume data. It defines metrics, dimensions, hierarchies, and business rules once, in one place, so that a dashboard in one BI (business intelligence) tool and a dashboard in a different BI tool compute 'revenue' or 'active users' the exact same way. Without it, every report author writes their own SQL, and small differences (a different filter, a different join, a different definition of 'active') silently produce different numbers for the same-sounding metric.

Structured elaboration
What it typically exposes to consumers:

• Metrics: named, versioned calculations (e.g. net_revenue = sum(amount) - sum(refunds)), not raw columns.
• Dimensions and hierarchies: the ways a metric can be sliced (region rolling up to country rolling up to sales org), defined once so 'region' means the same thing everywhere.
• Access rules: which rows or columns a given consumer is allowed to see, applied consistently regardless of which tool queries through it.
• Pre-approved custom calculations: a mechanism for an analyst to build something new without duplicating the base metric logic.

How it connects to the warehouse: the semantic layer does not usually store data itself. It holds a model (joins, grain, metric expressions) and compiles a request from a BI tool ("give me net_revenue by region for last quarter") into the actual SQL that runs against the warehouse. The warehouse remains the source of truth for data; the semantic layer is the source of truth for what the data means.

How it keeps two BI tools consistent: both tools query the same semantic layer instead of each maintaining its own copy of the metric logic. If Tableau and Power BI both ask for net_revenue, they get it from the identical compiled definition, not from two independently-written queries that happen to look similar. When the definition changes (say refunds now exclude a new fee type), it changes once and both tools pick it up automatically on their next query, instead of someone having to remember to update two calculated fields in two different tools.

Worked example
Imagine net_revenue is defined once in the semantic layer as: gross order amount, minus refunds, minus disputed chargebacks, at the order-line grain, rolling up through product to product-category to business-unit. An executive dashboard in Power BI asks for net_revenue by business_unit for Q1, and an analyst's ad-hoc exploration in Looker asks for net_revenue by product for the same window. Both queries compile down to the same underlying expression (sum(amount) - sum(refund_amount) - sum(chargeback_amount)), just aggregated to different grains. If someone later discovers refunds should also exclude store-credit reversals, that's one change to the metric definition; both tools reflect it the next time they query, and nobody has to hunt down every dashboard that independently reimplemented 'revenue.'

Trade-offs and pitfalls
A semantic layer is only as trustworthy as its governance: if anyone can add a metric with a name that collides with an existing one, or edit a definition without review, you've just moved the inconsistency problem instead of solving it, which is why most real implementations pair the semantic layer with certified/reviewed definitions and change control. It also adds a layer of indirection: debugging why a number looks wrong now means checking the semantic layer's compiled query, not just the dashboard's visible formula, which can slow down troubleshooting if the team isn't used to it. Finally, a semantic layer that tries to model everything up front becomes a bottleneck; most successful ones start with a small set of high-value, widely-disputed metrics (revenue, active users) and expand rather than modeling the entire warehouse on day one.

Missed dashboard service-level agreements (SLAs) from concurrent ad-hoc load is fundamentally a resource-contention problem, so the fix has to work at more than one layer: reduce how much compute each query needs, control how many queries compete for the same compute at once, and give critical dashboard queries priority over exploratory ones.

Warehouse sizing and workload isolation

Separate the warehouse or compute pool that serves dashboards from the one analysts run ad-hoc queries against, even if they read the same underlying tables. This is the single highest-leverage change: a runaway analyst query can no longer starve the dashboard's compute, because they are not sharing a resource pool. Size the dashboard-serving pool for its actual peak concurrent load, not its average.

Query queuing and prioritization

Within the ad-hoc pool, use the warehouse's workload-management or queueing feature to cap how many heavy queries run concurrently and to prioritize shorter, cheaper queries over long-running ones, so one large exploratory query does not block ten fast ones behind it.

Result caching

For the specific dashboard queries that repeat frequently with the same parameters, a result cache (warehouse-level or BI-tool-level) means the second and subsequent identical requests in a short window cost nothing, directly reducing concurrent load on the shared compute.

Sandboxes for exploratory work

Give analysts a genuinely separate, smaller compute environment for exploration (a personal or team-scoped virtual warehouse, or a sampled subset of the data) so their normal working pattern does not require touching the production dashboard pool at all.

Policy layer

The technical layers above only work if an explicit policy governs how they get used, and the policy half matters as much as the technical half:

• Prioritization rules: write down which query classes win contention by default (typically: scheduled dashboard-refresh queries outrank ad-hoc analyst queries), so the queueing/prioritization feature above is enforcing a real, agreed rule rather than an arbitrary default nobody chose.
• Sandbox access and quotas: define who gets a sandbox by default (all analysts, or by request), what compute and data it is scoped to, and a lightweight escalation path for a genuine one-off need to run something larger, so the sandbox is neither a rubber stamp nor a bottleneck.
• SLA ownership and monitoring: name an explicit owner for the dashboard SLA rather than leaving it to "the team," and define what breach threshold triggers action versus what is normal variance, so a slow week does not go unnoticed until users start complaining.
• Cost/chargeback visibility: make the isolated pools' cost visible to whoever owns the budget decision, so the isolation trade-off below (real infrastructure cost) stays a conscious, periodically revisited choice rather than a one-time provisioning decision nobody looks at again.

Trade-offs and pitfalls

Isolating pools adds real infrastructure and cost (you are provisioning compute you might otherwise have shared), and if the dashboard pool is sized too conservatively you have just moved the queueing problem from "analysts vs dashboards" to "dashboard queries queueing against each other" during a real traffic spike. Roll this out incrementally: separate pools first (the cheapest, highest-impact change), measure whether SLA breaches drop, and only add queueing/prioritization policy on top if contention remains within a single pool.