Senior Business Intelligence Analyst Interview Preparation Guide - FAANG Standards

Direct answer

The pyramid principle says to structure a data narrative top-down: state your main conclusion first, then the two or three arguments that support it, then the evidence beneath each argument, rather than building up to the conclusion the way you actually did the analysis. The closely related SCQA shape (Situation, Complication, Question, Answer) is a way to construct that top line: state the shared context, name what changed or went wrong, pose the question that creates, then answer it, with the Answer being the same headline the pyramid puts first.

Structured elaboration

1. Why top-down beats bottom-up for a busy decision-maker.
Analysis is naturally built bottom-up: you gather data, run tests, notice patterns, and arrive at a conclusion at the end of that process. But a decision-maker reading or hearing the result does not have time to retrace that path and does not need to; they need the conclusion first so they can decide how much of the supporting detail they actually want. Presenting bottom-up (data first, conclusion last) forces every reader to sit through the full derivation before learning the point, and it means anyone who stops reading after the first paragraph, which is common in a busy inbox or meeting, misses the actual finding.

2. The pyramid's three layers.
At the top: a single governing conclusion or recommendation, stated as a complete sentence, not a topic label ('Churn is a problem' is a topic; 'Churn among enterprise accounts rose 4 points last quarter and threatens renewal revenue, we recommend X' is a conclusion). In the middle: two to four supporting arguments, each one a reason the top conclusion is true, ideally grouped so they are mutually exclusive and collectively exhaustive of the case you're making, not an arbitrary list. At the base: the specific evidence, numbers, and analysis behind each supporting argument, which is where the detail-oriented reader or a skeptical stakeholder can drill in.

3. The SCQA framing for arriving at that top line.
Situation: state the shared, uncontested context ("Enterprise renewal rates have been stable around 92% for six quarters"). Complication: name what changed or what tension that creates ("This quarter renewal dropped to 88%, concentrated in accounts onboarded in the last year"). Question: the natural question the complication raises ("What's driving the drop, and can we intervene before renewal season peaks?"). Answer: your actual conclusion and recommendation, which becomes the pyramid's top line. SCQA is really a technique for constructing a compelling, honest top line; the pyramid is what you do with that top line once you have it.

4. Restructuring a bottom-up finding into this shape.
Take the order you actually worked in (data pull, exploratory checks, a few dead ends, the eventual pattern, the conclusion) and literally invert it for the write-up: conclusion first, then the two or three strongest reasons, then evidence for each reason. The dead ends and exploratory detours from your real process almost never belong in the final artifact at all; they belong in an appendix or nowhere, because the pyramid is a communication structure, not a lab notebook.

Worked example

An analyst investigates a support-ticket increase by pulling ticket volume by category, checking for a recent product release, cross-referencing with a signup cohort analysis, and eventually finding the pattern. Built bottom-up, the write-up would read: "We pulled ticket data for the last 90 days... we checked release notes... we then looked at signups by cohort... and found that tickets from users onboarded after the March release are 3x more likely to file a billing-related ticket." Restructured with the pyramid/SCQA shape: Situation/Answer-first: "Billing-related support tickets are up 40% quarter over quarter, driven almost entirely by users onboarded after the March release; we recommend a fix to the new billing confirmation step before the next release." Supporting arguments: (1) users onboarded after March file billing tickets at 3x the rate of earlier cohorts, (2) the March release changed the billing confirmation flow, (3) no other cohort or category shows a comparable increase, ruling out a general support-quality issue. Evidence for each argument follows beneath, in the same order, for the reader who wants to verify the claim rather than just act on it.

Trade-offs and pitfalls

• The most common mistake is writing the top line as a topic ("Q3 billing tickets") instead of a complete, decision-relevant sentence with a conclusion in it; a topic doesn't tell the reader anything they can act on.
• Forcing every supporting argument to be truly independent (mutually exclusive) takes real editing; a first draft often has 4-5 overlapping points that should collapse into 2-3 distinct ones.
• The pyramid structure is not a license to omit genuine uncertainty or counter-evidence; the top line should still be honest about confidence and limitations, not just punchy.
• Over-applying the framework to a finding that genuinely has no single clear conclusion (a mixed or inconclusive result) produces a false sense of clarity; in that case the honest top line states the ambiguity itself as the headline, rather than forcing a decisive-sounding conclusion the evidence doesn't support.

Direct answer

Before committing to a plan, spend the first days mapping every team your work actually depends on, get an explicit, dated commitment from each one on what they will deliver, and track those commitments in one visible place so a slip surfaces the moment it happens instead of at the deadline.

Structured elaboration

Map the dependency graph early, not incidentally

Run a short cross-functional session at kickoff specifically to list what you need from other teams: what, by when, and in what form. Treat this as a deliverable of the kickoff, not a side conversation that happens if someone remembers to ask.

Get commitments, not assumptions

"They know we need this" is not a commitment. A commitment has an owner, a date, and an explicit acceptance criterion, meaning what "done" looks like from your side, not just theirs. Ambiguous handoffs are where dependencies quietly slip.

Make status visible continuously, not just at standups

A shared dependency tracker, checked weekly at minimum, with a clear ready, at risk, or blocked status per item, turns a hidden slip into a visible one while there is still time to react.

If you are joining an initiative already in motion

The mapping happens differently. Your first days are spent finding out who currently owns each piece, which may not match the org chart or what the original plan assumed, and estimating the time-to-impact for each dependency, meaning how long before a slip there would actually hit your own critical path (the specific chain of dependent tasks whose delay would directly delay your own delivery date, unlike a dependency that has slack to spare), before you commit to a timeline of your own. Committing to a date before doing this is committing to someone else's assumptions.

Worked example

A project depends on three other teams: one providing a new data feed, one exposing an API endpoint, and one delivering a design system component. At kickoff, the team runs a short dependency-mapping session and gets each provider to commit to a specific date and a specific definition of ready, for the API that means a documented contract and a staging environment, not just "the code exists." These commitments go into a shared tracker with a status column, reviewed weekly.

In week two, the API team's status moves to at risk because their own upstream dependency slipped. Because the tracker surfaced this immediately rather than at the original deadline, there is still time to either help unblock the API team or replan the timeline around a slower path, instead of discovering the problem in the final week when no good options remain.

For the joining-in-progress case: an engineer joins a multi-team initiative already underway. In the first few days, instead of accepting the existing plan at face value, they interview each team named in the plan to confirm who currently owns each dependency, since ownership has quietly shifted since the plan was written, and estimate the time-to-impact of each one: the API dependency would only hurt the timeline if it slipped more than two weeks, while the data-feed dependency has almost no buffer at all. Only after that mapping do they commit to a delivery date of their own, rather than inheriting the original plan's assumptions unchecked.

Trade-offs and pitfalls

A heavy dependency-tracking process on a small, low-risk project wastes more time than it saves; scale the rigor to the size and risk of the dependency rather than applying it uniformly everywhere.

The most common failure is treating the mapping as a one-time kickoff exercise instead of a living tracker. A dependency list that is accurate on day one and never updated again is exactly as useless as never having made one, because the whole point is catching drift as it happens.

Sub-second interactive filtering over a billions-of-rows fact table is achievable only by moving most of the query cost off the hot path, so the design question is really which levers you combine and in what order you try them for an existing slow dashboard, not any single silver-bullet technique.

The available levers

• Materialized views or rollups at multiple granularities: pre-compute the aggregations most filters actually need (daily, weekly, by top dimension combinations) so an interactive filter change reads a small pre-aggregated table instead of scanning the fact table fresh each time.
• An online-analytical-processing (OLAP) cube pre-aggregation layer: a more structured, exhaustive version of the same idea, pre-computing aggregates across many dimension combinations at once so a wide range of ad-hoc filter combinations can be served without a bespoke rollup for each one, at the cost of higher storage and refresh complexity than a handful of targeted rollups.
• Result or dashboard-layer caching: for the specific filter combinations users repeat often (a default view, a popular segment), caching avoids recomputation entirely for the second and later requests.
• Approximate aggregation for the heaviest metrics: for the small number of metrics that remain expensive even after pre-aggregation (a high-cardinality distinct count, for example), an approximate technique trades a small, bounded error for a large cost reduction.

Trade-offs of combining them

More pre-aggregation and more caching both trade storage and refresh complexity for query speed; the OLAP-cube approach in particular can multiply storage substantially if it pre-computes many dimension combinations that turn out to be rarely queried, so it is worth auditing actual filter usage before committing to a full cube versus a handful of targeted rollups matching the filters people actually use. Caching adds staleness risk on top of whatever staleness the underlying rollup already has. Approximate aggregation is the narrowest tool, appropriate only for the specific metrics where exactness is not actually required by the business.

Prioritizing for an existing slow dashboard

Start by checking whether the current queries hit the fact table directly with no pre-aggregation at all; if so, a small number of targeted rollups matching the dashboard's actual filter patterns is almost always the highest-leverage first step, cheaper to build and reason about than a full cube. Add caching next for the specific filter combinations traffic data shows are repeated most. Reach for a full OLAP cube or approximate techniques only once targeted rollups and caching are in place and specific remaining metrics are still too slow, since both add meaningfully more operational complexity than the first two levers.

Pitfalls

A design that pre-aggregates everything up front, before knowing actual usage patterns, routinely wastes storage and refresh budget on combinations nobody queries while still missing the specific pattern a real user actually needs; instrument the dashboard's real filter usage first, and let that data drive which rollups and cache entries are worth building.

Direct answer

Move to a dedicated warehouse when ad-hoc analytical queries start measurably hurting the production database's transactional performance, when the same numbers are being computed slightly differently in different spreadsheets, or when reporting needs data joined across sources the production database does not have (a payments processor, a support tool, a marketing platform). Start with the simplest useful version: a small set of tables that are periodically copied out of production into a separate database or a managed cloud warehouse, denormalized just enough to answer the handful of reports people actually run today, not a fully modeled Kimball bus architecture with conformed dimensions across every future business process.

Structured elaboration

Signal one: production impact. A heavy analytical query (a full table scan for a monthly report, say) run directly against the database serving live user traffic can degrade transactional latency for real users; if analysts are being asked to "only run reports at night" or engineers are seeing production incidents traced to a report someone ran, that is a concrete, observable signal, not a vague sense that things feel slow.

Signal two: inconsistent numbers. Once more than one person is computing the same metric independently (one analyst's spreadsheet formula, another's ad-hoc query), small differences in filtering or date handling silently produce different answers to "what was our revenue last month," and nobody notices until two answers are compared in the same meeting. This is the earliest, cheapest form of the exact conformance problem later covered by dimension conflicts across marts; catching it before it compounds is far cheaper than the reconciliation project.

Signal three: joining across sources. Once a report needs to combine production order data with a separate support tool's ticket data and a third-party payment processor's transaction data, there is no single production database to query against anymore; some place has to receive copies of all three and let them be joined together, which is the core job a warehouse exists to do.

The simplest version to build first. Do not start with a full dimensional model. Start with a small, straightforward extract-and-load process (even a scheduled job that copies a handful of production tables into a separate database or a managed cloud warehouse on a nightly cadence) and let analysts query those copies directly, denormalized or lightly modeled, for exactly the reports people already run. Introduce actual dimensional modeling (declared grain, a real date dimension, slowly-changing-dimension handling) only once a second or third report reveals that ungoverned ad-hoc structure is producing inconsistent answers or is too slow to maintain by hand, which is the point at which the methodology and system-design questions the rest of this topic covers actually become relevant.

Worked example

A single unindexed analytical query scanning a 10-million-row production orders table for a monthly report can hold a lock or consume enough I/O bandwidth to add hundreds of milliseconds to unrelated transactional queries hitting the same table concurrently; at a company processing customer-facing checkout requests against that same table, a delay large enough for customers to notice during checkout is the concrete, business-visible cost of skipping a warehouse, not an abstract inefficiency. That single observation, "a report degraded checkout latency," is usually the moment a 20-person startup's engineering leadership actually approves the investment, well before any of the modeling-methodology questions in this topic become the operative concern.

Trade-offs and pitfalls

The most common mistake at this stage is over-building: reaching for a full Kimball-style bus architecture, multiple conformed dimensions, and Type 2 slowly changing dimension (SCD) history tracking before there is more than one or two reports that need any of it wastes engineering effort the startup does not have to spare, and most of that early investment will be redesigned anyway once real reporting needs are better understood. The opposite mistake, waiting until the production database is visibly struggling before doing anything, is also common and more expensive to unwind, since by then inconsistent numbers have usually already reached several audiences and eroded trust in whichever spreadsheet or dashboard people were relying on.

Direct answer
A stretch assignment only works as a growth tool if it's picked deliberately (real stakes, but survivable if it goes wrong), supported actively rather than handed off and hoped for, and evaluated by whether the person can now do something they genuinely couldn't before, not just whether the project shipped.

Picking the assignment

• Look for the specific gap between where someone is and where they want to go, and pick something that exercises exactly that gap: not a bigger version of what they already do well, but the thing they haven't had to do yet (leading ambiguity, owning a stakeholder relationship, making a judgment call without a clear right answer).
• Sanity-check the blast radius: a good stretch assignment has real consequences if it goes wrong, but not consequences the team or the person can't absorb. If failure would be catastrophic, it's not a stretch assignment, it's a bet you shouldn't be making on someone's first attempt.

Supporting through it

• Set explicit checkpoints rather than open-ended availability; someone stretching is often reluctant to ask for help exactly when they need it most, because asking feels like it undercuts the point of the assignment.
• Watch actively for the failure mode where the person becomes overwhelmed or delivery risk climbs mid-assignment. The fix isn't to quietly take it back (that undoes the growth and teaches them stretch assignments are a trap), it's to scope down the ask while keeping ownership intact: shrink the surface area, extend the timeline, or bring in narrow support on the hardest sub-piece, while the person still owns the outcome.

Knowing it worked

• The real signal isn't whether the deliverable shipped; plenty of stretch assignments succeed despite the person, propped up by others. The signal is whether they can now do a similar thing again with meaningfully less support than before.
• Ask them directly what they'd do differently next time; someone who's actually grown from it usually has a specific, concrete answer, not a vague "it was good experience."

Variants worth having ready

• Succession-driven: when someone owning a critical piece of the system is leaving, a stretch assignment can double as a deliberate handoff, usually spread across two or three people rather than one, so the knowledge doesn't just move from one single point of failure to another.
• Developing a mentor, not just a mentee: a technically strong senior who's never mentored can be given a stretch assignment that's explicitly about teaching, not delivery, such as owning a junior's ramp-up plan with the growth of the junior, not the speed of the project, as the success measure.

Worked example
A strong individual contributor wanted to grow into leading larger, more ambiguous work but had only ever executed against fully-scoped tasks. Rather than a bigger version of the same kind of work, the assignment was to own a smaller, genuinely under-scoped project end to end: figure out the actual requirements from a vague ask, make the technical calls, and report progress upward directly instead of through a lead. Support looked like a standing short weekly check-in (not daily oversight) and an explicit agreement that they'd flag it early if they felt stuck, rather than waiting until a deadline made the risk visible.

Partway through, the scope turned out to be bigger than either of us expected, and the person started showing the classic overwhelmed signs: shrinking updates, slipping the weekly check-in. Rather than pulling the project back, the assignment was rescoped down to the highest-value piece, with the harder edge case handed to someone else, while they kept ownership of the core decision and the delivery. They finished a smaller version of the original ask, and more importantly, on the next ambiguous piece of work a few months later, they scoped it themselves without needing the same weekly check-in structure. That second instance, done with much less support, was the actual evidence the stretch assignment had worked, not the fact that the first project shipped.

Trade-offs and pitfalls

• Picking a stretch assignment that's really just "more of the same, but bigger" doesn't build a new skill; it just tests stamina.
• Quietly rescuing someone the moment they look overwhelmed (taking the assignment back rather than rescoping it) protects the deliverable but teaches the person that stretching is unsafe, which discourages them from taking the next one.
• Measuring success by whether the deliverable shipped, rather than by what the person can now do independently, rewards you propping the project up rather than the person actually growing.

Direct answer

Treat this as a same-day, direct conversation, not something to quietly slow-walk or silently comply with. Name specifically what is being asked in plain terms, say why you are not comfortable doing it that way, and offer a version that serves the same underlying need, looking prepared, without misrepresenting the number.

Structured elaboration

1. Get precise about the actual request before reacting. Ask your manager exactly what change they want and why. Sometimes make it look better turns out to mean a clearer framing or more context, and sometimes it genuinely is a request to misrepresent, you need to know which before you respond.
2. If it is a request to misrepresent, say so directly but without accusation, name what you are being asked to do and state plainly that you are not comfortable presenting it that way. This is a today conversation, not something to defer until after the meeting.
3. Offer an alternative that meets the real underlying need. Most requests like this come from wanting to avoid looking bad in front of a specific audience, not from actually wanting to lie. An honest number paired with context, what caused the change, what is already improving, what the plan is, often serves that need better than a fudged number would if anyone ever checks it.
4. If your manager pushes back and insists, escalate the same day rather than letting it sit, to your manager's manager or whoever owns reporting integrity, stating the facts of the request and the alternative you already proposed.
5. Document what was asked and what you did, in writing, at the time, not reconstructed later if this becomes a bigger issue.
6. Keep the relationship with your manager intact by keeping the conversation about the specific ask, not their character. Most people who make a request like this under pressure are not asking for something they would defend if asked about it directly later.

Worked example

A manager asks you, a few hours before a leadership review, to present a metric excluding a recent dip so it doesn't spook the room. You ask exactly what they mean and confirm it would mean showing a number that does not reflect what actually happened. You tell them directly you are not comfortable presenting it that way, and offer to show the real number with one slide of context, what caused it and what is already being done about it, so the room gets the full picture instead of a partial one. Your manager pushes back once, you hold the position and offer to walk them through the context slide first so they are not surprised in the room. They agree to the honest version.

Trade-offs and pitfalls

Refusing without offering an alternative can read as unhelpful or self-righteous in the moment. Pairing the refusal with a real alternative that solves your manager's actual problem is what keeps the relationship workable afterward.
Escalating too fast, before even asking your manager what they meant, can turn a misunderstanding into a formal incident unnecessarily. Confirm the actual ask first.
If the pressure repeats after you have held the line once, a single principled stand does not fix a pattern. At that point the conversation needs to become about the pattern itself, possibly with someone above your manager involved, not just the metric in front of you that day.

Direct answer. Measurement error in a confounder or the treatment adds noise that generally biases a causal effect estimate toward zero (attenuation bias) when the error is classical (random, unrelated to the true value), but can bias the estimate in either direction, and in unpredictable ways, when the error is systematic (correlated with the true value or with other variables in the model).

Structured elaboration. Classical measurement error means the observed value equals the true value plus independent random noise; when this happens in the TREATMENT variable, the estimated coefficient on treatment is attenuated (pulled toward zero) in a mathematically predictable way, because the noisy treatment variable is a weaker proxy for the true treatment than the true treatment itself would be. When measurement error occurs in a CONFOUNDER instead, the confounder is only partially "controlled for" (the adjustment is diluted by the noise), leaving RESIDUAL confounding in the treatment estimate even after nominally controlling for it, which can bias the treatment effect estimate in either direction depending on the confounder's true relationship with treatment and outcome. Systematic measurement error, where the error itself correlates with the true value or with something else in the model (a device that consistently under-reports for heavy users, say), doesn't follow the clean "attenuation toward zero" pattern at all, and can inflate, deflate, or even flip the sign of an estimate.

Mitigation approaches.

1. Validation data: if a subset of observations has both the noisy and a "gold standard" accurate measurement, that subset can be used to estimate and correct for the measurement error's structure (a validation or calibration study).
2. Instrumental variable for the mismeasured variable: an instrument correlated with the TRUE value of the mismeasured variable but uncorrelated with the measurement error itself can recover a consistent estimate, using the same 2SLS logic as ordinary IV estimation.
3. Regression calibration: model the relationship between the noisy proxy and the true value (using external or partial validation data) and use the predicted "de-noised" value in place of the raw noisy measurement in the main analysis.

Worked example. Ad click tracking on iOS undercounts clicks due to known tracking loss (attribution restrictions), and the undercounting rate isn't uniform, it's worse for privacy-conscious users, who may also differ systematically in purchase behavior. This is closer to systematic than purely classical error, which means a simple "the estimate is probably attenuated, so the true effect is somewhat larger" adjustment isn't safely applicable; the more defensible response is either validation data (comparing tracked clicks to a platform-reported ground truth for a subsample) or an alternative measurement channel less affected by the same tracking loss.

Trade-offs and pitfalls. The comforting rule "measurement error just attenuates toward zero, so my true effect is probably even bigger" only applies cleanly to classical error in the treatment variable; applying that same comforting logic to systematic error, or to measurement error in a confounder, is a common and consequential overreach.

Approach (how to implement)

• Add Country → State → City filters on the worksheet or dashboard.
• For each filter card set “Only Relevant Values” (right-click filter → Apply to Worksheets → Selected Worksheets, then show only relevant values) so selecting Country limits State, and selecting State limits City.
• Alternatively, for more control use Parameters + parameter actions: populate a Country parameter, when selected update a State parameter’s domain via a calculated field or a distinct query and use that to filter City (useful when you need to persist choices or support URL-driven sharing).

Handling large-cardinality fields and performance

• Put high-cardinality filters (City) into Context only when they must pre-filter many joins; context filters create a temporary table and can speed downstream filters but are expensive to build—use sparingly.
• Use extracts (Hyper) with incremental refresh so quick filters run against optimized columnar data.
• Push filtering to the database: use custom SQL or initial extracts that pre-aggregate or include only necessary columns; rely on live connections only if the DB can handle predicate pushdown.
• Avoid showing full quick-filter lists for millions of members—that causes long load times.

UX for long lists

• Use search box (show filter → Single Value/Multiple Values dropdown with search) and enable typeahead.
• Provide hierarchical picker UI (country→state→city) and default to “All” for each level to avoid forcing choices.
• Offer “Top N” or “Most Recent” quick filters, or aviz initial drilldown: show only Country and State; reveal City after State selected.
• Display counts or applied filter badges so users understand the scope.
• Provide clear reset buttons and tooltips explaining large-list behavior.

Example: use "Only Relevant Values" for quick implementation; if City >100k members, switch to parameter-based lookup backed by a small distinct query or a server-side endpoint that returns matching cities as the user types to keep performance and user experience responsive.

Direct answer

Treat "engagement" as a symptom, not a metric: run a short discovery to find the actual decision the stakeholder needs to make, translate that decision into two or three concrete metrics with explicit formulas, and validate each one by showing the stakeholder what action it would trigger before it ever ships to a dashboard. The quantified version of this request ("grow engagement 10%") makes the ambiguity worse, not better, until the target itself is pinned down.

Structured elaboration

Step 1: Clarify the decision, not the word. Ask what the stakeholder would do differently if the number went up versus down, over what time horizon, for which user segment, and at what granularity. "Engagement" said by a growth lead usually means retention risk; said by a content team it usually means session value; said by a monetization team it often means feature adoption tied to revenue. The word alone does not tell you which.

Step 2: Translate to metrics with explicit formulas.

• Active rate: daily active users over monthly active users (DAU/MAU), computed as distinct users in a 24-hour window divided by distinct users in the trailing 30-day window, by cohort and platform. Signals habitual use; a low value points to retention work.
• Median session value: session duration and sessions per user per week. Signals whether the product is pulling people back in; a falling trend points to a content or UX investigation.
• Feature conversion funnel: view to click to complete for a target feature, with drop-off percentage at each step. Points directly at where to intervene: messaging, UX, or the feature itself.

Step 3: Validate against the ambiguous target itself. If the ask came with a number ("grow engagement 10%"), that number is often as underspecified as the word. Before building anything, confirm what "10%" is relative to, because a relative-growth reading and an absolute-percentage-point reading of the same instruction produce very different targets (worked below), and shipping the wrong one wastes a quarter.

Step 4: Prototype and walk through with the stakeholder. Build a mock dashboard with real sample data and ask: "if this metric moved from X to Y, what would you do?" If the stakeholder cannot answer, the metric is not actionable yet and needs another iteration. Capture a threshold, an owner, and a review cadence for each metric before calling the translation done.

Worked example

Suppose the baseline active rate (DAU/MAU) is 0.35, and the stakeholder asks for "10% more engagement" without saying what that 10% is measured against. Two honest readings of the same instruction:

$\text{Relative reading: } 0.35 \times 1.10 = 0.385$
$\text{Absolute reading: } 0.35 + 0.10 = 0.45$

The relative reading targets an active rate of 38.5%, a modest lift. The absolute reading targets 45%, which is a 10-percentage-point jump, nearly 29% relative growth over the same baseline:

$\frac{0.45 - 0.35}{0.35} \approx 0.286$

Those two targets imply very different roadmaps: the first is achievable with incremental funnel fixes, the second likely requires a structural change to the product's habit loop. This is exactly why step 3 above exists: the quantified ask does not remove the ambiguity, it just moves it one level deeper, into what the percentage is a percentage of.

Trade-offs & pitfalls

The main failure mode is skipping straight to a metric because it is easy to compute (total sessions, total time-in-app) rather than one that maps to a decision; that produces a dashboard nobody acts on. A second failure mode is over-fitting the translation to whichever stakeholder is loudest, producing a metric set that serves one team's decision but not the actual business question. Watch for gameable proxies too: session duration can be inflated by confusing navigation, and a feature-funnel completion rate can be inflated by making the "complete" step trivially easy. The fix in both cases is pairing the primary metric with a guardrail (task success rate, support-ticket rate) so an intervention that juices the number without creating real value gets caught.

Direct answer
Maintain a versioned library of shared visualization components (color palettes, KPI-tile templates, chart-type wrappers) with clear governance and discoverability, so every team builds on the same visual language instead of re-inventing (and subtly diverging from) it dashboard by dashboard.

Structured elaboration

1. Component scope: shared color palettes (sequential, diverging, categorical, all pre-validated for accessibility), KPI-tile and chart-type templates with consistent styling, and (if building custom visuals) a documented component API (props for title, data, annotations).
2. Governance: a small owning team reviews and approves new components or changes to existing ones, so the shared library doesn't fragment into competing versions.
3. Versioning: semantic versioning (a version number like 2.4.1, where the first number only changes for a breaking change, the second for a backward-compatible addition, and the third for a bug fix) so consuming dashboards can pin to a known-good version and upgrade deliberately rather than being broken by an unannounced change.
4. Discoverability: a documented, searchable catalog (with visual previews) so teams can find and reuse an existing component instead of building a near-duplicate.
5. Backward compatibility: deprecate old component versions with a clear migration path and sunset timeline rather than breaking consuming dashboards outright.
6. Testing: visual regression tests (does the component still render as expected) and accessibility tests (contrast, keyboard navigation) run on every component change before it's published.

Worked example
A shared "KPI tile" component with a documented API (value, trend, target, threshold-color props) is adopted across 40 dashboards; when the design team updates the palette for accessibility, every consuming dashboard picks up the improvement automatically on its next version bump, rather than 40 teams needing to independently update their own copy-pasted styling.

Trade-offs and pitfalls
A shared component library that isn't actively governed tends to drift into inconsistent forks anyway, as teams patch their local copy rather than contributing back; investing in a lightweight but real review/approval process is what actually prevents the fragmentation the library was built to solve.